Dune II editor with 1.07 support

[MrFlibble]

Honestly, I don't know. Dune 2 v1.07 doesn't recognize v1.0 WSAs, that's all I can tell you. Maybe Ultraq would know more, but it seems that he doesn't even have Dune II...

[Nyerguds]

MrFlibble... I added support for Super Dune II and any other renamed exe which can be produced

Just add the file to edit as command line parameter and it should work. In fact, you can just drag your exe file onto the icon of the d2editor program and it'll automatically cut the actual filename off the path to get the string it needs to find in the exe file (to determine the version)

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

Edited July 4, 2022 by Nyerguds

[Nyerguds]

lol, found some more... the unknown #5 of the units is actually 2 separate bytes... the first is a bit switch with the following meanings:

0000 0001 - unknown, related to airplanes

0010 0000 - Use camouflage instead of unit graphics (what the sandworm uses - great if you want to harass the SD2 player with "stealth" units )

0100 0000 - Unit has rotating turret

Rotating turrets in action:

Edited July 4, 2022 by Nyerguds

[MrFlibble]

MrFlibble... I added support for Super Dune II and any other renamed exe which can be produced :)

Cool, thanks 8) I'll certainly find uses for the new version ;D

Nice to see more of the Dune II code gets deciphered too :)

[Nyerguds]

V1.9.2:

Adds the ability to edit the graphics modifiers. So far, the only ones that seem to have any effect are the worm camouflage and the rotating turret option though, even though all aircraft typically seem to have option #1 enabled.

Note that if you enable the Rotating Turret option on units without turret graphics set (Turret gfxID option) they simply act as if they have an invisible turret, and can shoot to all directions without needing to turn around.

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

Unknown 029 seems to be another bit switch, with some options controlling whether an object is selectable.

I've also been looking into the internal order of the images the game uses... so far, I've come up with this:

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

This is strange though, because the sandworm is supposed to be 161, but units1.shp frame #011 is the beginning of the Deviator gas cloud. Then again, it probably doesn't matter, since removing worm camouflage from the sandworm doesn't make the unit graphics show up, even if the unit graphics ID is changed.

--- Units wih turrets

238 = units.shp  frame #000

354 = units.shp  frame #116

---

Edited July 4, 2022 by Nyerguds

[MrFlibble]

I gotta try the worm camouflage on the Saboteur, so as to get the golden mean between the completely invisible one from v1.0 and the perfectly visible one from v1.07 :)

[Nyerguds]

Oh wow, I just tried that out... it's absolutely great :)

[MrFlibble]

We can get a Stealth Tank or a Stealth Raider his way ;)

BTW, setting Unknown026 to 16 makes a unit totally invisible (no sprite and no selection marker), like the Saboteur from 1.0. Most units have this set to 22.

[Nyerguds]

ah man... It seems they compressed ALL booleans into bit switches... this is gonna be a mess to figure out.

I uploaded a saboteur vid on YT, but unfortunately the compression makes the saboteur even less visible.

It's nice that YT supports DosBox' own 256-colour video format as input though :)

[XTF]

ah man... It seems they compressed ALL booleans into bit switches... this is gonna be a mess to figure out.

What's the problem with bit flags?

[Nyerguds]

Because it's harder to see that a value is indeed a bunch of bit flags, and not just, well, a value.

It's already hard to sort this data out because there's no visible separation between the values. In C&C the unit data is program code (a CreateUnitType function call with all actual unit data as parameters), meaning there are Push (assembler) commands in between, neatly separating the data. Since this is not the case here, I don't know if they're single bytes, grouped by two, or grouped by four. These grouped booleans just complicate it more. In C&C1, all booleans were single bytes, making them easy to identify and compare with the other units' boolean values. In fact, before I realized they were grouped in bytes I had the impression that all of the data that C&C had in separate booleans were simply properties of the MovementType here.

I could make a Bit Flags data type and give it to all unknown single bytes, so they're all displayed as binary by default. May help me to figure out more of them, and will definitely make them easier to compare between units.

[XTF]

Because it's harder to see that a value is indeed a bunch of bit flags, and not just, well, a value.

Doesn't a disassembler like IDA give you an idea of the struct layout?

You might even be able to see where and how the struct is accessed.

