Cheat Engine

[mouser]

I'm a fool... I never looked at a dissected memory region with mono support enabled until now (attachment).

It shows everything in detail, black magic if you ask me ...how does that even work?

From there I've tried changing some new values to see if I can change the camera position (Z) without using the address with the value 11 (turns out it is declared as "DefaultCameraDistance".

So I have increased the numbers on "Deadzone" as that sounds like something that would restrict the camera in it's freedom and it does. The standard value at the beginning of the game (and presumably the rest of the game) is set to "2", I manually ramped it up to 50 and can move the camera around nearly as much as when disabling certain functions that I've mentioned in previous posts.

@justa_dude:
I did change the value "11" (DefaultCameraDistance) also manually.

The problem I have now with the "Deadzone" address is the same as with the "DefaultCameraDistance", nothing writes to it.

@Zanzer:
You may already have provided a resolution in form of that Lua script, I plan to look further into that but Lua seems to be another big chunk to wrap my head around and this takes me a lot of time so I want to ask if there is another way to store/restore these values?

I don't want to change these values manually because I want to create a script where you press "F1", then move the camera around and press "F1" again and the camera returns to it's former state in every aspect. It already does that for XYZ panning/rotating motion, the script provided by alanze (thanks btw) is doing that.

For these distance/deadzone settings it seems that the values wont return to their former state when I change them manually and I can't use the same code I've used for XYZ camera panning /rotation movement. I don't know why the value at these addresses change at all when I just nop the instruction (if it is an instruction!) and restore it the same way it was, to be honest.

Deadzone

[justa_dude]

Long post... I don't know where to start.

[Dark Byte]

[mouser]

Hi again, was a longer pause, sorry for not answering in time.

@justa_dude

I didn't want to cause confusion, I'll try to stay on problem at a time.

When you say "Just restore them the same way you change them...", refering to values and addresses here, I think I just still have problems changing them the right way.

Let me try this with another example, I'm trying to change Air/breath in a Tomb Raider game.
I have found the adress where the value is stored, but when I just freeze the value I will still run out of air when diving around and die eventually. As I understand it (having read that somewhere here) CE is not updating the value fast enough so I have to change the instruction that is setting the value in the first place.

I searched what is writing to that address where the value is stored and got one address, the instruction is:

[Zanzer]

fld dword ptr [esp+10] is loading a floating point value onto the stack
fstp dword ptr [esi*8+tra.exe+265268] is popping that value off the stack into the address

That address is calculated as follows:
Take the value in ESI (0x41) and multiply it by 8
Add that total to the address tra.exe+265268
So: tra.exe+265268+208

It almost sounds like you found the wrong address if freezing it did not stop you from drowning.
I can't imagine the game kills you that fast.

Anyway, you would need to replace that instruction with fstp st(0) to stop it from updating.
This pops the value from the stack into nothing in order to prevent a stack overflow crash.

However, since that instruction has a static "tra.exe+265268" it may make your script better survive patches to hack the "fld" instruction above instead.
For example, if the value starts at 0 and counts up until dead, you might replace the instruction with "fldz" to load 0.0 onto the stack.

[mouser]

Hi Zanzer, you were correct, I did find the wrong adress. What I have found was probably the display/graphic for the Air-meter because when I replaced the code