Cheat Engine

[paul44]

I made a little script to identify the different game EXE versions. What I post here (see below) works fine, but I do have some questions about it:

1. when I enable the script the very first time, it takes a "pretty long time" (5-7 secs) before its address/value (of symbol 'nDRM') is shown in the table? (once done, killing the game and loading another version almost instantly update its info upon re-enabling this script)
2. I initially tried to use 'readBytes', but I still have trouble in getting all bytes presented as 1 string. It appears to return an integer (?); which then needs to be converted to a string for easy comparison. If I read 8 bytes, I probably have to code a loop for that (seen some examples around here).
Also tried with the 'table' option, but that did not provide an easy solution either...
Q: is there an easy function/instruction to actually generate f.e. an 8-byte string, so this can be "visually" compared with the AOB strings? (so that I can simply compare the AOB strings "at the top" in my IF statements)
3. setting the symbol value 'nDRM' took me some time to get it working (looks simple enough though )
I initially started with the 'nDRM:' in the 'autoAssemble' section, but could not get it working; evt it did via the luacall. But since the initial initialisation took so long, continued experimenting with this... which gave me the current version (although I probably stick with the luacall ~ and it still takes the same time to update in the CE table)
Q: why is that "$asm"-part not working in the 'autoAssemble'? And perhaps there is an easier way to get the symbol initialised?

Btw: all scripts depending on the 'nDRM' value are 'children' of this script; making sure the symbol - at least - does exist/is initialised.


*****************
FYI: used in my AC BF table.

[ParkourPenguin]

1: It's probably because you're registering the symbol inside a separate AA script in a Lua block in the actual AA script. Embedding AA scripts like that is almost always bad. If you registered the symbol in the actual AA script, CE would update the address list.

2: You should use readString to read a string. However, that is not a string- those are bytes. Instead of doing whatever it is you're trying to do, use md5memory(process,4096).
2Q: No, because that's stupid if you can just compare the bytes. You could use a loop, but the "most correct" way would be to use metatables (IMO that's a problem with CE's API).

3: You could just return a string from the {$lua} block and it'll be inserted in the AA script:

[paul44]

1. Unless you mean something else, 'nDRM' is initialized only in this script (posted here). That said: once I "removed" the 'autoAssemble' altogether, and changed to:
_____________
{$asm}
globalalloc(nDRM,1,$process)

nDRM: // (works fine)
db $nDRMval
_____________

CE seems to update at "normal speed" now (will see how this goes during rest of week)... My guess here: since I already tested the $asm part - without success - moving 'globalalloc' to this location made it speed up (will do some more testing this weekend ~ same with $nDRMval: will try the principle as suggested in your code to eliminate the '$' variable).
Btw: the registersymbol is indeed superfluous; can't remember why/when I did this, but the script has changed quite a few times since then...
(ps: to get an idea how my table is set up: [ https://imgur.com/a/xlXb2oL ] ~ the '*' scripts depend on 'nDRM's value)

2. Not going to use 'md5memory()' for this reason: [ https://cheatengine.org/forum/viewtopic.php?t=601376&sid=d2c59ddcdbfd18887e0e0006a38d7f05 ] (unless that function has been updated since then). Which is - btw - also the reason why I ended up with this solution. Even more...

As #atom0s suggested, use Aobscan for this purpose. I can tell you know: I did try - and read quite a few articles on the subject back then - but was never able "to combine" multipe Aobscan's in one script. Meaning: IF 'Aobscan_1' fails, try 'Aobscan_2', etc. Basically, this is what I'm doing now, but using 'readQword' instead... (I thought that readBytes would give me the full AOB string in hex_bytes; but it doesn't... (there you go )
FYI: in the table I showed (see imgur above), the Inventory uses 2 completely different code locations; iow it is not just a matter of a few different bytes.


And if it wasn't clear enough: the script works - and probably sets the table value at normal speeds now - it is all about "visualisation". The AOB string in the 'aobscanmodule' command matches exactly with what one finds via the [Memory View]. Testing on the returned integer is ok, and after some T&R, I also got it working for the 'hex_values' (be it in reverse, and trimmed).
It is all about this lather part: trying to "visually test on the exact same hex_bytes" as shown in the Mem_Viewer (in that order). (probably "anal", I know, but I had an extra long weekend so...)

-UPDATE-
Did some additional testing last week(end): it seems - with globalalloc - in the {$asm} section, that CE always updates the table pretty much instantly. While in the {$lua} part, it sometimes updates quick, must "most of the time" it does not...
ps: rebooted with each attempt, as - even after login off account-wise - CE always picked up the latest selection immediately.