Dune II editor with 1.07 support

[dynasty]

Works great. I have problems running your editor under wine for some reason, but now that I've substituted CREDITS.FRE with PROFILE.INI in the exe, I can just edit the profile.ini file directly, which makes testing things out in dosbox so much easier.

[Nyerguds]

Well, not sure how well WINE handles console apps. And I don't think the editor runs in DOSBox since it's not a DOS app.

You could just compile it in Linux, though. Just install the Lazarus FreePascal IDE.

Source code for all versions is here:

http://nyerguds.arsaneus-design.com/dune/dune2edit/source/

You may have to change the "framechar" constant from "@charsetdos" to "@charsetascii" before compiling though, since the editor uses special characters from the DOS-437 character set for drawing the layout frames.

On 10/26/2012 at 9:24 AM, dynasty said:

but now that I've substituted CREDITS.FRE with PROFILE.INI in the exe, I can just edit the profile.ini file directly, which makes testing things out in dosbox so much easier.

Huh? For what purpose?

Edited August 14, 2018 by Nyerguds

[Nyerguds]

On the Wine issue, does this help?

heyo, as I wasn't able to figure out how to run your editor under wine in the past,

and rediscovered the issue again when trying tonight:

$ wine d2editor.exe

"No way to get console screen buffer info"

I figured that I'd share how trivial it was to get working with others,

just execute it with 'wineconsole d2editor.exe' rather than 'wine d2editor.exe'.

Pretty simple :)

[dynasty]

Huh? For what purpose?

Hm, you're right. Turns out OpenDune was converting the string to lower-case and therefore not finding the file.

On the Wine issue, does this help?

Ah, that fixes it. Thanks.

[Nyerguds]

Hm, you're right. Turns out OpenDune was converting the string to lower-case and therefore not finding the file.

I'm not even sure what you were trying to do... are you talking about Dune Dynasty or my editor now?

In windows, filenames are case insensitive, but for the record, the internal file name used by my editor is lower case "profile.ini", both for reading and writing.

[dynasty]

Nothing wrong with your editor.

I'm testing for consistent mechanics between OpenDune and Dune 2. I'm using profile.ini to create Super Trikes as Atreides, Super Raider Trikes as Ordos, switching on instant build on some buildings, etc. At the moment, I'm investigating at these issues:

1. Soldiers entering structures seem to do too much damage. In OpenDune, soldiers will do half the building's current HP worth of damage. This means three soldiers can capture a structure at full health, turning them into "semi-engineers". I quite like this mechanic though, so I might just keep it around as an option.

2. The AI in OpenDune doesn't seem to place structures down.

[MrFlibble]

2. The AI in OpenDune doesn't seem to place structures down.

You mean it rebuilds lost structures in the ConYard but doesn't place them?

