Cheat Engine

[Lurkily]

I see trainers that have options for things like build times, construction times. Homeworld 2 for instance. I had to assume that it was a % completed of the current construction - you select a construction unit, it shows you the percentage done. Make that value always 100% complete, whatever value signifies that, and just adding the build job completes it. Right?

So I tried searching for that value, using increasing numbers as I let a build job complete, then decreasing value once, when I start a new job. Eventually, I always come to 0 values matching that criteria.

I thought, maybe it changes each build job, and I have to use the value writing to it to get it. So I tried a single, really long build job - only increasing value searches, interspersed with some 'no change' searches after pausing the build job. Very careful to pause, search for the increased value, play the game again a bit, THEN search for 'no change,' so I didn't accidentally wipe my value out of existence.

I always made sure the same construction facility was selected when I searched, so that the "% complete" value that was displayed was always the same build job.

So why do I always whittle it down to "0 values found"?

How do I search for values like these?

[wizboy11]

They probably used a code cave or something of that nature to get 100% build. It's kind of like adding a no-op (no operation-replace with code that does nothing) but with a code cave the person who made the trainer probably made the code jump to a spot were he wrote his own code in ASM (code cave) and then had the code jump back to were it left off.
At least I think thats how the person did it.

As for your question I don't really know. But keep in mind that some expert trainer makers probably use Softice or something of that nature, which is alot more powerful then cheat engine. (and more confusing.) (Not that i'm saying cheat engine isn't powerful, it is.

Example of a simple code cave:
offset 0x10bb0 <--- Address of our code cave
mov dword ptr [eax+0x354],0x42C80000 <--- Write max health into our health pointer
fld dword ptr [eax+0x354] <--- Reconstruct original instruction
jmp 0x501979 <--- Jump Back to original routine
offset 0x501973 <--- Address of our gateway
jmp 0x10bb0 <--- Jumps to our code cave
nop <--- Balance the instruction

[Zhoul]

In your example, it talks of build times. There are *so* many ways to modify this, but they're all situational.

First: Finding a build time.

You state you would place a building down, then search for increasing numbers (as you are clearly seeing a bar move across the screen, in an increasing fashion.)

One rule of thumb, is to reverse the search logic if you can't find it the 'logical' way. That is, when you place a building, search for values that decrease over time. If a building takes, say 20 seconds to build, the game may set its build time to 20, and decrease the value every second. That would mean the bar you see increasing, is actually decreasing =)

Good luck finding this value in the time-frame of 1 building. Pause/scan as much as you can. Use buildings which take longer.

Once you find the value, which is most likely dynamic, and specific to each building, you have multiple options.

1. Use the "Find out what reads this address" option, unpause/re-pause the game, and now you see what is 'checking' the value. In the code, it probably checks to see if the building is 'complete' , then does a compare between the current build time (your found value) and the defined build time (length it takes to build that building). After that, it probably does a "Jump if equal" or "Jump if not equal". You would simply change that code line to do the opposite of what it usually does.

2. Using some steps in the previous example, during the compare, it has to pull the constant of build time from somewhere, and it will usually show the address (in code) to the constant. Simply get the address, and change the constant, however, since each building type has different build times, you'd have to find a lot of constants and change them. Luckally, they're all probably in the same place in memory... right next to eachother.. hopefully... right? heh

3. Use the "Find code that writes to this value" option. Then change the code to always write a very large number (or a 0, depending on the situation/logic). That way, whenever the value is written, its always the 'building complete' number.

Nasty side-effects of all these options can occur. If you change this code and it is also used by CPU players, then you've just given CPU players an insta-build feature. Without knowing how to code/inject DLL's (something that no one will ever try to explain, as it is extensive, and you will be better off learning it yourself), you can't really discriminate when the code is used.

[quote=Lurkily]I always made sure the same construction facility was selected when I searched, so that the "% complete" value that was displayed was always the same build job. [/quote]

