When UserInputService.InputBegan is connected, printing the result of the InputObject’s KeyCode returns Enum.KeyCode.Unknown even when the PreferredInput is KeyboardAndMouse.
According to the Roblox Documentation, MouseLeftButtonMouseRightButton and MouseMiddleButton are registered KeyCodes, but the InputBegan event does not return these.
The use case for this bug to be resolved is being able to use InputBegan to allow Players to rebind Input Action System keybinds according to the key they press on desktop.
I expect that InputBegan properly returns Mouse Buttons (MouseLeftButton, MouseRightButton, MouseMiddleButton) as KeyCodes on the InputObject, as every other KeyCode is properly returned.
This has happened to me, you have to do input.UserInputType, because.KeyCode is meant for keyboard input and some touchscreen, im not sure why mouse button is in the Enum though, i just heard that . KeyCode is for keyboard and UserInputType is like everything else.
I can’t use UserInputType because Input Action System requires the KeyCode version of the naming. UserInputType will return MouseButton1 which isn’t MouseLeftButton, the same name as one of the allowed KeyCodes for InputBindings.
Also, that would also mean I’d have to check by UserInputType for controls, which doesn’t work because that doesn’t contain all the other standard KeyCodes.
I get I could make a pointer to convert the UserInputType version of the Mouse Buttons to the KeyCode variants, however this isn’t intuitive. Since Roblox lists the Mouse Buttons as valid KeyCodes, it seems like unintended behavior for InputBegan to not return it.
Thanks for the report! This is legacy behavior of UserInputService and unfortunately we are not currently planning to change it.
For now, the mouse button keycodes are primarily meant to be used in the new Input Action System, we will get the docs updated soon. This means that for your use case, you should check for UserInputType on the InputObject to determine if an event corresponds to mouse buttons, and map to the keycodes for IAS.
This is honestly cumbersome default behavior and hopefully the team reconsiders the way this is structured in the future. Guess I’ll stick to hacky workarounds for now(?)
