Breakpoints

[Zach]

At the risk of getting a condescending reply, I'm going to ask this anyway because it's been driving me nuts for two weeks now.

Is breakpoint functionality broken in the current version of MHS?

(And yes, I have the debugger attached, and yes, the breakpoint(s) are listed in the helper Breakpoint tab, and yes, even the RMB context menu has the breakpoint commands disabled and "remove breakpoint" enabled [indicating that a breakpoint is already set].)

So, for instance, I know that code address 005DF590h will be executed when the player's fuel and money are displayed on-screen, and only then. (In game, you have to hit a key to display it.)

So in MHS, I go to the Disassembler, make sure it's attached to the application (I have it auto-attach, hence I why I verify since I'm not that trusting ), go to address 005DF590h, right-click and add breakpoint as shown:




But alas, when in-game and I display my fuel and money, no breakpoint is hit. (I've even tried detaching and reattaching the debug, but still no go.)

Now, Visual Studio, Cheat Engine, and OllyDbg all break just fine at this location as expected. It's only MHS that refuses to break, for this and also for several other locations I have tried.

So, first we have the SSE instructions that you say the disassembler should be able to recognize but doesn't, and now we have breakpoints that fail to get trapped (in the Disassembler), so now I'm wondering if maybe your disassembler got broken somehow in this latest build.

[L. Spiro]

Ensure that the Auto-Hack is not enabled while your user breakpoints are set. Only one group of breakpoints is active at a time. Either user breakpoints, Code Filter breakpoints, or Auto-Hack breakpoints.

Also ensure that your breakpoints are not on the same addresses as the Auto-Hack hits when you disable the Auto-Hack.
This is not intentional.


L. Spiro

[Zach]

Ensure that the Auto-Hack is not enabled while your user breakpoints are set. Only one group of breakpoints is active at a time. Either user breakpoints, Code Filter breakpoints, or Auto-Hack breakpoints.

Okay, that was the problem. I usually have one or two addresses in there (in Auto-Hack), so when I cleared them out and then set the breakpoint in the disassembler, it finally worked.

This is not intentional.

So does that imply that this is a bug that may be fixed in some future build? Auto-Hack (to monitor data addresses) and the Disassembler (to monitor code) kind of go hand-in-hand in the debugging process, and having to manually clear the data addresses is a tad inconvenient. It's not a big deal in the grand scheme of things, mind you, as it's easy to add them back, but I'm just wondering if this is a bug or a feature?


Also, I doubt this is anything you'll bother to investigate since you'll probably classify it as "not my problem," but I'm going to through this out there anyway.

I'm running the game through DXWnd so I can run it at 800x600 Windowed mode. Up until now, obviously, I've using Visual Studio (mainly), Cheat Engine, and OllyDbg to debug/trace the program with no problems.

The odd thing is that with your debugger, after the breakpoint is reached, my mouse remains constricted to the 800x600 area on top of the game! I could task switch to other apps, including the debugger, but I had zero mouse functionality since I couldn't get the mouse them.

Interestingly, Windows' Task Manager seems to reset the mouse, so I guess there is a workaround, but again, I just thought I'd through this out there since it only happens with your debugger and not with VS, CE, or OllyDbg. *shrug*

[L. Spiro]

Apparently there was a change at some point in the inner workings of the debugger that cause the user breakpoints to be unset by the Auto-Hack breakpoints when the Auto-Hack breakpoints are resetting.
This is my guess without having looked into the problem.

However you have misunderstood part of the solution. You do not need to remove the Auto-Hack breakpoints/addresses. Just Stop the Auto-Hack. Resume it when you want to use it again.

As for problem #2, this is probably caused by the window maintaining a lock on the mouse, which can be reset by MHS, fixing this problem, but obviously it does not do it in this release. Next release.










If there is one.


L. Spiro

[Zach]

If there is one.

Aww. And I was so desperately hoping for SSE instruction support in the next version, too.

Oh, well, I think I recall you mentioning that you just started a new job, so I completely understand.

[L. Spiro]

Problem #2 fixed (most likely) in MHS 5.004.


L. Spiro