Curious, this is what happens in Dune II v1.0: the AI does build a structure that is on its rebuild list, but then does not place it; instead, it goes on to build it again (or at least this is the impression I got from testing the issue by destroying a structure and then capturing the AI's construction yard).

[dynasty]

You mean it rebuilds lost structures in the ConYard but doesn't place them?

Curious, this is what happens in Dune II v1.0: the AI does build a structure that is on its rebuild list, but then does not place it; instead, it goes on to build it again (or at least this is the impression I got from testing the issue by destroying a structure and then capturing the AI's construction yard).

It rebuilds lost structures but doesn't place them, yes. Basically, the Dune II v1.07 AI is allowed to place the structure over the top of units*. To prevent this(?), the OpenDune code runs the same tests as those used when checking the position of a player placed structure. The test, however, checks whether the structure is connected to the player's structures, and so the AI rarely gets to place a built structure. (We don't really want the connectivity test for the AI anyway.)

This appears to be the same as the v1.0 bug, or is at least very closely related: if you destroy a structure and deploy an MCV next to where it was, the AI will build and place that structure!

* There was a thread discussing whether this was good or bad, but I can't seem to find it. A link would be greatly appreciated.

[Nyerguds]

well, You can always give the test function an extra boolean parameter to make it differentiate between AI rebuilding checks and player build checks, and just set it to True and False accordingly.

[MrFlibble]

This appears to be the same as the v1.0 bug, or is at least very closely related: if you destroy a structure and deploy an MCV next to where it was, the AI will build and place that structure!

Wow, interesting! I wonder if it works in v1.0 the same way?

* There was a thread discussing whether this was good or bad, but I can't seem to find it. A link would be greatly appreciated.

Here you go :)

[dynasty]

Wow, interesting! I wonder if it works in v1.0 the same way?

Yes, that was what I meant. It works like that in both v1.0 and OpenDune.

Curious, this is what happens in Dune II v1.0: the AI does build a structure that is on its rebuild list, but then does not place it; instead, it goes on to build it again (or at least this is the impression I got from testing the issue by destroying a structure and then capturing the AI's construction yard).

Nice find! As far as I can tell, this is indeed what it does:

When the AI finishes building a structure, it loops over its rebuild list and tries to place the built structure wherever a structure of the same type used to be. If it can't find a valid position, it cancels the finished building, but the rebuild list is not modified.

This isn't a problem in v1.07 because the AI is allowed to place a structure wherever it pleases, and so it can only reach the end of the list if the current building type is no longer in the rebuild list. e.g. you destroyed more than 5 structures, or another construction yard already rebuilt that structure. (If the AI has two construction yards, it seems like it will build the same structure from both construction yards. This causes it to temporarily waste money on the second structure, but it does get a refund for cancelling it.)

However, in v1.0, the AI can fail to place a structure that is on the rebuild list because of the connectivity test. As a result, it will cancel it and rebuild it over and over again.

Here you go :)

Thanks. It seems TrueBrain was going to leave the AI building on units behaviour in the game, but they seem to have restored the v1.0 behaviour somewhere along the way. Blocking the position with a tank seems like a legitimate tactic to me though. It's not really that easy to hold the position when the AI rebuilds rocket turrets.

[MrFlibble]

When the AI finishes building a structure, it loops over its rebuild list and tries to place the built structure wherever a structure of the same type used to be. If it can't find a valid position, it cancels the finished building, but the rebuild list is not modified.

This isn't a problem in v1.07 because the AI is allowed to place a structure wherever it pleases, and so it can only reach the end of the list if the current building type is no longer in the rebuild list. e.g. you destroyed more than 5 structures, or another construction yard already rebuilt that structure. (If the AI has two construction yards, it seems like it will build the same structure from both construction yards. This causes it to temporarily waste money on the second structure, but it does get a refund for cancelling it.)

However, in v1.0, the AI can fail to place a structure that is on the rebuild list because of the connectivity test. As a result, it will cancel it and rebuild it over and over again.

Ah, that explains a lot. I suspected that the behaviour in v1.0 was caused by the placement rules check, but didn't realise the game still checked for player-owned structures when dealing with AI structures.

It seems TrueBrain was going to leave the AI building on units behaviour in the game, but they seem to have restored the v1.0 behaviour somewhere along the way. Blocking the position with a tank seems like a legitimate tactic to me though. It's not really that easy to hold the position when the AI rebuilds rocket turrets.

Well, at least in Dune II you can prevent the AI from rebuilding defences by capturing turrets with infantry. In C&C, this tactic is obviously impossible since defensive structures are not capturable.

[Nyerguds]

Well, at least in Dune II you can prevent the AI from rebuilding defences by capturing turrets with infantry. In C&C, this tactic is obviously impossible since defensive structures are not capturable.

The C&C1 AI sends units to destroy anything blocking their rebuilding, so even capturing doesn't work that well ;)

---

Hmm... seems the first value of the Terrain info is also a name ID. The OpenDune code said it was unused, though.

That reminds me, there were Hint strings for the terrain types in the strings file too IIRC... maybe the game used to have a system for showing hints on terrain, just like it can still do on buildings?

[edit]

Yep! Last value is the hint string ID in message.eng :D

[edit]

http://nyerguds.arsaneus-design.com/dune/dune2edit/d2editor_v2.01.1.zip :)

[edit again]

Added full support for both reading and writing of Dynasty's profile.ini format. This means you can use the editor to experiment in Dune II, and immediately export its settings to Dune Dynasty :D

http://nyerguds.arsaneus-design.com/dune/dune2edit/d2editor_v2.02.0.zip

Heck, as long as you got a Dune II exe around, you can just use the editor as easy GUI for building mods in Dune Dynasty :)

(you may need to put the 'full CPU cycles' option on Yes for all units before starting, though)

Small question for Dynasty... your example profile.ini has [unitInfo] lines with sound IDs above 64, which is the highest value I got in my editor's sounds list. Does your source code have a complete list of those somewhere?

The list I got is this:

  sounds: array[0..35] of values =
  (
    (val: -1; txt: 'None                       '),
    (val: 00; txt: 'Not Applicable             '),
    (val: 20; txt: 'Place down                 '),
    (val: 22; txt: 'Twinkling                  '),
    (val: 23; txt: 'Intro chord                '),
    (val: 24; txt: 'Carryall dropoff           '),
    (val: 30; txt: 'Infantry kill 1       (VOC)'),
    (val: 35; txt: 'Infantry kill 2       (VOC)'),
    (val: 33; txt: 'Infantry kill 3       (VOC)'),
    (val: 34; txt: 'Infantry kill 4       (VOC)'),
    (val: 31; txt: 'Infantry kill 5       (VOC)'),
    (val: 36; txt: 'Infantry crush        (VOC)'),
    (val: 38; txt: 'Click                 (VOC)'),
    (val: 39; txt: 'Missile               (VOC)'),
    (val: 40; txt: 'Hit sand              (VOC)'),
    (val: 41; txt: 'Tank shot             (VOC)'),
    (val: 42; txt: 'Rocket                (VOC)'),
    (val: 43; txt: 'Sonic wave                 '),
    (val: 44; txt: 'Structure crumble     (VOC)'),
    (val: 46; txt: 'Death Hand target          '),
    (val: 47; txt: '"Cannot Place" beep        '),
    (val: 49; txt: 'Tank shot             (VOC)'),
    (val: 55; txt: 'Tank shot             (VOC)'),
    (val: 51; txt: 'Exploding unit        (VOC)'),
    (val: 52; txt: 'Money increase             '),
    (val: 53; txt: 'Money decrease             '),
    (val: 54; txt: 'Weapon hit                 '),
    (val: 56; txt: 'Tank shot             (VOC)'),
    (val: 57; txt: 'Tank shot             (VOC)'),
    (val: 58; txt: 'Single gun            (VOC)'),
    (val: 59; txt: 'Machinegun            (VOC)'),
    (val: 60; txt: '"Constr. Complete"    (VOC)'),
    (val: 61; txt: 'Plingplong                 '),
    (val: 62; txt: 'Radar static          (VOC)'),
    (val: 63; txt: 'Worm attack           (VOC)'),
    (val: 64; txt: 'Mini Rocket           (VOC)')
  );

(what is that horrible code tag doing to my poor, poor spaces? :O)

[edit yet again :P]

Fixed a minor bug that would ignore my custom set length (amount of bytes) for the ini data to write into the exe, if a value in the ini was given as decimal while the editor has it set to be written into the ini as hexadecimal. This was a side effect of the fact the custom-length logic is part of the system that makes it write hex bytes into the ini rather than an int value. All data can now correctly be read both decimally and hexadecimally, no matter how it is set to be written into the ini.

http://nyerguds.arsaneus-design.com/dune/dune2edit/d2editor_v2.02.1.zip

[dynasty]

Added full support for both reading and writing of Dynasty's profile.ini format. This means you can use the editor to experiment in Dune II, and immediately export its settings to Dune Dynasty :D

Awesome, thanks!

Heck, as long as you got a Dune II exe around, you can just use the editor as easy GUI for building mods in Dune Dynasty :)

