InvalidCastException when NetworkAnimator removed from gameobject

[mrwillt1986]

This is being spammed hundreds of times a second when a network animator gets removed from a gameobject. The client in my game doesn't send the server any animation, so the networkanimator gets removed from the gameobject as there is no other way to disable the network animator.

InvalidCastException: Specified cast is not valid.
Unity.Netcode.Components.NetworkAnimator.__rpc_handler_1069363937 (Unity.Netcode.NetworkBehaviour target, Unity.Netcode.FastBufferReader reader, Unity.Netcode.__RpcParams rpcParams) (at <b7c09b1b80264f9da254262437a7e141>:0)
Unity.Netcode.RpcMessageHelpers.Handle (Unity.Netcode.NetworkContext& context, Unity.Netcode.RpcMetadata& metadata, Unity.Netcode.FastBufferReader& payload, Unity.Netcode.__RpcParams& rpcParams) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/Messages/RpcMessages.cs:77)
Rethrow as Exception: Unhandled RPC exception!
UnityEngine.Debug:LogException(Exception)
Unity.Netcode.RpcMessageHelpers:Handle(NetworkContext&, RpcMetadata&, FastBufferReader&, __RpcParams&) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/Messages/RpcMessages.cs:81)
Unity.Netcode.ClientRpcMessage:Handle(NetworkContext&) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/Messages/RpcMessages.cs:154)
Unity.Netcode.MessagingSystem:ReceiveMessage(FastBufferReader, NetworkContext&, MessagingSystem) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/MessagingSystem.cs:457)
Unity.Netcode.MessagingSystem:HandleMessage(MessageHeader&, FastBufferReader, UInt64, Single, Int32) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/MessagingSystem.cs:387)
Unity.Netcode.MessagingSystem:ProcessIncomingMessageQueue() (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Messaging/MessagingSystem.cs:407)
Unity.Netcode.NetworkManager:OnNetworkEarlyUpdate() (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Core/NetworkManager.cs:1536)
Unity.Netcode.NetworkManager:NetworkUpdate(NetworkUpdateStage) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Core/NetworkManager.cs:1468)
Unity.Netcode.NetworkUpdateLoop:RunNetworkUpdateStage(NetworkUpdateStage) (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Core/NetworkUpdateLoop.cs:185)
Unity.Netcode.<>c:<CreateLoopSystem>b__0_0() (at External/com.unity.netcode.gameobjects/com.unity.netcode.gameobjects/Runtime/Core/NetworkUpdateLoop.cs:208)

[NoelStephensUnity]

@mrwillt1986
Currently, Netcode for GameObjects does not support deleting a NetworkBehaviour derived component during runtime. This is a known issue (#2188). Could you describe what you are trying to accomplish by removing the NetworkAnimator during runtime? Perhaps I might be able to offer an alternate solution/approach.

[mrwillt1986]

Hi Noel, appreciate the reply.

So the local client runs his/her own animations and does not need to sync those animations with the server, as the server is running its own animations which then sync out to all other clients. As such, the local client needs to delete the networkanimator, while the server needs to keep it. This is attached to the player prefab, and it appears you cannot add the networkanimator after spawn either.

[NoelStephensUnity]

@mrwillt1986
This is indeed a tricky combination!
Due to the known issue (#2188), removing the NetworkBehaviour is not a viable option.
With that said...
I think you could use the connection approval process to spawn a unique player prefab for client(s) that do not use a NetworkAnimator and for those that do:

• Player Prefab-1 with NetworkAnimator: All instances of this will be synchronized via NetworkAnimator for all clients
• Player Prefab-2 without NetworkAnimator: All instances of this will handle animation locally.

You would then get the GlobalObjectIdHash value for both Player Prefabs and use those during the connection approval process. The client would provide its "client type" as part of the connection approval process and then, based on the type, the server would determine which prefab to use for the player connecting.

Does this approach sound like it would meet your project's needs?

[mrwillt1986]

Its going to be a real pain I have to admit, but if its all I have to work with then I can work on something that will work.

Do you know if Unity have plans to solve this in the near term?

[NoelStephensUnity]

@mrwillt1986
I am definitely pushing for this process, and this is what I told the user who filed issue #2188:

There are still ongoing discussions about certain areas within the SDK that could be improved and this issue is being added to the list of things that still need to be properly mapped out/discussed in order to determine the best approach. This means a fix for this is not likely going to happen in the next update (or two).

So, this is something I can't make a definitive ETA on as it really depends upon how these changes align with other targeted improvements being discussed and if there are any cross dependencies. I definitely am in favor of improving this area of code and will continue to help drive for a better solution.

[NoelStephensUnity]

If you want unique network prefabs server or client relative you can do this using the NetworkPrefabHandler to override the prefab to spawn. Review this project as an example of how to do this.

[joaovictoralencar]

@NoelStephensUnity To me, the main issue is related to not being able to "disable" the sync of the NetworkAnimator. I don't need to remove, but just stop syncing animations during a short period and then enable them back.

[NoelStephensUnity]

@joaovictoralencar
We already have a revamp of the NetworkAnimator in our near future update plans. This should include more control over the entire synchronization process so you could do something like just stopping the synchronization of animations and potentially stopping/controlling the synchronization of animations for specific clients.