Replication

In order for a GameObject to be synchronized, you need to add a StrixReplicator component to it. This has to be done in advance, in editor, as all Replicator objects are registered with a registry that has to be shared between all clients. Do not add replicator components during runtime.

It is strongly recommended that the level of each player’s world be the same if objects will be replicated across them. Replicated objects are real objects in a player’s world, and therefore can interact with any objects within. Strix is made of non-dedicated servers, so take care to avoid desynchronization issues.

There are two types of replicators:

  1. Scene - Attached to scene objects

  2. Prefabs - Attached to prefab objects

Strix replicators by themselves only synchronize the instantiation and deletion of objects. No other state is synchronized. The replicated objects will be instantiated at world coordinates (0, 0, 0) by default.

Note

The position of replicas may be changed by other components (e.g., StrixMovementSynchronizer) before your script sees it.

Replicator Properties

StrixReplicator component has the following properties that you can configure on the Inspector.

Send Rate

int

The number of updates to the object’s properties every second.

Instantiable By

Anyone or Room Owner

Determines who instantiates replicas of this object on other clients.
When this is Anyone, all players in the room will instantiate a new replica of this GameObject on all other clients. This is useful for objects that are dynamically instantiated by a script.
When this is Room Owner, only the Room Owner will instantiate the replica, so there will be no more than one replica of this object on every other client. This is useful for objects like pick-ups that are statically placed in the scene.

Connection Closed Behaviour

Delete or Change Ownership

Determines the behaviour when a connection is lost.
The default is Delete, which will destroy the object when a connection is lost.
Change Ownership will instead select a new owner for the object and change its ownership to that owner.
Use this to keep objects alive until the room empties.

Sync Destroy

bool

Determines if this object will be destroyed when its original is destroyed.
The default is true. If false, the object will ignore deleted messages from the server.
This means that even if the original object is destroyed, its replicas will remain on other clients.
This may be required for smooth removal of objects from levels when players unexpectedly disconnect.

The following runtime properties are also shown on the Inspector. They may be useful for debugging or script access.

owner

UID (read only)

The owner of this object as represented by UID.
This property is accessible as ownerUid in scripts.

isLocal

bool (read only)

If true, this is a local (original) object, and the current client is its owner. If false, this is a replica object.
This is useful for determining if a script should modify or control this object.

Note

You will also notice Object Type and Network Instance Id properties on the Inspector. They are used internally by Strix for type and object identification.

StrixReplicator has some other properties for scripts (that are not visible on the Inspector). Following are the most useful ones among them:

isSync

bool (read only)

If true, this is a local (original) object that has one or more replicas (on other clients).

ownerUid

UID (read only)

The owner of this object as represented by UID.

roomMember

CustomizableMatchRoomMember (read only)

The owner of this object as represented by a CustomizableMatchRoomMember object.

Synchronization

In order for an object’s state to be synchronized you have to add StrixBehaviour scripts to the object.

See Variable Replication.

RPCs

Replicators allow the use of Remote Procedure Calls for performing actions on remote clients.

See RPC.

Note

If your StrixBehaviour script is on an object with a replicator, you can access that replicator through the strixReplicator member in the script.