While I was only really use them standalone for some testing, there appears to be an oversight in the code of UnityEngine.InputSystem.InputAction that prevents them being used without being part of an InputActionReference/InputActionAsset map.
Namely calling .Enable() checks its .enabled property, which checks its .phase property, which checks its .currentState property… which attempts to access its current action map… the one is doesn’t have because that only gets generated until after this check!
Am I completely missing something here, or is this a huge oversight? I noticed this originally in 1.8.2, but the code appears to be the same in 1.11.2 as well after manually updating by name.
Follow up: When I went to make a repro to submit a bug report, the issue didn’t happen.
I’ve realised now that said Input Action was being serialized by Odin, and something about the way it serialization works causes InputAction to stop functioning correctly.
Least I have an avenue to investigate now…
Right, another update.
I’m 99.99% sure that InputAction.Enable() has a logic error, and my initial thought as to the reason this doesn’t seem to cause an error under normal circumstances is that the quirkiness of Unity’s serializer incidentally causes the internal m_actionMap to initialise. But using reflection to test this post serialization, but prior to being enabled, seems to net null.
So franky I have no idea how when serialized this by Unity, it appears to magically work.
I attempted to manually kick-start the InputActionMap post deserialization with the Odin serializer API, but this throws errors during deserialisation as a bunch of extra code runs that does wacky things like the InputSystem class creating scriptable objects?
Question is, should I bother reporting this as a bug?