by L. Spiro » Tue Jul 18, 2006 10:28 am
As LouCypher mentioned, Tribes 2 triggers massive amounts of software exceptions (access violations).
Memory Hacking Software’s debugger was originally designed under the assumption that most of a game’s access violations would be caused by Memory Hacking Software itself, because that is how software read/write breakpoints work.
It was assumed that no game would be put together so poorly as to be constantly throwing access-violation exceptions with no cause.
Tribes 2 is a game famous for being so buggy out of the box that you absolutely must have patches to play it.
My first Tribes 2 experience involved jumping into a vehicle, and when the vehicle drove around, my guy drove with it, but my camera stayed in one spot, so I could watch my guy driving the vehicle, at least until I went over a hill where I would have to jump out and back in again to move my camera near.
Over the course of several patches they fixed many access-violation bugs simply by using IsBadReadPtr(), which is a function that checks for read access on addresses by attempting to read from them and then catching any exceptions that arise.
These exceptions are access violations, which is why Tribes 2 is constantly spamming access violations and lagging my debugger.
I fixed the speed issue in 3.0.0.2 Pro by checking to see if any software read/write breakpoints have been set, and, if not, immediately breaking from the trap.
This makes the game run at normal speed while being debugged, however there are some new problems with debugging it, and I have to find the time to look into it.
I will be completely rewriting the debugger in one of the future releases, and it will fix all problems.
the breakpoint handlers will be faster and more powerful, yet backwards compatible so this cheat will still work in future editions.
L. Spiro