This looks like a cheat for 'Raft' (which I've been messing with lately). There's a mono class called `CostCollection`.
If you don't know assembly language at all, better go through some tutorials on it. If you do and just haven't used CE before, I'll explain how the autoassembler scripts work. I had some trouble figuring out what CE does when I started, even though I knew assembly language. It basically does not RUN the code when you activate or deactivate the table entry. Instead if ASSEMBLES the code INTO THE GAME. There are three sections to every script in a table entry:
- Above the '[ENABLE]' line - this is assembled both when activating and deactivating the script
- After the '[ENABLE]' line and before the '[DISABLE]' line - this is assembled when activating the script, but not when deactivating it
- After the '[DISABLE]' line until the end of the script - this is assembled when deactivating the script, but not when activating it
The 'CostCollection' class has methods called 'MeetsRequirements' and `HasEnoughInInventory`. From their names and the comments they would seem to be functions that return true or false (rax non-zero or zero) based on whether the player has enough materials in their inventory. The top appears to be the [ENABLE] section without showing the [ENABLE].
What happens when activating the script is the following:
Code: Select all
CostCollection:MeetsRequirements: // Crafting in Inventory
The ':' means this is a label. When using mono, the mono data collector gives you symbols for methods like this. When a symbol is already defined, Cheat Engine SETS the address to continue assembling code to that address. This is the reverse of using your own label, which sets the address of that label to the current address of the assembler. Say for instance the method is at 0x7f10009c in memory. Cheat Engine will change it's internal assembly pointer to that address, and any instructions after this will start being assembled at that address.
This method normally has complicated logic to check a player's inventory for required items before returning. What this does is assemble the 'ret' instructing at the current address, which will be the start of the function label above. This makes the function return immediately and skip the normal logic.
Code: Select all
CostMultiple:HasEnoughInInventory: // Crafting when building
This does the same thing for the other function, first moving the address of the assembler to the new function, then assembling the 'ret' instruction at that address. If you use the memory viewer, you can goto 'CostMultiple:HasEnoughInInventory' and see the function. When you enable the script you will see the first instruction change to 'ret'. Now when the game calls that function it will return immediately, and presumably rax will have a non-zero value meaning that the return value will be true (really should do mov al,1 or something, but whatever)
This marks the end of the enable section (assembled when the table entry is activated) and the start of the disable section (assembled when the table entry is deactivated). From here on, the code will get assembled when DISABLING the script, not enabling it.
Code: Select all
Like above, this moves the address to assemble code to the function's address, and assembles an instruction 'push rbp'. This is the original instruction that was there before activating the script, so it returns the game to like you never activated the script. Likewise for the other function.
To see what it does, open the memory viewer and right-click and select the top option "Goto Address" and type in one of the function names like "CostCollection:MeetsRequirements" (without the quotes). Keep that window open to the side and see what happens as you enable and disable the script.