EXE editing & programming issues

[MrFlibble]

I remember that an author of a "trainer" cheat program for Dune II mentioned that he found the part of the code responsible for the global limit, and broke it, but the game would drastically slow down when the number of units on the map exceeded the preset limit.

[Skrilax_CZ]

Yeah I found the trainer on shai-hulud but I though the "slowdown" would be present only on "ancient" computers.

[MrFlibble]

I'm not competent enough to speculate whether this has something to do with the limitations of the hardware, or internal limits of the game engine's capacity.

[Nyerguds]

Didn't we find the code for that? The array limits of the different unit types in the editor?

Problem is just the total size of the units and structures array. You can't just expand those values without it overwriting other stuff in memory.

[TrueBrain]

Units are hard-limited to 103 entities. Buildings are hard-limited to 80 entities (ignore slabs and wall). This is partly a memory restriction, but with EMS/XMS it should be relative easy to extend those values (you only need to find ALL places those limitations are used, which is often used as constant, not as variable). That said, another hard limit is 256 entities for both pools. This due the fact mostly it only has 1 byte reserved for IDs.

For buildings there will be another problem, as ID 80, 81 and 82 are hard-used for slabs and walls, and are always assumed to be those numbers.

Carry-alls and 'Thopters use their own pool, which is limited to 17 entries.

Speed will be an issue, you even have slowdowns if you move 20 units at the same time :P (the game simply isn't made for big values like modern games are).

Also, units are limited by the scenario. Every type gets a range in which it can use IDs. Trying to use outside that range causes building failure (dunno how used it is by scenarios, but the code has such limitation). Of course the StarPort completely ignores this :)

Just my 2 cents on the subject :)

PS: sorry if most of the info was already known, it is hard to find back for a relative new user what is considered 'common' knowledge and what not. So I apologise for any of such occurrences.

[Nyerguds]

(you only need to find ALL places those limitations are used, which is often used as constant, not as variable).

Haha, I'm all too familiar with that kind of stuff. I expanded the units and music lists in C&C95; it was always a hunt for these list size values. The worst part was if they were not in the actual function that referenced the list, but some function that called it. And when I didn't get them all, I got these situations where a new unit worked, but didn't appear on the build list, and stuff like that.

I changed them all into a reference to one global value for each list size. Not sure how to even do that in a 16-bit environment though.

I don't know anything about the use of EMS/XMS though. I thought this array would be given its fixed place in a virtual memory section of the exe; not sure if 16 bit games even have those.

[MrFlibble]

PS: sorry if most of the info was already known, it is hard to find back for a relative new user what is considered 'common' knowledge and what not. So I apologise for any of such occurrences.

On the contrary, you have contributed a lot of useful, previously unknown information. While it is indeed common knowledge that units and buildings have limits in Dune II, exact values were never discovered, so we dealt only with approximations. You research on the subject is more than helpful. Thanks a bunch :)

[Daelin]

Is there any way to actually check how the Harkonnen Missile accuracy works? Sounds like complex work, but I thought maybe this could be tested somehow. Because I heard rumors such as "The shorter the distance the greater the accuracy" and "the more explored the area, the greater the accuracy" but I haven't verified any of those.

And also, is there an accuracy parameter somewhere? Maybe something which the missile and deviator rockets also have somewhere. Would be cool to check. :)

-Daelin

[jordos]

I believe (though I haven't done any extensive testing) that Unknown 44 in the Units section of Nyerguds' editor is the (in)accuracy (in tiles?) of the missile tank&deviator. It is set to 11 on the Death Hand 'unit', but it is quite possible it has a different function for the 'weapon units'.

[MrFlibble]

I think segra or the OpenDune guys can point to exact code responsible for that.

On a related note, it seemed to me that after I revamped the AI priority levels for structures, the missile got more accurate, but I didn't run enough tests to be sure.

[Nyerguds]

No, Segra identified unknown 44 as a reference to an index of special animations, like the worm's swallowing animation.

[MrFlibble]

What? I've never ever seen this happen, neither in my US 1.07 or the HitSquad version - I always capture enemy structures to prevent them from rebuilding. May have to test this...

Will, I think you were right, after all. I must have mixed up the situations when you capture a structure and when you build a structure of the same type at the same place as the enemy building.

BTW, I witnessed an interesting bug recently: one of my Launchers was destroyed by an enemy Rocket Turret, but instead of spawning an infantry soldier from the destroyed vehicle, the game accidentally spawned another Launcher ;D Must be something with unit IDs...

[Nyerguds]

lol, that's bizarre.

[MrFlibble]

If the AI really does not attempt to rebuild captured structures, that would be an excellent way of dealing with enemy turrets, as those are allowed to be captured in Dune II. Also, pre-placed AI-owned structures do not decay even after the player captures them, so that's a small bonus as well.

Another thing I noticed with capturing structures is that the game is seemingly unable to correctly calculate the total power output if the player captures an enemy Windtrap, as the power produced by captured Windtraps is not counted.

[MrFlibble]

Yep, I've run a few tests, the AI does not attempt to rebuild captured structures even if those are destroyed (after having been converted to the player's side). However, the AI will shamelessly rebuild its lost structures over anything that happens to get in their way, be it a unit or a player's structure. I'm not sure about walls, but probably those are not an obstacle as well.

