I’m using PlayerInput and the new version of the IS (1 preview) and I noticed a weird behaviour. I don’t know if it happened before because I just implemented it.
Basically, I’m using an InputAction file with two control scheme (Gamepad/Mouse&Keyboard), and two action map, “Player” for the gameplay and “UI” for UI (I’m trying to do all navigation myself because there is weird things happening when switching between devices). I’m using the Invoke Unity event in player input.
The problem is, action from my UI action map are getting called when I’m on the Player action map. Isn’t PlayerInput supposed to restrict to only the active ActionMap ?
PlayerInput will only activate one map at a time by default but it won’t prevent other pieces of code from enabling or disabling actions of their own.
In this case, it’s the UI input module doing its own thing. It will enable the actions it is assigned when is it itself enabled and disable them when disabled.
I’ve no clue if that’s related or not, but there is a REALLY weird thing going on. I have callbacks thare are getting called from a script that is on a monobehaviour of ANOTHER scene, what the heck ?
In my second scene I’ve a gameObject with “CharacterSelection” script attached to it, I’ve an InputActionReference navigationReference that I use like this
And it’s getting called when I go to the next scene (basic LoadScene, not additive or anything). And it’s still printing ?!
EDIT : So if you don’t unregister the event, it can be called even if there is no gameobject/script on the scene. Definitely looks like a bug to me, right ?
InputActions have no concept of scenes. So yes, as long as an action remains enabled, it will trigger.
PlayerInput integrates this with the GameObject world and will disable its actions once it is itself disabled (e.g. when going to another scene) but when working with actions directly, it’s basically up to you to enable and disable actions as needed.
I’m having to deal with a very similar situation, I have two action maps, UI and Player, everything works fine at first, the default action map is set to Player. When I turn my inventory on, I switch to the UI action map with the playerInput.SwitchCurrentActionMap("UI");, but when I switch back to the Player action map, the actions mapped with the same bindings as my UI (e.g., dpad for walk in the player, and the same dpad for navigation in the UI) throws a Should Not Get Here Exception
Should not get here
UnityEngine.InputSystem.LowLevel.<>c__DisplayClass7_0:<set_onUpdate>b__0(NativeInputUpdateType, NativeInputEventBuffer*) (at ?)
UnityEngineInternal.Input.NativeInputSystem:NotifyUpdate(NativeInputUpdateType, IntPtr) (at C:/buildslave/unity/build/Modules/Input/Private/Input.cs:120)
I ran into a similar problem. In my case, two actions in two separate action maps were being triggered by a single key press if the following criteria were met:
Two action maps exist, each one containing an action that is bound to the same key.
In the second action map, a one modifier composite action exists with a main binding to the same key as the other two actions.
Upon receiving an action triggered event (from PlayerInput.onActionTriggered), switch from the first action map to the second.
In this situation, when I received the input from the first action map and immediately switched to the second action map, the action bound to the same key on the second action map was also triggered. When I removed the composite action or changed its binding so that it was a different key than the other two actions, the problem no longer occurred.
Posted a comment to the unity issue mentioned above (closed as “by design”) – I’m still looking for a good workaround
I can understand if there were 2 action maps active before the input was given then both action maps consuming that input would be called. But in this case, there was only 1 action map active at the time of input, but somehow, when that action enabled a second action map, the input triggered new action map as well. In my case, adding any breakpoints along that path would prevent the second action map from being called.