Send Priority

Overview

Send Priority gives control over how often a NetworkObject is sent. Each object has a priority value that determines how many ticks pass between sends:

• A priority of 1 means the object is sent each send tick.
• 2 means the object is sent every other send tick, resulting in a send rate of SendRate/2.
• 3 means the object is sent every third send tick, resulting in a send rate of SendRate/3, and so on.

Objects use a priority of 1 by default, so every NetworkObject is updated each send tick unless a different priority is configured.

Lowering the send rate by raising the priority value reduces bandwidth for an object at the cost of less frequent updates.

Send Priority complements Interest Management: Interest Management decides whether a player receives updates for an object at all, Send Priority decides how often.

Per Player Priority

It is possible to adjust the send rate of an object to a specific player. This can be used for instance to adjust the priority of an object based on the distance to the player, providing an additional way to reduce bandwidth for far away objects besides hiding the object using Area Of Interest.

Per-player priority overrides the object's default priority of 1 for that specific player. Players without a per-player priority set continue to use the default priority of 1.

To set the priority for a specific player call:

C#

NetworkObject.SetPriority(PlayerRef player, int priority)

Each client is in control of the send rate of objects it receives. It is only valid to call SetPriority with the local PlayerRef (NetworkRunner.LocalPlayer).

To clear the priority (the object returns to the default priority of 1, sending every send tick) use:

C#

NetworkObject.ClearPriority(PlayerRef player)

High Send Priority and Jerky Motion

Raising the send priority widens the time between an object's updates. Once that gap exceeds NetworkProjectConfig.Simulation.ObjectInactivityThreshold (in seconds, default 0.251), interpolation for the object stops and its motion becomes visibly jerky.

ObjectInactivityThreshold exists to distinguish between two kinds of update gap, which need opposite handling:

• A slowly updating object. The object was moving during the gap, so interpolating between the two snapshots is correct and produces smooth motion.
• An inactive object becoming active. Objects that stop changing have no updates sent, so interpolation effectively stops. When new state eventually arrives, resuming interpolation from the stale snapshot would result in a jump. Instead, Fusion shifts the stale snapshot closer to the new one in time, so the object holds its position and starts moving from there.

So to use low update rates effectively, ObjectInactivityThreshold must be tuned so that objects with high priority values still fall into the first category above. If an object's regular update interval exceeds the threshold, every update is misclassified as waking from inactivity: the object holds its old position and jumps on each update.

Choosing a Threshold Value

The time between updates is approximately priority / send rate, but real gaps run noticeably larger due to send schedule aliasing and network jitter (a nominal 250ms interval has been measured at over 310ms). As a rule of thumb:

ObjectInactivityThreshold = 2 * priority / send rate

Where priority is the highest priority value used on any moving object, as the threshold is global.

For example, priority 4 at a 16Hz send rate gives 0.5 seconds. If the result is below the default, keep the default - an unnecessarily high value delays inactivity detection, restoring the jump artifact for objects that genuinely stopped changing.

The setting is not exposed in the inspector and is adjusted in code before starting the NetworkRunner:

C#

NetworkProjectConfig.Global.Simulation.ObjectInactivityThreshold = 0.5f;

To verify a value, enable the SendPriority trace channel via the Trace Channels field in the NetworkProjectConfig inspector. Each gap exceeding the threshold logs ObjectInactivityThreshold exceeded: 0.3125 >= 0.251. If these messages appear continuously for constantly changing objects, raise the threshold above the largest logged gap.