Water Hacking (and other challenges)

[Andy80586]

Since no one has replied to my post in GTA3/VC memory addresses, I will repost it here in the form of a challenge to all modders inclined to solve it. This challenge requires modding hardcode in gta-vc.exe, so I HIGHLY recommend that anyone attempting this has at least basic knowledge of assembly language. It also requires directly hacking the file with either a hex editor or file I/O in a programming language of your choice (preferably C). I don't want to scare newbies away (hell I hacked the boundaries and was pretty much a complete noob at the time), but it will probably take a lot of patience and perhaps time to pull this off.

 

I currently take 16 units at Cal Poly SLO (12 of which involve labs), which means that I have way less time to hack VC, and I also want to focus more on creating functions to handle game hacks and integrate them into Limit Adjuster 2.0. At the same time, State of Liberty (and other mods with hacked hardcode) continue to have hardcode-related bugs in them (e.g. water walls, path quantities, and some issues with the path bound algorithm). Anyone who completes any of these challenges will earn a credit on Limit Adjuster 2.0 and GTA: State of Liberty (pending approval of Keith, but since this stuff directly affects SOL I am sure he will grant it), perhaps get nominated by me for stars on this forum, and maybe other things (all I can think of at the moment).

 

With that said, let me actually list the challenges.

 

Challenge 1: Move or expand the water south of -2048 units

 

Currently, I can expand the water table in every other direction except south. Not only is this annoying, it interferes with making a solid algorithm for water. The water functions can be found at 0x5BFF00 and 0x5C1710 in gta-vc.exe. Lots of places use the value 31 - if you change these to 63, update the waterpro.dat file, make gta-vc.exe allocate more memory in the last section, and hack the water offsets to use the new allocation, you get an 8192x8192 water table. You can move it east and west by changing data values, and it extends north to 6144 units, but the south boundary is still -2048. Complete the challenge by moving the south bound downward. Extra points for posting a clear algorithm (pseudocode, C, anything as long as I can read it) that can move the water table in any direction by any amount. More extra points and a nomination for stars for posting the following two functions: 1) an auto-generating waterpro.dat based on paths and IPL map files, and 2) importing and exporting water bitmaps like Steve-M's Water Editor but with variable bitmap size (i.e. if someone wants a 12000x12000 water table, it can import and export the 188x188 and 376x376 files contained in that waterpro.dat, which would be 173KB in size).

 

Challenge 2: Make an algorithm for the path quantities

 

I already know how to hack these, and I might have posted it somewhere on here, so merely sending me a file with hacked path quantities doesn't suffice. However, you can save me a lot of time and energy (which I don't have to begin with) by writing C code. Use US 1.0 memory offsets, not raw offsets or offsets from some random-ass version of the game that you have - I can convert from US 1.0 to other .exe files, not the other way around. The path memory starts at 0x9B6E5C, and there are several places in that block (many of them adjacent or close to adjacent) that are directly addressed (example: 0x2F1F0 bytes after 0x9B6E5C - there are places in code with 0x2F1F0 and 0x9E604C). If you write the code and it works, you get points (and credit as stated above).

 

Challenge 3: 32-bit limits

 

When the game reads map ID numbers, it converts them into 2-byte words, meaning that there can only be 32768 of them before the game takes a sh*t and crashes. The ID references consist of 20-byte structures arranged in an array at 0x94DDD0 and 4-byte structures at 0x92D4C8. Change the 0x94DDD0 array to 24 bytes (e.g. the lines lea eax, [eax+eax*4] and lea eax, [eax*4] change to lea eax, [eax+eax*2] and lea eax, [eax*8]) and the word references to dword references of 4 bytes. Pull this off, and not only will you be nominated for stars, but since SA uses arrays of structures in a very similar manner, it will make it a lot easier to hack those parts of the game, meaning that the +5 limit in SA will become more like a +2147469654 limit. If each object takes up 128KB of memory, it would take up 256TB of memory and have a land area the size of the entire Western U.S., giving a whole other perspective on how to represent California in a video game if it ever gets filled.

 

Any takers?

[92F]

Isnt calling it a challenge just a fancy way of re-wording request?

 

Should be in one of the pinned topics.

[DexX]

If he had been successful in getting responses in the mem-hacking topics, they most likely would have gone dreadfully offtopic. What andy is doing is much more complicated than just posting offsets.

 

@ andy - i don't have much to add, but best of luck

[Andy80586]

k yea they are requests - but they are challenging requests and I can probably count with one hand the number of people who could make them work...

[Cowpat]

 

When the game reads map ID numbers, it converts them into 2-byte words, meaning that there can only be 32768 of them before the game takes a sh*t and crashes. The ID references consist of 20-byte structures arranged in an array at 0x94DDD0 and 4-byte structures at 0x92D4C8. Change the 0x94DDD0 array to 24 bytes (e.g. the lines lea eax, [eax+eax*4] and lea eax, [eax*4] change to lea eax, [eax+eax*2] and lea eax, [eax*8]) and the word references to dword references of 4 bytes.

Sorry if I'm being a bit thick but I'm confused as to the addresses you quote. I had a look at 0x94DDD0 and 0x92D4C8 in game and both appear to be contained within a large sequence of 20 byte blocks starting at ~0x8E4C38 and ending at ~0x96549E, with occasional short breaks in between. I can't see the 4 byte structs.

 

Also, could you give the addresses of the assembly instructions you quote.

 

Also, even if the size of the structures can be expanded, what of the code which reads and makes use of the structures? Won't it have to accommodate dwords rather than words?