TrueBrain

Not meant to hijack this thread, but I am curious enough: can you link where you would have read this? Assuming you meant OpenTTD, and not the OpenTT project ;)

We slowed down a bit ... but we are not dead yet :D Today we released 0.4 of OpenDUNE, the next version in our ongoing C-ification of Dune2. Please see http://www.opendune.org for more details and download locations.

It is mostly MrFlibble's job, but I want to beat him to it: http://forum.opendune.org/viewtopic.php?f=9&p=277 Crossposting. Mostly because I wonder what you guys think. Basically, when you now attack a structure of the enemy in OpenDUNE, they massively hunt you down. By all means it seems the intended behaviour. Patching Dune2 should be easy enough, if there is room for it (byte-wise). In 1423:0EAE (no clue where this maps in the executable), it reads: xor ax, ax push ax push si xor ax, ax xor dx, dx push ax push dx <call function in 0x0FE4> (Unit_FindFirst) The first line (xor ax, ax) should be: mov ax, 0xFFFF. For those who don't like to read the link above: Dune2 scans all units of the house of the structure that got attacked (if non-human of course), and puts them in HUNTING mode when they were in AREA_GUARD mode. But due to the above glitch, it only searches for Carry-alls, instead of all units (0 vs 0xFFFF). This seems an innocent glitch, with huge change in gameplay.

LOL! You are insane :D In a very positive way :) I noticed before that the Dune2 demos feel more complete .. would be nice to see if the game can be made playable .. insanity++ ;)

As every 3 months, a bump to this topic: Today we released 0.3 of OpenDUNE, the next version in our ongoing C-ification of Dune2. Please see http://www.opendune.org for more details and download locations.

Most likely :) I guess they couldn't get it to work correct, or had to cut on diskspace .. who knows what the reason was for removing those sound-drivers (hardcoded).

Digging up old topics. First, a small introduction. The next list shows which number matches which music driver (the number is in the dune.cfg, after decoding it): 0: NULL (NULL) 1: ALFX.DRV (ADL) 2: PCSOUND.DRV (PCS) 3: PCSOUND.DRV (PCS) 4: PCSPKR.ADV (PCS) 5: TANDY.ADV (TAN) 6: MT32MPU.ADV (XMI) 7: MT32MPU.ADV (C55) 8: ADLIB.ADV (ADL) 9: ADLIBG.ADV (ADL) 10: PASFM.ADV (ADL) 11: SBFM.ADV (ADL) 12: SBP1FM.ADV (ADL) 13: SBP2FM.ADV (ADL) The name between () is the extension used. Dune2 1.07eu HARDCODED ignores drivers 8 till 12, and sets it to 1. I guess you can still use 13, but this is most likely a bug, and it was not intended to be used. So I guess that is also the reason the drivers are nowhere to be found :)

In 1.07 EU I can find no trace of UnitInfo+3A (your unknown 031) ever being used. Neither is UnitInfo+38 for that matter. Are you sure it has any effect in 1.07 EU? Else I need to see if there are indirect references to the variables (good possible, but takes more effort to find ;)).

Hmm, yes, I guess. It is used twice, once for the target priority stuff we talked about before (the higher that value, the more priority a target has), and once in a function which selects what to build next. It goes a bit like this: Set in a bit-variable what units can be build If structure == STRUCTURE_HIGH_TECH, don't build carry-all if we already have one If structure == STRUCTURE_HEAVY_VEHICLE, don't build harvester if we already have one Loop all unit types, if unit type is allowed by above, there is a 75% chance to continue If 'Unknown 023' (or rather: UnitInfo+2D) is higher than last one, set this as new one Return highest (and this is the one that will be build) PS: For the construction yard something similar happens, but it picks a random structure from the 'just destroyed' buffer that is stored for each House.

I think you are out of luck with those. As for all those bits, all I can say: unused in 1.07 EU :P Variable 36 (Unknown 028 + Unknown 029): Bit usage: 1 - Not used (028, bit 1) 3 - Not used (028, bit 3) 9 - Not used (029, bit 1) 10 - Not used (029, bit 2) All the other 12 bits are used. Well .. maybe those unuseds are used in parts never run while analyzing Dune2, but OpenDUNE runs without ever reading (or writing) those bits. And then there is this very small maybe it is hiding by some weird construction, and they are used after all. But at this stage, I strongly doubt that ;)

