Gamepad RStick press-down triggers `UserInputService.LastInputTypeChanged` firing with the input type `MouseMovement`

Bug Reports Engine Bugs
#1

When connecting something to the UserInputService.LastInputTypeChanged event (and probably GetLastInputType too, did not test that) and using a gamepad (so currently, the input type is a gamepad, as expected), then pressing down the RStick (Thumbstick2) on the gamepad, will make the previously stated event trigger with MouseMovement. This is unexpected, as the mouse is obviously not moved at all.

This is an annoying issue as I use this to determine if the UI should show gamepad controls or keyboard/mouse controls. By simply pressing a key, moving the mouse etc, all UI will change to keyboard/mouse UI and triggering any gamepad input will switch the UI to gamepad UIs. Currently, when pressing RStick, the entire UI will shortly jump to the keyboard/mouse UI thanks to this bug.

OS: Windows 7
Gamepad: XBox 360 USB

edit: PlayerMouse.Move apparently also triggers when pressing RStick.

2 Likes
#2

Does it also influence (Player)Mouse.Move? (if not, you could use that for now, although that doesn’t mean this bug is “solved” then)

#3

PlayerMouse.Move apparently also triggers when pressing RStick.

I guess I can also simply ignore MouseMovement if the previous input was from a Gamepad, but pretty much every non-Roblox game switches UI with any keyboard/mouse input, so for a consistent UX I regard it essential for this to work properly.

#4

It’s probably being triggered because pressing stuff on gamepads moves the mouse to above center on the screen.

#5

This is kinda weird and it is hard to tell should the mouse move events fire in this case. This happens when the UserInputService.MouseBehaviour is changed to Enum.MouseBehaviour.LockCenter in the player scripts. The position of the virtual mouse used by Xbox does change from slightly above the center to the center. It seems like the PlayerMouse.Move event should fire, because developers may be using this. I don’t think LastInputTypeChanged should fire, and it’s unlikely that anyone is relying on it so it so I can probably make it not fire in this case.

#6

So the best would be detecting whether there’s a keyboard/controller/… and just display a menu where the user can choose the (main) input type? (and automatically pick keyboard if there’s no controller or touchscreen)

#7

That’s a worse UX, detecting the desired input based on the last input type is the most flexible and transparent way to handle this in my opinion (and the most common method used to my knowledge?). I’d absolutely avoid showing a dialog requiring interaction for something like this.

Would love to see the change @TheGamer101 proposed, I agree it makes sense to fire PlayerMouse.Move.

#8

I submitted a fix for this today. It should be out in around 2.5 weeks.

1 Like
#9

A fix for this has been shipped.

2 Likes
#11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.