Repository navigation
Dedicated server: mixed-authority NetworkObject is removed from NetworkTransformUpdate, so its owner-authoritative NetworkTransform never updates server-side #4159
Description
Description
On a dedicated server (NetworkManager.StartServer(), i.e. IsServer && !IsConnectedClient), the server's copy of an owner-authoritative NetworkTransform never updates when the same NetworkObject also carries one or more server-authoritative NetworkTransforms on child objects. The owning client keeps sending state, the server receives and interpolates it, but the transform is never written — it stays at the position given at connection approval for the lifetime of the object. A host with the identical prefab is unaffected.
Root cause (traced in 2.13.2 source and confirmed by reading the registry at runtime, details below): NetworkManager.NetworkTransformUpdate — the collection that drives non-authority OnUpdate(), which is the only code path that applies an interpolated position to the transform — is keyed per NetworkObject with no reference count. Every NetworkTransform.InternalInitialization calls:
if (CanCommitToTransform) m_CachedNetworkManager.NetworkTransformRegistration(NetworkObject, forUpdate, false); // removes the whole NetworkObject
else m_CachedNetworkManager.NetworkTransformRegistration(NetworkObject, forUpdate, true); // adds itSo on a NetworkObject with mixed authority, every authority-side transform's initialization removes the entire object, evicting its non-authority siblings. Spawn initialization runs in component order (root first), so the non-authority root adds the object and each authority-side child then removes it.
A host survives because NetworkTransform.InternalOnNetworkPostSpawn ends with:
if (!CanCommitToTransform && m_CachedNetworkManager.IsConnectedClient && SynchronizeState.IsSynchronizing)
NonAuthorityFinalizeSynchronization();whose InternalInitialization re-run on the non-authority root re-adds the object after the children evicted it. IsConnectedClient is false on a dedicated server, so that never runs there; and the finalize's only other caller, NotifyNetworkObjectsSynchronized, fires once at server start, never for a late-joining client's object. So the first block of that same method deliberately raises IsSynchronizing ("special case for client-server where a server is spawning an owner authoritative NetworkObject") and nothing on a pure server ever completes it.
Reproduce Steps
- Player prefab: root has a
NetworkTransformsubclass withOnIsServerAuthoritative() => false(owner authority). Add one or more child GameObjects each with a plainNetworkTransformleft atAuthorityMode = Server. (Ours: two owner-authoritative on root/child, eleven server-authoritative children used as replicated pose slots.) - Start a dedicated server with
StartServer()(notStartHost()), client-server topology. - Connect one client; its player object is spawned server-side with
SpawnAsPlayerObject(clientId). - On the client, move the player well away from the spawn point.
- On the server, read
client.PlayerObject.transform.position, and checkNetworkManager.NetworkTransformUpdate.ContainsKey(playerObject.NetworkObjectId).
Actual Outcome
- Server-side position stays at the connection-approval spawn position indefinitely (we measured
(0.00, 1.00, 0.00)while the client stood 110 m away). NetworkTransformUpdatedoes not contain the player NetworkObject (ContainsKey == false).- Client-side the owner-authoritative transform reports
CanCommitToTransform = trueand produces state each tick; server-side it reportsCanCommitToTransform = false,IsSpawned = true,enabled = true— willing to receive, butOnUpdate()never runs. - Remove the server-authoritative children (or run the same prefab on a host): position tracks correctly.
Expected Outcome
The non-authority root should remain registered for OnUpdate() regardless of how many authority-side sibling transforms share the NetworkObject, on a dedicated server exactly as on a host.
Screenshots
N/A — runtime readouts above.
Environment
- OS: Windows 11 Pro
- Unity Version: 6000.3.22f1
- Netcode Version: 2.13.2 (registry)
- Netcode Commit: n/a (registry package)
- Netcode Topology: Client-Server, dedicated server (
StartServer) — not reproducible on a host
Additional Context
Two things we ruled out while tracing it, in case they save time: SynchronizeState.IsSynchronizing is not what blocks reception — it reads True on the server before and after the workaround and no stage of the receive path (TransformStateUpdate, OnNetworkStateChanged, ApplyUpdatedState, UpdateInterpolation) gates on it; and setting the serialized AuthorityMode to Owner on the root changes nothing, since CanCommitToTransform derives from IsServerAuthoritative().
Workaround we are shipping, in our NetworkTransform subclass — it re-runs the finalize on a server that is not also a client, which re-registers the object via InternalInitialization:
protected override void InternalOnNetworkPostSpawn()
{
base.InternalOnNetworkPostSpawn();
var networkManager = NetworkManager;
if (networkManager == null || !networkManager.IsServer || networkManager.IsConnectedClient)
return;
if (CanCommitToTransform)
return;
// NetworkTransform.InternalOnNetworkSessionSynchronized is NonAuthorityFinalizeSynchronization()
// followed by an empty NetworkBehaviour base, so this is the finalize and nothing else.
base.InternalOnNetworkSessionSynchronized();
}It works, but only for transforms of a type we control — a plain NetworkTransform set to owner authority on such an object is still evicted. A reference count on NetworkTransformUpdate (or registering per transform rather than per object) would fix it at the source; alternatively the post-spawn finalize could run for a non-connected-client server too, since its first block already targets exactly that case.
Activity
NoelStephensUnity commentedon Sep 21, 2026
Hi @Laumania,
I think there might be something else "a-foot" here.
The removal of NetworkTransform instances for updating interpolation on the authority side is for performance purposes (i.e. no reason to invoke a method specific to interpolation when you are the authority instance).
Authority removes itself from the update but then registers itself for the network tick update which is when it checks for and sends any deltas on the transform.
It does not invoke OnUpdate or OnFixedUpdate as those are non-authority side only methods that handle interpolation.
If you are placing authority script/logic to control the motion of an object within OnUpdate or OnFixedUpdate, then that would indeed cause issues as those do not get invoked on authority instances.
You can resolve this issue by overriding OnInitialize and for the child authority instances that need to move around you can register for any specific NetworkUpdateStage where you will need to make your NetworkTransform derived child class implement the
INetworkUpdateSysteminterface (i.e. NetworkUpdateStage.Update).However, before you do that... I have some questions that could change my mind about the above potential solution:
Laumania commentedon Sep 21, 2026
Hi @NoelStephensUnity
Thanks for the reply. I have since changed the architecture of how I do this, so its not a problem anymore for me, but still might be a "bug".
It was a ragdoll system that was located under the player, but owned/controled by host. However, its changed so its by it self and host controlled.
Anyway, this was a bug identified by Claude (AI), so I will include his response here below in case it makes it more clear what the problem was, or you can just close this issue, its fine too.
Claude's response:
NoelStephensUnity commentedon Sep 21, 2026
Right. That would make more sense.
Let me look at that area and get a fix in for that as it needs to gate on removal if the root or a parent above it has an inverted authority motional model from the children.
NoelStephensUnity commentedon Sep 24, 2026
@Laumania
The fix for this should land in the next 2.x.x and 3.x.x versions of NGO. 👍
Laumania commentedon Sep 25, 2026
Awesome! Thanks for quick response and fix :)