Layered Action Maps?

I've been trying to implement the new system into my game for the past couple days and one thing I can't figure out is how to use multiple action maps at once, or if it's even possible.

I'm used to input systems that have a stack of action map equivalent objects, that each take precedence over the last. So for example I might have a base map that says something like Esc opens the main menu, and layer a player movement map on that which doesn't define the Esc, so Esc gets passed through to the base map. Then I layer on a UI action map that defines Esc as closing the UI (and blocking from further propagation).

Is it possible to do this with the new input system?

 

I'd really like an answer to this question. Is this not the right forum to ask it?

 

I would like this feature too. There are many times where I want to open an in-game menu with a start/esc button and I want that to happen when the player is on foot, in a vehicle, in a conversation etc. I'm guessing you can handle this action in code or duplicating the action for each of the action maps. The duplication though causes problems for rebinding if I want the game to be able to treat the bind as the same bind for every action map. I'm guessing again you could probably write some code to update the binding for all of the action maps. A built-in system for sharing action maps between contexts at the asset level would be spiffy though.

 

I don't think this feature exists in the current API, but I'm hoping we can add it to the list of feature requests for a post 1.0 release.

 

This is super high on the priority list and one of the next things on my own list.

I've recently dug a bit into that and my current thinking is to make two changes to the system:

1. When a control triggers its change monitor, instead of directly firing the associated action, the system instead goes and looks for the "most suitable" action to fire from the given event. This will take precedence according to the ordering of action maps as well as of individual actions in maps into account but also things such as a binding of "CTRL+B" needing to override a binding to just "B" in case both CTRL and B are currently pressed.
2. The system then triggers the action and afterwards checks whether it consumed the input. If not, it takes the "next most suitable" action and does the same and so on. Each event will get processed only once regardless of how many control change monitors it sets off.

With this in place and without any user code changes, the system would automatically take layering of action maps in assets into account and would also correctly handle things such as composite bindings such as CTRL+SHIFT+B pre-empting input on other bindings. At the same time, it would allow action callbacks to dynamically decide whether to let events pass through or not -- e.g. the UI input module can decide based on whether a UI element consumed the input, if the action should consume its input or not.

I haven't actually gone and tried implementing this so could be that it won't quite hold up in this form but FWIW, thought I'd just give a brain dump about where this is at ATM.

 

With this change would that mean that basically all action maps would always be enabled and individual actions on lower priority action maps will only be ignored if there inputs are consumed by higher priority actions?

 

The set of enabled maps would still be under your control but yup, if multiple maps are enabled, then higher priority actions will prevent input from reaching lower priority actions except if explicitly letting it through.

 

That sounds great, and thanks for the response. I have a couple of questions:

1. Would this work as a stack (eg you can push 'flying' and it overrides 'walking' until you pop it), or does each action map have a simple priority? I can see uses for both, and in my case I'd prefer a stack for my current project.
2. Can one layer (or action map, whichever) block a lower level one when enabled/pushed? In my flying/walking example, I'd want flying actions not to fire if the walking layer is enabled over it.

 

+1 for this feature.
In the game I'm currently working on, a key press or a mouse click have different functions/actions based on the context. I think the escape key scenario mentioned above is one of the most straight forward examples. There are other cases in my game where click should mean interact/attack/talk/etc.

Is there a way to track the progress on this feature or where it is on the roadmap?

 

ATM it's still too early to say how exactly this will work. Not enough work has gone into this yet.

