ID:101925
 
Resolved
Mouse activity could take a backseat to other verbs, so a repeating key could cause a delay. Now mouse actions are always handled before other verbs.
BYOND Version:475
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Firefox 3.6.9
Applies to:Dream Seeker
Status: Resolved (476)

This issue has been resolved.
Descriptive Problem Summary:
In my specific project, holding a directional key causes MouseEntered() to not trigger when one would expect it to. I assume this is because the directional keys que up, and then MouseEntered() starts queing up as well, which ultimately results in what looks like lag.

Numbered Steps to Reproduce Problem:
Create a MouseEntered proc that does something, in my project I have it always make the player face the mouse.

Hold a directional key down and wiggle the mouse around in different places.

Watch.

Code Snippet (if applicable) to Reproduce Problem:
atom/MouseEntered(object, location, control, params)
if(object && location=="mapwindow.map")
//if(object!="Inventory")
usr.FacePlace(object)
else if(location && location=="mapwindow.map")
usr.FacePlace(location)
else
..()

mob
proc
FacePlace(target)
src.dir=get_dir(src,target)


Expected Results:
Normal movement, with MouseEntered working normally as well.

Actual Results:
Movement works normally until you start calling MouseEntered rapidly, then both bog up, lag, and cause all sorts of problems.

Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur? If you're not moving, all works properly. If you tap the movement key, all works properly.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? This issue occurs in previous versions.

Workarounds:
Working on it.
I have a potential behavior change in mind for this, but I'm convinced your assertion that this did not happen before 475 is incorrect, since command queuing behavior didn't change in that version. Please retest in 474 if not earlier versions. I suspect you'll find that this has always been the case for mouse movement, but I agree it is not ideal.
"was not found not occuring in earlier versions."

I used a double negative here, my fault, I ment I didn't notice this working the way I wanted it to in earlier versions either. I was told the potential of client-side processing (future version?) might help, but rather than wait, I have been trying to find another method of doing this to get around the problem, which I haven't found yet.
Ah, that makes sense then. I have a plan in mind for this.
While the fix technically did fix my problem, it's now having the reverse problem. lol. It seems to be MouseEntered() that's just producing the 'lag'. Still trying to find an alternate method. @.@