Recently I found myself returning to some of the old classics of the 90's. TA is one such staple RTS game that my mates and I enjoy tremendously. Spinning it up and playing it quickly shows that while the majority of the game has aged quite well, there are parts that uhh... leave something to be desired.
Pathfinding is one such limitation that is so bad it is laughable for the first game. Watching all of your units bumble around knocking into each other like drunk children looking for chocolate in the dark provides entertainment for the first 30 minutes. Unfortunately it quickly gets old after the novelty wears off. So what to do?
Luckily the TA community is old and knowledgeable. In fact this entire post is just a lesson on trying to understand the findings on things that have already been investigated by others before me. There are two posts on the forum site tauniverse.com on pathfinding that are particularly useful:
- A Post by Ti_ in the thread Hacking TA, and
- Pathfinding Research by N72
The post by Ti_ is a little hard to follow because there is very little context and the author is not a native English speaker. Going back a page in the thread will provide any needed backstory context and just like Ti_ did their best to explain the solution so too will we do our best to interpret it. The post starts out talking about some hex offsets in the TOTALA.exe, implying that these offsets are significant and likely need changing via a hex editor.
Reading the rest of the post gives us some useful information about the pathfinding situation in TA. Specifically these quotes:
Pathfinding cycles limitation
...
do not use very high value, during this code in original cycle launchs 1332 times for player1, and 666 for player2
From this we can discern the following:
- There is a value that dictates the number of pathfinding cycles.
- The default value is 1332, however
- The number is different per player.
- Changing the number to a very high value can have bad consequences.
Sounds good to me; enough reading of English lets start reading some hex. The Hex Editor that I use is HxD but there are heaps of different Hex Editors and they all do pretty much the same thing, so choose the one you like the most.
Opening up the TOTAL.exe in HxD and going to the hex offset DF91 (Ctrl + g) shows that our value at that offset is completely different:
The hex offset DF91 shows us a corresponding value of 8B4648 instead of Ti_'s EBD190. Similarly going to hex offset DF64 shows a value of 90909090909090 for us, where as in the post it shows B8D4140000EB28.
At this point I'm not even sure we are in the right spot. Hopefully Ti_ has simply provided the updated values that we should change our hex offsets to, but maybe we are in the wrong spot. Well lets see if we can find any other occurrences of the values that Ti_ has posted. A quick Ctrl+f search for EBD190 and B8D4140000EB28 shows that there is no match:
There is also a possible typo in the post, where the value specified at offset DF64 is B8D4140000EB29. So I searched for that too, either way there are no results. This is actually likely a good thing, but there is another thing we can search for. As noted before we know the default value for pathfinding cycles is 1332, so lets search for that:
Well that's odd, there are 11 hits but they are all defined quite further down in the file, I would have expected the hit we are looking for to be roughly around the same area that Ti_ was pointing too. That is somewhere around DFXX, most likely before the other offsets as things are generally defined before use. Maybe we have the wrong number? Lets look at the other post, the one by N72. Right in the Intro we see that the 1332 is a typo by Ti_ and that the actual default value is 1333:
TA by default is set to 1333 pathfinding cycles.
Alright then, lets search for that value.
Bam! 6 hits. First hit is much closer to the offsets that Ti_ was referring to, as such my confidence is much higher that we are looking in the right place. This confirms with relatively high confidence what we suspected earlier: we know that the offset is right but the values we have are wrong. It seems Ti_ only supplied the updated values.
This raises a tantalizing question though: if we know where the number for pathfinding cycles is (offset DED6), then why do we need to change the offsets posted by Ti_? What do those other offsets, the ones at DF91 and DF64, even do? Well only one person knows that and that person is Ti_.
Doing some further reading in the thread Ti_ actually supplies a CFG file which contains instructions for an auto-hex editor. The auto-hex editor is a program that will hex edit the TOTALA.exe and make some modifications without the user having to download a hex editor and make the modifications themselves. That is a little scary though, I barely trust my own hex editing let alone someone else's, so lets see what those instructions are in the CFG file:
file=D:\Games\CAVEDOG\TOTALA\totala.exe
index=8
VTOL_group_min=00006F28;00000019;Byte;Big
GROUND_group_min=000081C6;00000014;Byte;Big
SHIPS_group_min=00008253;0000000A;Byte;Big
unlock_ai_cheat=001005D8;00000001;Byte;Big
unlock_control_cheat=001005E4;00000001;Byte;Big
unit_limit_max=00090A59;00000DAC;Word;Little
unit_limit_max=00090A66;00000DAC;Word;Little
force_group1_func_for_group5=00008176;000000B0;Byte;Big
Pathfind_cycles=0000DED6;000014D4;DWord;Little
The line we are interested in is the last one:
Pathfind_cycles=0000DED6;000014D4;DWord;Little
That instruction shows us that the only value that needs to be changed for pathfinding is indeed the 16bit value at offset DED6. Those other offsets talked about earlier are not needed. Usually that would be all I need to know before I go on my merry way, but for the sake of completeness I looked into it further and found an explanation. N72 asked Ti_ to clarify some things to which Ti_ replied:
... don't use patch or value in *.cfg will not work, it because patch change code, and original value was founded later
From this I take it there was some confusion by Ti_ when trying figuring out the right offset, maybe Ti_ was also hex editing other values trying to figure out what offset does what and some of the offsets got mixed up? Hard to be certain. In any case it doesn't really matter; now that we know the offset for the pathfinding cycles we need to change it. But what does it need to be changed to? What's the right number for the use case?
This is where we really start looking at the Pathfinding Research thread by N72. All the hard work has been done for us! The data is so well laid out that you don't even really have to read anything, just look at the pretty pictures.
This thread goes into high detail compared to the other post we looked at. The conclusion is basically setting the cycles to 66650 is the optimum value. But wait! is that too high? Ti_ did warn us about setting the value to high after all, but how high is too high? Well this too is already sorted out, as N72 states:
... basically I found that for this amount of units, increasing pathfinding cycles doesn't dramatically decrease performance beyond what the renderer is also doing until you get past 100,000 cycles or so, doesn't start making the frame rate very low until you get past about 2 million cycles, and doesn't make the game completely unplayable until about 3 million cycles. Again this is on a 4.5GHz desktop CPU. In any case, 66650 cycles seems like a pretty ideal value because you are getting extremely good pathfinding at a minimal performance hit beyond what the game is already doing. Plus, unlike what happens when you set to a ridiculously high value, using a value in this range doesn't affect your performance when you have low amounts of units. Good news is that the game is fully stable regardless of what you set the value too (at least up to the low millions) and will not crash, so you don't run the risk of doing anything other than lowering your frame rate when you use extremely high values.
What's more is that by setting the value to 66650 we know for sure that the value starting at offset DED6 is actually not 16bit as I thought earlier but is in fact 32bit. 66650 is larger than the 16bit uint maximum of 65535 so the variable must be 32bit, if I had of been paying attention earlier I would have noticed that Ti_ put it through as a DWORD, or Double Word in his instruction set which makes it a 32-bit unsigned integer.
Changing the value is rather straight forward, highlight the 32bit value for the pathfinding cycles and change the value over in the side-panel:
Save the changes, open up TA and play a game to confirm the pathfinding is much better.
Ez game, ez life.