This is a pesky bug that I've been struggling with for quite some time; And I have only today found the supposed cause

 

Sometimes (A somewhat rare occurence), the script will just stop alltogether, (Loop would stop getting called)

And after much debugging, I've concluded that the script sometimes never pass a call to client.moveMouse(MouseDestination, boolean). I am absolutely certain that this is the cause, since it has stopped at the very same line (It's the only place I use the moveMouse method). It is as if though the call to moveMouse never returns.

 

this is my setup:

if(dest != null) {
    debug = "FastInteract pre-mouseMove";
    this.client.moveMouse(dest, false);
    debug = "FastInteract post-mouseMove";
}

When the bug occurs, my debug message displays "FastInteract pre-mouseMove", and onLoop stops getting called.

the dest param is a valid MainScreenTileDestination, constructed from a tile that has also been through a null-check

 

The issue cannot be solved by interrupting the execting thread; As neither pausing the script, nor manually interrupting the thread through the code will get it 'unstuck'

 

Any ideas? This is a fatal bug, And Its not at all unlikely that others are struggling with it

 

Client version: .81; has been an issue in many earlier versions.

Edited February 15, 201412 yr by FrostBug

So, let me get this straight, if I just sit there and spam that method, would it eventually occur or do I need to do something else to replicate it?

Ive just succeeded in debugging it, and it would seem that the issue lies elsewhere

 

The input mouseDestination had negative X and Y coords, and insanely large width and height values (4000+).

The issue may lie in the constructor of MainScreenTileDestination, or simply be caused by some unexpected behaviour in the Position of the npc that I had constructed it from. The Position was however, not null, and the NPC entity had been gotten from an Area close the player (That the player was in).

 

I've added a validation of the MouseDestination before calling moveMouse now, So I don't expect to see the error again. This time it took 7 hours for the bug to occur, while last time it occured twice in ~40 minutes.. Truly a difficult issue to debug :E

 

My recommended official fix for this would be to add some checks to the MouseDestination, within moveMouse method, or within the constructor of MainScreenTileDestination (and possibly others). And for the love of god, be sure that the method can be interrupted properly. I have to shut down the client process every time this happens :E

Edited February 15, 201412 yr by FrostBug

Ah.. Wrong again

 

it just happened once more, but this time with a perfectly valid MouseDestination

Nothing conclusive yet , this bug is preventing me from releasing my script

 

Further testing & Debugging has shown me that moveMouse has some strange behaviour, and will occasionally hang or even crash the entire client, if the destination is outside of the screen at low camera pitch angles. The state of the executing thread, when stuck, is RUNNABLE

Edited February 16, 201412 yr by FrostBug

Update:

 

Ive tracked the issue to the MouseDestination#getPointDestination method invoked from within Client#moveMouse; Calls to getPointDestination will not return if the given mouseDestination is offscreen & camera pitch is at its lowest (no idea why)

 

Ive bypassed the problem now by using a random point from Position#getVertices in place of a point from getPointDestination; And call MouseController#moveMouse(int, int, MouseDestination, boolean, double) instead, passing the x and y coords of the point

 

I can't conclude that this workaround works for all cases, but I haven't had the error again since.

Bleh, it still occurs for some reason.. This issue is giving me cancer..

 

Are there any out-of-the-ordinary checks within selectOption/Interact methods that I'm missing, which prevent this error?

The only reason I need to re-implement interactions in the first place though, is because I need something without the massive sleep between right click & menu selection.

 

My only alternatives at this point is to just deal with the inefficiency of the long sleep in predefined interact methods, or send a new thread into the moveMouse methods every time, and abandon it if it doesn't return within a small timeout by callback :|

Any help or advice would be greatly appreciated.. Can't release my script before this last bug is quashed

It must be nice to feel like talking to wall ;/

It must be nice to feel like talking to wall ;/

 

I am paying attention still. I just don't post if I don't have anything to add. I've been busy enough so I haven't been able to devote the type of time necessary to locate the problem.

 

@FrostBug

I appreciate the work that you're putting in, and know that I am still reading and it's still on my list.

 

 

Edit:

An update. I may have identified another issue, but it doesn't have to do with the mouse. From what I've seen, it isn't the mouse causing problems, but rather, some other interactions between threads. But that remains to be seen.

Edit 2:

We're testing out the fix.