Dune II editor with 1.07 support

[dvalin]

I've added the (probable) offsets for other versions: http://bazaar.launchpad.net/~doonlunacy/libeastwood/trunk/annotate/head%3A/src/Dune2File.h

I detected these with a crude tool I wrote and haven't really verified them..

I might clean up the code, make it more reliable and commit it, would anyone have the interest in such a tool?

[dvalin]

hmm, I'm trying to figure out the dune2edit pascal code on how to create the name string for units, structures etc., but

I find the code a bit hard to follow...

Could someone provide a brief explanation, perhaps some pseudocode?

[segra]

pAddress is the address from the Name field in the structs (or the picture field,etc),

_bufferExe is ptr to the very start of dune2.exe

_version->offReferences is the reference offset modifier (0x333E7FE0 in 1.07-HS)

string cResourceExe::stringGet( size_t pAddress ) {

string tmp;

if( !pAddress )

return "";

tmp.append( _bufferExe + (pAddress - _version->offReferences));

return tmp;

}

[Nyerguds]

nyerguds, I was talking about data structures, not buildings ;)

I know that. I was asking which ones.

action table is 14 entries

Are those the unit commands? There are exactly 14 of those.

hmm, I'm trying to figure out the dune2edit pascal code on how to create the name string for units, structures etc.

Basically you take the value that's set in the data there and add the refAddress of that game version to it to get the place where the string is. That's all. RefAddress is stored as 4 bytes, but you just put them together to one big (hex) value.

[dvalin]

nyerguds: I wasn't asking about any buildings in particular..?

Anyways, I figured that hardcoding file offsets per version etc. was quite ugly and boring,

so I've added support for parsing the DOS MZ format used by DUNE2.EXE.

This way libeastwood now knows where to find the memory references used in the data structures. :D

This should also help finding and reading additional data as well!

[segra]

couple of unit hardcoded fields,

unitdata+0x32  (Units: Unknown 034 in the editor)  is the distance to move before changing the frame

This value is divided by 5 before usage, therefor if you enter 16 * 5 = 80 (16 = width of tile) the units will move 1 tile cell before changing to the next frame

unitdata+0x48  (Units: Unknown 040 in the editor) seems to be the number of frames per angle, but there must be a flag somewhere which alters the interpretation of this field, as the thopter doesnt match... and in some cases, such as the carry-all.. there is only 3 angles (flip switch somewhere?)

[Nyerguds]

unitdata+0x32  (Units: Unknown 034 in the editor)  is the distance to move before changing the frame

This value is divided by 5 before usage, therefor if you enter 16 * 5 = 80 (16 = width of tile) the units will move 1 tile cell before changing to the next frame

What exactly do you mean by "changing to the next frame"?

[edit]

Ohh... you mean movement animation frame?

unitdata+0x48  (Units: Unknown 040 in the editor) seems to be the number of frames per angle, but there must be a flag somewhere which alters the interpretation of this field, as the thopter doesnt match... and in some cases, such as the carry-all.. there is only 3 angles (flip switch somewhere?)

If you look at the actual SHP files, the air units are indeed flipped and mirrored. This is probably unrelated to that though; it looks like the number of frames for the move animations of the units. As for the 'thopter, this might be right, since it has its wing animations.

[Nyerguds]

I've been implementing some extra small features for bit switches:

-When you have a bit switch selected, hexadecimal mode's compare column now shows the value of the selected bit instead of the entire byte value

-hexadecimal mode now uses binary editing when you have a bit switch selected

-When using binary editing mode on a bit switch, you will automatically have the correct bit selected.

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

[edit]

Implemented the data types that were still missing for the houses (House letter and superweapon type)

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

Edited August 9, 2023 by Nyerguds

[MrFlibble]

Cool. I'll check it out as soon as I got time :)

[segra]

Units: Unknown 040  is actually the 'mode' to use for the animation/angles

0 does nothing

1-2 are the same, they read the number of the frame to use from a hardcoded table based on the current angle

this value is added to UnitGfxID

3/4 use a different table from 1-2, but 3 multiples the value from the table by 3, and 4 multiples the value by 4

