Hi,
There appears to be an issue with active IMC Input Triggers when any mapping context is added or removed while an input trigger is active - the LastValue of any trigger seems to be wiped out.
An example I have is set up as shown in the attached image. If the key ‘M’ is held down, then it keeps hitting the Triggered pin in the blueprint repeatedly (printing ‘Added’ and ‘Removed’ over and over in my example) because AddMappingContext and RemoveMappingContext keep clearing the Triggers. The expected behaviour here for me would be that it would only trigger once until the key has been depressed (which is what used to happen in 5.4).
This breakage appears to have come about when fixing UE-270589. Turning off bRespectIMCPriorityForTriggers fixes the problem, (as it just turns off the change), but that’s presumably swapping one set of problems for another. My assumption would be that the old triggers cannot be overwritten wholesale and should at least maintain the LastValue, but I’ve not dug that deep.
Thanks,
Steve
[Attachment Removed]
Steps to Reproduce[Attachment Removed]
Hey there,
The original bug UE-270589 is an issue where if somehow changed the modifier/triggers on a key mapping (for example, adding a higher priority mapping context with a mapping to the same input action, but different modifier values) then we want to maintain the state of the trigger or modifiers, since the input action itself is still being used. We actually had a live example of this in the Lyra sample project with the “ADS” (Aim down sights) input action. When scoped in, we wanted a lower aim sensitivity applied via input modifier, which was not working.
You point out an interesting edge case here. The additional “Add Mapping Context” call triggers a call to `IEnhancedInputSubsystemInterface::ReorderMappings`, which is where we are retaining the trigger state if needed, which is correct. The issue appears because the ActionInstanceData for that data is cleared though, so on the next tick it will re-evaluate the trigger state and fire the “triggered” event again.
I have filed UE-361208 which you can use for tracking of this issue once it goes public.
For now, I would say that using that CVar set to false is a fine work around if you don’t need this behavior. Otherwise, you could first check if the IMC is already applied before calling add a second time if your gameplay code depends on this logic, and that should prevent the additional call to ReorderMappings. You can do this with a call to IEnhancedInputSubsystemInterface::HasMappingContext.
I hope that helps,
Ben
[Attachment Removed]