Enum.KeyCode.MouseButton / Programmable buttons



As a roblox developer, it is currently impossible to detect Enum.KeyCode.ButtonR2 without detecting MouseButton1Down(). This is a problem because for my gun script, and for many other scripts, it is necessary to detect only one of these because otherwise the gun will fire twice. I think it’s a little old to be using mouse.Button1Down() when the UserInputService would offer a nice place to put all of our input objects at once. It would help people stay organized, and let devs have things work the way they want.

That is why I propose that ROBLOX adds a new input keycode object for each of the mouse buttons, as well as any programmable buttons. It would be nice to have a keycode that matches up to mouseButton1 because that way, when ButtonR2 is fired, the dev gets to decide whether or not the function attached to MouseButton1 is fired. As for programmable buttons, it would be nice to add support for these because that opens up the door to adding custom keybinds in games that may require them. Personally, I planned to add support for every platform out there, including different kinds of gamepads such as Wii remotes and PS4 controllers. This would require for scripts to create new input keycodes as the user inputs them. My approach would be to use an object value and store whatever input object the player has put in, but it could be done many ways. At the moment, however, I don’t think it’s possible to use programmable buttons at all. Thanks!


This is what ContextActionService is for. You can bind the same function to multiple inputs. For instance:

function fire(_, _, input)
   if input.UserInputState == Enum.UserInputState.Begin then
       -- button down
   elseif input.UserInputState == Enum.UserInputState.End then
       -- button up
      --probably UserInputState.Cancel because something else bound to this key. May need to use BindActionAtPriority to resolve potential conflicts

contextActionService:BindAction("MouseFire", fire, false, Enum.UserInputType.MouseButton1)
contextActionService:BindAction("ControllerFire", fire, false, Enum.KeyCode.ButtonR2)


You could also use UserInputService, which is a bit more customizable.

For example:

    if Input.UserInputType == Enum.UserInputType.MouseButton1 then
        -- mouse
    elseif Input.UserInputType == Enum.KeyCode.ButtonR2 then
        -- R2


If you are still using the mouse instance for button clicks etc then you most definitely need to make the change over to user input service. The mouse has become sort of irrelevant and outdated now outside of its Hit value since TargetFilter can’t be a table and the events are better used with user input service.


I honestly had no idea this existed - I was expecting it to be a keycode. That answers half of my problem, and I’ll be sure to use UIS.MouseButton1 but programmable buttons are still not supported, so that would be the second half of my thread :slight_smile:


Programmable buttons? What do you mean exactly?

There are World0 - 95 KeyCodes which I think represent extra buttons. But I don’t think using them is very practical, either, unless you arguably waste your time making a custom keybind system.


I’ve never heard of World0 - 95 keycodes, but when I said programmable buttons I was referring to the ones found on the side of some mice and some keyboards. It would help speed up gameplay for some people if they had their own custom keybinds set up.

From what I can tell, roblox didn’t even notice I had been inputting anything from my mouse. I pressed the buttons on the side with a script that printed the KeyCode of my input, but nothing happened. Same deal with the wii remote (though that was much more expected.)


The World KeyCodes would only work with extra keyboard buttons probably (hence being KeyCodes).

Try printing all of the other properties of the InputObject to see if there is something that distinguishes a special mouse button from a normal one. UserInputType only supports the three normal mouse buttons AFAIK, but there might be something else.


Don’t forget about GuiService.SelectedObject