And carry-alls ;)

Yup! Flag 16. It is nowhere used. Never ever. If I look at the maps the flag is on for, I can only speculate to the intended meaning. Maybe it was the idea to have all the enemy units destroyed too? I don't know .. any clues in the dialogues about other goals?

Every scenario currently has a 'TimeOut=0' value in them :) I can only guess that was the intention of the field .. now if only someone could get their head around the original idea of this ;) Then fixing should be relative easy, it seems not to require that many bits (and because there are a few debug-statements in those functions, enough bytes free :) Oh yeah, I forgot to mention: this seems to be the only function which still contains debug functions. It prints things like: Forced end. Destroy end. Etc.

I don't really get what you mean by this? Credit Quota means that if flag 4 is set, and the player reaches an amount of credits, the goal is reached. TimeOut means that if flag 8 is set, and the player plays for N time, the goal is reached (depending on LoseFlag this can be a good thing. Survive N minutes is possible). The problem with the whole Timeout stuff is: it is partly done (as bluehappybyte already states). The TimeOut value is, as the Quota value, stored in the House information, but never moved to the global variable where it is expected. So all I can tell is that the value always remains 0. I guess it is easy to resolve this issue. One other thing that really doesn't make sense to me: the check to see if the level ends with the timeout, looks like this (pseudo-code): if currentTime < variable: level-ends This doesn't make sense. I can't give any meaning to the 'variable' value which would make sense in this situation. It really feels like they made a bug here, and never fixed it or what ever. Btw, if we would fix both problems, you could even make a 'survive' map, where you have to hold out for N minutes :)

Ah, now I get you. Yes, for a while I had the bit flipped. And the variable in OpenDUNE needs a better naming ;) I now also understand what you mean with 'force full script cycle' ;) Tnx!

I have no clue what you/he means with "forcing full script cycles", but the code says to me: if the bit is NOT enabled and unit is OUTSIDE the viewport, run 2 instructions per tick. Else, run a bunch more. I think it is created to reduce the amount of script instructions required to run the game, and then this makes a lots of sense :)

I couldn't find any reference that this was indeed figured out. So I just wanted to let you know. Sorry to dig up this old topic, I hope that is okay. First of all, those are bit-fields. Their meaning (same for both): 1 -> Enemy has no buildings 2 -> You have no buildings 4 -> You reached credit quota 8 -> You reached time limit That was the easy part. The scenarios also tempt to use 16 as flag, but that seems never used. Now, the meaning of those 2 flags. First, forget about the name, they are very misleading. What they mean: WinFlags -> Conditions to be met for the game to end (win or lose!). LoseFlags -> Conditions to be met to win the game. So, if we take any campaign 2 level (when using MrFlibbles scenario.pak, else one of the Atreides campaigns is broken): WinFlags -> 7 LoseFlags -> 5 So the game ends if: you have no buildings, the enemy has no buildings, or you reached the credit quota. You will win the level if: the enemy has no buildings, or you reached the credit quota. You will lose the level if: you have no buildings. (derived from disabling the bits in WinFlags that are active in LoseFlags). And that is all there is to it. So the names are very misleading, but the result is very simple (and efficient). (source: http://forum.opendune.org/viewtopic.php?f=13&t=41 )

Figuring out bit-flags is fun, so lets continue a bit, in reversed order, for Units: Bit 8000 - Unused. Bit 4000 - Unused. Bit 2000 - Priority; talked about above. Bit 1000 - Target Air Units; when set, units can target air units. Note: it only affects auto-targeting Bit 0800 - Script Slowdown; when NOT set and a unit is outside the viewport, it only runs 2 instructions per tick of script. Normally it is a multiple of 5 (and depends on a few settings) Bit 0400 - Tab Selectable; when set, the unit will be selected when cycling units by pressing tab in-game. Bit 0200 - No Message On Death; when set, you will not read "<<House>> unit is destroyed" for this unit type. Bit 0100 - ??; something to do with a script command. A bit hard to trace at this moment. Bit 0080 - ??; something to do with a script command. A bit hard to trace at this moment. So, there .. 7 out of the 16 bits identified :) After this it gets a bit tricky, as it is hard to differ between UnitInfo and StructureInfo. StructureInfo only has 7 bits in use, so up till now it were only UnitInfo properties. Oh well .. the other bits will reveal themselves in time :) PS: above is for 1.07 EU version btw :)

