Is that not what this is intended to be?
I sent my reply because it looks like Roblox is already working towards the prerequesites necessary for this to be a thing, but didn’t actually mention anything concerning rebinding. Just want to make sure it’s not being forgotten.
I think it’s designed for the classical multi-script architecture, where you have independent scripts instead of a main script; in that way it’s good, and follows the principle of instances where they stop functioning once they get removed.
If this does happen, will we be able to rebind default roblox-set actions such as mouselock? Or only developer-created actions?
I think that means “it’s a possibility” without explicitly stating it.
My initial reaction is that this is…ok? Seems like User Input Service to me but in instance form. I will look further into this later but this was just my initial reaction.
I do like these Input bind icons though.
rebinding actions within the ESC menu is probably in my Top 5 wishlist for Roblox
This is definitely a cool built-in way of binding inputs across different devices. But I do believe the current implementation is a bit bloated. Having to create at least 20 instances for a simple walk direction input is not exactly convenient or efficient.
Also, writing your own cross-platform Luau inputs isn’t that hard. My entire module for the controls of custom characters is less than 100 lines long. So I don’t exactly understand the exact motivations behind this new system. Although it is still a neat feature.
Could we have an option to make it something like Action:CreateAction("Run")
and thenAction:BindFunction("Run", someFunction) this way the players can control multiple actions in one ActionInput, then when player press shift it will be this code Action:Fire("Run") and when he release it will be Action:Stop("Run")
Any support for multi-button action triggering?
Will LocalToolEquipped and LocalToolUnequipped still be supported? I use both events as a framework for gears and it helps a lot.
Thanks for the update, the system looks solid overall.
Just wanted to bring up a few cases that seem tricky to handle with the current setup:
When InputBinding.Type is set to Boolean, it seems like multi-key combinations aren’t supported.
It’d be helpful if bindings could trigger when multiple keys are pressed simultaneously.
If multi-key support is added, input order would matter in some cases — for example, Ctrl + C should trigger, but C + Ctrl shouldn’t.
So there should be a property like RequireKeyOrder: boolean.
Also, if there’s an action bound to Ctrl + Shift + C and another bound to Ctrl + C, and both exist in different contexts with the same priority,
then pressing Ctrl + Shift followed by C should only trigger the Ctrl + Shift + C action, Ctrl + C should not be triggered in that case.
Of course, if only Ctrl is held and then C is pressed, the Ctrl + C action should trigger as expected.
It doesn’t seem possible to scope input to specific UI elements (like with GuiBase2d.InputBegan)
This is especially important for plugin development to avoid input conflicts between widgets (or GuiBase2d elements)
Currently, detecting key input inside a specific plugin widget is quite difficult, and there doesn’t seem to be a standard way to handle it.
Mouse position input also feels limited.
In some cases, we need the mouse position relative to a specific UI element’s AbsolutePosition,
not just the global screen space (from the top-left corner under the TopBar).
A MouseBinding-like instance that supports relative UI-based detection would be helpful, especially for plugin tools or UI-scoped systems.
Maybe some of this is already in progress, but just wanted to share in case it’s useful.
This is so cool, however it is missing very crucial features such as Rebinding, individual actions sinking inputs, run-time editing and multi-key combinations. Also not a big fan of instance-oriented APIs
I think it would be cool to hear the whole proposal/roadmap for this feature since it is potentially foundational to input handling. Looking to hear if support is planned for:
Are these instances very light on memory just like user input service? If not, why should I switch?
cant you just… change the keycode / input property on input binding?
No wayyyy, I literally just finished a module for this because I wanted rebindable keys and a object-oriented input system where instead of binding everything to UserInputService, it would use BindableEvents instead.
This feature basically made my module almost obsolete. lol
I’m so glad it’s a built-in thing now.
OH questionnnn!
Can we get an input/action object for axis (WASD keys, Joysticks, mouse, etc acting as an object that returns a position/delta)?
Edit: Oops, very silly of me, I missed some while reading. There’s indeed joystick and WASD functionality.
Does that mean InputBegan is going to the gutter?
There is an action type, Direction2D that you can add thumbstick/WASD bindings for.
They might deprecate it maybe, but never removed. Which means if there is a glitch with User Input Service Input Began they may feel not to fix it.
I would consider it depreciated since Roblox wants you to use this “Better” and modern version. Who knows if it gets depreciated.
Oh my bad, I somehow skipped over that while reading.
Too excited for this new feature I guess. 
What about mouse movement? I assume this also works?
Woah, what are these methods of? Seems really useful.
