Multiple controllable characters in new Input System

[tnpcook1]

Howdy,
I'm using UCC, and shift between control of a large cast of actors during play where the player controls a single entity while the others switch to AI. Our move to the new Unity Input System's integration has been pretty smooth, but we hit a problem.
When we have multiple characters in the scene, it seems only one will "connect" to their inputs, even if we use different inputassets or instances for them.

Ex. Character A and B both enabled in scene, character B will be controllable and A will not.
If character B is disabled prior to play, character A will now function properly.

Each character is configured with it's own UnityInputSystem and PlayerInput script, with a unique input Actions object reference.
When not controlled by the player, a nav agent and behaviordesigner AI affect them as expected.

Is there a method to assuring these characters are able to enable/disable their input on demand?

 

[Justin]

This is more on the new Unity Input System side of things but from what I understand you should be able to assign a new InputActionAsset to the Unity PlayerInput component. When the character controller's Unity Input System component uses that PlayerInput component it should then use the InputAction setup. If that's not working it's probably worth posting on the Unity forums to see what could cause that not to work.

 

[tnpcook1]

Alrighty, if that's the intended function (multiple inputactionassets and playerinputs) then it almost certainly is

 

[tnpcook1]

an update on this for anyone else.
This was indeed a bug in Unity's new inputsystem.
It seems duplicating an input action asset can cause all sorts of weird pointer problems, including but not limited to-
Duplicate guids,
Implicit unserialized references pointing to separate objects (one playerinput was pointing to a constructed class, the other to an inputasset that was disabled.
InputActionAssets not re-enabling (because you aren't truely able to point at the one the input system is active in)
Weird priority-fighting, where two inputactionassets seem to conflict over reading an input.

This doesn't happen every time, but it can create some wild error-free conflicts with the class generation.

The solution, remove the playerinput class, and delete the inputactionassets being used on the objects that are failing (and any generated classes). manually make the new inputactionassets to be used, do not duplicate any Actions or classes, even if near-identical. Re-attach them to their various controllers and playerinputs.
If you can identify the ones you duplicated, this problem seems likely isolated to those, and the one you used as a source for the duplication.
This was dominantly a problem for our cinemachine integration, (The CinemachineInputProvider), and the standard PlayerInput. However, this even extended to causing bad references when instantiating a new class based on an inputactionasset at runtime.

Edit: This can also be caused by device mixing happening with the playerinput object. check your inputdebug and see if only certain players are being paired to devices (versus global, or all on each as needed.)
My workaround for this was to make extra inputschemes for each character (a unique name for the control scheme for each too, because the device register seems to conflict internally if not.)
In those control schemes, add each needed device and select "required".
You may need to enable/disable the input scheme for each of your action's bindings. However it doesn't seem to matter much. Once they receive the {Global} tag, it seems to circumvent the assignments happening in playerinput.