Search Issue Tracker
By Design
By Design in 1.14.X
Votes
0
Found in [Package]
1.14.0
Issue ID
ISXB-1532
Regression
Yes
PlayerInput actions not triggered when using Invoke C# Events behavior
Steps to reproduce:
1. Open the attached "InputSystemMigrationIssue-master.zip" project
2. Open the "OutdoorsScene"
3. Enter Play Mode
4. Press ESC
5. Observe the Console Window
Expected result: "Cancel pressed!" logs are present in the console
Actual result: No logs are present in the console
Reproducible in: 1.14.0 (2021.3.51f1, 2022.3.60f1, 6000.0.37f1, 6000.1.0b5, 6000.2.0a9)
Not reproducible in: 1.12.0 (2021.3.51f1, 2022.3.60f1, 6000.0.37f1, 6000.1.0b5, 6000.2.0a3), 1.13.1 (2021.3.51f1, 2022.3.60f1, 6000.0.37f1, 6000.1.0b5, 6000.2.0a3)
Reproducible on: Windows 11
Not reproducible on: No other environment tested
Note: On 2021.3.51f1 it throws errors every button press on versions 1.12.0 and 1.13.1, but doesn't throw any errors on 1.14.0
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
- Changing Transform values in Search window Inspector loses focus while dragging and stopping mouse without releasing dragging action
- Saving changes on the dirty VFX Graph during the Play mode throws "The referenced script (Unknown) on this Behaviour is missing!" warnings
- VFX Graph Debug Info overlaps the "Initialize" block debug info by default
Resolution Note:
In 1.13, all the action maps of a project-wide action asset were enabled on startup. This means any actions react to callbacks regardless of what was set up in the default action map in the PlayerInput component.
In the bug project, the default action map of PlayerInput is set to "Player". But the actions the user is expected to trigger are related to the "UI" action map. This should not be the expected behavior in 1.14. It was not well-defined behavior in 1.13 and older versions, but it is now.
To fix this, the PlayerInput default action map needs to have "UI" action map selected.
Also, if another asset is used, that is not a project-wide actions asset, and has not been enabled, you will see the same behavior even in 1.13.x: the default action map of PlayerInput or (PlayerInput.currentActionMap) needs to be selected for it to trigger callbacks. All the other action maps are disabled, except the PlayerInput current one.
Feel free to reopen if my assessment is incorrect.
Resolution Note (1.14.X):
In 1.13, all the action maps of a project-wide action asset were enabled on startup. This means any actions react to callbacks regardless of what was set up in the default action map in the PlayerInput component.
In the bug project, the default action map of PlayerInput is set to "Player". But the actions the user is expected to trigger are related to the "UI" action map. This should not be the expected behavior in 1.14. It was not well-defined behavior in 1.13 and older versions, but it is now.
To fix this, the PlayerInput default action map needs to have "UI" action map selected.
Also, if another asset is used, that is not a project-wide actions asset, and has not been enabled, you will see the same behavior even in 1.13.x: the default action map of PlayerInput or (PlayerInput.currentActionMap) needs to be selected for it to trigger callbacks. All the other action maps are disabled, except the PlayerInput current one.
Feel free to reopen if my assessment is incorrect.