* Comparing code TRL vs TRA: both games show great similarities in code. Besides some differences in offset, most cheats were taking from my TRL table with little changes to make...
ps: TRL vs TRU is quite different. I have not yet taken the time to compare TRA with TRU, but I'm guessing it will be just "as different" as it did with TRL...
* Labelling functions: see [
[Link] ]
This research is based on #Sunbeam's feedback: [
viewtopic.php?p=173385#p173385 ].
However, I did come across some obstacles, that - at this stage - makes this process "less" interesting:
1. You can export your "labelling" work (to a json file), but it does look like it is 'bound' to that particular game exe; and definitely that game version.
- renaming the same exe will no longer find them labels; although I'm guessing this is my lack of x32dbg knowledge, and how it saves info per game_exe basis... (similar to how it keeps them breakpoints for example)
- removing labels, and then importing the (json) database will not update the labels either
2. As stated earlier (see also json file), the db file is "game_exe" locked?! That would mean that game updates could dissolve your work in this area unfortunately... Since labels seem to be linked directly to their mem_address location, any updates in that area obviously will fail loading those labels. Also: the json file does not have a Module_base address; which could possible fail loading if your CPU loads the module/game in a different location altogether?! (if that is all possible ofc)
3. I have found no solution on how to export/convert to a pdb file (if even possible)
4. Label db: possible better approach: use unqiue AOBs (+ offsets) to link labels instead (with a "backup" aob just in case). And 2 saving routines: a) save as aob b) save as mem_addresss... (~ loading a 'aob' db could take some time to update; once done, save as mem_addr)
* Run speed: normally not my kind of stuff to research. But I always check trainers to see what they offer, and the one really working for me came from #Sunbeam's table (yep). Did some initial research myself - looking for some values to change - but was not getting anywhere (although I did find the right struct, as it showed later on). So, after some on/off's with his table, I quickly found a 'default/fixed' speed-parameter... Logically, this type of info usually is related to the player's coordinates; and actually found 2 pointers: one with a 'constant' updated param and a 2nd just being read (which is the one i'm using here)...
