Dune II editor with 1.07 support

[Will]

Heh, looking at hat we know so far, that looks like another bunch of code exceptions :P

That seems very likely, yes. Did you know this is also in Red Alert 1? (Probably :P)

I once multiplied all weapon damage by 10 (or so) in the rules.ini, and suddenly Artillery units had Cruiser shell explosions when they fired. All the projectile weapons now had changed explosion graphics (except for the Cruiser's shots, because those used the biggest cannon explosion graphic available in the game already).

[MrFlibble]

I once multiplied all weapon damage by 10 (or so) in the rules.ini, and suddenly Artillery units had Cruiser shell explosions when they fired. All the projectile weapons now had changed explosion graphics (except for the Cruiser's shots, because those used the biggest cannon explosion graphic available in the game already).

Yeah, I also found this out recently (I was interested in differences between v3.03 and the previous ones, as some changes were introduced to warhead behavior and effects). For a reason, versions below v3.03 use one and the same explosion graphic for most warhead types.

[Nyerguds]

Huh, odd. In the C&C weapon system, weapons should be linked to specific graphics.

[MrFlibble]

In Red Alert, there are weapons, projectiles and warheads. The explosion graphics, the smudge type left by the explosion on the ground (craters or scorch marks) and the way the weapon affects different types of armor are defined by the warhead type.

[Nyerguds]

Ah, true. Fire and nuke leave scorch marks.

[MrFlibble]

I've noticed an odd thing concerning the "File type" variable. As I mentioned before, some of the PAK files are marked as "Required PAK file" (as we called it), namely:

DUNE.PAK

ENLGISH.PAK

INTRO.PAK

MENTAT.PAK

SCENARIO.PAK

SOUND.PAK

This is true for all versions except the EU version (which also seems to be the latest one, judging by file dates and the presence of features that are missing from other releases), where none of the PAK files are tagged as "required". What is interesting is that by default, the EU version does not display the "Taking advantage of extended memory. Please wait..." message during initialization (given that digitized sounds and the use of extended memory have been enabled), unlike any other version (some even have this message translated into German and French). However, when I changed the above-mentioned files' status to "required" in the EU version, it started showing the extended memory message when appropriate.

I have no idea what to make out of this, but it seems possible that these files have something to do with memory management at game startup or something along those lines...

[Nyerguds]

yeah, I noticed that too, about it not having any required PAK files... in fact, the whole thing baffled me since I usually tested the editor on the EU version. I switched to the US one shortly after that, for some reason.

[Nyerguds]

I think I'll release the next version as soon as I get home. The only real change (besides some internal refactoring) is the new item-specific Help system. As I probably mentioned before, help items are a separate list now, and any option can be linked to any help item. This also has the advantage that help items can be recycled for differenty options :)

Any assistance with these descriptions would be greatly appreciated, but I guess I'll have to release this version so people can see what I got so far and what I still need help descriptions for.

[edit]

Looks like I had the latest version of the source code on my USB drive after all :)

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

[bluehappybyte]

Thanks for incorporating my patch. It now compiles fine on Linux with "fpc -Mobjfpc duneedit_v1.17.1.pas".

A few notes about running the editor on Linux:

- Using the F1 to F12 keys conflicts with the Terminal Emulator (at least under Gnome). e.g. F1 is the Gnome Terminal Help, but you can define other key combinations for the Gnome Terminal.

- The Linux terminal normally uses UTF-8 but your editor uses special characters (character code above 127) for drawing the window borders. These are not valid in UTF-8 and thus an "unknown" character ('?') is drawn instead.

- The terminal window must be 80x25 characters or bigger

[Nyerguds]

-F-keys: Not really my problem, tbh... this is made as independent application; you could have similar problems with programs like vi.

-charset: Yeah, I use standard ASCII DOS-437 for drawing the frames. It's kind of the only thing to work with in DOS environment, and they look nice. The set of frame characters is defined in the source, in the "framechar" variable, so you can always adapt them if you want... here's a pure UTF-8 ASCII version:

  framechar:array[1..2] of chset = (                        ($2E, $2E, $60, $27, $2D, $7C, $2D, $2D),                        ($2B, $2B, $2B, $2B, $3D, $23, $3D, $3D));

You can even redefine the "chset" type to take the Char type instead, and(<- not needed) just do it like this:

  framechar:array[1..2] of chset = (                         ('.', '.', '`', '''','-', '|', '-', '-'),                         ('+', '+', '+', '+', '=', '#', '=', '='));

-the size: ehm, the editor is exactly 80x25... what's the problem?

[edit]

lol, looks pretty weird.

Edited August 9, 2023 by Nyerguds

[bluehappybyte]

-F-keys: Not really my problem, tbh... this is made as independent application; you could have similar problems with programs like vi.

Yes, just want to mention it. Actually you can map any key to any other key. The point is that it is the default configuration for the Gnome Terminal. Probably an alternative key would be useful, like 'h' for help. Just an idea...

-the size: ehm, the editor is exactly 80x25... what's the problem?

The DOS console window is always 80 characters wide. If you resize it, it will add horizontal scroll bars. On most (all?) Linux terminal windows the width is not fixed. You can run a (terminal) editor with 200 characters per line or with 20 characters per line; the editor will use whatever size the terminal has.

But it's no big problem. The user has to make the console window big enough and your editor will look like under windows (beside the DOS characters).

As your editor gains more and more functionality the user interface becomes more and more complex. Have you plans to migrate to a "real" GUI? As your already using pascal the Lazarus IDE/project might be useful. It's open source, cross platform and is a clone of Delphi...

Don't know what your plans for the editor are. Is there a roadmap?

[Xaroth]

- The Linux terminal normally uses UTF-8 but your editor uses special characters (character code above 127) for drawing the window borders. These are not valid in UTF-8 and thus an "unknown" character ('?') is drawn instead.

I think you're confusing terms here, seeing UTF-8 supports charcodes above index 127 ... it's most commonly the terminal emulator that does not properly handles it; ASCII characters are completely identical in both size and data in both UTF-8 and ASCII, so a terminal client reading as ASCII but getting sent UTF-8 will work most of the time, that is, until somebody sends out the dreaded non-ASCII characters, resulting in distorted views... most (if not all) terminal clients nowadays support UTF-8 either automagically or by pre-configuring.

On that note, I must admit, the table-layout does look quite funny with the ASCII characters :P

[Nyerguds]

Making that character map was the easiest way of drawing my frames, but the fact you can replace em so easily is a fun side effect ;D

As your editor gains more and more functionality the user interface becomes more and more complex. Have you plans to migrate to a "real" GUI? As your already using pascal the Lazarus IDE/project might be useful. It's open source, cross platform and is a clone of Delphi...

Don't know what your plans for the editor are. Is there a roadmap?

This editor started as an experiment on how to make my own text UI. I now know Pascal's libraries already contain functions for pretty much all of the list-related stuff (just look at the TP7 editor itself - written in TP7), but honestly, that wasn't the point. From a programmer's point of view, this is an "old program" for me. Old code which I would do totally different if I would make it today, and which I really don't want to mess too much with. It's pretty expandable though, so I do add some new stuff to it, but I won't mess with the core programming.

---

What exactly do you mean with roadmap? The basic loop the program follows? That's pretty easy. At each moment, you're in a list. There are 4 lists (internally, the "level"):

-the 'types' list: level 1

-the 'units' list: level 2

-the 'options' list: level 3

-the 'editing' list: level 4

(I'm considering adding a 5th level, the 'sub-editing' list, for modiftying referenced scripts)

Each of these have settings that say how far the entire list is scrolled down, which visible index on the list is currently selected, and how long the list is. The UI handles the part that determines how many items of each list are shown (and where). The 'real' index in the list is simply the 'scroll' value + the 'index on the visible list' value. Due to the way the program is built, almost every function knows where to read and write its data by just giving it the real indexes on the first 3 levels. The index on the 4th level usually determines the data to write back. Pretty much every function has some sort of overloaded variant that accepts (typeindex,unitindex,optindex:integer) as parameters.

The program is actually nothing more than a loop receiving basic navigation commands to move up and down in these lists, and to switch to the next list (going to a different "level"). Of course, if you move to a different item on the types list, the second and third lists should update on screen to show the units and options of that other type. And if you scroll in the units list, the values in the second column of the options list should change. And if you press [enter] on an option in the options list, you go to level 4.

Another big part of the editor are the data types. There are hundreds of options, but a lot of those are the same data type, so I made a list of all different ones. A data type determines in which form the data is shown in the second column of the level 3 list, how it creates the level 4 list when you press [enter] on an option, what special instructions (like scrolling to the selected item) it needs to execute when opening the level 4 list, and which method it uses to save the data when you select an item in the level 4 list. These are a bunch of big CASE structures spread over the source code; the first of them being the one determining the datatype's length in bytes.

After building this structure, I realized that this is something I would probally have done with objects in Java or C#.

These case structures have a little exception though. The actual level 4 list is sometimes not used at all. In some cases, the CASE result (in function "drawLayout4") for a certain data type just calls one input function (like showinputInt) that lets you input a certain value, and then just exits level 4 again.

[bluehappybyte]

I think you're confusing terms here, seeing UTF-8 supports charcodes above index 127 ... it's most commonly the terminal emulator that does not properly handles it; ASCII characters are completely identical in both size and data in both UTF-8 and ASCII, so a terminal client reading as ASCII but getting sent UTF-8 will work most of the time, that is, until somebody sends out the dreaded non-ASCII characters, resulting in distorted views...

Yes, that's what I wanted to express. The "dreaded non-ASCII characters" that Nyerguds uses for the window borders are no valid UTF-8, resulting in printing out a replacement character (http://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences).

What exactly do you mean with roadmap?

I thought of your future plans for the program; a TODO list for future editor features or something like that. But you already gave the answer: The editor is a kind of legacy program with only minimal updating. That's ok because it already has the functionality needed to edit values inside DUNE.EXE.

[MrFlibble]

Got another unknown value (well, sort of). In Structures, Unknown 005a (bit 5) has something to do with a building's ability to receive shipments. It is active for the Refinery and Starport. I disabled it for the Refinery, and in the game, the Refinery did not play its docking bay animation while it was waiting for the first free Harvester to be delivered. When the Harvester was dropped, it disappeared entirely, and the Refinery went into the docking bay animation loop. No more Harvesters were delivered.

My guess is that this byte is responsible for the ability to deploy units delivered from off-screen either via Carryall or Frigate.

[bluehappybyte]

"Units/Unknown 007" is the same as "Structures/Inf spawn chance / cell". It is the chance that a soldier will appear when the unit explodes. It only works if "Units/Explode when dying" is "Yes", but there are other dependencies. Tried making a soldier respawn immediately, but that doesn't work. Changing the percentage for units that already have a chance in creating a soldier works. Tried it with the harvester.

[Nyerguds]

oh that's nice. Great info there, thanks people! :)

Implemented "Can receive airdrops" and "Infantry spawn chance" :)

I think you're confusing terms here, seeing UTF-8 supports charcodes above index 127 ... it's most commonly the terminal emulator that does not properly handles it; ASCII characters are completely identical in both size and data in both UTF-8 and ASCII, so a terminal client reading as ASCII but getting sent UTF-8 will work most of the time, that is, until somebody sends out the dreaded non-ASCII characters, resulting in distorted views... most (if not all) terminal clients nowadays support UTF-8 either automagically or by pre-configuring.

Ehhhh... you seem to be under the mistaken impression that the +127 characters in UTF-8 and ASCII are the same... they aren't. To edit different-language briefings in C&C1, I have to convert it from UTF-8 to DOS ASCII with Editpad Pro to make it show correctly ingame.

I thought of your future plans for the program; a TODO list for future editor features or something like that. But you already gave the answer: The editor is a kind of legacy program with only minimal updating. That's ok because it already has the functionality needed to edit values inside DUNE.EXE.

Yeah... at school they keep slapping me around the head with neat and tidy object-oriented design and programming... this editor is just my way of coming home, throwing all rules out of the window and going nuts ;D

If you read through this thread you'll see I really only planned to make a basic editor, and update it only if people either found bugs in it or identified new data in it. Back then, I never even thought of adding more lists than just units and structures.

Mind you, any suggestions are still welcome :)

Oh, btw, forgot to mention this... a new feature in 1.17.1 is that the editing frame always shows the address in the exe at which that data is located. Binary and hex editing mode will show the address in hexadecimal ;)

In the next version, if something has only a single prerequisite or owner, the string will no longer be abbreviated in the values column :)

I'm also kicking out some more of my home-brew general functions, like max() and min(), and putting a string in upper or lower case. By including math and sysutils they're already in there anyway.

[MrFlibble]

I've tried to dig deeper into the "Unit array range" stuff. They are most certainly bit switches, here are the sets for various unit types (the first byte of each value is always set to 00, so I did not include it):

[pre]Air units      Min: 0000 0000 Max: 0000 1010

Ground units    Min: 0001 0110 Max: 0110 0101

Projectiles    Min: 0000 1100 Max: 0000 1111

Saboteur        Min: 0001 0100 Max: 0001 0101

Saboteur (v1.0) Min: 0001 0000 Max: 0001 0010

Sandworm        Min: 0001 0000 Max: 0001 0001

Sandworm (v1.0) Min: 0001 0011 Max: 0001 0101

Frigate        Min: 0000 1011 Max: 0000 1011[/pre]

With this, I tried playing around with these parameters (used the EU version), with following results:

Setting all the Saboteur's parameters to that of v1.0 actually changes its limit back to 3 per map (it's 2 per map in v1.07). However, changing only Max. to the v1.0 value results in the Saboteur becoming completely inaccessible in the game: pre-placed Saboteurs do not appear on the map, and none can be spawned by the Palace. In fact, many random changes to the Min./Max. values that I tried give exactly this result.

[pre]Saboteur: Min: 0001 0100 Max: 0001 0101

                  |  ||

                  Z  XY[/pre]Setting X to 0 will make the Saboteur (and its selection marker when it is selected) invisible, as in v1.0.

Setting both X and Y to 0 for a ground unit makes the first four units of this type to appear on the map invisible like the Saboteur in v1.0. Every other unit after the first four will be visible.

Setting Z to 0 gives a ground unit certain features of an air unit: it cannot be selected, and the graphics offset is visibly above the cell the unit occupies.

In short, it appears that these switches work in tandem with other parameters of a unit, producing different results for different unit types. It is certain that the array range values affect unit limits: setting Min./Max. to air units' values for a ground unit will put it outside the global unit per map limit for ground units (in addition to giving it some of the air units' features described above). Same is true for the Saboteur: changing its array range to that of a regular ground unit will apply the global limit to the Saboteurs as well.

[Nyerguds]

umm, the Unit array range is simply the minimum and maximum index on a fixed available list that can be filled with units during a game. It has nothing to do with bit switches.

The saboteur has indexes 20 to 21, meaning there can be 2 of them on the map. All normal units are in the 22-101 range, meaning there can be 79 of them on the map.

full array:

000-010: air units

011-011: Frigate

012-015: weapon projectiles

016-017: sandworms

020-021: Saboteurs

022-101: All normal units

This was taken from the 1.07-HS version. It seems that in this version, indexes 18 and 19 are unused.

I'm not sure exactly how this works, but Segra looked into this. IMO it's pretty bizarre that with this list, only 4 weapon projectiles can exist simultaneously...

[MrFlibble]

The saboteur has indexes 20 to 21, meaning there can be 2 of them on the map. All normal units are in the 22-101 range, meaning there can be 79 of them on the map.

full array:

000-010: air units

011-011: Frigate

012-015: weapon projectiles

016-017: sandworms

020-021: Saboteurs

022-101: All normal units

This was taken from the 1.07-HS version. It seems that in this version, indexes 18 and 19 are unused.

This sounds quite reasonable, but then how changing the Saboteur's array range to 16-18 additionally makes it also fully invisible? ??? I'm also certain that there can be more than 2 Sandworms on the map at any given time... (e.g. in early missions, there are usually 3 Sandworms placed on the map)

[Daelin]

Really? I don't rememeber seeing 3 worms :)

[MrFlibble]

There are 3 worms placed on the map. I did not specifically check if all of them appear though. Unless the player is bound on locating all the worms at once, it is hardly possible as one or two of them (I'm talking about the earlier missions with 3 worms on Area Guard) are closer to the player's starting position, and one is a bit farther.

[TrueBrain]

This sounds quite reasonable, but then how changing the Saboteur's array range to 16-18 additionally makes it also fully invisible? ??? I'm also certain that there can be more than 2 Sandworms on the map at any given time... (e.g. in early missions, there are usually 3 Sandworms placed on the map)

And here is where the shit starts. There are 2 possible ways to create a unit:

Give the Index

Don't give the Index

If you do the former, the unit is _always_ created, given that the index is free. So you can create 100 sandworms if you like, under the condition you give them all an unique index.

If you do the latter, the unit is only created if it fits in the range for that type. If there is no more room, the unit is not created.

So, in theory, it is complete bullshit to give sandworms a range, as they are always created via the scenario, and get assigned an index by the scenario. Therefore, it is easy possible to have 3 sandworms. Just it is never possible to have 3 saboteurs (or you need to create them via the scenario :P)

[MrFlibble]

Hm, I'm pretty sure the game removes all extra pre-placed units that do not fit into the range. Even if you place, say, four Saboteurs in a scenario, only two will actually appear on the map. Same with Sandworms: I checked their limits, and in v1.07 they really reduced the max number of Sandworms to 2. No matter how many Sandworms I placed on the map, it were always 2 in v1.07, and 3 in v1.0.

Curiously enough, the Saboteur and Sandworm units had their index slots swapped in v1.07 (with both unit type limits reduced from 3 to 2). As I said above, if the Saboteur's array range in v1.07 is changed back to its 1.0 stats, it will turn invisible. However, if you change the Saboteur's array range in v1.0 to the 1.07 stats (16-18 to 20-21), it will not turn visible. The only way to make it visible in v1.0 is by giving it a regular units' array range.

[TrueBrain]

Hm, I'm pretty sure the game removes all extra pre-placed units that do not fit into the range. Even if you place, say, four Saboteurs in a scenario, only two will actually appear on the map. Same with Sandworms: I checked their limits, and in v1.07 they really reduced the max number of Sandworms to 2. No matter how many Sandworms I placed on the map, it were always 2 in v1.07, and 3 in v1.0.

(..)

You are absolutely right; scenario-unit-create ignores the given index completely and uses an index from the range (I didn't expect this ..). So sandworms are in 1.07eu always limited to a max of 2 (any others in the scenario are ignored; the ones defined first are used), no matter what, no exceptions. Well .. unless you modify the savegame, but that is another story ;)