Dune II editor with 1.07 support

[Nyerguds]

Right, I've implemented the Houses in the editor. Got some bizarre bugs though... mostly because I never designed the main types menu to be larger than 2 items, and because so far I never had items and options lists that didn't completely fill the list.

All I need to do now is add data types for missing stuff like house letters, music, the palace specials, etc.

As always though, I'm doing this in my breaks in between my studying for my 2nd try exams, so I have no clue when I'll actually get it done.

Oh, MrFlibble, I've used this list, but there's still some things quite unclear... do you have any idea how the color selection works?

[edit] nevermind. It's the palette index of the radar colour, I see. [/edit]

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

Edited August 9, 2023 by Nyerguds

[MrFlibble]

Nice :) The color does not affect actual unit/building colors on the field though, only the colors on the radar minimap.

Would be nice to find the code defining remaps and fix that annoying IX remap bug after all.

EDIT: Unkown 006 (bit 5) is the unit's ability to target air units (Troopers and Launchers have this option enabled, but only in v1.07). Note that human-controlled Troopers and Launchers (in Guard mode) seem to ignore enemy aircraft however, but CPU-controlled ones (at least when in Area Guard mode) will actively attack hostile aircraft.

Also, as I expected, setting Decay to -1 disables building decay for that House. Damaged buildings don't get regenerate their health, and structures placed on incomplete concrete foundations or on bare rock still get damaged.

[Nyerguds]

Nice :) The color does not affect actual unit/building colors on the field though, only the colors on the radar minimap.

Yeah, I already adapted the colour thing in my code. It now says "Radar Color Index". This version was just a rough implementation of the list you had in that other thread.

Would be nice to find the code defining remaps and fix that annoying IX remap bug after all.

yeah...

EDIT: Unknown 006 (bit 5) is the unit's ability to target air units (Troopers and Launchers have this option enabled, but only in v1.07). Note that human-controlled Troopers and Launchers (in Guard mode) seem to ignore enemy aircraft however, but CPU-controlled ones (at least when in Area Guard mode) will actively attack hostile aircraft.

Added to my source code as well now. Will be in the next version ;)

Also, as I expected, setting Decay to -1 disables building decay for that House. Damaged buildings don't get regenerate their health, and structures placed on incomplete concrete foundations or on bare rock still get damaged.

Hmm... any idea what difference the other values make? The houses use values 0, 1 and 2.

[Nyerguds]

Now I have the houses as list in the editor, I removed the hardcoded houses strings from the program (those used for the ownership value). It now reads those strings straight from the exe, just like it does with units for the "Weapon type" and "Construction option" :)

[segra]

Nice Nyer :)

heres another bit for you,

Unknown 006 Bit2 is something to do with a sound thats played when a unit is attacked but still alive,

Ive labelled it as "No Attacked Sound" because it skips this soundplay section but the truth is i havnt actually tested it :)

Reasoning is this,

seg031:0C6D                  notSaboteur:                                                ; CODE XREF: objectTakeDamage+E7j

seg031:0C6D C4 5E FC                          les    bx, [bp+unitDataPtr]

seg031:0C70 26 F7 47 0C 00 02                test    es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_NoAttackedSound

seg031:0C76 75 3C                            jnz    short action0A

seg031:0C78 83 7E FA 00                      cmp    [bp+Alive], 0

seg031:0C7C 74 36                            jz      short action0A

...

seg031:0CAD 50                                push    ax

seg031:0CAE 9A 2A 00 86 42                    call    j_soundTableLoad

it plays using a different sound table after mission 3... table 0xE + HouseID..

before and in 3 it only uses table 0xD

[Nyerguds]

um, unless you use different numbers than my editor, this option seems to be activated on all WEAPONS.

[edit]

Yeah, UnitOptsWocaTuro is what is currently unknown 005 in my editor. The Unknown numbers don't start from 0 since they're supposed to be for the users :P

[edit]

Maybe this option was meant to suppress "unit under attack" messages for a certain unit? Though Dune II doesn't have such a message...

Are there more checks that make it jump to that action0A? (which I presume is after that sound function call?)

[segra]

Yeah thats ok Nyerguds, the Unknown 5 field (WOCATURO) is actually a word, thus the enum appears as (we already spoke about this before)

00000001 ; enum _UnitOptsWocaTuro (bitfield)

00000001 _UnitOptsWocaTuro_AirUnitShadow  = 1

00000002 _UnitOptsWocaTuro_2  = 2

00000004 _UnitOptsWocaTuro_4  = 4

00000008 _UnitOptsWocaTuro_8  = 8

00000010 _UnitOptsWocaTuro_10  = 10h

00000020 _UnitOptsWocaTuro_WormCamo  = 20h

00000040 _UnitOptsWocaTuro_2ndAnim?  = 40h

00000080 _UnitOptsWocaTuro_80  = 80h

00000100 _UnitOptsWocaTuro_CarryAllPickupRepairs  = 100h

