Jump to content

Dune II editor with 1.07 support


Recommended Posts

  • 3 weeks later...
Posted

Hmm, just checked the Files section, and the sizes for PAK files seem to be all wrong in v1.07 (haven't checked v1.0 yet). I wonder if those are really used by the game, 'cause if they are, this certainly leads to some spectacular file size miscalculations...

  • 2 weeks later...
Posted

A lot of data like that is in fact filled in on startup. I'd assume it's the same with those. The ones visible in the editor could just be some original data from some old internal beta.

Posted

Which basically means that fixing the file sizes isn't going to positively affect the game (e.g. the sound issues with Windows*)?

* I've had reports that even with the speech files fixed and XMS properly configured, there's still unstable behaviour when playing under XP, especially noticeable if played for a long time. Didn't have any time to test that myself though.

  • 2 weeks later...
  • 8 months later...
Posted (edited)

After looking for better ways to organize my internal data in the editor, I've come across the neat feature of pointers in FreePascal. Using this system, I managed to remove the code exception for the differences in graphics lists for the demo and 1.00 version compared to all the others.

I didn't stop there, though. The pointers opened a world of possibilities, and I've taken the chance to completely reorder everything. This means that instead of needing 5 or 6 arrays of the same size for storing information of different kinds for all different Dune II versions, I now have a neat array of versions, with one block per version containing all necessary information. The same has been applied to the information of editable data types. This more customizable system also allowed me to build in a system to support data types that don't have a name string in their data.

This last change allowed me to implement new lists found in the OpenDune data, namely music, voices, and Terrain. The first two don't really have much to edit, but the Terrain options allow editing movement speed modifiers for all terrain types, for all movement types, so that's pretty neat :)

And while I was at it anyway, I kicked out the internal traffic based on an array of four bytes, in favour of using the 'Cardinal' type, FreePascal's 32-bit unsigned integer. This also led me to extend decimal editing to both a signed (F4) and unsigned (F5) variant.

With all these changes, I've decided to leave Dune II Editor v1.0 behind forever. So it is with some pride that I present to you:

Dune II Editor v2.00.0

image.png.25a16741147a629dd9d00af5b9b9247b.png

Edited by Nyerguds
  • Upvote 1
Posted

One of the neat things I noticed from this data is that Sandworms can't move onto the transition cells between rock and sand, even the ones that are mostly sand and can't be built on. That's the type indicated as 'sand edge' in the editor. The 'mostly rock' type, which you can build on, is indicated as 'rock edge'. This is the only transition for which there seem to be 2 types though.

Oddly enough, most unit types seem to have particular slowdowns on these transition areas, compared to the normal terrain.

[edit]

Oh, and I guess 'Broken wall' should probably just be be 'Rubble' in general. I just copied that from the OpenDune source.

On a related note, Spice Value '-1' means the terrain can be converted to spice by blooms or destroyed harvesters. I'm not sure if the spice value itself actually WORKS as spice value, mind you, since the entire value was replaced by nothing more than a 'can become spice' boolean in the OpenDune code. Then again, they might just have moved the spice/thick spice value indicators to some more general data constants file.

  • Upvote 1
Posted

Oddly enough, most unit types seem to have particular slowdowns on these transition areas, compared to the normal terrain.

Yes, I've noticed that in Dune II, I'm guessing that maybe this was done to represent the elevation of the rocky ground over the sand: units have to go upwards when they move onto rock from sand, and they had to slow down when they move down onto sand, especially since sand is less stable than rock.

What doesn't seem immediately obvious to me though is why tracked units gain speed on sand hills.

Oh, and I guess 'Broken wall' should probably just be be 'Rubble' in general. I just copied that from the OpenDune source.

"Broken wall" is a separate tile that is not used as generic rubble for buildings. A bit annoying here is that the structure rubble is solid tiles with no transparency (unlike the wall rubble), so destroyed structures that were built on rock/sand edges leave rubble that looks unnatural because of its rectangular shape.

I considered editing the regular rock pattern background away from structure rubble tiles sometime ago, but didn't have the time and patience to actually do that.

Posted

"Broken wall" is a separate tile that is not used as generic rubble for buildings. A bit annoying here is that the structure rubble is solid tiles with no transparency (unlike the wall rubble), so destroyed structures that were built on rock/sand edges leave rubble that looks unnatural because of its rectangular shape.

I considered editing the regular rock pattern background away from structure rubble tiles sometime ago, but didn't have the time and patience to actually do that.

