Cheat Engine

paul44 · Last edited by paul44 on Mon Apr 15, 2019 11:40 am; edited 1 time in total

I recently made a table for AC III REM. Strangely enough, a number of gamers - using the exact same exe - can't seem to enable a number of the cheat scripts. One of them was kind enough to perform some verifications for me. Turns out CE does find the AOB strings when doing a manual scan, but somehow CE simply will not enable the script(s) in question?!

Example of such script (+ manual AOB scans): [ https://imgur.com/a/7N70o7X ]

Note: that one script in particular (which collects the player's coordinates) does enable fine...

Q: somebody can clarify this, and more importantly, possible solution/workaround?

ps: I'm working with Win7 - but based on the mem_location - either this gamer has plenty of RAM and/or is on Win 10.
ps2: I tend to replace the "effective offset address" in the alloc() for practical reasons, but - just to be sure - I had the gamer tested with the original_generated AA script as well.

ParkourPenguin · Posted: Sun Apr 14, 2019 7:48 pm Post subject:

The memory allocated by globalalloc is probably more than 2GB away from the injection point- you can't address it directly in square brackets.

I think globalalloc can take a third parameter to specify the region to allocate memory in (similar to alloc). If that's not feasible, store the address in a register and address it using the register:

paul44 · Posted: Mon Apr 15, 2019 2:13 am Post subject: $process...

Based on the examples - used in the wiki - I have changed the script as follows: 'globalalloc(pStructHealth,8,$process)'. This still works on my side; have sent it over to gamer for testing... (you'll get updated evt)

That said: to proact on the situation, in case of failure:
a) could using alloc() give better solution/solve this?
b) since I'm talking x64 here, I guess I should/must use RAX here ? (well, I will anyway)
c) other ?

ps: I was "guessing" it would be in the lines of "out of mem_loc boundaries" (found/read a couple of articles here on the topic; but none of the suggestions resolved my problem). Can I safely assume that such phenomena:
1. would NOT happen with any x32 application (whether it is running on win x32/x64)
2. could "always" happen with a x64 app at some point? (I have created some other "x64" tables in the past, but this is the first time several gamers reported this issue)

ps2: user has Win10_x64/16GB ram; I'm on Win7_x64/12 GB (I immediately noticed the mem_loc on the user's side: game loads much higher up in memory, unlike in my case ~ a quick check in the [Mem Regions] tells me most/all game dll/drivers are loaded there).

ParkourPenguin · Posted: Mon Apr 15, 2019 7:37 am Post subject:

paul44 · Posted: Mon Apr 15, 2019 11:34 am Post subject: SOLVED.

First off: user mailed me today that the script is now working. So thx for pointing me in the right direction.

For completeness sake, find the Symbol list BEFORE and AFTER the update here: [ https://imgur.com/a/xQSbDQc ]. In the last case, notice proximity of the allocated memory in relation to the AOBScan's 'cave'... (I've used $process, but probably using the symbolname would give me similar results).

ps: what I meant to say with 'mem_loc' was: that the allocated memory (location) to the global 'variables' would reside outside that 2 GB limit boundary (which I picked up in one of those discussions). Sorry for the confusion...
I guess (!) it relates to this: [ https://stackoverflow.com/questions/3818746/is-there-a-limit-to-how-far-a-je-can-jump ]?
ps2: maybe a coincidence but the 2 reporting players confirmed running W10... (in the 20-30 restart/run/loads, I never encountered this problem on my Win7 ~ in fact, first time ever)