[Nyerguds]

Nope.. it can't disassemble Dune II correctly because of its inbuilt memory manager. All non-local references are gone.

[MrFlibble]

Aww, this means solving problems like concrete bug will be a lot more complicated, right?

all aircraft typically seem to have option #1 enabled

I just thought, all aircraft have transparent shadows that are actually the same sprite with transparency. Ground vehicles all have gray shadows which are parts of their sprites. Maybe option 1 enables the transparent shadows? (haven't tried that out yet)

About the saboteur, I think it would be a nice twist to have him visible when he's player-controlled, and cloaked if he's computer-controlled (somewhat like the spy in RA1). At least, this is what I think the developers originally intended...

[Nyerguds]

Well, I can disassemble the code, but not the text references to strings like "Concrete". I can adapt the code, but it's horribly hard to find what to adapt.

In C&C1 I got a similar problem, but it's easier to figure out since I can compare it to the (pretty similar) C&C95 code, so I can still hack it. I already hacked it to put DOS C&C permanently into Funpark mode.

[MrFlibble]

Maybe option 1 enables the transparent shadows?

No, it doesn't. Or, at least, it doesn't do it for non-aircraft unit types.

[MrFlibble]

I wonder if it is possible to edit the EXE to reinstate the crumbled wall frames as seen on this pre-release screenshot:

And maybe also the shattered concrete tiles, too?

EDIT: I think I wasn't thinking quite clearly when I posted this... Guess I meant the difference that in this build of Dune II shown on the screenshot, walls could be either put on concrete or bare rock. Perhaps, at some point of Dune II development, the other structures' frames also had transparent parts, so that it would be visible if a structure was placed on bare rock instead of concrete foundation (like it is done in the Dune 2: The Sleeper Has Awakened remake). If this is the case, it is sad the guys at Westwood dropped this nice idea (maybe it was memory-straining or something?).

[Nyerguds]

Heh. An MCV doesn't even want to deploy on concrete -_-

[2468_1454213254]

Hi, people. :) I've just started trying Nyerguds' editor. I need to ask a couple of questions:

- Comparing the soldier and the trooper, I see that the weapon ranges are different, but the "weapon type" parameter is the same: "Bullet". But we all know that the trooper uses two weapons: normally a rocket launcher, but a machinegun at close range. So how can we see this in the code? The trooper isn't actually shooting a machinegun at targets five squares away, instead it switches automatically to rockets... ???

- Would it be possible to make the quads have the same weapons as a squad of troopers, i.e. two unguided rockets as primary weapon, two machinegun bursts at close range? (Dune 2000 comes to mind...)

- What value tells us which is the building a newly-built unit will be deployed from? That is, soldiers from barracks, trikes from light factories, and so on...

Thanks, that's all for now. I'll keep trying the editor on my own... It's looking pretty good so far, by the way. Congrats, Nyerguds. :)

[2468_1454213254]

OK, two more questions... :)

- Some units fire two shots every time they attack. For example, a single soldier fires once, but a squad fires twice. A tank fires once, a siege tank or devastator fires twice. Moreover, a damaged unit that normally fires twice can only fire once (after the hit point bar turns yellow).

So in the code, what tells us whether a (undamaged) unit will fire once or twice? (Or perhaps even more times?)

- Is it possible to add our own sound effects somehow? ;D

