Posted: Tue Sep 29, 2020 8:51 pm Post subject: "Find Out What ..." issue and requests
When using the function "Find out what access/write to this address" you sometimes have locations that is being accessed hundreds of times a second which sadly make the game "freeze" and you wont be able to find what you want to find.
is there a way to limit the update interval (i suppose it lags since it update the table aka screen) or simple being able to "filter" out results.
imgur(dot)com/vM8q27a
Another thing that would be very handy is to be able to be able to set breakpoint in the foundlist "assembly scan"
imgur(dot)com/yhSbvLr
and another nice feature would be "Set breakpoints on callers" instead of needing to jump to each 1 of them to place a breakpoint can take hours if its to many. (decrypt/encrypt functions as example)
imgur(dot)com/k79qeiq
apperently new users aint allowed to post urls.. (dot)
Not really.
The "Find out what accesses/writes..." thing works using hardware breakpoints, which basically tell the cpu to stop what it's doing any time an address gets accessed or written to. It's a hardware-level feature, and there's no hardware-level support for disregarding a certain instruction. I don't think optimizing anything on CE's side will result in any substantial performance improvements considering the overhead that already exists in the CPU generating an interrupt and Windows sending out an exception.
If the instruction writing to the address isn't too important, it might be a good idea to make a code injection that will conditionally change the value e.g. once every 100 times or only when the value actually changes.
And the "set breakpoints on callers" thing... I feel like this is an XY problem. Why not set a breakpoint at the first instruction and look at the stack to see what called this function? If you really want to do it your way, use Lua to automate the process. Read celua.txt for more information. _________________
I don't know where I'm going, but I'll figure it out when I get there.
Not really.
The "Find out what accesses/writes..." thing works using hardware breakpoints, which basically tell the cpu to stop what it's doing any time an address gets accessed or written to. It's a hardware-level feature, and there's no hardware-level support for disregarding a certain instruction. I don't think optimizing anything on CE's side will result in any substantial performance improvements considering the overhead that already exists in the CPU generating an interrupt and Windows sending out an exception.
If the instruction writing to the address isn't too important, it might be a good idea to make a code injection that will conditionally change the value e.g. once every 100 times or only when the value actually changes.
And the "set breakpoints on callers" thing... I feel like this is an XY problem. Why not set a breakpoint at the first instruction and look at the stack to see what called this function? If you really want to do it your way, use Lua to automate the process. Read celua.txt for more information.
Im not sure if its due to how the function works but if that would be the limitation maybe being able to "filter" out that address from the result instead of keep redetecting it. the idea of making hooks to slowdown results in a foundlist is just absurd.
At the momeny i do use the "nop at location" which works in some cases but when it comes to graphic it simply wont work.
Some functions is called by over 20 locations and called hundreds of time a seconds which is why its good to be able to sort out the location who call it at a certen time you do something. placing a breakpoint on the entry simple does not help in situations like this.
The feature can be found in most debuggers and feelt like it belong in CE also
Ok, let me be more clear: filtering results in the "Find out what writes/accesses..." window will not make the game run any faster or slower. If it makes the game "freeze" without filtering, it will also make the game "freeze" with filtering. Such a feature would be purely cosmetic.
If you don't believe me, then go ahead and try it in some other debugger. _________________
I don't know where I'm going, but I'll figure it out when I get there.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum