How do I implement input fade out feature

I should start by saying that the new Input System is one of my most anticipated Unity features, and I can't wait to try the next Preview, that is coming in the next release.

Overall, I really like the design of the system, and the fact that you try to cater for as many cases as possible. However, there is one feature I've been wondering how I'd implement using this system.

So imagine you're playing an MMORPG game, and you hold "W" - naturally, your character now keeps going forward. Now, let's say you want to open the main menu - you press "ESC". The main menu opens - and your character still keeps going forward, because you keep holding "W". Now, if you release "W", your character should stop. But while the main menu window is open, pressing "W" again will not make your character move forward.

I call this feature input fade out (maybe there is a better name for it), because during this phase the system will accept input release, but will not accept input press. I know at least one popular game that implements this behaviour.

Is it something you are bringing in the next Preview, or is it something that you never thought about and would like to implement in the future?

 

It's not on our roadmap. With how layered ActionMaps work, the character would stop walking forward when opening the menu (unless the menu ActionMap doesn't use W and is set not to block lower ActionMaps, but then it won't block new presses either).

We can't support every single conceivable feature out of the box, so if this is just something one game does, then we're unlikely to ever prioritize this over the many other things that need to be done. But if it's a common pattern already used in lots of places, then we can have a look again and consider if it should be a priority.

 

What if action maps weren't all or nothing blocks? We could selectively allow key ups or keydowns and axis increase or decrease.. or maybe there could be some more configurable object that determined when one actionmap blocked the input for its siblings. ActionMapInputFilter that we could slot in with a public bool ShouldBlockInput(KeyCode keyCode)

 

It sounds like as an out-of-the-box feature, this would add a lot of complexity to the system, while we still don't have indication that it's a commonly used functionality already established across many games. As such, we don't have any plans to prioritize such a feature for the time being. For a programmer, it would be entirely possible to make a custom version of one of our classes that adds this functionality to it though. (The system will ship with source available.)

 

Well, in my way of seing things, this could be done by having a specific bool in your game to change what happens when you press the "W" key. For example its value when oppening the menu would only change if no key was being pressed.
Think like implementing the movement script for -let me think of an example- god of war 2. In certain moments, the camera shot changes drastically, and the character movement is based on the camera position. But to avoid confusion with movement, it only "updates" the position of the camera when the player releases the L3 analog.
The same logic would apply to the game menu, only updating the functions of the buttons when no button was being pressed.

I know, this is a really weird explanation, but I hope this helps, if not, perhaps I'll post some example code with he logic.

 

Seems to me like this is the kind of thing that should be handled entirely by your gameplay code; not by the input system.

The Input System's job is to tell you if W was pressed on the keyboard. It's up to you to decide what to do with that information (if you want to process the key press or not).

Adding this sort of feature to the Input System would only cause unwanted bloat in the API, and would be completely unnecessary because it takes 5 seconds to implement it yourself