| View previous topic :: View next topic |
| Author |
Message |
Snooman Cheater
Reputation: 1
Joined: 20 Jan 2012 Posts: 42
|
Posted: Wed Mar 26, 2014 12:38 pm Post subject: Feature request: Pointer Scanner |
|
|
Hi Darkbyte
For the next version of Cheatengine I'd really appreciate two minor improvements to narrow Pointer Scanning:
1.
Initial Pointer Scan: Base pointer must be in range: from [00000000] to [FFFFFFFF]
If you already know the exact base pointer or in what region the base pointer must be this will be very helpful. At the moment I find this option only when re-scanning a pointerlist. I don't see a point why that is so. This wastes unneeded scanning time and disk space for false pointer paths.
2.
Ability to specify known / unknown offsets.
Or to put it simple: allow "?" as wildcard for an offset.
example:
Pointer must end with specific offsets:
[14C]
[ 20]
[ ?]
[ 16]
What do you think about that?
Last edited by Snooman on Wed Mar 26, 2014 2:29 pm; edited 1 time in total |
|
| Back to top |
|
 |
Chris12 Expert Cheater
Reputation: 1
Joined: 27 Apr 2012 Posts: 103
|
Posted: Wed Mar 26, 2014 1:29 pm Post subject: |
|
|
I think its an awesome idea.
If used, it would narrow down the paths to check a lot.
In my opinion at least something like "base module must be xyz" is really neaded.
Because most of the time, you know exactly what module is using the structure.
For example: If you look for the ammo of a weapon you can be 100% sure the basepointer WILL start in the executable of the game (or one of its related dlls like game.dll / engine.dll etc...) and you know for a fact that something like Direct3D9.dll will never contain a reliable path to the value you are searching for.
I think the features you suggest are really essential to the pointer scanner.
We can only speculate why this hasn't been in it since the very first version of the scanner.
|
|
| Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25807 Location: The netherlands
|
Posted: Wed Mar 26, 2014 1:36 pm Post subject: |
|
|
Base module is in the next version. It won't speed up the scan at all(since the base address is the very last thing checked), but it will reduce the number of results
If you wish a faster scan, use the structure spider instead which is the pointer scanner but then reverse
Also, threadstack0 is a very important base address as well
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
 |
Snooman Cheater
Reputation: 1
Joined: 20 Jan 2012 Posts: 42
|
Posted: Wed Mar 26, 2014 2:25 pm Post subject: |
|
|
So we would not gain scanning time - no problem, this is not essential, I just thought it woud. A good i7+16GB+fast SSD made P.Scan way more comfortable now.
But I'd love to filter the results when I already know exactly what the basepointer must be.
|
|
| Back to top |
|
 |
Gniarf Grandmaster Cheater Supreme
Reputation: 43
Joined: 12 Mar 2012 Posts: 1285
|
Posted: Wed Mar 26, 2014 2:29 pm Post subject: |
|
|
| Dark Byte wrote: | | Base module is in the next version. It won't speed up the scan at all(since the base address is the very last thing checked), but it will reduce the number of results | Don't know if you read my comment on that in another topic, but incase you didn't:
Since HDD writes are the current bottleneck, the less useless results you write to disk the faster the scan. I was thinking base address filtering would improve speed through result reduction.
_________________
DO NOT PM me if you want help on making/fixing/using a hack. |
|
| Back to top |
|
 |
Snooman Cheater
Reputation: 1
Joined: 20 Jan 2012 Posts: 42
|
Posted: Wed Mar 26, 2014 2:36 pm Post subject: |
|
|
| Gniarf wrote: | | Dark Byte wrote: | | Base module is in the next version. It won't speed up the scan at all(since the base address is the very last thing checked), but it will reduce the number of results | Don't know if you read my comment on that in another topic, but incase you didn't:
Since HDD writes are the current bottleneck, the less useless results you write to disk the faster the scan. I was thinking base address filtering would improve speed through result reduction. |
I thought that too. The initial xxx.PTR.x may grow many GB depending what you scan.
@Dark Byte.. I think this was worth a little donation in advance
|
|
| Back to top |
|
 |
Dark Byte Site Admin
Reputation: 470
Joined: 09 May 2003 Posts: 25807 Location: The netherlands
|
Posted: Fri Mar 28, 2014 10:32 pm Post subject: |
|
|
Thanks.
If you wish to test it, I have a 64-bit exe build with the latest improvements to the pointerscanner (it's an custom alpha build so it has some garbage in the gui at places, just ignore that)
http://cheatengine.org/temp/cheatengine-x86_64.rar
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
 |
mgr.inz.Player I post too much
Reputation: 222
Joined: 07 Nov 2008 Posts: 4438 Location: W kraju nad Wisla. UTC+01:00
|
Posted: Sat Mar 29, 2014 12:47 am Post subject: |
|
|
ok, "compressed pointerscan file" option works great. "spent writing percentage" decreased from 40% to 2%.
I made another benchmark, same method as in this thread: http://forum.cheatengine.org/viewtopic.php?t=564603 - my usual benchmark . Overall "compressed" scan is only 10-20 seconds longer than "NOWRITE" version.
no compression, ptr files size: ~10GB, "spent writing percentage" 35%-40%
with compression, ptr files size: ~3.34GB, "spent writing percentage" 1%-2%
_________________
|
|
| Back to top |
|
 |
Snooman Cheater
Reputation: 1
Joined: 20 Jan 2012 Posts: 42
|
|
| Back to top |
|
 |
|