InputAction.Pressed() should pass InputBinding as a parameter

InputActions work wonderfully as is, however I encountered something when trying to make a custom backpack system.

Let’s say I wanted to create a numbered key backpack system for PC players. I would create an InputAction with 5 InputBindings underneath, all of which share the name of their respective keycode.

Now in my script, what I want to do is equip/unequip the Weapon that is associated with that numbered key by using the name of the InputBinding as a way to reference an index that points toward specific Weapon code:

Number_Keys.Pressed:Connect(function() -- No parameter provided
		
	Weapons.Cycle_Weapon_To_Number( ? ) -- I have no InputBinding to pass to this function here to strip the Name from!
		
end)

I cannot possibly achieve what I want, because InputAction.Pressed() does not provide any parameter that points to the InputBinding that triggered the core action. There is no way to index a table and therefore trigger Weapon equips registered by numbered slots. In order to do this, I’d have to create an InputAction for each slot in the game that I intend on using, and place a single InputBinding underneath. That feels unintuitive considering the point of the InputAction being every binding underneath is to fulfill a sole action (which in this case is, switch to a weapon that is bound to that particular numbered key).

This is already something present within my current experience. It would make more sense to have the below:

Look like this so that I can use the name of the InputBinding as a method of shifting the Current Weapon up or down a slot (Left or Right D-Pad, for example).

image

Even if I used something like UserInputService:GetKeysPressed(), this will return a list of ALL keys being pressed at the time of calling the method. If I wanted to check for any particular number, I can’t easily do so because they could be pressing directional keys or other numbers, forcing me to write extra code to scrub regular keybinds from the table given, as well as assuming the first/last number found within that table, leaving the most recent number being pressed, ignored.


The only realistic scenario where you’d want this functionality is for something like a backpack where various input methods just cannot work the same in all ways, on all platforms. For example, Console players don’t have numbered keys, they only have bumpers or a D-Pad. Whereas PC does have numbered keys. You could say “just make one button cycle between them all” but in a fast-paced game, this is cumbersome at best.


If Roblox were to implement this into the InputActionSystem it would allow developers to achieve systems such as Backpack support for PC without additional overhead (as well as improving existing functionality for Controllers).

2 Likes

Hi, thanks for the feature request! We designed IAS so that each action has a distinct purpose, and all bindings connected to an action should result in the same output regardless of platform / input.

In your use case for a backpack system (connecting different bindings to one action that requires each binding to do a different thing), we suggest using distinct actions with one binding each, then reusing the same abstracted callback function with a different parameter per action.

1 Like

I believe you may be misunderstanding. I want all the InputBindings to achieve the same result, switching a weapon. My weapon system slots by number, so it’d actually be easier and more intuitive to be able to have both my Keyboard & Touch code share the same space by indexing a table with the name of the InputBinding that was pressed (Going to use Enum.KeyCode.Two as an example here).

This would imply that if the user taps on slot two, or presses 2 on their keyboard, it’d route the same way because the InputBinding shares the same name as the position in my table that points to the logic used for that kind of weapon (Equip or Unequip in this instance). Without this implementation, I actually had to manually listen for ImageButton.MouseButton1Click and had to manually scrub actively pressed keys to achieve this result.

I still personally believe creating 5 different input actions for each individual key or slot is ridiculous, especially considering these InputActions / InputBindings consume client memory.

Is there a reason we can’t have the InputBinding passed as an argument by default? This change shouldn’t change pre-existing behaviour, I’m just asking for it to be provided in the situation where it’s necessary to mitigate writing more code for different platforms (because again, Console does not have numbered keys, nor does Mobile, so in a perfect world I would create one InputAction they all use, but that’s not possible)

I don’t think they are misunderstanding. They stated that “each action has a distinct purpose”. Your “Cycle weapon” action really should be two separate ones with their own bindings, “Previous weapon” and “Next weapon”. Or even better, also include actions for “Primary weapon”, “Secondary weapon”, “Melee”, etc. It really isn’t that much of a hassle to use multiple actions, one for each weapon slot, and some to switch weapons relative to the current slot.

1 Like

I never claimed it was a hassle, nor am I dismissing the methods you have provided. The point of the feature request was to expand the ways you can make something like this. It’s more efficient to use keys that can directly switch to, or switch off of a Tool / Weapon. Forcing each part of the system to interact the same can feel weird across platforms when the way you approach it for that platform is different.

It’d be totally different if for example, you’re pressing an ability keybind or you bound something to the jump key. In situations where it’s one primary control that every platform requires, great, but again creating 5 InputActions that all end up doing the exact same thing feels unnecessary. Am I crazy for thinking that way? At that point, the InputActions themselves are becoming the InputBindings because I’m making them just to get 2 to switch to Weapon Slot 2, when the actual InputBinding itself could have passed it’s name to the InputAction which then only one function would have needed to be connected.

I get that I could create 5 different InputActions that represent the 5 different numbered keys / slots for both Mobile & PC, but then it begs the question why the UIButton property on InputBindings even exist. It just feels like this way, each InputAction is limited to having one button per-platform which feels scuffed at best.

This wouldn’t work in Server Authority, where just the states and changes of the actions are sent. The calling binding would have to be networked in the input packet or something. For what you’re doing, I would recommending using a Direction1D.

1 Like

Direction1D could work for the Controller side of things which would resolve one of the situations I brought up in the initial post. However, PC & Mobile aren’t (which was the one I was the most concerned about) as having to press two directional keys (or on-screen GUI) to navigate the Backpack wouldn’t be optimal (because Players are conditioned to either tap on the respective slot icon, or press the number key that matches the slot).

Thank you for the suggestion. It doesn’t resolve my use case though.

As for Server Authority, I’m not entirely sure how that fits into this. I’ve also never used it.

1 Like

Ah, sorry, I mean by calling :Fire(value) on the InputAction objects. The newer official PlayerModule scripts do this for converting local movement vectors to world ones, though that might be convoluted and unnecessary in client-authorative :stuck_out_tongue:

I mention it cause IAS is a pretty major part of Server Authority, as the states from it are some of the only things clients can replicate to the server. I would imagine they wouldn’t want a feature that either would need more data to be replicated or just wouldn’t work in IAS’s primary use-case (presumably)

1 Like

If InputAction.Pressed is the only way to listen for player input that began using IAS, anything passed through (such as the parameters) should work alongside it, no? In order for InputActions to be triggered, there has to be InputBindings. If there are any internal connections that allow that to happen, I fail to see how submitting the InputBinding that triggered it is an issue with Server Authority (assuming it works how I think it does) as it’d be retrieved the same way the connection is even possible in the first place.

This isn’t the case. InputAction’s states can be changed with :Fire(). .Pressed is only called on boolean state changes (.StateChanged is called for any state change)

It would have to be another thing that’s replicated and sent. Pretty sure that the only thing that’s sent to the server is the state of the action. I suppose something like it could be implemented on the clientside only, but an engineer back during its release explicitly mentioned that they chose not to implement it

1 Like

Ah, well, I guess this won’t ever be implemented then. Figured I’d shoot my shot anyway. Sky high instance memory here we come.

I’ve already went with what I had mentioned before for using the buttons and scrubbing the keys for PC and it works well enough. IAS is still very new, so maybe it could change later, but based off the wording I doubt it.

Thanks for informing me of the specifics. Have a good one.

1 Like