This page is a work in progress and could be pending updates.
fusion | v1 switch to V2  

Script Execution Control


There are two main Attributes for controlling the relative script order in which Fusion executes SimulationBehaviour and NetworkBehaviour components:

  • [OrderBefore]
  • [OrderAfter]

These affect the script execution order of FixedUpdateNetwork() and Render() in SimulationBehaviour and NetworkBehaviour components.

[OrderAfter(typeof(NetworkTransform), typeof(MyOtherNetworkBehaviour))]
public class MySimulationBehaviour : SimulationBehaviour {


Back To Top

Relative Order Of Unity And Fusion Callbacks

  • FixedUpdate()
  • FixedUpdateNetwork()
  • Update()
  • Render()
  • LateUpdate()

Back To Top

Update() And LateUpdate()

As an alternative to using [OrderBefore] and [OrderAfter] to control Render() order, you may also make use of the standard Unity callbacks:

  • Update() will always execute BEFORE all Fusion Render() calls for all component types.
  • LateUpdate() will always execute AFTER all Fusion Render() calls for all component types.

Unity Script Execution Order can be used as usual to control the script order for Update() and LateUpdate(), as these are regular Unity callbacks.

NOTE: Unity's FixedUpdate() in most cases should not be used, as it is completely independent of Fusion's timing mechanisms and the rate at which Fusion calls Physics.Simulate().

Back To Top

Sorting Process

During recompiles and on game startup, All SimulationBehaviours are found in the assemblies and are sorted alphabetically with the exception of NetworkPhysicsSimulation3D and NetworkPhysicsSimulation2D.

First each SimulationBehaviour is then checked for [OrderBefore] or [OrderAfter] attributes; if neither exist on the class, then parent classes will be searched recursively and the attributes of the closest parent with either of these attributes will be used. Then all SimulationBehaviours are then sorted to generate a deterministic order which satisfies all OrderBefore and OrderAfter attributes.

N.B.: Any number of [OrderBefore] and [OrderAfter] types can be specified. If they create a conflict that cannot be resolved, the Debug Log will show an error indicating which scripts are in conflict.

NetworkPhysicsSimulation3D and NetworkPhysicsSimulation2D are initially sorted to be after all other alphabetized SimulationBehaviours. To execute scripts after either of these two, they will have to explicit be instructed to do so using the [OrderAfter] attribute.


Back To Top


If a derived Behaviour has no [OrderBefore] or [OrderAfter] attributes, it will inherit ordering from its base class by default. However, if the derived class declares either an [OrderBefore] or [OrderAfter] attribute, then all order attributes on the parent class will be entirely ignored.

N.B.: Ordering attributes on base and derived classes therefore are NOT additive.

Back To Top

Simulation Inclusion

The [SimulationBehaviour] attribute can be used to restrict execution of FixedUpdateNetwork() to:

  • only specific stages (Resimulation or Forward); and / or,
  • specific peer modes (Server / Host / Client).
  Stages = SimulationStages.Forward,
  Modes  = SimulationModes.Server | SimulationModes.Host

Back To Top

Fusion Script Execution Inspector

The Fusion Script Order window can be opened from the menu Fusion > Windows > Script Execution Inspector. This will show in which order and in simulation stages the various scripts will be executed.

N.B.: Script execution is controlled by these attributes:

  • [SimulationBehaviour]
  • [OrderBefore]
  • [OrderAfter]

The Fusion Script Execution Inspector window is only for visualizing the results of these attributes. Attributes must be altered in scripts to make changes.

To Document Top