00000200 _UnitOptsWocaTuro_NoAttackedSound  = 200h

00000800 _UnitOptsWocaTuro_800  = 800h

00001000 _UnitOptsWocaTuro_1000  = 1000h

00002000 _UnitOptsWocaTuro_TargetAirUnit  = 2000h

00004000 _UnitOptsWocaTuro_4000  = 4000h

00008000 _UnitOptsWocaTuro_  = 8000h

with the struct as,

00000000 _unitData       struc ; (sizeof=0x5A)

00000000 stringID        dw ?

00000002 Name            dd ?                                        ; offset (00043420)

00000006 stringLongID    dw ?

00000008 Picture         dd ?                                        ; offset (00043420)

0000000C optsWocaTuro    dw ?

0000000E field_E         dw ?

00000010 HitPoints       dw ?

00000012 Sight           dw ?

yeah action0A is after the sound call, and the only other place to jump there is right before the previous pasted code,

seg031:0C57                   checkSaboteur:                                              ; CODE XREF: objectTakeDamage+B6j

seg031:0C57 C4 5E 06                          les     bx, [bp+unitGamePtr]

seg031:0C5A 26 80 7F 02 06                    cmp     es:[bx+_unitGame.typeIndex], 6      ; Saboteur

seg031:0C5F 75 0C                             jnz     short notSaboteur

seg031:0C61 B8 14 00                          mov     ax, 14h                             ; Saboteur Destroyed

seg031:0C64 50                                push    ax

seg031:0C65 9A 2A 00 86 42                    call    j_soundTableLoad

seg031:0C6A 59                                pop     cx

seg031:0C6B EB 47                             jmp     short action0A

seg031:0C6D                   ; ---------------------------------------------------------------------------

seg031:0C6D

seg031:0C6D                   notSaboteur:                                                ; CODE XREF: objectTakeDamage+E7j

EDIT: According to the Unit Action Table at seg156:006E, Index 0A is 'DIE'

[MrFlibble]

Just a thought occurred to me right after I posted, what if the auto-targeting of aerial units is separate for human and computer-owned units? There are some bits always set to No, even among Unknown 006, and from what I have observed, human-controlled units seem to ignore enemy aircraft, or are very lazy about attacking it.

Do you think this could have some merit? That there's a separate bit which, when activated, would make player-controlled units automatically attack air units within their range?

[Nyerguds]

There's stuff like that in C&C1 too... logics that differ if the player is human. For example, the helicopter Guard command is blatantly replaced by Area Guard for CPU-owned units.

[segra]

not sure if this will help, but this is the only location (that ive found) which checks the target air unit bit... right afterwards it checks for the BIT before it (bit4 of unknown6) but only if its a flying unit

seg031:1242 26 F7 47 0C 00 20                test    es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_TargetAirUnit

seg031:1248 75 03                            jnz    short loc_295AD

seg031:124A E9 50 FF                          jmp    NoRange

seg031:124D                  ; ---------------------------------------------------------------------------

seg031:124D

seg031:124D                  loc_295AD:                                                  ; CODE XREF: unitDamageUnitGet?+C3j

seg031:124D C4 5E FC                          les    bx, [bp+unitDataPtr2]

seg031:1250 26 83 7F 3C 04                    cmp    es:[bx+_unitData.MovementType], 4  ; Flying

seg031:1255 75 3C                            jnz    short notFlying

seg031:1257 C4 5E F8                          les    bx, [bp+unitDataPtr]

seg031:125A 26 F7 47 0C 00 10                test    es:[bx+_unitData.optsWocaTuro], _UnitOptsWocaTuro_1000

seg031:1260 75 03                            jnz    short loc_295C5

seg031:1262 E9 38 FF                          jmp    NoRange

seg031:1265                  ; ---------------------------------------------------------------------------

seg031:1265

seg031:1265                  loc_295C5:                                                  ; CODE XREF: unitDamageUnitGet?+DBj

Also later in this function, the unit data field 'Aggressivity' is added with the word just before it, at +0x2D

seg031:12FC C4 5E FC                          les    bx, [bp+unitDataPtr2]

seg031:12FF 26 8B 47 2F                      mov    ax, es:[bx+_unitData.Aggressivity]

seg031:1303 C4 5E FC                          les    bx, [bp+unitDataPtr2]

seg031:1306 26 03 47 2D                      add    ax, es:[bx+_unitData.field_2D]

[segra]

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

[Nyerguds]

So this means units will act differently off-screen? Bizarre.

Or is this 'user screen area' the revealed terrain? That might explain how worms only become active after they are discovered.

[edit]

eh, are we talking about a different option again? The unknown 6 bit 3 is only activated on weapons and flying units... or do you count your bits from 0 too? I got bits 1-8.

If you mean the 4th option then it would make sense... this is disabled on all units except the harvester and saboteur. Strangely enough this is also enabled on the sandworm though.

[segra]

ive been posting all references in relation to your editor (im using v1.12.0), was converting from the dis-assembly so we don't have any confusion about the sizes or naming of them.. guess that backfired :)

