Dune II editor with 1.07 support

[Daelin]

Perhaps it is related to the ability to order a unit to self-destruct? I'm not sure, but IIRC giving a unit other than Devastator the "Destruct" command results in nothing.

Actually try self-destructing a siege tank.... or raider trike... or trooper.... works just fine :)

-Daelin

[MrFlibble]

I'm pretty sure it didn't work with the sandworm - I tested various buttons when I was trying to make them more controllable in Super Dune II.

This is probably because the sandworm has special behaviour and is different from other units in many aspects.

[Daelin]

Okay, after some long time of taking a break, I decided to make an EXCEL FILE (you will need Microsoft Excel to actually open the file - dunno if open office version works) to synthesize all the updates to the unknowns. :) All unknown fields or fields which contain unknown bits have been added to the list. To explain the colors a bit:

    - Green is a "solved" field (in my opinion)

    - Red is problematic (can't find a solution and I'm almost certain that I won't find one in a short time)

    - Yellow is partially solved but unimportant to further develop at this point as there are other elements "somewhere else"

    - Light-purple is an empty field, which most likely has no effect upon the unit/building and is therefore unused by the game.

With every update I make to the file I will be reattaching the excel, and remove the previous files so look for my latest post to see the latest version. For now:

New info upon Unknown 005 (buildings). They are as they follow:

  BIT 2 seems to activate "building menu/creen" for the building. It is useful if deactivated for a building which has it activated. If it is activated it seems to cause quite some problems (tried on windrap and there was a really nasty outcome - plus building could never actually spawn units). Construction Yard and Starport special menus cannot be found here anyway and are nowhere between the bits here.

  BIT 4 is responsible for placing buildings on concrete. If activated concrete is not needed and building placed on rock will not be damaged. Notice that walls are actually half-damaged when placed on empty rock. Only units immune to rock are actual concrete and the CY.

  BIT 5 is related to unit generated by "deploying" (Starport frigate and Refinery Harvester spawning). Deactivate the bit for these two to notice the outcome. For the rest of the buildings has no effect.

  BIT 8 enables "building capturing". If the bit is disabled no unit can actually enter the building. Notice that this proves that WOR and Barracks can never be captured (meaning that Atreides could construct troopers if enemy WOR were to be captured).

Unknown 006 is also pretty tricky but damn useful if modifying soldiers is planned. It is related to soldier spawning. If set to 0 then upon destruction the building spawns NO soldiers. The higher the value, the higher is the number of soldiers spawned! Notice that the number is restricted to the size of the destroyed building (a 2x2 building can never spawn more than 4 soldiers) and the number of soldiers that could actually exist on the map (unit limit with the current properties of the soldier).

Note: the file is still not complete. Not all fields have yet been filled but I will do so in a shorty. :)

Best regards,

Daelin

Unknowns_Nyerguds.zip

[segra]

nice Daelin, i'll add whatever info you find into my ida database

[Nyerguds]

Small hint Daelin... you can add new lines in one cell by pasting an empty line copied from Notepad. It's cleaner than spaces ;)

Oh, and it's "aggression", not "aggressivity". Though in this case, it's probably more like, "threat level"

[edit]

Right, got around to implementing it. Your excel file was a bit confusing though... if you split up a longer value into bytes, please remember that the order of the bytes inside the exe is REVERSED. So these building options for unknown 5 you found.. they're in the FIRST byte.

As I mentioned before, the thing I've implemented now is showing all of the boolean options as separate values in the list.

I've kept the "unknown ###" indicator in the unknown bit switches that are left over from bytes where some bits are identified. I've also kept the old numbering everywhere, splitting that "Unknown 005" for the building into 005a (the bit switches) and 005b.

This will make it easier to continue the research without having to adapt all numbers in our research documents (like that xls you made).

Anyway, without further ado:

Dune II Editor Version 1.11.0 :)

For anyone taking a look at the code... the 8 bit switch options I added are actually 7 "ghost" options with a size of 0, and then the final 8th option has a size of 1, making the list progress. This way I can read all 8 values from 1 byte :)

All editing and display functions for the bit switches call one function for their type, but with an extra parameter telling it which bit to read.

[Nyerguds]

Unknown 006 is also pretty tricky but damn useful if modifying soldiers is planned. It is related to soldier spawning. If set to 0 then upon destruction the building spawns NO soldiers. The higher the value, the higher is the number of soldiers spawned! Notice that the number is restricted to the size of the destroyed building (a 2x2 building can never spawn more than 4 soldiers) and the number of soldiers that could actually exist on the map (unit limit with the current properties of the soldier).

It serves as "percentage of surface". Commonly used percentages are 0% (0), 25% (64), 50% (128), 75% (192) and 100% (256). I'm making a list of them for the editor right now.