Follow-up: The function it is used in, is what we now called Unit_GetTargetPriority(). It only works on units (so turrets are not affected by the bit flag). When the flag is not set, a target get the lowest priority: 0. Some other 'fun' facts: When you are outside the map, you can shoot at things inside the map. When you are inside the map, you cannot shoot outside the map. So make sure your ornitopther stays outside of the map, and you will be fine ;) The function does not check the target range of the unit (when inside the map). So something can get priority before it is inside the fire range. Priority is divided by distance between you and the target before returned. So something that is closer has more priority. 1.0 most likely didn't had this check at all, and that they added it for some reason. Maybe enabled it for all units, because it was never finished? Or maybe it was part of rebalancing, but it turned out to make things worse. Something in those lines I guess :) All I can see code-wise so far, is that air-units have to be inside the FoW for the player. AIs shoot at it in all cases :) The priority function also returns values for airunits, for both AI and human players. Maybe something else filters it .. will found out when climbing up this tree of function calls :) So you want us to skip the fun part, and go play dead immediately? Part of our fun is figuring things out, and that keeps us alive. If we would skip that and only had to do the boring work of C-ifying everything, while already knowing what it all does and how it works ..... then this project would be dead very quick. Either way, lets agree to disagree on this topic, and drop it. You won't change our minds, as we strongly believe this approach is sane. You can disagree, in that you are free. So if we agree to disagree, we can do useful stuff, like figuring out flags :)

As promised, I spend a bit of time tracing the bit you talked about (it is 0x2000 in variable_0C in the case of OpenDUNE btw). It turns out there was only one instance where it was used, so that was easy :) (I love that we can just search in the source :)) When a unit wants to auto-target something, it calls a function which checks if the other unit is an enemy, if it is in range, stuff like that. One of those checks is if that bit you talked about is active for the unit it wants to target. If it is, the unit will be targeted. If it is not, it will be skipped. So, if you disable this bit for all units, you will see that your units no longer attack any enemy units, unless you explicitly order them. (or at least, it looks that way from what I can tell so far :P It is in a function we haven't named yet, but a few debug lines showed that it is used as I just described). Two observations here: 1) Units can still target structures. 2) I have no idea if this also holds for turrets wanting to target a unit. I guess you will have to try to figure that out ;) As for a name of the bit, I have no good suggestions at the moment, except: 'auto-targetable'. Let me know if your observations show something similar :) PS: Xaroth, it should be: "as long as I can learn and have fun!" Fun is more important ;)

As I said above: I will get back to you in a few months. For now, my approach is much better, for the reasons above :) Tnx anyway.

And I was asking how it was defined ;) But Nyerguds answered nicely ;) I will see tomorrow if I can find what that bit does :) Tnx! Please read my pre-last post :) I explain why we don't, and won't :) Independent research is always better. If we are done, we match up and see where we differ :)

Yes, but what does it mean? Does Unknown 006 point to the 6th variable in the struct or the 6th byte? I am not familiar with what syntax is used :)

If you put the files in another PAK, they should not be loaded. Dune2 is very picky where a file should be, and if it is not where it expects it to be, it doesn't load it. Either way, I see no logic reason why the fact it is loaded in the EMS/XMS could cause such problems. The code looks clean and bug-free, as far as I can tell. Maybe it makes some assumption on its location .. dunno. We will see when we get to the Mentat stuff, but I am afraid it will remain a mystery ;) For sure it will work in OpenDUNE btw. What is Unknown 006 (bit 6)? (I never used the editor, and most likely never will ;) It will only bias me while converting. When I would have known you guys thought the above mentioned flag did what you think it would do, it would have taken me much longer to understand the code :P). Check: http://svn.opendune.org/trunk/src/unit.h?mode=view#filecontent Under 'UnitInfo'. This should match the data you talk about. Or at least I hope that the mapping from the disk to this struct is one-on-one. Either way, that file documents what we think the variables do (and for those without '??', we are pretty sure). If you have any specific questions, let me know :)

That I tried to say: yes :) Else voices can never work. (if you have no XMS/EMS, voices are never loaded. It doesn't fit in the normal memory). So all code is intact, just disabled for PAK usage. That is indeed odd. What is the name of such file? (haven't touched any Mentat code yet ;))