Send Rate is zero but server movement is still happening

It looks like this API is set up so that a send rate of 0 means "on demand".

If you're continually moving an object that's been set to, say, 10 network updates per second, those transform changes get recorded but not sent right away. Then, when the next 10 Hz window comes around, the latest value is picked up and sent across the network.

But if you've set this value to 0, then there's no regular process checking in on the transform value to send it at regular intervals. So transform changes could get missed entirely.

To prevent changes from not being replicated at all, if a NetworkTransform that's not scheduled for regular transform updates moves, Unity sends the message right away to ensure that change isn't lost.

Since the Unity docs say to use this for objects that don't move after being created, this should be rare:

Basically this should ensure that a late fix-up to its position after spawning isn't missed. Or if the object occasionally has to be swapped to a new location, you only pay overhead cost once on each teleport, rather than periodically as long as the object exists.

Based on the documentation quoted above, you should not set this value to zero on an object that moves continuously. As you observe, that can trigger an effectively unlimited send rate (say, once per display frame / Update() call), which could quickly eat into your bandwidth budget at high framerates.

This might be because your movement script doesn't specify where to execute the code, so when you input something, the code is executed on the server.

Make sure your movement code has an if(isLocalPlayer) check:

private void Update() { if (!isLocalPlayer) { return; //this checks if the code is not running on the local instance of the game // if it isn't, it stops executing what's next } //Your Code here }