[edit]

Percentages added as data type:

Version 1.11.1

[Daelin]

Wow, awsome Nyer... I just checked the editor out, very nice modifications. Just some things to mention:

    - "Tank Death Animation" is infact "Tank Explosion"... it is not only merely an explosion animation but it also affects crushed infantry. If you turn the raider into a soldier for instance (how Flibble did for the Sardaukars) and the unit is crushed by a tracked vehicle, the unit "Explodes" causing great damage to the vehicle. This is more than plain animation and is practically used for vehicles to destroy Carryalls that attempt to pick up a "just destroyed" tank.

    - Unknown 041 is in fact "Death Animation" (related apparently only to tanks). There are two significant values you may add to the list (while of course there are some graphics references here - I even wonder if it is not connected to unknown 040 too - I'll check this out in a quickie as usually such references are on four bits):

    162: small tank (used by almost all tanks)

    165: big tank (used by harvesters and devastators)

      Check some of my ealier posts in which I mention more about this unknown.

    - Structures Unknowns 035-040 are the sprite animations I mentioned before and they are grouped again in unknowns of four bits (035 with 036, 037 with 038 and 039 with 040). Maybe you can modify this in the editor too (group them two by two and change their "unknown numbers"). Again, check my previous post for more information here.

For now that's about it! Thanks a million for taking the time to modify all this! You're awesome!

-Daelin

[Nyerguds]

then it's more like "explodes when dies", I'd say.

I'll look into the rest.

[edit]

Structures Unknowns 035-040:

I sincerely doubt that these values should be taken together. Remember, as I said before, the bytes are REVERSED in the exe. Adding 2 bytes before a value multiplies it by 65536.

[Daelin]

They just seemed to go together. Not to mention that graphic paths seemed to be a bit weird. I think those are paths, just like it is when it comes to unit references and other things above. I don't know exactly how they work as I was not extremely interested by this aspect.

There are also two functions which I've been wondering if you could implement if you have the time:

1) A reset values function - simply reset all current-selected-unit's fields to the original values (shouldn't be too difficult to implement - just grab the values into an extern previously-created file and just grab the values from there with the program when the reset button is pressed)

2) A "copy all values" from an unit to another. This is excellent so that I do not have to manually move all the values by myself. Most likely a "copy" and a "paste" button should work.

As a medium programmer I'd say these are not hard to implement, just that not being my program (and as far as I remember you've done it in Pascal - I know only C) I wouldn't really want to mess with it.

Let me know if you have the time for these. Thanks! :)

-Daelin

[Nyerguds]

As for the animations.. I've already been building a list of those. I just need to have time (or a volunteer) to test them all:

--- Icons:

065 = shapes.shp frame #053

110 = shapes.shp frame #098

--- Units without turrets + projetiles:

111 = units2.shp frame #000

150 = units2.shp frame #039

--- 151-238: unknown, posibly explosions and such

160 = units1.shp frame #010 (the frame that shows up when removing worm camo from the Sonic blast)

--- Units wih turrets

238 = units.shp  frame #000

354 = units.shp  frame #116

---

There are also two functions which I've been wondering if you could implement if you have the time:

1) A reset values function - simply reset all current-selected-unit's fields to the original values (shouldn't be too difficult to implement - just grab the values into an extern previously-created file and just grab the values from there with the program when the reset button is pressed)

Hard... especially since values may differ between veraions. As with alll editors, it's best to back up your exe before modding it.

2) A "copy all values" from an unit to another. This is excellent so that I do not have to manually move all the values by myself. Most likely a "copy" and a "paste" button should work.

Hmm... hard, but not impossible. I'd have to just read the entire length of bytes of a unit, ignoring all the different options. Actually copying the bare data, rather than the "values of the options".

[Daelin]

Hard... especially since values may differ between veraions. As with alll editors, it's best to back up your exe before modding it.

Well, not really if there would be an option to actually "save values" by pressing a button and just store the whole information into an external file, and then have a "restore values" which simply recopies the information from the file back into the executable. :)

Hmm... hard, but not impossible. I'd have to just read the entire length of bytes of a unit, ignoring all the different options. Actually copying the bare data, rather than the "values of the options".

Obviously that's what I had in mind, bare "overwriting" followed by a "refresh" of the editor screen (displaying the data).

-Daelin

[Nyerguds]

oh. So one to just save the data in mem, and the other to save it to a file? Hmm...

[Daelin]

