Dune II editor with 1.07 support

[Xaroth]

So? I guarantee you he'll find the entire scope of the worm ripple effect a LOT faster if he can trace it from the bit that actually CAUSES it. Which, imo, IS a valid origin point to start a trace from. You can always trace in 2 directions, and see where it links back into known code.

It's just, the way he does it, he'll never get the remake finished ::)

A wise man once said, it's not about reaching the destination, but the journey experienced...

I'm content with the knowledge that this project might take years to complete, or maybe not ever.. I don't care about that, as long as I can learn during the process.

[TrueBrain]

(..)

Oh, and maybe you would be able to shed some light on the Unknown 006 (bit 6) option in the units section? It's turned on in v1.07 for units, and turned off for everything in v1.0. I wonder what it could be for. Maybe other unknowns could be also explained as well? :) (Just asking ;D)

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 ;)

[Nyerguds]

So a unit on which this is enabled can just walk into your base unhindered?

Hehe, scary. Maybe it was for the Saboteur?

PS: Xaroth, it should be: "as long as I can learn and have fun!" Fun is more important ;)

See, that's my point, actually. A lot of this kind of projects drop dead when the people doing it stop having fun doing it. And I guarantee you there will be boring parts. Once you just have to repeat 10 times what you already did once, the "new and exciting" factor fades pretty quickly.

[MrFlibble]

More curiously, this bit is turned off for everything in v1.0, meaning that there was a different logic in that version, just like turning on the "Can target air units" doesn't have any effect in v1.0. Speaking of which, is there an explanation of why only computer-owned Troopers and Launchers auto-target air units, while player-owned ones don't?

[TrueBrain]

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.

More curiously, this bit is turned off for everything in v1.0, meaning that there was a different logic in that version, just like turning on the "Can target air units" doesn't have any effect in v1.0. Speaking of which, is there an explanation of why only computer-owned Troopers and Launchers auto-target air units, while player-owned ones don't?

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 :)

(..)

See, that's my point, actually. A lot of this kind of projects drop dead when the people doing it stop having fun doing it. And I guarantee you there will be boring parts. Once you just have to repeat 10 times what you already did once, the "new and exciting" factor fades pretty quickly.

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 :)

[Nyerguds]

lol, sure.

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 :)

On that note, do you have any info on the "thopter revealing large spots of terrain" thing? It only does that as long as the enemy base isn't found (or no enemies are found at all, not sure).

[TrueBrain]

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 :)

[Nyerguds]

Yeah, the scripts thing at bit 0100 was figured out by testing it, but I think you won't find that in the exe itself since it's probably linked to those external script files. The effect of the bit is that if you got a repair facility, this unit will get picked up by a carryall for repairs. Someone even fixed this script so it brings the unit back to where it was picked up (without you having to block the repair bay for that to happen).

Not a clue about the other script thing though, but it's good to know we probably have to look in the direction of unit behaviour and interaction when researching that one.

Thanks for the info on the rest though... didn't know about the tab thing. I wonder if I can make that select 'thopters :D

Segra's descriptions said that the outside the viewport thing worked the other way around though. He described the bit as forcing full script cycles outside the viewport. This seems to match the fact it's disabled for pretty much all units except for the weapons and air units. The only exceptions being the Harvester and saboteur, which do have it enabled.

[TrueBrain]

(..)

Segra's descriptions said that the outside the viewport thing worked the other way around though. He described the bit as forcing full script cycles outside the viewport. This seems to match the fact it's disabled for pretty much all units except for the weapons and air units. The only exceptions being the Harvester and saboteur, which do have it enabled.

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 :)

[Nyerguds]

Yes, this is the thing that causes the bug that if you follow your units when making them attack, they arrive at their destination about twice as fast. It's a way for the game to say "units the player isn't looking at aren't really important, give them less cycles."

So you might want to enable this bit for all units in OpenDune ;)

Unknown6 bit3 seems to be 'ForceScriptCycles', it controls the number of script executions that occur during the units processing turn

If its set to 0, the unit is checked to see if its inside the 'user screen area', if so it uses the standard amount, otherwise it only executes 1 cycle.

when the bit is set to 1, it always uses the standard amount

standard amount calc:  word_46D58 == 0x0A (seems to never be modified)

seg030:06F7 A1 38 39                          mov     ax, word_46D58  

seg030:06FA BA 05 00                          mov     dx, 5

seg030:06FD F7 EA                             imul    dx

seg030:06FF A3 3C 39                          mov     scriptCyclesLeft, ax

[TrueBrain]

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!

[Nyerguds]

Heh, this option was pretty much the reason I implemented an Individual Item Help system in my editor... it's indeed just one of these things that needs some more info :P

This option forces the program to go through the full number of script cycles for this unit, even if the unit is outside of the user's screen area.

Normally, units outside of the screen area only execute 1/10th of the script cycles, to save CPU cycles.

^ The F1 help for this option in my editor

[Nyerguds]

I guess it's about time for this...

http://nyerguds.arsaneus-design.com/dune/dune2edit/d2editor_v1.17.2.zip

-added some more help items

-added TrueBrain's new researched options

-added normal alphabet shortcuts to all special functions, with bright colour indication of the shortcuts in the footer line (for bluehappybyte )

-fixed a bug in the Voice Prefix Letter editing box that made it try to show the type help and the old value on the same spot

-if something has only a single prerequisite or owner, the string in the values column is no longer abbreviated

If anyone can advise me on which other options should need some specific help text, please let me know. It's kinda hard for me to judge since I know the full research history behind every option.

