Enhanced Input and ignoring prior key downs?

Using Enhanced Input in UE5.1, is there a way to listen for key-down events ONLY after a context is applied? The default behavior seems to be to begin checks for key down immediately. I suspect I could do this with a Trigger modifier but I’m not entirely sure how those are supposed to work and there’s very little documentation/tutorialization on that.

Specific use case: I have a behavior assigned to Left Mouse Button in two contexts. What currently happens is, if I press LMB in the first context, then remove the first context and add the second context, the second context’s LMB event IMMEDIATELY fires Start because it detects that LMB is currently down.

Desired behavior would be that the second context does nothing until LMB is released, and then pressed again, because it is listening for the key-down event to occur while it is active, and an existing “key is down” state is insufficient to trigger it.

If you right click the options pin of the add input mapping node it opens up to an option to “ignore all pressed keys until release.” This might give you the result you want.

It DOES (and in fact it’s the default options behavior, it has to be explicitly disabled) but only in a specific circumstance, which where a second context of higher priority is applied over the first. If two contexts are added/removed in tandem this does not work.

e.g. if you have a base input context which has some function for LMB, and you use Add Context when near an object to add the “object interaction” inputs which overrides LMB, you will get the functionality you described. LMB will not be considered a valid input in the interact context until released. And this will work in reverse; if you have an interact context active and press LMB, then remove it, it will not register the “base context” input until released and re-pressed.

But suppose you have two distinct contexts: the first is “sword mode” and the second is “bow and arrow mode”. There may be bow and arrow mode functions not mapped to any sword mode inputs or vice versa, so you don’t want to just apply one on top of the other (otherwise some sword functions will still be callable in bow and arrow mode, say, if bow and arrow mode does not have any inputs mapped to those functions) but some inputs may be in conflict so they require separate input contexts. So the sensible solution is to “remove sword mode” and “add bow mode” when you swap weapons. However, if you do this, you will run into the issue I described, because one input context does not override the other, it replaces it.

Actually jay, you’re very nearly right. The trick is you must always ADD the new context before REMOVING the old context. As long as some context exists which is listening for the input, the option you described will function as desired. My mistake was thinking these two were interchangeable; I was removing the first context and then applying the second, but in so doing I evidently created a situation where, because nothing was listening to the input, it got reset. I would have assumed that as long as these function calls occurred on the same frame, it would be the same result, but it’s not. You have to add the new context, THEN remove the old context, so that some action that cares about the input is always active.