I did a very thorough debugging session so I hope I’ll hear an official answer. I believe it echoes to several other issues stating that inputs are broken in build. (2021 LTS + Input System 1.7)
Added Breakpoints on the following code and the last hit is an add with my callback
public event Action<CallbackContext> performed
{
add => m_OnPerformed.AddCallback(value);
remove => m_OnPerformed.RemoveCallback(value);
}
After my .performed +=callback was called, the m_Perfomed Callback array holds the correct value.
Later in the execution path, probably on the next frame as it’s within an Update(), I check the value of m_Perfomed and it’s is empty in build and has the correct callback in editor.
Note :
The action is disabled when calling perfomed +=, it is enabled on this next frame, but shouldn’t be an issue.
Wondering :
Asset duplication in build ? So they are actually two different Map/Action ? (I check the m_Id of each and they are consistent.) The InputMap is not an adressable. But the GameObject enabling the action is in an adressable scene.
Depends on anything else that is referencing the input map. If you have a non-addressble asset point to the map, and also an addressable asset pointing to it, you will have duplicated assets. The Addressables Analyze window should be able to tell you if this is the case.
I simply added the input action map to the main addressable group and it seems fixed.
I had the “luck” to already have had the same issue with the audio mixer and that someone knew it was adressable related : https://discussions.unity.com/t/817856
Unbelievable. How do you know that? It worked.
That sounds like a bad API design. If I'm using Input System on addressables, I need to call Enable on InputActionReferences (actionReference.action.Enable())
Thank you for your help, and shame on whose design it like that.
I don’t think its related to Addressables. In general action maps/actions need to be enabled before they can be used. Just I think sometimes in the editor they get auto-enabled for whatever reason; I think namely if you assign them as your project-wide input actions.
So yes,
On Project boot,
There should be a script that enable all of those inputs, if you are working with addressables, because it works in build if you don’t use addressables.
Another point is, if you referenced one of those actions in an addressable, it won’t work until you enable it, but it will work if you use that input reference on a non-addressable.
So,
to avoid addressables / input system issue;
you need to enable all of the actions by using this code on boot:
[SerializeField] AssetReferenceT<InputActionAsset> inputActionAssetReference;
// Start is called once before the first execution of Update after the MonoBehaviour is created
async void Start()
{
var iaa = await inputActionAssetReference.LoadAssetAsync<InputActionAsset>().Task;
foreach (var map in iaa.actionMaps)
{
foreach (var action in map.actions)
{
action.Enable();
}
}
}
Still, that’s a bug more than a design issue in my opinion.
It’s not a bug. You have that Input actions assigned as your project wide actions, so it gets auto enabled. But only if you’re using addressable via the asset database in the editor. Otherwise, it’s enabling a different instance than the duplicate in your addressable groups.
In the end it just comes down to asset duplication.
Yes I understand now. It’s not a bug.
but IMHO, just a bad design, and developer should be notified somehow about this in the editor.
I mean It should not be that tricky.
At least If someone reads this post, they will get a clear idea and fix the problem.
Thank you for your help and knowledge.
