Hi, please follow these instructions here to make your place as simple as possible to demonstrate the issue and download / send it to us as an .rbxl file. I’ll start a private message with you in case you’d like to share it privately.
For an InputBinding that has the UIButton property set to a button, it would be ideal if the Released event for the InputAction also fires when the player’s mouse/finger leaves the button.
Currently, you have to ensure your mouse/finger is released from within the bounds of the UI button for Released to fire. If you press the UI button and move your mouse/finger out of its bounds, the InputBinding will stay in the Pressed state after you release your mouse/finger.
Does this account for mac users? For example a Ctrl + Z binding becomes Cmd + Z on mac.
Hi, I believe on Mac clients pressing Ctrl will report Ctrl and pressing Cmd will report Meta, so if you want to create modifier keys using these two keys you may have to use two InputBinding instances. The behavior in IAS should be similar to what InputObjects and keycodes are created when using UIS.
1 Like
I suppose if there are 2 InputBindings then both will work, right? Cmd + Z will work on Mac but Ctrl + Z will also work, some combinations may differ a lot in mac too.
There’s also the problem that the keybinds have to be displayed in UI. For Mac users, an undo button should display Cmd + Z instead of Ctrl + Z since that’s what they’re expected to press. It’s very annoying that there’s no way to do this without using unreliable, unsupported and deprecated operating system detecting methods that may stop working at any time despite the common use case. Maybe an addition to UserInputService:GetStringForKeyCode can fix this problem? Or a feature in the Input Action System to use a special modifier key that acts as Ctrl on Windows and Cmd on Mac, and allow scripts to read from that so the right keybind can be displayed.
1 Like
Hi Creators,
We’ve just released a behavior change when a player’s mouse or touch input leaves the bounds of a UIButton associated with an InputAction.
If the InputAction was previously in the Pressed state, when the player’s mouse/touch input leaves the UIButton bounds the Released event will now fire.
3 Likes
Thank you for acting so quickly on my feedback. Much appreciated!
Hellooo!
May my experience be opted out of the sinking changes? Thank youu!
PlaceId: 80299426886587
Hellooo! I’ve opted your place ID out of the sinking change. Please let me know if you observe any additional issues!
Hello! Just tested it and everything seems to be functioning as intended again. Thanks a ton! 
1 Like
Are there any plans for an InputBinding to accept touch inputs that don’t use a UI Button?
This is an absolutely miserable feature and among the worst I’ve seen. There is no benefit to this system besides modifier keys, which we can already implement with IsModifierKeyDown plus pass/sink. CAS does literally everything better out of the box. In no world is there an excuse to make something that is ONLY used in code into instances.
This is unbelievably inflexible. There is no way to programmatically pass/sink based on real-world conditions. Everything has to be literally perfect for this to not F everything up. Instead of a nice line of code to bind something to a shared callback, I now have to write Instance.new and call Destroy repeatedly. God forbid I need to disable the input based on some arbitrary state. Now I have to be constantly monitoring that state with additional events and hellish nested logic to do what CAS can do with a single-line if statement. Not only do I have to spend all this time with useless logic, I still have to check this logic when the input is activated in case it’s still enabled. This is an absolutely miserable developer experience.
Lets say all these conditions must be met for the input to be acceptable:
- Must be on Red team
- Must have Bat equipped
- Must not be sitting
- TimeOfDay must be between 11 and 12
To do this logic in CAS, I just do if not (A and B and C and D) then return Pass end
Now I have to do the following:
- Create updateEnabled to run all these if statements and set the Enabled on InputAction
- LocalPlayer.Changed:Connect(updateEnabled) or PropertyChangedSignal for the team
- LocalPlayer.Character.CharacterAdded(… character = LocalPlayer.Character …) AND character.DescendantAdded/Removing:Connect(updateEnabled)
- Same character event above plus character.Humanoid:GetPropertyChangedSignal(“Seat”):Connect(updateEnabled)
- Lighting:GetPropertyChangedSignal… you get the rest
This is an additional 6 unique event connections that I have to create for what used to be a single if statement. Not to mention the rate this would update if the Lighting.TimeOfDay were to change smoothly. Add the risk for memory leaks on top of that if you have poor event cleanup in play. All of these events constantly running an update function for an input that we might use once an hour.
This is NOT a simplification whatsoever. This adds unnecessary complexity and makes it harder for developers to configure input. Sunsetting CAS in favor of this garbage is a huge mistake.
All of my game input is configured through a wrapper that handles keybinds and keybind updates. As long as CAS works and this new input system is in this unusable of a state, I will not be making any changes. This is worlds harder.
I was sceptical at first, but once you get used to it, it’s surprisingly easy to use. For me, it massively reduces the amount of logic I need to write to support cross platform users. Also, it’s pretty neat that all inputs across all platforms (including button UIs) such as triggers can be detected by simply listening for the Pressed event on an InputAction. That’s a massive win.
I also don’t mind that it’s instance based. Sometimes it’s not ideal, but for me, there are a lot more positives than negatives when using Input Action System compared to ContextActionService.
The more time you spend using it, the more you will see the benefits and flexibility of the system.
IAS works with server authority out of the box, which is one major reason for using instances.
But there are many other benefits outlines by others and the announcements. I think the challenge is keeping IAS, UIS and CAS all available with no strong preference for new Devs is confusing, but I doubt CAS will ever be fully disabled.
We might eventually “deprecate” CAS for new experiences.
But you are correct that it won’t stop working.
hello again!
here’s my place id: 133701727273517
Hey! I’ve placefiltered you out of the sinking change which should be applied on restart, please let me know if you observe any issues!
ok, it seems like only some of the keycodes are working correctly. all of the keycodes for thumbstick2 ,dpad and also ButtonB worked
Does anyone know how to get which Gamepad(1-8) pressed/used the InputAction?
Similar to the UIS inputBegan method of funtion(input,...)
This is the best I got.
Current Script
local UIS = game:GetService("UserInputService")
local action = script.Parent.InputContext.InputAction
action.Pressed:Connect(function()
local last_input = UIS:GetLastInputType()
local player_Vehicle = workspace.Vehicles[last_input.Name]
if not player_Vehicle then return end
-- different gamepads control their own vehicle
end)
Hi! Any update on a keycode to register touch taps to the screen (like MouseLeftButton but for touch devices)? Thanks
(Apologies Trainmaster2341, no intention to reply to you there 
)