Cheat Engine

[Coreveen]

Hey all. So I was wondering what's up with this game and if there's any way to solve this rather annoying issue.

Basically what's happening is, when I load the game and attach the table and then proceed to load into the world and perform the related action at least once to get it loaded into findable memory for the script to activate - that half or dare I even say 75% of the time it just simply doesn't activate.

The thing is, if I search for the value in question again, find it, and repeat the exact same process to re-create an alternate version of the AOB scan script, it produces an exact clone of the original script - the same array of bytes in the enable and disable sections and everything. Yet the game just ignores it in this alternate state.

The only fix I've found is to completely close the game and spend another 100 - 120 seconds loading the game and world back up and repeating the process for another 25-50% chance that it will work.

I've loaded this table at least 50 times over the years so I can confirm this behavior is accurate, I'm just getting sick of not knowing why this happens and seeking help and advice from the professionals here.

This isn't just for one value either, if this alternate instance enigma occurs, none of the other AOB scan scripts will activate either, even if I try re-creating them. The game is Valheim on Steam by the way.

Does anyone have any ideas?

[ParkourPenguin]

You probably can't directly address `findweight`- the globalalloc needs to be within 2GiB of the instruction addressing the memory location. I forget if globalalloc can take a third parameter or not, but you might be able to forego it and use registersymbol instead.

[LeFiXER]

[Coreveen]

[ParkourPenguin]

Branch instructions (call, jmp, jcc) can address memory locations using a signed 32-bit relative displacement (i.e. give or take 2 GiB). They can't directly address most memory locations further away. CE can do a little bit of trickery to jump to addresses further than 2 GiB away, but CE uses a 14-byte jump instead of a 5-byte jump. If you don't account for these extra bytes in your script, it will almost certainly crash the process.
This is what the third parameter to alloc is for: CE will only allocate memory within 2 GiB of the specified address so that a 5-byte jump can be ensured.

Other instructions that address memory locations (e.g. mov) use something that's practically the same called RIP-relative addressing. This allows instructions to directly address a memory location within 2 GiB of where the instruction is located. If the addressed memory location is further away, the instruction can't be assembled and the script will fail.

[Coreveen]

Well the alternate version managed to find the weight, which is a success and a great extra tool to add to the old script toolbelt!

It's just unfortunate that I don't quite grasp an understanding of what is happening. I get the push and pop instruction section but i've never seen this align function nor do I have any idea why 8 CC is used and what I would change to make it work correctly in other scripts where it gets used.

Thanks for taking the time to explain these things, trying to wrap my head around them.

[ParkourPenguin]

CE's align pseudoinstruction simply inserts bytes in memory (i.e. 0xCC) until the next address is aligned to some specified amount (i.e. 0x8).
It's unnecessary most of the time- the CPU will resolve most "problems" that can occur with unaligned accesses. I just find it annoying when data access is unaligned as it goes against the information I've learned from compilers.

[luplay2]

Thanks for your discussion! I have learned a log.