Cheat Engine

[ParkourPenguin]

What type are you viewing the values as? If you're looking at them like they're a 4 byte value, it could be that they're actually a float or a double (I'd bet on double). Try shifting around the alignment of viewing the data as a double on a 4 byte boundary. In other words, if the 4 bytes at the address 07001234 are changing, try adding a double to the address list, and put in 07001230 for the address. If that doesn't look right, try changing it to a float. If it still doesn't look right, try doing both of those but increase the address by 4 (view address 07001234 as a double and a float).

I'm not entirely sure what you meant by that last line, but if you want to track the changes to an address, I made a script that would do that here.

[Majin]

Naw, they display fine; they're float values. It's just odd that there are duplicates of the position data, is all.


Not an address, but, like, watching a region of memory for addresses that change. When they do, display the address and the value that was changed, and the new value.

Even better, would be if CE could track the changes and display all of 'em.

[ParkourPenguin]

You can use that script I linked to and watch multiple addresses.

[Majin]

I managed to find the xzy positions that are actively updated (as in, when the enemy moves, these float addresses change in accordance), but, uh, oh my god is it insane.

The x z y positions (not ordered as x y z due to Havok I think) are stored in a pointed at offset 88 from the NPC's structure. The thing is...There are hundreds of addresses with the exact same position, surrounded by seemingly nonsensical variables consisting of decimals changing many times a second.

Sorting through the automatically generated structure data is a nightmare in and of itself (an address split up into four separate bytes when it should be a float for one of the axis' positions, for example).


It's just...Bloody what?

I managed to get 11 sets of the xzy values before I gave up, as I didn't even make the scroll bar the tiniest bit bigger, in the structure window.

Changing the address manually does nothing, as it's promptly overwritten. The instructions that write to the addresses, when looking at what writes to the xzy addresses, are modifying hundreds of addresses at any given moment.

Like, this is insane. I used CE's "Replace with code that does nothing" feature to see if that would freeze the npc in place, which immediately crashed the game.


Uuuurgh. It would have been a godsend if Technojacker explained what the code does and how it works, in his table, as I'm feeling utterly helpless.

[ParkourPenguin]

[Majin]

[ParkourPenguin]

You can right click on an instruction and select "Find out what addresses this instruction accesses". So find the script in the disassembler (register a symbol if the script doesn't do that already) and do that for whichever instruction(s) you want.

[Majin]

[ParkourPenguin]

Let's take the "Monster Vac" script for example. First, we need to look at all the registered symbols.

[Majin]

AAAAH! Labels function as an address! That had me stumped for yonks. I was looking for a "Move to symbol" address. Ya just have to right-click -> "Go to address" -> Type in the name of the label.

Movq seems like a very bad thing to use, no? It moves a quadword, which is 64bit, and the game is only compiled for 32 bit. Would explain why enabling/disabling the script several times will crash the game.

esi+10 is the x axis, and esi+18 is the y axis. Yet, somehow, the script modifies the Z axis.

Since it's using quad words (eight bytes?), the z axis is included in the esi+10 instruction. Wonder why a quadword is used at esi+18 though, if the three axis are already obtained.

Anyhow, got one of the addresses. I'll go check where it is in the structure.


Edit: Huh. It's before what I thought was the base of the NPC structure. The offset of the x axis is @ -2C0. Maybe each NPC's data structure is placed right after the NPC position structure?

[ParkourPenguin]

The instruction movq isn't an x86-64 instruction, it's an extension of the x86 instruction set (probably introduced with SSE2). It's perfectly fine to use that on 32-bit systems.

The reason why it modifies the z axis is that it's moving 8 bytes at a time with the movq instruction and single-precision floats only take up 4 bytes. Sum up the different axes, and you get 4+4+4=12. So it uses two movq instructions to do this: The first one gets the X and Z axis, and the second one gets the Y axis along with something else.

It might be that another structure contains pointers to both the entity's position and the entity's data.

[Majin]

Aaaaagh. Turns out that the offset is invalid; the address of the position data changes whenever the NPC is reset (e.g, resting at a bonfire) or reloaded (player died, load screen, restarting the game, etc).


Man, it would have been killer if the creators of the scripts shared info on this stuff.

One of the instructions run when the enemies are reset, has the esi register set to the NPC data with the +90 offset. Might be significant, I suppose. Adding that offset to the structure doesn't yield anything usable; it's not a pointer, but is good to have I suppose.

[Majin]

Having utterly no luck with the position data, I was pointed to where much of the AI data is kept; a non-unicode string search for "NPC_THINK_PARAM_ST" will yield two searches. One earlier in memory, the other later. You want the latter.

I'm having to use the debug mode to identify the addresses, which is better than messing around with hex bytes manually I suppose.

Is it possible to add a group to the structure window, exactly like how Cheat Engine has groups in the address list? There are a lot of values at different offsets (all of them an equal offset apart, however).

The autocreated values are useless, as most of the generated ones are 4 byte hex values, instead of them actually being strings, floats or 2 byte hex values, with the odd 4 byte value.

So being able to group 'em up, so I'll be able to have the offset for the beginning of the Silver Knight AI data (for example), which will expand to show all the offsets in regards to the data.

I can add the offsets manually, since it will be easy once I have the first one done; get the proper offsets for one set of AI data, duplicate it, then just add an offset to the offsets, and BAM. All the AI data.

[ParkourPenguin]

You can go to File -> Add New Group, but I don't think that's what you're talking about.

You can delete elements that aren't important to you in the structure. And again, stop complaining about CE's autoguess values being wrong. If you want to try to make a better one, use the Lua functions registerStructureDissectOverride or onAutoGuess. Just change the elements if they're wrong; it's not that hard.

If you only want to display elements that fall under a specific category, you can define a new structure and add all the elements you want to it manually.

[Majin]