(you may need to put the 'full CPU cycles' option on Yes for all units before starting, though)

Just to clarify, I specifically didn't assign the "full CPU cycles" (scriptNoSlowdown in OpenDune) option; it will always be yes. It doesn't make sense now with variable viewport sizes anyway. The other thing that can't be changed is "Tab selects this"; tab selection isn't implemented in Dune Dynasty anyhow, and I also used that value to see what can be box selected. And you probably shouldn't change some things like "Is factory". Anyway, the code is in scenario.c if you need a reference at any stage.

Finally, when I was doing the Super Dune II profile, I discovered that in Super Dune II, the units don't have the "Is a priority target" option set. This seems to make units on guard not fire at enemy units in range. The AI will charge at your structures unless attacked(?), which seems like v1.0 behaviour, but your own units must be targetted manually. MrFlibble, can I get some clarification on this please?

Small question for Dynasty... your example profile.ini has [unitInfo] lines with sound IDs above 64, which is the highest value I got in my editor's sounds list. Does your source code have a complete list of those somewhere?

The SoundID enumeration and the g_table_voiceMapping in sound.h and sound.c:

http://sourceforge.n...le/sound.h#l219

http://sourceforge.n...le/sound.c#l504

const enum SampleID g_table_voiceMapping[SOUNDID_MAX] = {
...
0xFFFF, /* 43: Sonic Tank */
...
SAMPLE_BLASTER, /* 65: Harkonnen end game */
SAMPLE_GLASS, /* 66: Harkonnen end game */
SAMPLE_LIZARD, /* 67: Ordos end game */
SAMPLE_FLESH, /* 68: Harkonnen end game */
SAMPLE_CLICK, /* 69: Harkonnen end game */
...
SAMPLE_INTRO_WIND, /* 108 */
0xFFFF, /* 109 */
SAMPLE_INTRO_HARVESTER, /* 110 */
0xFFFF, /* 111 */
SAMPLE_INTRO_FIRE_ORNITHOPTER_TROOPER, /* 112 */
SAMPLE_INTRO_BREAK_GLASS, /* 113 */
SAMPLE_INTRO_FIRE_LAUNCHER, /* 114 */
0xFFFF, /* 115 */
0xFFFF, /* 116 */
SAMPLE_INTRO_CARRYALL_FRIGATE, /* 117 */
SAMPLE_INTRO_TROOPER_EXPLODE1, /* 118 */
SAMPLE_INTRO_TROOPER_EXPLODE2 /* 119 */
};

