I am not sure if this is a bug or an intended feature. However, it causes multiple issues especially in systems like movement. I noticed this issue while developing a block mechanic for my combat game. I am utilizing the new IAS (Input Action Service) to map out my games input. When a user presses F which toggles the block, I disable the InputContext that holds the InputActions for movement. This works perfectly. Now lets say the player stops blocking and returns back to running. If the player then lets go of shift (which is the sprint key) the player keep running. This is because the InputAction did not listen to the .Released event when I let go of shift despite the InputContext being re-activated when block is ended.
Expected behavior
I may be wrong, however the functionality that should occur is the .Released event firing when the Context and action is re-enabled. after being disabled. Please keep in mind that this only happens if the player never releases the key that they were holding down when the InputContext was disabled. But then release the key when the InputContext/Action is re-enabled.
Thanks for the report. We’ve released a change that should fix this issue with disabling actions/contexts not properly resetting the action state. The Released event should now fire when the action is disabled while the binding is being pressed.
Hi! Thanks for the response back, I have checked if the fix worked but it does not seem to be working.
The issue is not the Released event firing when the action is disabled, the issue is when the action gets re-enabled while the player is still pressing the key, and then player lets go of the key, the .released event fails to fire.
Hi there, we don’t update actions to match the current state of the hardware when they are re-enabled by design. There’s a couple reasons for this, but a short summary is that actions update their state based on input changed events. We can’t just update the action to match the state of the bindings because there could be many different bindings connected to the action in different states and also there may also be actions at higher priorities sinking the binding connected to the re-enabled action. The good news is that it’s relatively easy to implement your own “Enable” attribute or variable and just keep the official InputAction.Enabled property toggled to true. This way, the action should always match the state of the keys you’re interest in, and you’ll have your own property that you can manage to know when to ignore Pressed/Released events.