Network Replication¶

For Pro 2.6+ and Lite 1.4+ For older versions, see the Networking Legacy Guide.

Network replication can be configured for state machine actor components. On initial replication state machines replicate their current states. Afterward they are kept in sync by replicating transitions.

Replication in Logic Driver is reliable and most actions will replicate in the same order they executed in across all connections.

Video¶

This video is based on an older version of networking, however it is still relevant. The following properties referenced in the video have been renamed.

NetworkTransitionConfiguration is now StateChangeAuthority.
NetworkStateConfiguration is now NetworkStateExecution.

Connections and Actions¶

Replication is generally automatic, but there are some considerations to be aware of.

Manual commands that instigate replicated actions should only be called from the state machine component, not the state machine instance.
1. Calling LoadFromState or LoadFromMultipleStates is an exception and should be done from the SMInstance.
2. Calling SetActive or SwitchToLinkedState is an exception and should be done from the state instance.
When a component's state machine initializes it will always be done on the server first. The instance is then replicated to clients and the clients will initialize their state machine if configured to.
Server machines where the remote role is autonomous won't start broadcasting RPCs until the owner has connected. This should ensure the owning client receives all RPCs and that the state machine won't start until a connection is established.
RPCs will always be sent to the owning client, but may not be sent to simulated proxies unless configured to do so.

The following tables summarize when an action will execute and if it is allowed to:

Action invoked from the server¶

Action	Client(s)	Server	Requires State Change Authority
Initialize	Initializes on instance replication	Executes immediately	No
Start	Executes in order	Executes immediately*	No
Stop	Executes in order	Executes immediately*	No
Shutdown	Executes in order, null instance replicated	Executes immediately*	No
Load States	Executes as part of initial sync	Executes immediately	No
Transition taken	Executes in order	Executes immediately	Yes
State manually switched	Executes in order	Executes immediately	Yes

Action invoked from the owning client¶

Action	Client	Server	Requires State Change Authority
Initialize	Initializes on instance replication	Executes in order	No
Start	Executes immediately*	Executes in order	No
Stop	Executes immediately*	Executes in order	No
Shutdown	Executes immediately*, null instance replicated	Executes in order	No
Load States	Executes immediately	Executes as part of initial sync	Yes
Transition taken	Executes immediately**	Executes in order	Yes
State manually switched	Executes immediately**	Executes in order	Yes

* If the command was initiated from a location that does not have state change authority it will not execute until the authority broadcasts the change.

* *If Wait for Transactions from Server is set, then the actions will execute in order after the server broadcasts them.

Loading Saved States¶

Loading states works as normal and should be done after the state machine is initialized but before it has started. Loading states is called from state machine instance, and can be done from either the client (providing it has state change authority) or from the server.

Lifecycle Management Best Practices¶

Ideally the server should be responsible for initializing and shutting down a state machine. If Initialize on Begin Play is used then you don't have to worry about initializing the state machine manually. In most cases you won't have to call Shutdown either.

Client Initialization¶

It's possible to manually initialize and start clients as long as you wait for the initialization event to be replicated.

Uncheck Initialize on Begin Play and bind to the component event OnStateMachineInitializedEvent.
Manually call Initialize().
Call Start() from the event you bound. It is important call Start after the initialize event fires.
- Keep in mind the initialize event Instance parameter is for the SMInstance, not the component. When you call Start it needs to be from the component.

Dynamic State Machine Creation¶

If you need to change the context or the state machine class there are extra steps involved to ensure it is replicated correctly.

This should always be done from the server.

Option 1 - Replace the Entire State Machine Component¶

The best way of doing this is to completely destroy the component and add it back in.

Components have a Component to Copy property exposed on spawn that can be set, which internally calls CopySettingsFromOtherComponent so existing settings can be maintained.
After adding the component you can initialize it again.

In the example below there is a DefaultNetworkSettings component which is available to easily edit from the actor, but is never initialized. This is passed to Add State Machine Component so its settings can be copied. DynamicNetworkComponent is a variable that gets created at run-time and is actually used.

Option 2 - Re-Initialize the Component¶

Alternatively, from the component call Shutdown, then Initialize.

While testing has shown this to be successful, this is not the recommended solution because the internal state machine instance is replicated via standard replication. There may not be a guarantee that the variable is replicated within the correct sequence.

Configuration¶

Under the Component Replication category of components you can configure the replication settings.

Component Replicates

Component Replicates must be checked for replication to work. This is also required for variable replication and making remote procedure calls.

/images/Network/NetworkSettings.jpg

State Change Authority ¶

Configure which domain should determine the active states. This includes all primary commands such as Start and Stop, manually activating states, and transition evaluation. It is recommended to either use Client or Server for an authority. Client and Server is not supported and the client or server may conflict on when a state should transition or not.

If the server performs a command it will then replicate to all applicable clients.
If a client performs a command it will then inform the server which will replicate down to all applicable clients.

Network Tick Configuration ¶

Configure which domain you want the state machine to tick in. For accurate time tracking and executing state updates ticking needs to be enabled.

Network State Execution ¶

Where general state logic will execute. This includes On Begin, On Update, and On End.

Include Simulated Proxies ¶

Include simulated proxies instead of just autonomous proxies in RPC broadcasting and state execution. This can also allow actors not possessed by a player controller to execute state logic. If this setting is unchecked then simulated proxies will not receive any RPCs from the server. Some variables, such as the state machine instance, will still replicate.

Replicated Initialization Mode ¶

Allow either single threaded or multi-threaded initialization on proxies. This occurs once proxies have received the replicated state machine instance variable.

Wait for Transactions from Server ¶

If a client executes a command or evaluates that a transition can be taken it will always inform the server. By default it will continue execution immediately and disregard the server update when it receives it. If this option is checked the client will instead wait for the server's update before continuing execution. One benefit to this is if you need to read accurate server time in the client.

Calculate Server Time for Clients ¶

Calculate the server time spent in states when NetworkTickConfiguration is set to client only. This only impacts the client value of GetServerTimeInState and has no effect if the server is ticking.

Get Server Time in State

GetServerTimeInState is an available method under state classes.

When true and the server is not ticking, it will take a measurement from the timestamp of when the state first started compared to when the server received the request to end the state.

If only using auto-bound events, or the state machine is being manually updated, this may not be necessary and disabling could increase accuracy.

Net Update Frequency ¶

Configure the maximum ticks per second RPCs should be processed and sent. Logic Driver will automatically pack consecutive transitions together into a single call.

Always Multicast ¶

Force multicast calls to all simulated proxies even if Include Simulated Proxies is unchecked. This is primarily to support legacy behavior, but may be useful if you want simulated proxies to have the correct state, but don't want them to execute any logic.

Manually Determining Client or Server Domains¶

If using Client and Server you may want to check in the graph which domain you are running under. The best way to do this is use methods Unreal Engine provides, such as HasAuthority. This requires an actor to do this. If your context is an actor you could read this information from there.

Variable Replication and RPCs¶

State machine blueprints support replicated variables and remote procedure calls when used in a replicated state machine component. If the state machine is being used as a state machine reference then Can Replicate as Reference needs to be checked under the state machine blueprint's class defaults.

Component Replicates must be checked to make any RPCs. If you only need to make RPCs and do not need the state machine to replicate otherwise, you may be better off defining your RPCs outside of the state machine and disabling Component Replicates.
Can Replicate as Reference is false by default so as not to add unnecessary network overhead when using state machine references.

Custom Node Classes

Custom node classes do not support variable replication or RPCs.