EXACTLY! Okay... here's a more detailed idea of what I had in mind. First I'll just assign some buttons to the actions and explain how they could work

   F10 - Save Values. When pressing this button the program would just save ALL data (units and buildings) into an external file (overwrites it if already exists - though may ask for confirmation to actually overwrite - not sure if necessary though).

   F9 - Restore Values - restores all fields of selected item (unit or building) based on the file created with the above function. Hope it wouldn't be too difficult to implement for a single item. For grabbing the right bits from the file - each unit has a number of bits assigned, and each building has a different number of bits assigned too. If for example I want to restore all bits for Soldier I get "soldier" index (let's say n), skip (n-1)*number_of_bits_per_unit bits and just copy number_of_bits_per_unit in the place of "Soldier" in the executable. If it is a building you just skip all unit data from the file, and grab information for the building.

   F5 - Copy Fields. Copy all data bits for unit/building into the memory. Works just like copying a piece of text let's say, just that in this case it has a fixed length.

   F6 - Paste Fields. Pastes data previously stored into the memory on the selected unit/building (into the executable) and then just refresh editor screen to get the correct data displayed. WARNING! If unit data was copied and it is intended to paste on building, function should not work. Same the other way around (just because the number of bits allocated differ).

That's what I basically had in mind with the new functions. Let me know if I was clear enough (I know I may have mentioned some idiotic "obvious" elements but just thought I should mention clearly how I tsee these stuff and why I do not find these functions hard to implement - sorry for my naivete if it ain't so simple).

The first practically helps you easily restore data after heavily modifying the executable, while the second allows you to copy entire data from one unit to another (try to transform a Sandworm into a Harvester for example and see how much of that data is actually found here). I'd find both functions useful, that's why I mentioned them.

-Daelin

[Nyerguds]

dude, I know how to do the programming, mkay... :P

at the moment, I won't be spending more time on it though. As I said, exams coming. You can always help me by completing that icons/animations list though.

[segra]

Daelin, In your excel document you have fields Unknown 26, and Unknown 27, these fields are as follows

these are not limits as such, but "possible INDEXES" into the Real-Time "Unit Array" (there is one giant array at runtime, which keeps every unit on the map in it)

Ie. if the values are

Unk26: 10  and Unk27: 13

(Min-pos)      (max-pos)

This means the unit could appear at index 10-13 in the big array.

This is the reason why you cant have more than 2 saboteurs, the saboteur has values 20-21

[Daelin]

dude, I know how to do the programming, mkay... Tongue

I am aware of that Nyer, I was just justifying why I find this whole thingy easy "not-so-difficult" to implement. Hope I didn't annoy you too much  :P

Daelin, In your excel document you have fields Unknown 26, and Unknown 27, these fields are as follows

these are not limits as such, but "possible INDEXES" into the Real-Time "Unit Array" (there is one giant array at runtime, which keeps every unit on the map in it)

Ie. if the values are

Unk26: 10  and Unk27: 13

(Min-pos)       (max-pos)

This means the unit could appear at index 10-13 in the big array.

This is the reason why you cant have more than 2 saboteurs, the saboteur has values 20-21

That's actually very ingenious and if this theory has been tested it allows us to heavily control the number of units of each type/map and in higher categories (such as for instance a maximum number of 75 tanks out of which at most 10 can be sonic tanks). Was this actually tested? I'm not a hacker/assembly-programmer here. What I merely do is brute user-testing.

-Daelin

[segra]

That's actually very ingenious and if this theory has been tested it allows us to heavily control the number of units of each type/map and in higher categories (such as for instance a maximum number of 75 tanks out of which at most 10 can be sonic tanks). Was this actually tested? I'm not a hacker/assembly-programmer here. What I merely do is brute user-testing.

-Daelin

The code is in a function i named "UnitGameCreate"

Starting at

seg015:0444 26 8B 87 32 00                    mov    ax, es:[bx+_unitData.indexMin]

Where it then proceeds to loop thro the main unitgameptr, starting at indexMin, finishing at indexMax

while this code is here, im not sure if anything else affects unit limitations or not

[Daelin]

Yes, unit limit/map. Though what is intriguing is the fact that the game seems to make a difference between ground units and air units (after all air units do not enter this limit as far as I can remember - not sure however if it actually has to do with the type of movement). I will have to check this and see :)

Btw segra, you studying/working as a programmer or is this just a hobby? I'd love to start learning some assembly but I have no clue what to begin with... :) (sorry for the off-topic bit)

-Daelin

[segra]

Interesting, scrolled up a bit and found

First it checks the house unit count is < limit (kept in the 'housegame' struct)

if its less, it jumps forwards and does the index test

otherwise, it checks if the movement type is 4 or 5, or if "unit create mode" is enabled.. then creates the unit

not sure what unit create mode variable is actually for, but its usually set in the function which calls "UnitGameCreate"

seems like a "force unit creation" maybe?

[segra]