Things called SOUND_* in the enumeration play a VOC file, whereas things called EFFECT_* are synth effects (e.g. sonic tank). I'm pretty sure SoundIDs 70 through 107 are unused.

In one case (SoundID=38), the same SoundID is used for both BUTTON.VOC and also for the synth effect EFFECT_HALL_OF_FAME_END_METER. This is the little "ping!" you get when the meter in the Hall of Fame gets completely filled up. If you changed something's SoundID to 38 (e.g. on an action), it would probably play BUTTON.VOC. I'm not sure if BUTTON.VOC is actually used in Dune II; the clicky response sound you heard in Dune Dynasty when you had multiple infantry selected and ordered them to guard was originally a bug.

It might be fun to make harvesters play soundID 110 as a selection response sound, but I'm not sure if it is possible at this stage.

[Nyerguds]

Huh... the comment above g_table_voiceMapping says "Sounds mapped to SAMPLE_INVALID are effects", but the table itself just uses 0xFFFF manually everywhere :P

Where are these defined sound IDs from SoundId used, though? It seems like the list just identifies some specific numbers rather than having a full list. g_table_voiceMapping seems to be incomplete as well, and doesn't seem to use the SoundId table values... or does that one just indicate which ones have a .voc file?

Some values just plain don't seem to match, either... I got the squish sound as 36, while the Dynasty code has it as 35. I better re-test this. It'd be annoying if there were version differences in that list as well... though, I got a system of making data like that version-specific, at least -_-

And you probably shouldn't change some things like "Is factory".

But, is it read or not? I kinda wondered why the [Factory] stats didn't have that as first parameter, actually, before realizing it was in the ObjectFlags :P

[Nyerguds]

It looks like my fixing of the special keys input has some nasty side effects; because it clears the character buffer on every single character read, you can't paste values into the program anymore, and can't give navigating commands faster than the program refreshes. I think I fixed it all now, but I'm going to look into this sounds thing before releasing a new version.

