NetworkAnimator is messing up "Float" parameters values in Animator component.

[Xeynt]

Description

This occurs with the host player in the game, it is likely that the clients are affected but would like to solve it for the host first as I'm assuming it will also resolve any client issues.

It seems as if NetworkAnimator is overwriting changes made by my mob script:
animator.SetFloat("velocity", 0f);

For context, I'm setting animator.SetFloat on the host/server side in Fixed Update loop.

For some reasons NetworkAnimator overwrites the above line of code / SetFloat(); sometimes which causes my mobs to have their animation parameter "velocity" value to hold it's previous non-0 value, and visually it makes the mobs remain in their "walking" animation state while they are in their Idle behavior state (gameobject not moving physically).

This issue only occurs when there's a NetworkAnimator attached to the gameobject. When it is removed, the issue does not occur. Hence this is clearly a bug with the NetworkAnimator.

Reproduce Steps

1. Have an NPC mob move around the map with both an Idle and Move State.
2. In the Move State, use animator.SetFloat("velocity", x); <- This is runned in FixedUpdate
3. OnExitMoveState, use animator.SetFloat("velocity", 0f); to stop the character from playing it's walking animation. <- This is runned in FixedUpdate
4. Monitor the issue, sometimes NetworkAnimator does not interfere and the parameter "velocity" is set to 0 while in the "idle" state as it should be, while sometimes "velocity" is not zero in the idle state.

Expected Outcome

Network Animator should not overwrite my script setting the "velocity" parameter to 0 when the Mob shifts from Moving state to Idle state.

Screenshots

If applicable, add screenshots to help explain your problem.

Environment

• OS: Windows 11
• Unity Version: 6000.0.47f1
• Netcode Version: 2.4.2
• Netcode Commit: [e.g. https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/commit/ba418fa5b600ad9eb61fab0575f12fbecc2c6520]
• Netcode Topology: Client-Server (1 Player is the host/server)

Additional Context

[Valerionn]

I've encountered the same problem, though I set the float value each frame in a Coroutine, with a Host as well. I've investigated the relevant code, and understand where it comes from, though I don't know if my proposed fix has any side effects.

The relevant code is here: https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/blob/develop-2.0.0/com.unity.netcode.gameobjects/Runtime/Components/NetworkAnimator.cs#L90

How the Network Animator works

Linked above is the Network Update (PreUpdate) code that does the following:

1. Send all queued messages
2. Handle all Parameters Updates - when an Animator parameter changes, an update is sent which is then received by the client and the host, is put into m_ProcessParameterUpdates. For the host, this contains the updates from the last frame.
3. Handling those updates will set the animator's float value at some time: m_Animator.SetFloat(hash, newFloatValue); (even for the host/owner!)
4. Afterwards, the NetworkAnimator checks for parameter changes (as host/owner), comparing the values it potentially just set in the last step - if they're different (which they are not if they were just set), then an update message is queued.

The Bug (host-only, no clients connected)

1. Update function Frame 100: Parameter Velocity is set to 5 in user code
2. PreUpdate NetworkAnimator Frame 101: No new queued parameter updates, but parameters changed -> queue "Update Velocity to 5" update via network to everyone (including self)
3. Update function Frame 101: Parameter Velocity is set to 0 in user code
4. PreUpdate NetworkAnimator Frame 102: Send all queued messages (which arrives immediately for the host). Apply queued parameter update - change Parameter Velocity to 5. Check for Updates - Parameter is 5 (because we just set it), no new updates, don't do anything
5. Now Velocity=5, even though the user set it to 0 last

Potential Fixes

There are multiple ways to fix this, the easiest would be to simply not update the Animator's parameter on host side (specifically, don't update with ServerAuthority if we're server, and don't update for ClientAuthority if we're owner). Alternatively, it would be possible to simply not process the updates if we're the one responsible for the NetworkAnimator. Funnily enough, this already happens for client authorative NetworkAnimators: https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/blob/develop-2.0.0/com.unity.netcode.gameobjects/Runtime/Components/NetworkAnimator.cs#L1346
(but server authorative network animators always process all events - but I don't understand why?)

@NoelStephensUnity Since you wrote this code, maybe you have some more insights if there is a specific reason why it's necessary to call ProcessParameterUpdate even as the server for server-authorative NetworkAnimators?

I have changed this line locally to

            if (!isServerAuthoritative && !IsOwner || isServerAuthoritative && !IsServer)
            {
                m_NetworkAnimatorStateChangeHandler.ProcessParameterUpdate(parametersUpdate);
            }

and it seems to fix the problem - but I don't know if there are any side effects I cause with this fix?

[NoelStephensUnity]

maybe you have some more insights if there is a specific reason why it's necessary to call ProcessParameterUpdate even as the server for server-authorative NetworkAnimators?

It does seem like that would invoke that if you were running a host but not a server only instance, which would mean you could get a value re-applied parameter value applied one frame after already having set it... so it could be that adjustment you made is the best temporary fix (for now until #3586 is finalized).

I might just switch all of the NetworkAnimator RPC calls over to Universal RPCs and away from the legacy ClientRpc and ServerRpc... and while doing that make sure the server doesn't send to itself. There are some observer related fixes I need to add anyway which could be part of that pass.

Regarding the value on the server side

• Update function Frame 100: Parameter Velocity is set to 5 in user code
• PreUpdate NetworkAnimator Frame 101: No new queued parameter updates, but parameters changed -> queue "Update Velocity to 5" update via network to everyone (including self)
• Update function Frame 101: Parameter Velocity is set to 0 in user code
• PreUpdate NetworkAnimator Frame 102: Send all queued messages (which arrives immediately for the host). Apply queued parameter update - change Parameter Velocity to 5. Check for Updates - Parameter is 5 (because we just set it), no new updates, don't do anything
• Now Velocity=5, even though the user set it to 0 last

I am wondering if on frame 103 or 104 (beyond the what the above issue outlined) the velocity is set finally set to 0 or is this being reset because of that ClientRpc issue?

[Valerionn]

I am wondering if on frame 103 or 104 (beyond the what the above issue outlined) the velocity is set finally set to 0 or is this being reset because of that ClientRpc issue?

Whenever I observed it, it would stay on Velocity=5 forever - that's how I detected the bug because in my turn based game, sometimes characters would keep moving forever, even when standing still, because I only set Velocity=0 once at the end of the movement, which was then overwritten with the value from the last frame, letting the character play the walk animation forever (until I started a new movement).

Setting the value to 0, and then setting it to 0 again in the next frame does keep the value at 0 forever, which I used as a workaround (for some boolean parameters).