Edited August 9, 2023 by Nyerguds

[MrFlibble]

Someone even fixed this script so it brings the unit back to where it was picked up (without you having to block the repair bay for that to happen).

That would be Minniatian's patch. I used it some time ago, it was fun ;D Basically, he copied the section of the Refinery script that tells Carryalls to pick up empty Harvesters from a Refinery to the Repair Facility script. However, recently a bug was reported concerning this tweak, as the units would sometimes get out of the Repair Facility before a Carryall could pick them, causing the latter to cease picking up units at all.

Actually, even with an unmodified script, a Carryall can sometimes pick up a unit before it emerges from the Repair Facility even if the exits are not blocked. It happens very rarely, and only if a Carryall is in close proximity to the Repair Facility at the time when a unit gets fully repaired.

Thanks for the info on the rest though... didn't know about the tab thing.

Yeah, I remember discovering it by pure chance :) I forgot if it is mentioned in the manual; it should be, though.

Segra's descriptions said that the outside the viewport thing worked the other way around though. He described the bit as forcing full script cycles outside the viewport. This seems to match the fact it's disabled for pretty much all units except for the weapons and air units. The only exceptions being the Harvester and saboteur, which do have it enabled.

Hm, do you think enabling this bit for all units will still cause the game to slow down on modern machines/DOSBox?

[Nyerguds]

On modern OSes, if it's just CPU cycles? I doubt it'll matter much.

[MrFlibble]

There's this Unknown 028 (bit 1), which is only enabled for the Devastator. We guessed it could be somehow connected with the self-destruct ability, but it does not disable it if turned off. Maybe it has something to do with the AI behavior (e.g. the AI would initiate self-destruct when a Devastator is critically damaged)?

Unknown 029 (bit 1) is only enabled for wheeled vehicles. Unknown 029 (bit 2) is only enabled for infantry and the 'thopter (maybe it has something to do with animated movement?).

[TrueBrain]

There's this Unknown 028 (bit 1), which is only enabled for the Devastator. We guessed it could be somehow connected with the self-destruct ability, but it does not disable it if turned off. Maybe it has something to do with the AI behavior (e.g. the AI would initiate self-destruct when a Devastator is critically damaged)?

Unknown 029 (bit 1) is only enabled for wheeled vehicles. Unknown 029 (bit 2) is only enabled for infantry and the 'thopter (maybe it has something to do with animated movement?).

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 ;)

[MrFlibble]

Unknown 023 seems to define the AI unit building priority: the AI will try to build more units that have a higher value.

[TrueBrain]

Unknown 023 seems to define the AI unit building priority: the AI will try to build more units that have a higher value.

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.

[MrFlibble]

I've mentioned a long time ago that Unknown 031 classifies each unit as a member of a certain group:

0 - infantry

1 - wheeled vehicles

2 - tanks

3 - long-ranged tracked vehicles

4 - attack aircraft

5 - unarmed aircraft

6 - projectiles

7 - other

I have no idea if these groupings are related to the team types, but they do affect AI production priorities as well. For example, when I changed the value from 3 to 2 for the Rocket Launcher, the AI started building a lot more of them (usually there are less Launchers than tanks in a Tracked attack team).

[TrueBrain]

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 ;)).

[MrFlibble]

Are you sure it has any effect in 1.07 EU?

I'll check it out. This was a long time ago, and it could be I tested that one on v1.0 (BTW, in the old Dune II Unit Editor that worked only with v1.0, from which I got most of the info upon which Nyerguds' editor was eventually built, this variable was mistakenly identified as unit sight range).

[Edit] Hm, it seems that modifying this variable, indeed, does not have any effect on AI production priority in the EU version. Either it does in a different version (I have briefly tested v1.0, and there were some weird effects like the AI would only build one tank at a time if all tanks were set to 3 instead of 2), or I'm remembering it incorrectly altogether.

[MrFlibble]

Joust wanted to know your opinion about the following issue (it is somewhat indirectly related to the editor, but anyway :)). I have noticed that in the Sega Mega Drive Dune: The Battle for Arrakis, the Ordos get access to Siege tanks on level 6, just like any other House, while in the PC version they only get it on level 7. Although it is possible this was done to make the Ordos more difficult to play, I think there's still chance that it occurred due to an error (taking into account the occasional slips here and there in the code of Dune II). I was able to locate the code responsible for this tech tree alteration, and since it relies on the "previous mission number" variable I think it's a plausible assumption that the developers intended to make the Siege Tank available for the Ordos starting with mission 6 onward, but mistakenly made it available only after it. In the Sega version, this was fixed along some other stuff (looped reinforcements, building decay dependence on slabs etc.) Your ideas?

[Nyerguds]

Considering which thread this is posted in...

are you asking me or TrueBrain? :P

[MrFlibble]

I'd like to know the general opinion, actually :) It's quite easy to change the code to make the Siege Tank available in Ordos mission 6 (and when I played Dune II for the first time, I had the wrong impression it was available then, as it seemed quite logical), so my question is, bug or not? The Ordos are already disadvantaged by the absence of the Rocket Launcher, but then again, their campaign is supposedly set on "hard" difficulty level.

[Edit] There's yet another side to this, namely the Harkonnen mission 6 is against the Ordos, and the above exception applies to the AI player too, making the Harkonnen mission easier, Siege Tanks against Combat Tanks (there are a few pre-placed Ordos Siege Tanks though). So the question remains, is this an intentional thing designed to make one campaign easier and another more difficult, or a mere oversight?