[dynasty]

Where are these defined sound IDs from SoundId used, though? It seems like the list just identifies some specific numbers rather than having a full list. g_table_voiceMapping seems to be incomplete as well, and doesn't seem to use the SoundId table values... or does that one just indicate which ones have a .voc file?

I'm afraid I don't quite understand your question, but I guess I should try to explain this better.

The SoundIDs correspond to the things you have listed as "weapon sound" in the your unit table. They are also used in explosion scripts, cutscenes, and various other non-tabulated places*. As the comment says, g_table_voiceMapping maps a SoundID to a SampleID, meaning that it takes SoundID as an index, and returns a SampleID. Hence the types on the array:

enum SampleID g_table_voiceMapping[SOUNDID_MAX].

So the SoundID enumeration and the g_table_voiceMapping are really the same list. A SampleID corresponds to a VOC file, which is the g_table_voices[sAMPLEID_MAX] array above.

When the game is told to play a sound by a SoundID, it remaps that value using g_table_voiceMapping to get either a SampleID or SAMPLE_INVALID (0xFFFF). If it is a SampleID, and if sound blaster sounds are available, it goes and plays the appropriate VOC file by looking up the g_table_voices table. Otherwise, it plays a synth effect using the given SoundID number as the track number (from the same ADL file as that of the current music being played).

Example 1: mini-rocket fired.

Mini-rocket has a weapon sound of 64 (SoundID = SOUND_MINI_ROCKET).

g_table_voiceMapping[64] = SAMPLE_MINI_ROCKET (27).

g_table_voices[27] => "+MISLTINP.VOC".

So we play that VOC file.

Example 2: sonic tank blast.

Sonic tank has a weapon sound of 43 (SoundID = EFFECT_SONIC_BLAST).

g_table_voiceMapping[43] = 0xFFFF (SAMPLE_INVALID).

So we play track 43 of the current ADL file, which happens to be the wavy sound.

The list is basically complete. SoundIDs 0..19 are where some of the music is stored (varies depending on the current ADL file), and 70..107 appear to be unused. As far as I know, the remaining entires in g_table_voiceMapping that don't have a name in the SoundID enumeration are either silent or unused (0xFFFF but can't distinguish them), played through the explosion scripts (listed in the comments), or played in the introduction (SAMPLE_INTRO_*).

* Note that the "response sound" in your action table is not a SoundID, but is a SampleID. It doesn't go through the g_table_voiceMapping step. Instead, it skips directly to the g_table_voices step.

Some values just plain don't seem to match, either... I got the squish sound as 36, while the Dynasty code has it as 35. I better re-test this. It'd be annoying if there were version differences in that list as well... though, I got a system of making data like that version-specific, at least -_-

It seems you skipped over index 32 in the soldier death sounds. Infantry kill 2 should be moved from 35 to 32, crush should be 35, and the set target confirmation sound should be 36.

But, is it read or not? I kinda wondered why the [Factory] stats didn't have that as first parameter, actually, before realizing it was in the ObjectFlags :P

Yes, it is read.

[dynasty]

A few points:

• The explosion type field in the profile.ini exporter is wrong.  It should correspond to the "special animation" field in your editor. e.g. 13 for sandworm.
  
• It might be worth noting that "tech level" only applies to structures, contrary to what the OpenDUNE comment says.  To limit a player's buildable unit options, you can only use the upgrade level required and prerequisite structure fields.
  

[Nyerguds]

The explosion type field in the profile.ini exporter is wrong.  It should correspond to the "special animation" field in your editor. e.g. 13 for sandworm.

Hmm. Why "explosion type" then? I thought for the sandworm that was its bite animation. What does this animation actually do, and is there an actual list of them? I'd love to add that list into my editor.

 

Anyway, I fixed it in my code.

It might be worth noting that "tech level" only applies to structures, contrary to what the OpenDUNE comment says.  To limit a player's buildable unit options, you can only use the upgrade level required and prerequisite structure fields.

Huh. that would explain why they're all on '0' :P

[dynasty]