Unknown 006 (bit 3) is not activated on flying units or weapons

that means all units, except the flying ones and the weapons will always run there script normally... flying units/weapons only run normally once they enter the users screen

[Nyerguds]

weird. Especially projectiles should not be affected by whether they're in the user's screen... not to mention that projectiles shouldn't do much more than fly to a target and explode anyway.

And I can't imagine any behaviour difference between a carryall I'm looking at and one I'm not looking at.

Are you sure it's the user's screen it checks, and not the shroud?

#4 seems like a likely candidate for an option like "active even in shroud".

[segra]

yeah its definatly not shroud related, the function which is called doesn't access the map data.. but this may explain it

the variable is actually the TACTICAL Position, not the cursor position.. apparently i labelled the variable wrong at some point in the past.. doh :)

so when these units are within a certain range of tactical, they execute more cycles than normal

[stefanhendriks]

I have seen units move way quicker on screen, than off screen.

[Nyerguds]

Ehh, that has no relation to AI behaviour, Stefan. It's probably just a bug of the same kind as how the game speed affects the sonic range :P

Segra:

So the variable is actually "unit is more active/intelligent outside TacticalPos range" then? Still seems kinda odd if all units have it enabled anyway.

Then again, this code might be for 'thopters...

[stefanhendriks]

Lol, I should stop posting using my IPhone. Somehow I have posted in the wrong topic.

EDIT:

Meh, I did post in the correct topic.

I meant to reply to:

So this means units will act differently off-screen? Bizarre.

Basically, this is correct. Somehow I always thought that this was intentional to save CPU cycles for all that happens off-screen. Especially in the days of the 80286 / 80386 processorss.

[Nyerguds]

Actually, Segra just said that this didn't relate to that; it's about the TacticalPos set in each map. Which, I guess, is an indication for the AI player as to where to find the player's base... or at leaast, where to move its units to before attacking. I guess that way they can control from which side the AI attacks.

[edit]

Oh, Segra, is CursorPos actually changed with the screen location when scrolling? I know it's set in the ini file, but there it just acts as the point on which to center for the start location.

[stefanhendriks]

What i meant, is that without looking into the EXE, i can see it happening while playing.

Try this:

Be any house, build the fastest unit available (ie ordos trike is a good example).

Now, put both trikes in the same X axis. Keep them a bit apart. Then, move them both UP/DOWN to the other side of the map. Of course, you will have a delay to move the units. Keep ONE unit in your screen, the other not.

It is tough to test, because there are possible slow downs by terrain; so you have to watch for this. I've seen a trike arriving first, while i sent him later.

Also, i was playing with setting "FASTEST". If i'm correct, the FASTEST option is somehow FPS based and not timer based?

[XTF]

Actually, Segra just said that this didn't relate to that; it's about the TacticalPos set in each map. Which, I guess, is an indication for the AI player as to where to find the player's base... or at leaast, where to move its units to before attacking. I guess that way they can control from which side the AI attacks.

[edit]

Oh, Segra, is CursorPos actually changed with the screen location when scrolling? I know it's set in the ini file, but there it just acts as the point on which to center for the start location.

Isn't TacticalPos the position of the screen and CursorPos that of the cursor/pointer?

I've heard this before, units off-screen don't get as much CPU cycles.

BTW, bits should really be counted from 0. ;)

[MrFlibble]

So this means units will act differently off-screen? Bizarre.

It is said that units that are off-screen actually move slower than those on screen:

In order to render the game playable on 8-16 MHz systems, it was necessary for the designers to have off-screen units update at about half the rate of those on-screen. This only affected movement, but it resulted in a player being able to move an army much faster if he scrolled the map to keep them in view.

(source)

[segra]

Olaf is correct about the tactical/cursor options/variables.

from the affected scripts tho, most of them just do a delay and destroy (weapons)

carryall/thopter/sandworm all have more to do, however alot of the functions are still unknowns.

not sure how much realtime change we could see, but enabling the bit for thopters should make them select targets faster (the script seems to check unit house, compare distance, then attack).. instead of it taking maybe 5 loops of the game engine for 'one script loop', it may only take 1... ( these numbers are all made up )

[sonicBlast]

PushWord            1800

Execute             Delay

AddSP               1

Execute             Destroy

Pop                  (Return)

[bullet]

PushWord            6000

Execute             Delay

AddSP               1

Execute             Destroy

Pop                  (Return)

EDIT: Btw, for the interested...

In the unit scripts:

Register 0 is current action, set after a call to the "unitAction" function

Register 3 is the Human House ID

[Nyerguds]

I don't see how a mission would benefit from changing the position of the mouse cursor...

It is said that units that are off-screen actually move slower than those on screen:(source)

Right, but as I already said to Stefan, that's not what this is about... this is about it actually behaving differently -_-

[segra]

without changing the mouse cursor position it might be hard to click on things :P (the variable is used for building placement, unit selection, etc)