(I'm thinking maybe another modding tool is needed for this...)

[Nyerguds]

Quote

Hi, people. I've just started trying Nyerguds' editor. I need to ask a couple of questions

Before you start, keep in mind this editor is a work in progress, and that most of the stuff has yet to be identified. So if stuff isn't in the editor yet, chances are it's amongst the unidentified data. Because of this, I won't be able to help you much. But if you identify new data, be sure I'll test it out and add it to the editor if it's correct

Quote

- Comparing the soldier and the trooper, I see that the weapon ranges are different, but the "weapon type" parameter is the same: "Bullet". But we all know that the trooper uses two weapons: normally a rocket launcher, but a machinegun at close range. So how can we see this in the code? The trooper isn't actually shooting a machinegun at targets five squares away, instead it switches automatically to rockets... ???

Not a clue. In fact, since no data seems to point at the units having any ability to have secondary weapons, this may be an exception handled in the actual program code that makes the unit shoot, rather than in the unit data list.

Quote

- Would it be possible to make the quads have the same weapons as a squad of troopers, i.e. two unguided rockets as primary weapon, two machinegun bursts at close range? (Dune 2000 comes to mind...)

Kinda the same answer as the previous one... not a clue.

Quote

- What value tells us which is the building a newly-built unit will be deployed from? That is, soldiers from barracks, trikes from light factories, and so on...

Um... look at the buildings section. Each building has a list of units it can construct. It doesn't work the other way around. You can just as easily make a barracks construct tanks. It'll probably work just fine.

Quote

- Some units fire two shots every time they attack. For example, a single soldier fires once, but a squad fires twice. A tank fires once, a siege tank or devastator fires twice. Moreover, a damaged unit that normally fires twice can only fire once (after the hit point bar turns yellow).

So in the code, what tells us whether a (undamaged) unit will fire once or twice? (Or perhaps even more times?)

Uhh, define "code". If you mean the options you can edit in the editor, that's not code. It's just binary data. Code are program instructions that are actually executed.

Also, please keep in mind this editor started as a straight port of an older editor, with the sole purpose of being able to edit more Dune II versions, so there hasn't been very much research into the unknown data.

As for this specific data, I've noticed that all booleans (on/off switches) are packed together in bytes, so you'll have to use binary mode (F2) to look through the unknown data, compare it between the units and see if one of the bits has the correct setting on each one to be the "fires weapons twice" switch. Full hexadecimal mode (F11) can also be a help for this, since it shows the actual data as bytes. I wish I could implement a full binary mode too, but the right-side column isn't wide enough for that.

Quote

- Is it possible to add our own sound effects somehow? ;D

(I'm thinking maybe another modding tool is needed for this...)

I doubt it. I've had to do some really serious hacking to get that done in C&C95, and I can't do that here for tons of reasons, like the fact Dune II is a 16-bit DOS program with a memory manager. I can't disassemble correctly, and the fact the exe is divided into lots of tiny data sections, one for each piece of data, and I can't expand those.

To compare, adding new sounds to the internal sounds list is really pretty much the same thing as adding entirely new units. Which I really won't ever be able to do in Dune II.

Edited July 30, 2018 by Nyerguds

[MrFlibble]

EMC_analysis.txt

[2468_1454213254]

Thanks, MrFlibble and Nyerguds. :) I appreciate your help.

Wow, this editor is really something exciting... :)

Before you start, keep in mind this editor is a work in progress, and that most of the stuff has yet to be identified. So if stuff isn't in the editor yet, chances are it's amongst the unidentified data.

Also, please keep in mind this editor started as a straight port of an older editor, with the sole purpose of being able to edit more Dune II versions, so there hasn't been very much research into the unknown data.

I understand. It's no surprise that this takes a lot of good old-fashion hacker work... ;D

I've used the editor to make minor modifications to Dune 2 on my system. So far it's working out pretty well. I'll let you know if I can find something new, we'll see...

Um... look at the buildings section. Each building has a list of units it can construct. It doesn't work the other way around. You can just as easily make a barracks construct tanks. It'll probably work just fine.

Got it. And I'm suddenly feeling tempted to make either a WOR or a Barracks produce both Infantry and Troopers for all houses, without having to build two different buildings, like in Dune 2000... ;D

Uhh, define "code". If you mean the options you can edit in the editor, that's not code. It's just binary data. Code are program instructions that are actually executed.

You're right. My bad. :P

To compare, adding new sounds to the internal sounds list is really pretty much the same thing as adding entirely new units.

That sucks. But I guessed as much, anyway. :)

Thanks again, guys.

[2468_1454213254]

I've attached an analysis of BUILD.EMC I made when re-writing Minniatian's patch for v1.07 - perhaps you'll find it useful.

Wow... :) That's interesting. I used to study something like that... But where are all the functions defined that are called by the Exec command?

[Nyerguds]

He linked to those.. they're the numbers listed here.

Heh... actually, that code is pretty much what programming in Assembler (REAL hacking ;) ) looks like. I wonder though, the goto comand, does it work relative (jump forward/backward ## bytes) or absolute (jump to byte ###)?