The sandworm bite animation is an explosion, i.e. the pixel-based animation things.  It normally looks tile-based, but that's a side effect of how sandworm swallowing works.  You can tell because you can only have one explosion per tile.  When you're attacking the worm, and it swallows your unit, often the bite animation doesn't complete because it gets interrupted by a bullet explosion animation.

 

BTW, I couldn't figure out what your previous numbers corresponded to.

 

 

The list of explosions is unnamed.  There are 20 explosion types (0..19) and -1 for invalid, in table/explosion.c.  Anyway, some magic numbers:

 

0..3: bullet and rocket explosions. (somewhat randomly chooses between them)

4: saboteur explosion (killed, or reaching destination).

5: saboteur explosion 2, delayed (when entering structure?)

6: tank explosion?

7: deviator gas green puff.

8: something to do with sand.

9: tank flames.

10: wheeled vehicle explosion.

11: death hand explosion.

12: ?

13: sandworm bite.

14: building explosion?

15: critical damage smoke.

16: ornithopter death.

17: carryall death.

18: mini rocket explosion.

19: spice bloom.

 

You can test these out by changing the (deviator) grocket's explosion type in Dune II or Dynasty, but not others (e.g. bullets).  Not a very useful thing to adjust, but I guess you could experiment with making deviators launch suicidal ornithopters that deviate enemies  :P

[Nyerguds]

On the old value, it seems I messed up, and just took the only thing explosion-related I had. The v2.02.1 code says it's option 43, which would be the "Explode when dying" boolean. Which is actually a bit switch in an entire byte of booleans. I'm not even sure if using these bit switches even works correctly on this system, since all but the eighth one are handled as having a length of 0 bytes, internally, and this function needs a length  :|

[MrFlibble]

I'm not sure I'm entirely following, but speaking of the explosion animations, is it possible to change the wheeled vehicle explosion animation of the Sardaukar Trooper in DuneX to something else by editing the EXE after all? Or is it something that is "had-coded" in UNIT.EMC?

[dynasty]

The explosion type (10) is hard-coded into UNIT.EMC.  Luckily, this should be easily fixable.  There's an offset table at the start of UNIT.EMC, 4 bytes past ORDR, which tells each unit type what script to run.  If you change the offset for the raider trike to that of a trooper, then it should behave like a trooper.  Not sure if there are differences between soldier/infantry and trooper/s, so you might want to change that too.

06e1 -- Carryall0654 -- Ornithopter05f0 -- Infantry0609 -- Troopers0622 -- Soldier063b -- Trooper...0826 -- Raider trike -- change this to 0x0609...0958 -- Frigate

Don't you like how it damages the tanks that crush them though?

 

Edit: Added wheeled vehicle explosion into the list above.

[MrFlibble]

Thanks a lot for the info!

Don't you like how it damages the tanks that crush them though?

I sure do, it's just that i was thinking that different explosion graphics (like that of the Saboteur for example) would be more fitting.

By the way, one more thing about the DuneX Sardaukar is that it seems that they do more damage (compared to other infantry types) when entering enemy structures. My suspicion was that this type of damage is somehow dependent on the hit points of the infantry units (since Sardaukar Troopers have more HP than other infantry types), but I never bothered to actually verify this.

[dynasty]

I sure do, it's just that i was thinking that different explosion graphics (like that of the Saboteur for example) would be more fitting.

Apparently OpenDUNE put some work into decoding the EMCs.  It is mentioned in the developer blog section.  Never noticed it before.

 

Looking at that, it seems safe to change the explosion type of the raider trike.  So in UNIT.EMC, around bytes 0x10B4 you should see: 44 0A 4E 0E.  This means push (44) explosion type (0A) execute function (4E) spawn explosion (0E).  So just change 0A to 04 for the saboteur explosion.

 

By the way, one more thing about the DuneX Sardaukar is that it seems that they do more damage (compared to other infantry types) when entering enemy structures. My suspicion was that this type of damage is somehow dependent on the hit points of the infantry units (since Sardaukar Troopers have more HP than other infantry types), but I never bothered to actually verify this.

That's right.  The formula is min(unit->hitpoints * 2, structure->hitpoints / 2).

 

P.S. OpenDUNE has some updates.