What is the correct way to consume trigger input from an IMC? In the repro steps above, I would expect axis trigger input to not fire off, until the trigger returns to zero (released). Instead if you have the trigger held at the point of switching IMCs, the trigger will immediately start sending axis events every frame, triggering the input action it is linked to. I need it to instead wait for the trigger to be fully released before sending axis events, could someone please advise the best way to achieve this?
Steps to Reproduce
- Add an IMC to the player during an ability, with a digital controller trigger input.
- Remove the IMC from the player when the ability is finished, with force immediately and ignore all keys pressed until release set to true.
- Flush player input from the player controller.
- Add another IMC to the player with an axis controller trigger input.
- In game, keep the trigger held as the old IMC is removed and the new one is added.
Hello there,
I just want to clarify a few things.
- Are you also ignoring key presses on the added IMC as well?
- Does the issue disappear if you use the Axis trigger for both? You may wish to use a Digital (Bool) in the InputAction for the first action you were mapping to keep logic consistent if it isn’t already using that.
If those don’t help, would you mind if I ask for a repro project to make sure I’m looking at the same setup?
Best regards,
Chris
Hey, thanks for the reply.
- bIgnoreAllPressedKeysUntilRelease is set to true however in the comments of EnhancedInputSubsystemInterface.h it says the following “* Note: This will only do something for keys bound to boolean Input Action types.”
- Setting the first IMC to be axis as well makes no difference.
I’ll create a repro project when I get the time 
No worries.
I’ll dig more into the IgnoreAllPressed in the meantime. It’s possible this is intended as the second IMC is an axis type on the IA.
If the actions are related and dependent, you may be able to add an intermediate IMC to handle this. Am I correct in my understanding that the ability adds an IMC, and if the input action (IA) triggers, a second IMC is added?
Best regards,
Chris
Attached is a basic repro scene, you can go into the trigger axis issue folder and check out the player and item BP to see what’s going on.
Holding right trigger puts the player into a “catch” state where they can catch items. Colliding with an item while in this state ends the catch state and removes the catch IMC, it then adds the Item IMC (as you wield the item). In the Item IMC, the trigger axis equates to “using” the item. You can see in the demo scene that if you are holding RT to stay in catch state, then moving over an item to wield, you will immediately start using the item instead of it waiting for the trigger to be released.
In my actual project an ability is what adds / removes the “catch” IMC, here it is just given on begin play and taken away when you wield the item. But the flow is essentially the same. Worth noting that in the actual project these actions are not dependent, you can wield an item by other means like picking it up. Equally you can enter / end the catch state without ever “catching” an item.
I’m surprised that there isn’t some version of bIgnoreAllPressedKeysUntilRelease for axis inputs, this seems like a fairly standard use case.
Hope that all makes sense, thanks for the help and let me know if you need any more info
There are a few situations where it’s somewhat required to use an intermediate IMC to handle the lifecycle of actions, especially if they need to out last the IMC they are on. This appears to be one of those situations.
What I tested was to add a new IMC with a new action called ‘IMC_CatchHandler’ and ‘IA_CatchHandler’ respectively. This IMC is added instead of IMC_Catch in the repro at priority 0. All instances of IMC_Catch can be be replaced with IMC_CatchHandler as the handler takes control of adding IMC_Catch. IMC_Catch’s removal will be handled by itself.
IA_CatchHandler’s Triggered state is bound to add IMC_Catch at priority 1. It is important that this IMC is added at a higher priority as they need to share key-bindings exactly for this to work. By default, IMC_CatchHandler will keep the active action unless the incoming IMC is a higher priority. Additionally, I turned the IA_Catch into an Axis action. Removing bIgnoreAllPressedKeysUntilRelease from the options should also work, but this prevents any future updates accidently breaking it.
The Completed state of IA_Catch is bound to remove the IMC_Catch IMC. You may wish to bind Cancelled as well if the trigger can enter that state.
The overlap event was modified to remove the Handler IMC and FlushPlayerInput was removed.
What should now happen in ShowDebug EnhancedInput is that the key-press causes the handler to add the Catch IMC, which itself immediately fires catch logic on the triggered state. When Catch is released, the Catch IMC is removed, but as CatchHandler is not removed here, repressing the trigger will repeat this process. If IMC_CatchHandler is removed during the activation of the Catch IA, the Catch IA stays active and continues consuming the input until its own Completion event removes it.
Because it is of higher priority than the UseItem IA, UseItem will not receive input. If IA_Catch is released, it will remove IMC_Catch, which then allows the next input to hit the UseItem IA as expected.
Let me know if this works for your use case. If you have any questions about this, please don’t hesitate to ask.
Best regards,
Chris
This method worked! I’m surprised there’s nothing built in to handle this case. Thanks for the help though, much appreciated
No worries, I’m very glad it worked for you.
If you have any further questions, please don’t hesitate to ask. Otherwise, would you mind if I close this question for now?
Best regards,
Chris