That's an interesting addition. The graphic edits don't really need to be all that spectacular. Just masking out the corners with the fog tiles looks really good. For the destroyed turret, you would cut out a little bit from each corner and apply a slight stipple pattern.

The destroyed structures would need to revert the terrain back to rock or rock/sand (which shouldn't be all that hard in Dune Dynasty, and might be possible in the Dune 2 animation scripts). You can only have one transparent overlay per tile though, so you wouldn't be able to have soldiers and craters on those tiles.

  • Upvote 1
Posted

"Broken wall" is a separate tile that is not used as generic rubble for buildings. A bit annoying here is that the structure rubble is solid tiles with no transparency (unlike the wall rubble), so destroyed structures that were built on rock/sand edges leave rubble that looks unnatural because of its rectangular shape.

This is about terrain types though, not about tiles. I think the thing indicated as 'broken wall' in the list is actually applied to all rubble. There's nothing else in the list that could be the 'rubble' settings, and I'm fairly sure rubble has a different radar colour from normal rock (which is one of the settings here).

The destroyed structures would need to revert the terrain back to rock or rock/sand (which shouldn't be all that hard in Dune Dynasty, and might be possible in the Dune 2 animation scripts). You can only have one transparent overlay per tile though, so you wouldn't be able to have soldiers and craters on those tiles.

I do notice Dune II has a bug where rubble reverts to normal terrain if the attacking units kill one of the spawned infantry units on it right after the building is destroyed. I always thought rubble and buildings actually REPLACED the terrain tiles, but the error screenshot I posted on the Dynasty thread shows it restored the original terrain corner (which may be related to why it crashed, or something, I dunno).

So I guess the rubble vanishes to show the infantry corpse, then?

[edit]

no wait, it also shows an infantry corpse ON rubble. Because rubble isn't transparent. Right. I wonder what causes the clearing bug then -_-

Posted

Right, buildings replace the terrain when you place them. When a building is destroyed, an animation script is launched which sets the terrain back to rock, creates explosions*, and later on to sets the terrain to rubble. I originally thought that you could get transparent rubble to work by setting the terrain back to rock or rock/sand, and then setting the transparent overlay at the end of the script. However, there are two problems with this:

  1. This conflicts with the soldier corpses, craters, and broken walls. This is a big deal as soldiers often die on rubble.
  2. The landscape doesn't have the properties of rubble anymore.

I think a better way would be to just make a special case in the code so that you draw the old terrain before drawing the rubble. This is something that I could do in Dune Dynasty (and saved games would still be compatible), but I'm not sure about Dune 2.

The clearing bug is due to having only be one active animation per tile. In this case, two animations are started on the same tile: the building destruction quickly followed up by the soldier death. The second causes the first animation to abort, so it never gets around to setting the debris tiles, which causes it to restore the landscape to its original state. I think this can be fixed if, instead of simply aborting the first animation, it is fast forwarded to the end.

Finally, this bug probably doesn't have anything to do with the crash you observed. But then again, I'm currently clueless about that issue (and the win 7 one), so I may as well look there. :|

*Note that explosions are a different type of animation.

Edit: Got some things wrong. The terrain doesn't go back to rock, and explosions spawn animations rather than the reverse.

  • Upvote 1
Posted

*Note that explosions are a different type of animation.

I gathered that, yes. One is icon tiles, the other SHP animations.

Thanks for the explanation on the clearing bug. It makes me wonder though... isn't the 'show rubble' "animation" a single frame anyway? Seems odd for that to abort after the rubble is already showing. Then again, the Concrete's basic animation is "show frame 2, wait 300 ticks, stop". Wonder why it needs those 300 ticks.

Posted

Hey Nyer,

Could you make your editor read and write PROFILE.INI files? The format is pretty simple:


; comment.
[construct]
object=buildCredits,buildTime,hitpoints,fogUncoverRadius,availableCampaign,priorityBuild,priorityTarget,sortPriority

[combat]
unit=fireDistance,damage,fireDelay,movingSpeed

The parameters are all unsigned shorts. That way you can make some changes without writing to the executable all the time. You need to add PROFILE.INI to the file table to use it though.

  • Upvote 1
Posted

Ahh, the good old PROFILE.INI. I wonder why no one else came up with this one. Sure, the RULES.INI the editor currently generates comtains way more info, but the original PROFILE.INI and HOUSE.INI are more authentic :)

Posted

I don't have an import for that rules file anyway. The version differences alone make it impossible :P

Can anyone point me to the profile.ini though? I'm not quite sure what to use for "object" and "unit" in that example. Is that an index? A text name?

Guess my next job is making an ini reader in Pascal... wheee.

Posted

Can anyone point me to the profile.ini though? I'm not quite sure what to use for "object" and "unit" in that example. Is that an index? A text name?

The text name. i.e. the one used in the scenarios and in the categories of your rules.ini. The ReadProfileIni() function in opendune.c and the relevant tables are linked below.

http://sourceforge.n...opendune.c#l404

http://sourceforge.n...able/unitinfo.c

http://sourceforge.n...structureinfo.c

Ahh, the good old PROFILE.INI. I wonder why no one else came up with this one. Sure, the RULES.INI the editor currently generates comtains way more info, but the original PROFILE.INI and HOUSE.INI are more authentic :)