the current 'frame' number is then used to lookup another table, this value is added to the one obtained from the previous lookup

we then have the final value to add to the UnitGfxID

Flags are included in the hardcoded tables, following the frame/angle references

[Nyerguds]

Ah, so I'll just need another values table of "animation modes" to choose from for that.

btw, I fully identified the animations list...

000-006: MOUSE.SHP

007-011: BTTN.ENG(/GER/FRE)

012-110: SHAPES.SHP

111-150: UNITS2.SHP

151-237: UNITS1.SHP

238-354: UNITS.SHP

atm I haven't tested what values beyond the end of UNITS.SHP do.

[Nyerguds]

1.14 finally adds graphics modding to the editor

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

I'll soon be releasing 1.14.1 with a list of the frame usage modes. They're funny to put on 0 and have a single frame unit. I turned the quad into a sonic turret placed on an Target cursor like that. Looked pretty cool. Like, a hover disk of death ;D

Edited August 9, 2023 by Nyerguds

[Nyerguds]

1.14.1:

-Fixed hex comparison mode so the comparison value updates after editing it

-Added graphics display modes. These seemed like accurate descriptions:

0: Use single frame

1: Normal (unit)

2: Normal (weapon)

3: Normal frames * 3

4: Normal frames * 4

5: 'Thopter special

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

[segra]

Not sure on the exact purpose,

but Units Unknown 39 is used as the ActionID in place of sidebarCommand4 in a number of places when the player is the AI

guess its the default mode for AI units?

[Nyerguds]

So we don't know what it is, but we know I can link it to the commands data type? :P

Well, I'll put it in as default AI command until we know more. Looking at the data, it seems logical.

(well, besides the fact all normal units have 'Hunt' there. Though I suspect this might be overridden by the units.emc thing)

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

-fixed an error that made the editor crash when opening a 4-byte value in decimal editing mode (was related to negative number checking... stupid 4-byte integer limit)

-fixed an error in the saving of booleans that sometimes cleared the entire byte when changing one bit

-rewrote the code to convert negative integers to 4-byte array so it works correctly for large values

-Identified "Unknown 039" as "default AI command", and changed it to the "Command" data type

-Changed handling of the Commands to allow a "None" value (-1) in the list

-Grouped together unknown 30 and 31. Seeing as the second byte is always empty, they're obviously a 2-byte value. (note that this means the numbers behind it are shifted now)

-Added a note to the type description of the Graphics to inform people that value "0" (normally the mouse cursor) is also used as 'None' in some cases (more specifically, the death anim)

btw, at the beginning of the developement of the editor, MrFlibble already found out that the current value Unknown 031 (just before the movement type) was related to how many units the AI builds. Can you find any more info on that?

[Nyerguds]

Crap... the graphics lists are different in different versions. I'm going to have to make these version-sensitive -_-

Hm, seems it's just in the demo/1.00 version. Now to figure out what's changed...

[MrFlibble]

I think it's the demo.

[Nyerguds]

It's both the demo and 1.00. I actually noticed the graphics sets were different when checking the old Dune II 1.00 editor.

It seems the early versions are missing BTTN.ENG(/GER/FRE), and have all of these frames incorporated somewhere at the end of SHAPES.SHP instead. The fact I even noticed the values were off was because the "Credits" text is not a SHP frame in v1.00, since it doesn't have any language support.

Anyway, I added an adapted list to the editor, and added some exceptions in the code to use that list for the demo and 1.00 versions. It's a rather messy solution, but the only other option is either leaving it as numbers without any editing help, or copying the entire giganormous list for every single version, which seems pretty useless to me.

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

The exception is programmed so only the demo and 1.00 versions use the special list, so any other Dune II versions that might get added later (though I doubt there will be any more) will still automatically use the normal 1.07 list.

[MrFlibble]

It's both the demo and 1.00. I actually noticed the graphics sets were different when checking the old Dune II 1.00 editor.

I'm not sure, but it seemed to me that some graphics IDs were different by 1 in the demo and v1.00. I think it was the sidebar icons.

