Mouse Proc Updates in Bug Reports

ID:110298
 
Mar 2 2011, 5:29 pm
BYOND Version:480
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 3.6.14
Applies to:Dream Seeker
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
In regards to this fix:
- MouseEntered/Exited are no longer called when you Click an object. That can be somewhat easily worked around, but I was using the previous functionality.
- If you have MouseEntered() set for mapped objects, it will trigger as you move around the map (with your mouse cursor over the map control). This is only somewhat of an annoyance in my case, but I could see it being a game breaker in others. There is also no way to work around it, as far as I can think.
#1 Mar 2 2011, 8:02 pm
That first issue is more of a problem if you delete the object in its Click(), then MouseExited() will never get called.
#2 Mar 3 2011, 7:56 am
I'm not sure I follow the problem. Can you please provide more detail (filling out the template really does help us) and perhaps a demo project or code snippet, with clear indications of what the expected vs. actual behavior is?
#3 Mar 3 2011, 4:26 pm (Edited on Mar 3 2011, 4:39 pm)
You can try it in Guardians, unless you need access to code http://www.byond.com/games/Falacy/GGToaK

Place a troop on the map, then align the mouse cursor a tile or so above him, and walk down. This will cause his tool-tip to popup, which is in MouseEntered(). This didn't happen before the update. MouseExited() also triggers in a similar manner, but didn't before.

If you then use the Sell Mode button, near the bottom right of the map, and click on him, this will leave his tool-tip open (because he gets deleted), though it used to close itself. This used to happen automatically before the update, the click would trigger Exited and/or Entered.

Also, if you buy an upgrade for any of the classes, the tool-tip for it used to automatically update, and cause it to properly say [Acquired]. This no longer happens, and you have to move your mouse entirely off, and back onto the upgrade icon. Probably because of the same issue as above.
#4 Mar 3 2011, 4:30 pm
I'm still not following what you mean. A simpler example would be best with some kind of demo (there's really nothing worse than having to learn how to get into a specific game to figure a bug out) and a detailed set of steps would be helpful, with the differences between the expected and actual behaviors spelled out at each step.
#5 Mar 3 2011, 4:32 pm (Edited on Mar 3 2011, 4:38 pm)
A demo would be nearly identical to Guardians... and I'm not really sure how I can explain the current vs previous functionality any better than I did below.
#6 Mar 3 2011, 4:44 pm
Your descriptions are still too vague and seem to be inconsistent. I really need more to go on than you've given me so far.

Falacy wrote:
Place a troop on the map, then align the mouse cursor a tile or so above him, and walk down. This will cause his tool-tip to popup, which is from MouseEntered(). This didn't happen before the update. MouseExited() also triggers in a similar manner.

If the mouse is several tiles north and the unit goes south, won't this move it further away from the mouse? Or are you referring to using the arrow key to scroll the map south which would move the unit northward on the visible screen? If the latter, then none of this part is actually a bug; this is really the way it should have functioned all along. I do see some value in telling the player whether the event was triggered actively or passively though.

If you then use the Sell Mode button, near the bottom right of the map, and click on him, this will leave his tool-tip open (because he gets deleted), though its supposed to close itself in MouseExited(). This used to happen automatically before the update, the click would trigger Exited and/or Entered.

I don't follow that. Are you saying MouseExited() used to be called due to a click, even when you weren't exiting the object? That seems like a bug.

Also, if you buy an upgrade for any of the troops, the tool-tip for it used to automatically update from the Click(), and cause it to properly say [Acquired]. This no longer happens, and you have to move your mouse off and back onto the upgrade icon.

I have no context to understand any of that, so a demo is critical. (Short of a demo you could give me a full, highly detailed set of steps to follow in the game that start with the login.) The click proc hasn't really undergone any change here so it doesn't make sense that its behavior would be altered. And I think that regardless, I'd have to see the relevant code sections to understand what the proper procedure is.

