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
- Non-multisampled texture binding errors are logged when running the DepthBlit URP scene with MSAA enabled on Vulkan
- The Editor does not recognize code errors in generic classes when using C# Source Generator to generate serialization code
- NullReferenceException is logged when undoing Deletion of a Visual Query Block of a Search Expression
- “Unsupported type MinMaxCurve” error and “Could not register property modification for animation binding…” warnings are thrown after moving playhead when Particle System Property is added to Animation window
- Nested LocalizedStrings can not query local variables
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.