Seems like infantry isn't that useless after all, eh? ;)

[Daelin]

Walls are never rebuilt.... neither are concretes. I wonder though if threat level has something to do with rebuilding the base. Did you observe any significant differences after modifying Super Dune's AI behavior?

[MrFlibble]

Walls are never rebuilt.... neither are concretes.

I meant that I don't know if player-build walls could prevent the AI from rebuilding its structures.

As for modifying the AI attack priorities, I haven't noticed that it affected the way the AI rebuilds its base.

[MrFlibble]

While playing around with building stats, I found out that in v1.07, if a structure has more than 500 hp, it is repaired for free (this is what can be observed with the Palace). I seems to me that the game fails to correctly calculate the amount of credits needed for repairs, so it's most likely a bug. Note that it doesn't happen in v1.0 though.

[Nyerguds]

It's more likely that the actual value at which this happens is 512 :P

[MrFlibble]

I think I need an explanation. Other than that 512 is 256x2, I don't get why the repair cost becomes 0 in this case.

[Nyerguds]

well, not sure in this case, but values like these tend to be the separation between positive and negative. For example, for 1 byte, the value 128 is seen as -128, 129 is -127, etc. until finally 255 is -1.

[Daelin]

Value representations usually come with a global limit in BYTES.

Char/"tiny int" comes on 1B, meaning

   - Signed values (usually represented in 2's Complement) have a range of -128...127

   - Unsigned values vary from 0 to 256

The 512 seems to have no point here.

But MrFlibble has a very neat question: why 2x256? I wonder how the repair cost is actually calculated for buildings. Is it related to HP, or building cost? Are the building's HP somehow divided by 2 and then the value stored on 1B (instead of 2)? And what do negative values actually do to the credits? Shouldn't repairing a building for "negative cost" actually GIVE money instead of taking?

-Daelin

[TrueBrain]

Bytes that hold 512 different values? I sure hope you made a typo or I read you wrong. Byte (unsigned char / uint8) goes from 0 to 255. Char (signed char / int8) goes from -128 to 127.

Either way, OpenDUNE allows us to look inside the code in great detail, so I went on a discovery tour .. did find some things you always wanted to know (or not):

From campaign 4 and on you don't repair per 3 hitpoints, but per 5 hitpoints. For the same cost ;)

In both cases, you only pay for repairing 2 hitpoints. So an almost destroyed structure cost only 2/3th or 2/5th of the cost to repair.

The palace shows in a nice way the problem of avoiding floats. It is very common for any (sane) application to avoid floats, but for Dune2 it is more fundamental: it doesn't use any FPU command (old computers didn't have a FPU :P). To still do floating calculations, a simple trick is used: multiple every float by value N. In this case: 256. And here is your problem: the palace has 1000hp. 2hp are repaired every tick. 2 / 1000 * 256 = 0. So, 0% of the cost has to be paid (values are round down). So, repairing palace is for free :) Every structure with the hp of over 512hp has this 'problem'.

So, MrFlibble, your 2*256 was not far off ;) 2 for the pay-hp-per-repair and 256 for the float-resolution. Nice guess :)

PS: I like to take this opportunity to underline it has absolutely nothing to do with signed values. All values are unsigned in this question.

PPS: this method used is _very_ unfair. A strucuture with 257hp cost as much to repair for the same amount of damage as a structure of 512hp (if they would have cost the same price).

[Daelin]

Whooops..... typo there. Thanks TrueBrain for pointing that out. I modified the post :P

Interesting stuff there. This certainly explains a lot about the repair cost. Great job TrueBrain! :)

-Daelin

[Nyerguds]

Oh of course... multiplying for division. That explains.