Btw segra, you studying/working as a programmer or is this just a hobby? I'd love to start learning some assembly but I have no clue what to begin with... :) (sorry for the off-topic bit)

-Daelin

just graduated from Uni about 3 weeks ago, still jobless, but been programming as a hobby for about 18 years now (started in Amiga basic when i was 7.. coding examples from a book... lol)

first dont worry, its not as hard as claimed, most of it :P

from there guess it depends on how u prefer to do things, either read a book... or learn the harder way, reverse something and lookup the instructions as u come across them (guess it depends on how much previous programming exp u got?)

reverse engineering is another topic all-together, but u can learn it same time as asm... theres a few good books around, and some online tutorials/videos floating about

[segra]

Nyerguds,

just wondering if at anytime you are planning on implementing HouseData editing?

offset: 0x3B80C

while i havnt figured out the entire structure yet, so far

00000000 _houseData      struc ; (sizeof=0x1E)

00000000 houseNamePtr    dd ?                                        ; offset (00043420)

00000004 field_4        dw ?

00000006 field_6        db ?

00000007 field_7        db ?

00000008 buildingDamage? dw ?

0000000A field_A        db ?

0000000B field_B        db ?

0000000C PalaceUnitBuildTime dw ?

0000000E FrigateTime    dw ?

00000010 houseLetter    db ?                                        ; char

00000011 field_11        db ?

00000012 PalaceUnitType  dw ?

00000014 missionWin?    dw ?

00000016 missionLose?    dw ?

00000018 missionBrief?  dw ?                                       

0000001A houseVoicePtr  dd ?                                        ; offset (00043420)

0000001E _houseData      ends

the 3 'mission' variables are pushed onto the stack for the "display briefing screen", altho i changed their values.. i saw no changes, not that i was really looking that hard :)

each specific var is pushed for the various screen, win/lose/start brief

+8 buildingDamage? im not entirely sure of either, but its used as the "damage" value with a call to buildingDoDamage during the main 'gameHandleBuildings' function

[Nyerguds]

well as I said before, I got exams now, so I won't be looking into that for about half a month.

[MrFlibble]

just wondering if at anytime you are planning on implementing HouseData editing?

offset: 0x3B80C

while i havnt figured out the entire structure yet, so far

00000000 _houseData      struc ; (sizeof=0x1E)

00000000 houseNamePtr    dd ?                                        ; offset (00043420)

00000004 field_4         dw ?

00000006 field_6         db ?

00000007 field_7         db ?

00000008 buildingDamage? dw ?

0000000A field_A         db ?

0000000B field_B         db ?

0000000C PalaceUnitBuildTime dw ?

0000000E FrigateTime     dw ?

00000010 houseLetter     db ?                                        ; char

00000011 field_11        db ?

00000012 PalaceUnitType  dw ?

00000014 missionWin?     dw ?

00000016 missionLose?    dw ?

00000018 missionBrief?   dw ?                                       

0000001A houseVoicePtr   dd ?                                        ; offset (00043420)

0000001E _houseData      ends

the 3 'mission' variables are pushed onto the stack for the "display briefing screen", altho i changed their values.. i saw no changes, not that i was really looking that hard :)

each specific var is pushed for the various screen, win/lose/start brief

+8 buildingDamage? im not entirely sure of either, but its used as the "damage" value with a call to buildingDoDamage during the main 'gameHandleBuildings' function

That's the same thing as I talked about here, right? The "building damage" thing you mention is probably related to the building deterioration caused by harsh climate (happens over time; I wonder if setting it to -1 will turn it off for a particular side).

BTW, all value names I used to identify House parameters (LemonFactor, Special, Frigate etc.) were taken from the Dune: The Battle for Arrakis (Sega Mega Drive version), and they are also used in the Dune II PC Demo.

[Nyerguds]

That's the same thing as I talked about here, right? The "building damage" thing you mention is probably related to the building deterioration caused by harsh climate (happens over time; I wonder if setting it to -1 will turn it off for a particular side).

More probably, that will heal your buildings over time, lol.

Well either that, or they'll self-destruct in seconds, if the value is seen as non-signed, because then you put it to 255 (or, if it's 2-byte, 65535):P

[edit]

Wait, wasn't that stuff in the buildings emc file?

[segra]

well that takes care of that then, good work Flibble lol

has the lemonfactor been explained yet?

the decay value is used based on something in the EMCData, i havnt fully explored how this works, so im unsure of what exactly is going on

essentially tho, theres a couple of checks (not sure what the vars here are used/done with yet..) and mission > 1, then we set "canDecay"

it doesnt hit this very often, perhaps every few mins

then it checks the EMCDATA field for 0x400 (this needs to be investigated, alot of things rely on this flag thro the game)

finally it checks if the building has < 50% hitpoints