MouseDown Failing in Bug Reports

Page: 1 2
ID:461994
 
Mar 7 2012, 1:59 pm
Resolved
MouseDown events were not generated in the case of a double-click. Now MouseDown() will always precede DblClick().
BYOND Version:493
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 10.0.2
Applies to:Dream Seeker
Status: Resolved (494)
This issue has been resolved.
client/MouseDown() and atom/MouseDown() fail to trigger every time the mouse is pressed. They only seems to trigger every other click, possibly due to some sort of internal double click interference? Using Click() will trigger every time (even during a DblClick). This MouseDown issue seems to extend to DS in general, and will not trigger if you spam click a verb in a stat panel. However, if you set an interface macro for that verb, the key will properly trigger it every time.

Demo: http://www.angelfire.com/hero/straygames/ByondBugs/ MouseFails_src.zip
#1 Mar 7 2012, 2:21 pm
I would imagine this was considered to be intended before. Personally, I don't like it, and I think it would be better off as a feature request: MouseDown() is called for both mouse-downs in a double-click.
#2 Mar 7 2012, 2:23 pm
Also, Click() doesn't trigger at all in situations where both the player and/or the mouse are moving, as is often the case in action shooters.
#3 Mar 7 2012, 2:29 pm
In response to Falacy (#2)
I'm not completely sure if there isn't a bug associated with that issue, but as far as I know, Click() only occurs:
- After MouseDown() and MouseUp() are called one after the other on the same atom.
- Between MouseDown() and MouseUp(), the mouse can't ever leave the atom. (it can move around within the atom, just not ever "exit" the atom)
- If the mouse leaves the first atom between Down and Up, MouseDrag() is called instead of MouseExited(), and (I think) MouseEntered() just doesn't happen. MouseDrop() is called on whatever atom the mouse is over when it MouseUp()s (of course, you can drop an atom onto itself).
#4 Mar 7 2012, 2:36 pm
MouseUp properly triggers every time the mouse is released.
#5 Mar 9 2012, 10:54 pm
In response to Falacy (#2)
Falacy wrote:
Also, Click() doesn't trigger at all in situations where both the player and/or the mouse are moving, as is often the case in action shooters.

I'm working on some click movement stuff and I've had quite a few issues with clicks also. It's hard to explain the exact details, but something is wrong with clicking for sure.
#6 Mar 12 2012, 2:29 am
Yeah... Clicks are for sure wonky. In two separate projects I've found that clicks and mouse movement are either delayed or just not registering.
#7 Mar 12 2012, 1:09 pm
DblClick has priority over MouseDown.

Here is what happens when you double-click:
MouseDown, MouseUp, Click, DblClick, MouseUp, Click.

What should happen is this:
MouseDown, MouseUp, Click, MouseDown, MouseUp, DblClick.

A temporary (and sloppy) way to fix this would be to call MouseDown() from DblClick().
#8 Mar 12 2012, 1:12 pm
In response to SuperAntx (#7)
SuperAntx wrote:
A temporary (and sloppy) way to fix this would be to call MouseDown() from DblClick().

I would assume it suffers from the same issue as Click()? Where it just doesn't trigger at all when in motion?
#9 Mar 12 2012, 1:20 pm
In response to Falacy (#8)
Falacy wrote:
I would assume it suffers from the same issue as Click()? Where it just doesn't trigger at all when in motion.

Click() requires a press and release in order to trigger, it is not designed to work while the mouse is moving around. What is happening is the user ends up dragging things before releasing their click.

Here is what I did for Decadence:
client
    MouseDown()
        //Point player at cursor.
        //Begin shooting.
        
    MouseUp()
        //Stop shooting.
        
    MouseDrag()
        //Point player at cursor.

    DblClick()
        MouseDown()
#10 Mar 12 2012, 1:25 pm
In response to SuperAntx (#9)
SuperAntx wrote:
What is happening is the user ends up dragging things before releasing their click.

You should put the MouseDown() call into MouseDrag() as well then =P
I am just using MouseUp for now, since it seems to be the only reliable option. Though, when I make automatic weapons, I will have to go with a design closer to yours.
#11 Mar 12 2012, 1:30 pm
In response to Falacy (#10)
Falacy wrote:
You should put the MouseDown() call into MouseDrag() as well then =P

MouseDrag() is called after MouseDown(), it assumes the player is already holding down their mouse button. It is not the same as another click because that would require MouseUp() to be called first.

MouseDown() -> MouseDrag() -> MouseUp()
#12 Mar 12 2012, 1:32 pm
Except, MouseDown often fails, while MouseDrag(?) and MouseUp always work. This means you could have something like:
Down -> Drag -> Up -> (missing down) -> Drag -> Up
#13 Mar 12 2012, 2:57 pm
If you use the workaround I suggested you will not have problems with MouseDown().
#14 Mar 12 2012, 9:33 pm
Your workaround isn't any more reliable. Click() and DblClick() don't trigger when the mouse is in motion.
#15 Mar 12 2012, 10:09 pm
In response to Falacy (#14)
Click() can be broken down into MouseDown() then MouseUp(). What I'm suggesting is ignoring Click() entirely and handling its functions yourself by using MouseDown() and MouseUp().

It may be more complicated than just using Click() but it will give you greater control over what you want your game to do.
#16 Mar 12 2012, 10:11 pm
I was using MouseDown to begin with, hence this bug report about it being broken. You were suggesting that I use DblClick to catch the missing MouseDowns during double clicks, but DblClick is hardly more reliable than MouseDown, due to it not triggering when in motion.
#17 Mar 13 2012, 2:20 pm
In response to Falacy (#16)
Falacy wrote:
You were suggesting that I use DblClick to catch the missing MouseDowns during double clicks, but DblClick is hardly more reliable than MouseDown, due to it not triggering when in motion.

If you check the sequence of events you'll notice DblClick() doesn't quite behave the same way as Click(). It's triggered on the second MouseDown() rather than the second MouseUp(). That makes it impossible to mess it up with a MouseDrag() event since MouseDrag() would only be triggered between MouseDown() and MouseUp().
#18 Mar 13 2012, 5:57 pm
In response to SuperAntx (#17)
SuperAntx wrote:
If you check the sequence of events you'll notice DblClick() doesn't quite behave the same way as Click(). It's triggered on the second MouseDown() rather than the second MouseUp(). That makes it impossible to mess it up with a MouseDrag() event since MouseDrag() would only be triggered between MouseDown() and MouseUp().

Regardless of your proposed sequence of mouse events, DblClick() does not trigger when the mouse is in motion, same as Click(). Make a simple test if you don't believe me?
#19 Mar 14 2012, 3:03 am
I'm not following the point you're trying to make. MouseDown() and MouseUp() will avoid the problem Click() has with dragging. DblClick() allows you to avoid the problem with MouseDown() not triggering.

You have countermeasures for both problems, what is the issue?
Page: 1 2