Vindictive Newbie cheater Reputation: 0
Joined: 02 Oct 2017 Posts: 17
|
Posted: Mon Nov 20, 2017 1:28 am Post subject: Suggestion - Pointer Scan time estimate? |
|
|
It's probably already been thought of but I couldn't find anything related to it on Google.
Is it possible to estimate how long your pointer scan will take based on the memory size of the program, the paths/second, your max offset parameter and your max level parameter? I lack a lot of the theory that goes behind the scenes of cheat engine but it seems to be a combinatorics problem where we can figure out how many paths CE will have to brute force and by knowing our paths per second we can do the math to give an estimate.
Thought this might be a nice feature as I may be willing to wait 8 hours to do a scan but maybe not 7 days but right now I have no way of knowing how long it will take
|
|
Dark Byte Site Admin Reputation: 458
Joined: 09 May 2003 Posts: 25295 Location: The netherlands
|
Posted: Mon Nov 20, 2017 5:42 am Post subject: |
|
|
the way the pointerscan works makes predicting how long it takes pretty difficult to impossible (without slowing it down a lot)
how it works in basic terms:
It looks for a pointer that falls within the range of the current pointer you're looking at.
If so, it adds it to a queue and then keeps on searching.
then randomly other CPU's take pointers from that queue and then they look for pointers that fall in that path, etc...
If I didn't let other CPU's share in the load I might be able to calculate how long it would take by calculating the max number of paths possible and the current branch/base it's at now, but as it is now with random cpu's adding workloads to the queue from random level heights it's quite impossible.
Hmm, alternatively, I could calculate the total number of paths possible and then deduct the total number of paths skipped and processed, but that would require adding counters to the most timecritical codeloops probably decreasing the speed (and would still not be accurate)
---
Tip, check the "limit nodes" option and set it to 3 or 4, it will usually save you a lot of time
----Explanation---- (boring stuff, you can skip if you like)
when the scan processes a pointer it requests the pointervalues of pointers that have your pointer within range. with the node limit on it only picks the 4 closest values (lowest offsets) and throws the higher ones away, ignoring the structuresize
e.g:
you have pointer 00412300 and structsize of 100 (example)
and the following pointer values within that structsize are:
00412300- (offset 0) - (6 pointers have this value)
004122f0- (offset 10) - (2 pointers have this value)
004122e0- (offset 20) - (1 pointer has this value)
004122d0- (offset 30) - (10 pointers have this value)
004122c0- (offset 40) - (150 pointers have this value)
004122b0- (offset 50) - (12 pointers have this value)
then without a nodelimit the pointerscan has to follow 6+2+1+10+150+12=181 pointers which all branch of in a lot of pointers again and again and again (up to max level)
with a nodelimit of 4 the pointerscan only needs to follow 6+2+1+10=19 pointers, which also all branch out but are also limited by the max number of nodes, causing the scan to usually only take a few minutes or even seconds (ignoring the pointermap generation/loading at the start)
_________________
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 |
|