Beta8397/virtual_robot

Virtual gamepad - snap back issue

Opened this issue · 4 comments

alan412 commented

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 commented

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 commented

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 commented

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 commented