Having control over the stack in some form (with some default ordering based simply on ordering within assets) definitely sounds useful. And yes, there should be the option to block (should probably be the default as I think it's not that frequent that you trigger something from, say, the B key but then also want something lower down the stack to trigger from the same key).

But yeah, all conjecture at this point. It'll only be after 1.0 this will get looked at for real.

Not ATM. I expect that after 1.0 is all baked and dry, there'll be more news.

 

Is there any update on this? Based on the Changelog (https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/changelog/CHANGELOG.html),1.0 was released in late April and it doesn't look like there have been any updates or news on this since. Prior to the release of 1.0, it looks like there had been fairly consistent updates, but since then it looks like radio silence (almost 6 months now).

Reviewing the documentation around the original design for the InputSystem, it looks like the concept of layered ActionMaps was core to the project goals (https://sites.google.com/a/unity3d.com/unity-input-advisory-board/design-overview). This video in particular highlights their importance (

) to the stated goals.

However, as I understand it based on reviewing the forums and documentation, right now it is not possible to do what the above video outlines and have one ActionMap layer "block" Actions mapped to another lower layer (for example, binding the Right Trigger to an "Accelerate" Action in the "Diving" ActionMap which blocks the Right Trigger binding to the "Sprint" Action in the "Walking" ActionMap, when both ActionMaps are active). Obviously a developer can write custom logic to provide this functionality, but that's non-trivial work.

On a related note, the "Known Limitations" states that Actions cannot "pre-empt" each other's input, meaning that if you're using a ButtonWithOneModifer or ButtonWithTwoModifier composite binding, it still fires the underlying unmodified Action when firing the modified Action (for example, if you have "Right Trigger" bound to a "Sprint" Action and then you also setup a ButtonWithOneModifier composite binding for a "Fire" Action with "Left Trigger" as the modifier and "Right Trigger" as the button, if the player presses the left and right triggers it's going to fire "Sprint" and "Fire"). Again, you can fix this by implementing custom logic, but this limitation is very "limiting" to the utility of the Modifier composites.

These two items seem related because they're both about suppressing/prioritizing Actions (either based on the presence of a Modifier or the priority of an ActionMap). Can someone provide an update on when (or if) these issues might be addressed? To me these seem like they are core to any "input system" implementation and they also seem like they were core to the original goals of this project.

 

Any update on this?

I know I'm not the only person looking for information on this topic as it's been raised in other threads as well (https://forum.unity.com/threads/usi...another-action-using-the-same-binding.775109/).

 

Unfortunately, no update yet. Very much agree, though, it's a significant missing piece.

In terms of missing functionality, we've opted to pick off the smaller missing things first. Some of that stuff has made its way in by now (such as an improved polling API, being able to query timeout completion percentages, some other things) and some stuff is already in the works (such as an easy replacement for Input.anyKey) but there's a few items left there.

But yeah, unfortunately, no concrete ETA yet. My guesstimate is that the change will land in 1.2 (we're in the process of starting to wrap up 1.1 at this point). That'd still put it a couple months out. Sorry I don't have better news ATM.

 

@Rene-Damm any updates? Also, is there an alternative way of hacking this together while we're waiting for the feature?

 

@Rene-Damm I'm looking for this feature too. Very important one I guess. Any updates ?

 

Not to speak for @Rene-Damm, but he said in his last post (2020-10-20) that they're currently working on 1.1 and so this functionality, while important, likely wouldn't land until 1.2 at the earliest (this was his best guess at the time).

Checking the package documentation, 1.1 is still in preview and under active development. Looking at the Changelog, the most recent version is 1.1.0-preview.3 and that was pushed about a month ago (2021-02-04). Based on all that, I'd say this feature is still a ways out (probably many months from now, as 1.1 has been under development since spring of). Of course, it's always possible that this has been pulled into 1.1 and we'll see it in some future preview release, but based on the most recent information there is no reason to expect that.

 

This is still a dream in Unity 2021.3.18f1 LTS

 

Still dreaming

 

Dreams

 

Dreams indeed

 

@Rene-Damm it has been 3 years since you said this is super high on priority list.
Has something unexpected happened?

 

Still dreaming

 

Still dreading

 

The dream that never ends...

 

After a few hours of research, I feel confident in saying that as of 09/11/2023, there is no in-built way to consume or prioritise input events. That is of course, unless the event you want to prioritise is a binding with one or more modifiers. For some reason, input event consumption has been implemented for this case, but they have not (since Input 1.4... we're at 1.8 now) expanded this to other forms of input at all.

For such a fundamental and rather basic feature, 4 years and 9 major package versions with no progress or information is absolutely unacceptable.
It is 2023. We should not need to wrap the "new" input system with our own code just to avoid multiple actions activating on the same input event.

I mean, they have the ability to create binding masks for individual actions, but you can't consume an input event. This is incredibly frustrating, and seems to be another example of Unity's impractical priorities; like creating a project wide input action configuration, which while it may be nice, solves exactly 0 of the input system's current issues. (https://docs.unity3d.com/Packages/com.unity.inputsystem@1.8/changelog/CHANGELOG.html.)