Wait, there's a HOUSE.INI? Oh, found it. Apparently it's used in the Sega Mega Drive and/or the demo versions. That would be a nice addition too, but as far as I know, there's no way to use it in Dune 2.

http://forum.dune2k....es/page__st__40


[Harkonnen]
Decay=2
Special=Missile
Recharge=60
Weakness=89
LemonFactor=33
Voice=H
Frigate=10

Special is Missile, Fremen, or Saboteur. The mysterious LemonFactor is there too.

Posted (edited)

My editor kinda has all of that House information, dynasty. Heck, my current ini writer already dumps it:

 

Quote

[Harkonnen]
Name string reference = Harkonnen
Weakness to deviation = 200/256 (78%)
LemonFactor (?) = 85
Decay factor = 2 (damage=3)
Radar color index = 144
Palace recharge time = 600
Frigate delay time = 10
Voice prefix letter = H
Palace special ability = Death Hand
Win music = Win Harkonnen
Lose music = Lose Harkonnen
Mentat music = Brief Harkonnen
House voice reference = nhark.voc

Also, um.

 

'Nyerguds said:
Can anyone point me to the profile.ini though?

Please? Text name isn't the only thing I'm unsure about, and it's always nice to have an example :P

[edit]

Nevermind, found it here:

http://forum.dune2k.com/topic/19114-dune-2-dune-ii-editor-with-107-support/?p=345080

Really though, the fact "availableCampaign" was the first build level was really not clear :|

Anyway, the dumper works. Of course, it doesn't do any fancy formatting. From the 1.07EU exe:

Quote
; Created with Dune II Editor v2.00.0 (created by Nyerguds)

[Construct]
Carryall=800,64,100,0,0,20,16,16
'Thopter=600,96,25,5,0,75,30,28
Infantry=100,32,50,1,0,20,20,4
Troopers=200,56,110,1,0,50,50,8
Soldier=60,32,20,1,0,10,10,2
Trooper=100,56,45,1,0,20,30,6
Saboteur=120,48,10,1,0,0,700,0
Launcher=450,72,100,5,0,100,150,26
Deviator=750,80,120,5,0,50,175,30
Tank=300,64,200,3,0,80,100,22
Siege Tank=600,96,300,4,0,130,150,24
Devastator=800,104,400,4,0,175,180,32
Sonic Tank=600,104,110,4,0,80,110,34
Trike=150,40,100,2,0,50,50,10
Raider Trike=150,40,80,2,0,55,60,12
Quad=200,48,130,2,0,60,60,14
Harvester=300,64,150,2,0,10,150,18
MCV=900,80,150,2,0,10,150,20
Death Hand=0,0,70,0,0,0,0,0
Rocket=0,0,70,0,0,0,0,0
ARocket=0,0,70,0,0,0,0,0
GRocket=0,0,70,0,0,0,0,0
MiniRocket=0,0,70,0,0,0,0,0
Bullet=0,0,1,0,0,0,0,0
Sonic Blast=0,0,1,0,0,0,0,0
Sandworm=0,0,1000,0,0,0,0,0
Frigate=0,0,100,0,0,0,0,0
Concrete=5,16,20,1,1,0,5,2
Concrete4=20,16,20,1,4,0,10,4
Palace=999,130,1000,5,8,0,400,5
Light Fctry=400,96,350,3,3,0,200,14
Heavy Fctry=600,144,200,3,4,0,600,28
Hi-Tech=500,120,400,3,5,0,200,30
IX=500,120,400,3,7,0,100,34
WOR=400,104,400,3,5,0,175,20
Const Yard=400,80,400,3,99,0,300,0
Windtrap=300,48,200,2,1,0,300,6
Barracks=300,72,300,2,2,0,100,18
Starport=500,120,500,6,6,0,250,32
Refinery=400,80,450,4,1,0,300,8
Repair=700,80,200,3,5,0,600,24
Wall=50,40,50,1,4,0,30,16
Turret=125,64,200,2,5,75,150,22
R-Turret=250,96,200,5,0,100,75,26
Spice Silo=150,48,150,2,2,0,150,12
Outpost=400,80,500,10,2,0,275,10