What if you are building 2 simultaniously? They may have the same build time, but the address of their current build time is indeed different. Look at it like this.

Free Memory
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000

Game creates building in free memory
12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678
12345678 00000020 12345678 12345678
12345678 12345678 12345678 12345678
12345678 12345678 12345678 12345678

A building is an object. An object has properties, each 4 byte value above is to represent a 'property' or 'feature' of the building, such as building type, location, etc.
Lets say 00000020 is *that* buildings build time. The build time was taken from a constant (a value defined, for that building type). Its a copy of the constant. So the game pulled the constant from somewhere. I wrote a little how-to on finding constants in this thread.

http://forum.cheatengine.org/viewtopic.php?t=3736

So you can see that just because you're using the same building type, using multiple buildings and searching for 1 value won't work, as each building retains its own build time value, even after the building is complete, because the building is an object, with properties that remain in memory.

[Lurkily]

Actually, the most helpful advice here was the reversal of logical expectations. What I'm working on in this instance was actually construction of units - Homeworld2, the game in question, used units as construction facilities, as it actually had no permanent emplacements you could call a building. Not that YOU could create, and excluding weapon platforms, which were not really permanent or strong enough to be called a building. Even the shipyard was mobile.

The reason I worked to look for this, and had an expectation of finding it, was because I found a Trainer that gave you instabuild for your units. But that's not the only reason. It ALSO only functioned on the unit you were looking at - that is to say, if you paused the game and qeued up build jobs on carriers, shipyards, the mothership . . . but then unpaused it, it would finish all the build jobs on the ship you were focused on . . . but you would have to switch TO the carrier, and inspect it's build jobs, to instabuild all those. Without pausing, they would have built the moment you selected them, and be hard to discriminate from a real instabuild.

In reality, it's obvious (at least, I think it is) that it's using the value that is used to display the current build job for the unit your focused on - not the obviously dynamic value for each individual build job. I have since put the game down, but not uninstalled it - for the sake of experience and experimentation, I'll pick it up again, and give that search a try.

As for building two simultaneously, it isn't a problem in this extremely specific instance, as HW2 isn't a very traditional RTS - since you only have access to unit construction, and each unit can only build one unit at a time (Unlike HW or HW:Cataclysm) there is really only one value at a time, making it (it seems to me) much more likely to be a single, static value.

[Zhoul]

Ahh yes. In this case, the unit is not actually 'created' until the build time is over, yes? Unlike placing a building, at which point a new chunk of unused memory is taken, and time to build applied.

To find a value like the one you describe, is going to be more difficult for this reason.

Lets say you find the value that shows 'current build status' of a unit. You can find out what writes to that value *now* but it wont help you find where it originally copied the total build time from.

As the build time nears completion, you'll see one 'code' (asm block) writing to that value. When it 'completes', if you're watching 'what writes to this value', you will probably see another one pop up at that time.

What would help, is if this value stayed in the same spot in memory , between each build.

If thats what happens, keep watching what writes to the value as it queues up the next ship/whatever. You should see at least a 3rd, if not a 4th/5th piece of code write to the value, which would be copying the piece of memory/build time for that unit.

Once you find that code... Then find out what that code reads from , the next time another unit is queue'd/started. *that* will be the area where the rest of the build times will be around, most likely.

[Zhoul]

Also, just because a unit moves through space, doesnt mean it moves through memory. I only really bring this up, as you mentioned the fact that these 'structures/ships' are ever moving.


Once they are created, they take up a specific space in memory (or spaces) with their properties. The only thing changing is their properties which define X, Y , Z location, and those stay in 1 offset as well.

Collision detection is nothing more then a calculation of which units are close, then further to see if they're actually 'touching'.

Most of the time, there is a separate defined and invisible 'block' on the model itself which represents its collision limits. More and more though, games are going to the much more processor intensive, math that determines if the models themselves are actually close enough to collide (Which is 1. a good thing! makes it more realistic. and 2. has nothing to do with the main point of this thread heh).