[Nyerguds]

I got all exes here with me, and the icons and graphics all match in the editor now.

[segra]

(well, besides the fact all normal units have 'Hunt' there. Though I suspect this might be overridden by the units.emc thing)

yeah, the "action ids" (or sidebar/ai command) are all passed into the scripts and handled from there

not sure on that value, can only find 2 places its used and neither of them have been investigated yet.. will take a look soon tho

[Nyerguds]

I implemented Actions into the editor... they all got a string reference (for the ini reading, I guess), so I could use my normal methods for getting the entry names

Besides that string reference, they only got four 2-byte options though.

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

There are some odd data in this section... Stop has action ID 37, where you'd expect 8 in the list, and Deploy has 32, and Destruct has 153.

Die is the only command that has "-1" as value for the last option, where the others always have 20, 21 or 22.

I think Unknown 004 is related to whether an option can be targeted. Since it switches between 1 and 3, I think this might be a bit switch option, where bit 2 is "Not Targetable"

I wonder if this can be used to make a harvester return to a specific refinery...

[edit]

Hehe, non-targeted Harvest and targeted Return indeed work. Odd fact... if the targeted refinery for the Return command was occupied, it automatically chose another one. If no spice was around, the Harvest command did nothing though, except trigger the automated Return if the harvester wasn't empty. When it was close to spice it did automatically go to it like it normally does though.

I think non-targeted commands simply target the current cell.

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

Separated byte into bit switches:

[edit again]

Unknown 003 seems to be set to 1 on commands that cause death, though activating the bit on Move or Stop didn't cause the unit to die after executing the command. Also, oddly enough the bit isn't set on "Sabotage", which also causes self-destruct.

Edited August 9, 2023 by Nyerguds

[Nyerguds]

nyerguds: I wasn't asking about any buildings in particular..?

Anyways, I figured that hardcoding file offsets per version etc. was quite ugly and boring,

so I've added support for parsing the DOS MZ format used by DUNE2.EXE.

This way libeastwood now knows where to find the memory references used in the data structures. :D

This should also help finding and reading additional data as well!

So, how exactly is that done? I'm VERY interested in removing as much hardcoded stuff as possible from the editor, and these reference offsets are one of the main annoyances.

[segra]

for the "action id" i actually meant the index in the table, thats what the game uses for passing actions around

not sure what the first field is for, but got this so far

00000000 _unitActions    struc ; (sizeof=0xC)

00000000 field_0        db ?

00000001 field_1        db ?

00000002 Name            dd ?                                        ; offset

00000006 interruptAction db ?                                     

00000007 field_7        db ?

00000008 sidebarMode    db ?

00000009 field_9        db ?

0000000A field_A        db ?

0000000B field_B        db ?

0000000C _unitActions    ends

sidebarMode is the mode the sidebar has to be in to use this action

interruptAction is how the action is handled when clicked,

the values for interuptAction are,

0 - Finish current action, then execute new action (moving for instance will finish moving cells before changing mode)

1 - immeditately execute new action, wipes current unit script data, puts the new actionid into script register 0, and prepares the script for run (at beginning of the units' script)

2 - Causes current script to be interrupt, all script data is pushed onto the units script stack, new action is run, then the script returns to the previous script

none of the actions seem to take use of 2... so no idea if it actually works or not

[Nyerguds]

Are you saying the Sidebar Mode are actually just different numbers, and not handled as bit switches?

If so, do you have any idea what sidebar modes there are?

[edit]

On an unrelated note... do you know why the Area Guard command seems to trigger Retreat when I give it to units? They first retreat and then stay on area guard mode there.

[edit again]

Interrupt mode at work: when I leave it on 1 for Destruct, the devastator will stop in the middle of moving between 2 cells to self-destruct. If I put it to 0, it first finishes moving to the next cell.

2 seems to have some bizarre effects. When I put the Stop command to "2", I could interrupt the harvester's harvesting without stopping its sand filter animation. Though on most commands, 2 doesn't work because they automatically seem to jump to command #4 on the sidebar as final action in their script.