Relying on mono data collector for tables

Want Cheat Engine to do something specific and no idea how to do that, ask here. (From simple scripts to full trainers and extensions)
Post Reply
all_my_sins
Table Makers
Table Makers
Posts: 164
Joined: Sun Jun 13, 2021 12:01 am
Reputation: 264

Relying on mono data collector for tables

Post by all_my_sins »

What are the pitfalls to relying on the mono data collector over AOB in tables? Thanks!

EDIT:
Pitfalls
1. methods sometimes have the same name.
Last edited by all_my_sins on Sun May 29, 2022 12:54 am, edited 1 time in total.

all_my_sins
Table Makers
Table Makers
Posts: 164
Joined: Sun Jun 13, 2021 12:01 am
Reputation: 264

Re: Relying on mono data collector for tables

Post by all_my_sins »

Maybe I can clarify: For the purposes of creating a table, are there any concerns with relying on the mono data collector for unity games vs. AOB? Are there situations where it would be inadvisable? I've seen a couple of tables now that just turn on the mono data collector and use the addresses it provides and if that was just as good as AOBs in Unity games, that would make my life easier.

User avatar
LeFiXER
LeFixer
LeFixer
Posts: 479
Joined: Wed Mar 24, 2021 9:35 am
Reputation: 242

Re: Relying on mono data collector for tables

Post by LeFiXER »

Mono data collector can give narrower searches for AOBs which in turn makes activation of scripts faster at the expense of giving off more information. Anyone that downloads the table will know where to look to update should the original author fail to update. I'm certain you can do the same with normal AOBs but I think mono makes this method easier.

User avatar
VampTY
Table Makers
Table Makers
Posts: 809
Joined: Tue Mar 05, 2019 10:52 am
Reputation: 1047

Re: Relying on mono data collector for tables

Post by VampTY »

I prefer using aobScanRegion instead of aobscanmodule in Unity, is rather faster updating and reading the values if pointers are involved or not.Depends if the game based on unity engine has obfuscated values or not, protection or not, if is IL2CPP involved or not.Some, in Unity can be even used as normal aobscan or aobscanmodule, you can even add the .exe's name or not.Using "aobScanRegion" will tell you exact what's missing if you need to update.In some cases, you can add "??" instead of unused bytes or "*" for symbols with direct "readmem".I prefer scripts instead of pointers though, for working scripts add the address to the name.I'm not the best in explaing.Or, back and trace to the thingy you want to update, let's say life for one character, backtracking to it's real address, add it to "readmem", see how much is in hex, then even if is updated or not, will always read the real value or address, just like other game engines.I'm just an amateur in all these, but you get it! :P

Have a wild night baby! :wub:

TheByteSize
Expert Cheater
Expert Cheater
Posts: 293
Joined: Sat Mar 04, 2017 7:28 am
Reputation: 232

Re: Relying on mono data collector for tables

Post by TheByteSize »

Unity doesn't load the Method/Function into memory until that particular Method/Function is needed. By using Mono Data Collector to invoke it first would allow you to AOBscan early and initiate your script before it even needed like other game engine.
For Unity engine game, make a habit of anticipation for 14 bytes jump.

all_my_sins
Table Makers
Table Makers
Posts: 164
Joined: Sun Jun 13, 2021 12:01 am
Reputation: 264

Re: Relying on mono data collector for tables

Post by all_my_sins »

LeFiXER wrote:
Mon Nov 15, 2021 7:21 pm
Mono data collector can give narrower searches for AOBs which in turn makes activation of scripts faster at the expense of giving off more information. Anyone that downloads the table will know where to look to update should the original author fail to update. I'm certain you can do the same with normal AOBs but I think mono makes this method easier.
Thank you for clarifying!
VampTY wrote:
Mon Nov 15, 2021 8:13 pm
I prefer using aobScanRegion instead of aobscanmodule in Unity, is rather faster updating and reading the values if pointers are involved or not.Depends if the game based on unity engine has obfuscated values or not, protection or not, if is IL2CPP involved or not.Some, in Unity can be even used as normal aobscan or aobscanmodule, you can even add the .exe's name or not.Using "aobScanRegion" will tell you exact what's missing if you need to update.In some cases, you can add "??" instead of unused bytes or "*" for symbols with direct "readmem".I prefer scripts instead of pointers though, for working scripts add the address to the name.I'm not the best in explaing.Or, back and trace to the thingy you want to update, let's say life for one character, backtracking to it's real address, add it to "readmem", see how much is in hex, then even if is updated or not, will always read the real value or address, just like other game engines.I'm just an amateur in all these, but you get it! :P

Have a wild night baby! :wub:
I've never tried aobScanRegion, I'll look into it! Thank you for the description as well, very helpful!
TheByteSize wrote:
Mon Nov 15, 2021 8:47 pm
Unity doesn't load the Method/Function into memory until that particular Method/Function is needed. By using Mono Data Collector to invoke it first would allow you to AOBscan early and initiate your script before it even needed like other game engine.
For Unity engine game, make a habit of anticipation for 14 bytes jump.
Thank you! I'm not sure just invoking the mono data collector is enough to trigger JIT compilation, I think other steps are needed, but I haven't explored that yet. Very helpful, though!

I'm gathering from these replies that there is not much concern about relying on the mono data collector over AOB. I'll give it a shot with a few tables and see how it goes. Thanks, everyone!

Eric
Hall of Famer
Hall of Famer
Posts: 174
Joined: Thu Mar 02, 2017 11:01 pm
Reputation: 90

Re: Relying on mono data collector for tables

Post by Eric »

just activating mono and looking up a method will JIT that method

Post Reply

Who is online

Users browsing this forum: No registered users