"Consume input" doesn't work (the input still propagates everywhere)

Development Programming & Scripting
,
1

Hi, all! So, inside UE5 I created a FirstPerson template for testing out this issue. Looking at its already-setup Enhanced Input configuration, we can see that moving our character is being accomplished by listening to an Action Input called IA_Move, which belongs to an Enhanced Input Mapping called IMC_Default.

The problem is that if we take a look at the IA_Move settings, we can clearly see that the Consume Input flag is being checked:

image

however, if you use the Enable Input node on the EventBeginPlay event of several Blueprint Actors and then start listening for the triggers of this input’s event:

image

we notice that all of them are perfectly able to respond to the pressed keys belonging to this Input Action (i. e. all of the WASD keys), which is very strange, as to me, “consume input” should behave exactly the opposite, meaning that the first Actor that gets to react to the trigger of the IA_Move event should also consume it, leaving all other Actors with no further input to capture (effectively acting as a mask/blocker for any further input processing on those keys).

So, as an example, I added a Print String node on the trigger of IA_Move throughout several BPs, including: 1x Ball actor, 1x Cone actor, the Level BP, the GameMode BP, the PlayerController BP and the FPS Character BP and they all receive the same input without any issues (I’m walking forwards here by holding down ‘W’, hence the 1.0 value for the forwards-backwards axis):

image

And in case you’re wondering why my Print nodes have “UE5” as a prefix, it’s because I was curious to see how the old UE4 system behaved under the exact same conditions (not using the Enhanced Input, but the old Input Axis Mapping and then listening for my keys throughout the same BPs as above). And here are the results:

image

As we can see, the (now deprecated) UE4 version works as expected, I’m guessing due to the “If one InputComponent takes the input, it is not available further down the stack.” statement written in the official docs. You can even see the priority stack in that same section:

image

What am I missing here?! Please help me out, as I’m stuck with this issue for a week now. Much appreciated! :blush:

2

Yeah, it just doesn’t work, eh? :slight_smile:

I thought for a moment, that you could use IA_Move as many times as you wanted, but it would consume whatever keys you had defined in the IMC_Default, but that’s not the case…

1 Like
3

@ClockworkOcean Well, that’s how UE4 used to do it with its now-deprecated system in the favor of this newer (and apparently broken) one. I’ve updated my main post with a few more paragraphs at the bottom (I went ahead and tried the old UE4 way, as seen above), just in case it helps with the overall picture, if anyone has any clues/ideas… :melting_face: Btw, I forgot to mention that I’ve also used the Enable Input node on the EventBeginPlay event of all those BP actors in order to make input listening possible (also added this to the main post). I thought it is obvious, as it won’t work without this, but then decided I should mention it nevertheless, for the sake of completeness, just in case anyone else wants to try this out.

1 Like
4

Imagine I have 2 sets of controls:

  • IMC_Default (Priority 0) to move around with WASD
  • IMC_Backpack (Priority 1) to move between backpack slots, also with WASD
  • if priorities are equal, the one added last gets to the hardware input first

image
image759×317 29.3 KB

When I open my backpack and WASD inside it, I’d rather not walk off the cliff, so I add a new Mapping Context with higher priority, so it can intercept Actions associated with keys:

image
image774×728 115 KB

Think with mapping contexts - abstracted layers of input. It’s not the Input Actions that get priority anymore, its the mapping contexts. The Input Action can be, optionally, consumed within that context:

image
image444×518 27.2 KB

Now I’ll walk off the cliff even with the backback open; it’s not consumed and the IMC_Default (Priority 0) will also detect W being pressed.

I’ve been using this system only for a week, if someone tries to correct me on the above, they’re probably right…

2 Likes
5

@Everynone Hmm… how is that different from the Set Input node? Is it like the same, just for the new Enhanced Input in UE5? Here’s a quick reference for what I’m saying:

6

Set Input is for passing input priority between widgets and the player controller. It can also pass focus from widget to widget but there are better ways to that particular thing.

Not sure how EI meshes with widgets, tbh. I am as much of an explorer as you are.

1 Like
7

Just for clarification, the new Enhanced Input system is not working as expected, correct? I am having the same problem with IA_actions not being consume and causing problems.

Or, are we stuck in UE4 mindset and not using the new Enhanced Input correctly?

8

They are correctly consumed within their mapping context’s priority. See the post above.

9

in 5.2, using the VRTemplate I use IMC_Default with priority 0 and it includes IA_Grab_Right and IA_Grab_Left. This IMC is added at BeginPlay in VRPawn. Then I created a new IMC_Override that uses the same IA_Grab_Right and IA_Grab_Left (both have Consume Input checked). In game, I then add this IMC_Override with higher priority and I do a grab. I see the new IMC_Override is activated and then right after IMC_Default is also activated. I was expecting the input action in IMC_Default would not be triggered. How am I thinking wrong, please?

Oh, I think when the IMC are added, for input to be consumed, both IMC must be on the same actor. In my case, IMC_Default is in VRPawn while IMC_Override is in a different actor. Is this the correct interpretation?

10

It is specific to VR. Non-VR inputs work fine.

I looked through the enhanced input code and saw that it was correctly updating the bindings according to priority. The old VR binding is no longer present in the array of mappings (EnhancedActionMappings in UEnhancedPlayerInput). Yet the old input action still fires.

When I switched both the old and the new physical input for this action to non-vr controls, like a key, it worked immediately.

Epic, plz fix!

11

Following up with a workaround for priorities in VR, when using OpenXR in UE5.

  • Make a superset of ALL the possible contexts that you want to load, and add them to a Player Mappable Input Config.
  • Set that Input Config in Project Settings → Plugins → OpenXR → Mappable Input Config for XR.
  • In your Pawn, set the Input Config property in Class Defaults to another Playable Mappable Input Config, only including the Input Contexts you want to start the game with.
  • At some later point, load a new context with a higher priority.

Check ShowDebug EnhancedInput to see if the correct actions are loaded.

12

thanks basisvector (great user name, btw). Your approach does work, thank you.

I also had the additional complexity between switching between openXR and metaXR plugins. The latter doesn’t use PMI at all. I also found that if I took the default IMC_Default from the VR template and split it into two but tried to load both IMC when using openXR, my controllers were stuck to the floor. If you try to do the same thing w/ the VRTemplate, it does the same thing. Weird.

Wish there was some good documentation the usage pattern to be used for Enhanced Input. I dredge touching PMI/IMC/IA since something always breaks.