FEnhancedActionKeyMapping::bShouldBeIgnored not being respected

Development Programming & Scripting
, ,
1

I am having an issue when we change possession between pawns that a held binary input is triggering on the newly possessed pawn if the input button was held prior to the possession change.

The issue looks to stem from a change in:

IEnhancedInputSubsystemInterface::RebuildControlMappings

Although reading the commit note on this change, the notes sound like the opposite of the change that was actually made:

https://github.com/EpicGames/UnrealEngine/commit/4cf4b69897e5179bfd109917905e9f30ad7830bb

The issue being that the code on ~line 930 ( according to github on UE 5.5 ):

Mapping.bShouldBeIgnored = true;

Is made redundant by the line further down ~line 947 ( according to github on UE 5.5 ):

Mapping = MoveTemp(OldMappings[Idx]);

where the value of bShouldBeIgnored is being written over by the value of this in the old mapping.

The change mentioned above has the comment:

“Ensure that we set bShouldBeIgnored AFTER we retain the state of old triggers and modifiers”

however the actual change looks to move it before to before it is retaining the the state of the old triggers and modifiers?

Am I just misunderstanding the commit/message/logic or is this a legitimate issue?

NB: I swapped the code around locally and it resolved the issue for me ( so it looked like it did before the change linked above ).

Edit: Having looked back over our local history ( typically taking later release iterations like 5.4.3 etc. but going as far back as 5.2 ) I don’t ever see that code that sets bShouldBeIgnored AFTER the code that is copying over from the old mappings. The issue *seemed* to appear for us when we upgraded from 5.4.X to 5.5.X ( though it is possible it was there before and we just didn’t have a clear use-case in place yet, but I am relatively sure I was testing this functionality about 18 months ago and it was working, but maybe not? ).

Ah, ok - it was this commit that moved it AFTER, not much time before moving it back again with the commit above:

https://github.com/EpicGames/UnrealEngine/commit/64be6db96f23312cf3cdf9b13693dff3e1944309

Was there an issue with this being AFTER and this wouldn’t be a suitable fix for this?

2

Steps to Reproduce
Speculating on reproduction steps as I haven’t set up a pure test case.

Create 2 pawns with the enhanced input set-up on them.

Have Pawn 1 set up with some logic to change the players possessed pawn to Pawn 2 when a binary input (B) has been held for a short amount of time.

Have Pawn 2 set up to debug print ( or do _something_ ) when the same input (B) is pressed.

In our case, this is 2 separate input actions ( one for press and one for hold ) but both mapped to the same buttons.

In our case the input actions are set up in 2 different Input Mapping Contexts. When the possession changes we remove the IMC with the input configured for Pawn 1, and push the IMC with the input configured for Pawn 2.

Ensure that when the IMC’s are being pushed the ‘bIgnoreAllPressedKeysUntilReleaseOnRebuild’ is set to true.

Ensure the input is set up as a binary input.

If you now hold the input (B) while possessing Pawn 1 to trigger the logic to possess Pawn 2, at the point Pawn 2 is possessed the input action linked to input (B) will trigger, and debug print.

This is not the desired behavior, as the (B) input should need to be released and then depressed again to trigger this input action.

3

Hey there, sorry for any confusion.

The order of operations changing there caused a bug with some existing bindings, specifically within some editor utility widgets, where they were not triggering as frequently as they should have been.

I’ve created this issue: Unreal Engine Issues and Bug Tracker (UE\-295787) to track the fix for it and will investigate further.

Thanks for the detailed bug report! I would say that you should feel free to try the original change if you like, from what I found the issue was specific to a test project which may not affect the needs of your own game. Another alternative would be to inject a value of 0 for the input you want to make sure is cleared when you possess the pawn, which should cause the input trigger evaluation to be canceled and reset.

Ben

4

Excellent, thanks Ben - I think I might go with something simple like this for now as it will hopefully make for an easier merge down the line and will spot fix this ( I haven’t seen any other properties being blatted over causing issues yet so hopefully this is the main one ):

[Image Removed]