Virtual gamepad - snap back issue

[alan412]

If you have "HOLD_CONTROLS_BY_DEFAULT" = False and you are on right joystick and move to the left and keep going and get mouse on left joystick and move it then when you let go, it lets go of the left joystick (snapping it back) but doesn't snap back the right joystick.

Please let me know if this doesn't make sense.

[jkenney2]

I wasn't able to reproduce. Here's what I'm seeing when I try it (with HOLD_CONTROLS_BY_DEFAULT = false):

Click on right joystick and drag to left with left mouse button down (so far so good);

While continuing to hold left mouse button down, keep dragging over left joystick (left joystick doesn't engage, but right joystick continues to track vertical mouse position-constrained horizontally by its square area);

Release the left mouse button (right joystick snaps back to center);

Press left mouse button again while over left joystick (left joystick now engages)

Is that the sequence of actions where you are seeing the issue?

[alan412]

It isn't very easy to reproduce when I tried to do it for a recording. Here is a 30 second clip. The problem shows up around 16 seconds, but I included the whole thing in case it gives a hint. My personal guess is there is a race condition. Perhaps the easiest way to fix it is when one of them snaps back, snap both of them back.

Screen Recording 2020-10-29 at 2.53.32 PM.mov.zip

[jkenney2]

I see it, as you said starting at around 16 seconds. Unless Alt or Shift is pressed, it shouldn't be possible to have both the left and right sticks away from their origins. I've tried a bunch of times to reproduce, both with USB mouse on my Win10 desktop, and mousepad on Win10 laptop and haven't been able to get it to happen. Gamepad state (i.e. the values of a, b, x, etc) is shared between two threads (written by one and read by the other, but that doesn't affect the UI of the virtual gamepad, or the mouse handling--that's all done on the application thread. Somehow it seems that a Mouse.RELEASED event is being missed. I hate to force both sticks back to the origin, as some users (e.g., with tank drive), might want to keep one stick at a fixed location (by using Alt or Shift) and move the other around. I'll try to look for anything I might be missing in the mouse handling. I notice you're using a Mac; I wonder if there could be some subtle difference in mouse behavior there that could expose this issue.

[alan412]

I'll take a look through it this weekend too, but it should be pretty low priority.

--Alan

On Thu, Oct 29, 2020 at 5:16 PM jkenney2 notifications@github.com wrote:

I see it, as you said starting at around 16 seconds. Unless Alt or Shift is pressed, it shouldn't be possible to have both the left and right sticks away from their origins. I've tried a bunch of times to reproduce, both with USB mouse on my Win10 desktop, and mousepad on Win10 laptop and haven't been able to get it to happen. Gamepad state (i.e. the values of a, b, x, etc) is shared between two threads (written by one and read by the other, but that doesn't affect the UI of the virtual gamepad, or the mouse handling--that's all done on the application thread. Somehow it seems that a Mouse.RELEASED event is being missed. I hate to force both sticks back to the origin, as some users (e.g., with tank drive), might want to keep one stick at a fixed location (by using Alt or Shift) and move the other around. I'll try to look for anything I might be missing in the mouse handling. I notice you're using a Mac; I wonder if there could be some subtle difference in mouse behavior there that could expose this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Beta8397/virtual_robot/issues/66#issuecomment-719027295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF3Y73QA3LY73WV5OADPRLSNHLT3ANCNFSM4TD45L4Q .