[Combat]
Carryall=0,0,0,200
'Thopter=50,50,50,150
Infantry=2,3,45,5
Troopers=5,5,50,10
Soldier=2,3,45,8
Trooper=5,5,50,15
Saboteur=2,2,45,40
Launcher=9,75,120,30
Deviator=7,0,180,30
Tank=4,25,80,25
Siege Tank=5,30,90,20
Devastator=5,40,100,10
Sonic Tank=8,60,80,30
Trike=3,5,50,45
Raider Trike=3,5,50,60
Quad=3,7,50,40
Harvester=0,0,0,20
MCV=0,0,0,20
Death Hand=15,100,0,250
Rocket=8,75,0,200
ARocket=60,75,0,160
GRocket=7,75,0,200
MiniRocket=3,0,0,180
Bullet=0,0,0,250
Sonic Blast=10,25,0,200
Sandworm=0,300,20,35
Frigate=0,0,0,130

Edited by Nyerguds
Posted

My editor kinda has all of that House information, dynasty. Heck, my current ini writer already dumps it:

I know, but it's not quite in the same format as that used the SMD file. :P No big deal.

Anyway, the dumper works. Of course, it doesn't do any fancy formatting.

Awesome, that's just fine.

Oh, I found out what some of the unknowns in your editor correspond to:

- Unknown 10 in the terrain info (variable_10 in OpenDune) is the crater type when a missile explodes. 0 = none, 1 = sand, 2 = rock. (This has to do with that bug you reported.)

- Unknown 001 in the actions are the string IDs read from the language files.

- Unknown 001 in the sound info (variable_04 in OpenDune) is the sound priority, which is necessary because you can only have one sound blaster sound at a time. Sounds with higher (equal?) priority will stop those with lower priority and will be played instead. This is used in a few interesting ways:

1. the narrator sounds have the highest priority (~20), then unit confirmation sounds (~15), and finally general battle sounds (~10).

2. soldier squish sound (priority 12) overrides soldier death screams (priority 11).

3. trooper rockets (priority 10, played by the mini rocket) overrides trooper machine gun (priority 9, played by the trooper).

  • Upvote 1
Posted

Awesome, thanks!

I managed to get the reader for profile.ini working flawlessly too, btw. Going to add this info you found, and then release v2.01 :)

Not sure how useful this import and export really is though.

Posted

Oh, I found out what some of the unknowns in your editor correspond to:

- Unknown 10 in the terrain info (variable_10 in OpenDune) is the crater type when a missile explodes. 0 = none, 1 = sand, 2 = rock. (This has to do with that bug you reported.)

- Unknown 001 in the actions are the string IDs read from the language files.

- Unknown 001 in the sound info (variable_04 in OpenDune) is the sound priority, which is necessary because you can only have one sound blaster sound at a time. Sounds with higher (equal?) priority will stop those with lower priority and will be played instead. This is used in a few interesting ways:

1. the narrator sounds have the highest priority (~20), then unit confirmation sounds (~15), and finally general battle sounds (~10).

2. soldier squish sound (priority 12) overrides soldier death screams (priority 11).

3. trooper rockets (priority 10, played by the mini rocket) overrides trooper machine gun (priority 9, played by the trooper).

Great, thanks a bunch for clarifying this! ^_^

The sound thing is especially interesting. IIRC with the Trooper(s) weapon, the synthesized version of the machine gun sound is still played when the rocket sound plays, creating a unique (and somewhat weird) attack sound. Same stuff happens with the 'thopters, which have a rocket fire sound as the attack sound, while at the same time a sound that is attached to their projectile also plays when it is fired.

Basically, my understanding is that whenever one digitized sound overrides another, a synthesized version of the suppressed sound is played, if available.

BTW, I also remember that sometimes when an enemy unit is killed, a synthesized trumpet sound can be heard - at least, this si true for earlier levels but somehow I had that feeling that this either worked in some irregular way, or got much less frequent in v1.07.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.