If I'm reading this right though it sounds like there was some buggy behavior for MouseEntered() and MouseExited() in the past which has now been resolved, but that your game relied on. I don't necessarily see the harm in generating extra exited/entered calls on a click, although I have no idea how it could have happened in the past.
#7 Mar 3 2011, 5:04 pm
http://www.angelfire.com/hero/straygames/ByondBugs/ NewMouseFails_src.zip
You are the yellow dot, place the mouse on yourself, then step north, south, east, or west. This will trigger the MouseEntered() for the red dots, which opens a small window in the top left. These did NOT used to trigger due to movement.
If you click on one of the red dots, it will delete the red dot. This will leave the small window open, and make it so MouseExited() is NEVER called for that object. MouseExited() (and MouseEntered()) used to be called automatically, through the clicking process, though not necessarily related to Click().

Lummox JR wrote:
I have no context to understand any of that, so a demo is critical.

You have no context because you won't take 30 seconds to test the game. The same could be said about the demo, if you were unwilling to download it.
#8 Mar 3 2011, 5:13 pm
Actually, I seem to have been mistaken about the deletion part. If you delete the source object, MouseEntered/Exited don't get called, even in the old version.
However, if the object isn't deleted in the process, then MouseEntered (probably MouseExited too, but I didn't directly test that) is automatically called when you click on it, in 479, but not 480.
#9 Mar 4 2011, 10:43 am
Oh wow, you mean MouseEntered()/MouseExited() is now called while you move around the map? I was actually thinking of asking for this feature awhile back but it looks like it's in already.

Awesome!
#10 Mar 4 2011, 11:30 am
Falacy wrote:
Actually, I seem to have been mistaken about the deletion part. If you delete the source object, MouseEntered/Exited don't get called, even in the old version.

Yeah, it wouldn't be. There's really no way to call MouseExited() after the object has already been deleted. And doing it on a just-before basis would be pretty hacky.

SuperAntx wrote:
Oh wow, you mean MouseEntered()/MouseExited() is now called while you move around the map? I was actually thinking of asking for this feature awhile back but it looks like it's in already.

Yeah, this fell out of your bug fix. Basically to cover the case of objects moving around on their own also meant that the map scrolling would impact this as well.
#11 Mar 5 2011, 1:15 pm
Any chance this new behavior could be applied to MouseDrag() as well?

ie: If you walk north while already dragging but didn't move your mouse, it acts as if you just drug your mouse up a tile.
#12 Mar 7 2011, 8:10 am
It's potentially possible to apply this to MouseDrag(), but it's a little bit more difficult because during a drag the application has capture, instead of letting the individual control handle it.
#13 Mar 10 2011, 5:49 am
lol This was a bug report about the new functionality breaking things, not a feature request for it to be extended further.
#14 Mar 14 2011, 2:19 pm
I confirmed that MouseEntered() (but not MouseExited()) is being called in 479 after you click on an object, but that is definitely incorrect behavior. I could see adding in the spurious call if it was also calling MouseExited() before, but my tests say it was not. So as far as I can see this isn't a new bug; it's an old bug that got fixed, and putting in extra entered/exited calls would be a mistake.
#15 Mar 14 2011, 4:45 pm
While I can see how this could be considered a bug since it is a backwards-incompatible change to the behavior, we're not going to "fix" it unless there is a really compelling reason. I'm sure very few games rely on either old behavior, and those that do can be adjusted.

The old behavior for issue #1 seems silly; there's no reason to assume that an Enter would occur with a Click, especially without a corresponding Exit. The new behavior is better and I hope you can just adapt your game(s) accordingly.

Issue #2 is a little trickier, and you are correct that it doesn't have a satisfactory workaround (namely determining if an enter/exit occur as a result of map changes or mouse motion). However, unless we are given a good example of where this would be necessary, there's no reason to muck up the language further (even with a simple flag parameter) to support it.