The maximum number of concurrent connections is limited to 100 on a Type 0 instance, but no other limits are imposed. The “Max 25 rooms” is a rough estimation of the maximum number of rooms that can be created while keeping good performance in a typical game.

The actual number of rooms that can be created while keeping good performance depends on various factors such as the number of replicated objects in a scene. Exceeding an appropriate number of rooms may degrade your game’s performance and cause some problems with game play. So, Strix Cloud allows you to limit the maximum number of rooms per room server instance in your game titles. This limit is not a fixed value, and you can set any number that best fits your game. You can set a number larger than 25 for a Type 0 instance (and its default is 100 rooms). When the limit specified by you is reached, it becomes impossible to create more rooms.

• If multiple different game titles share the same server, when the load for a particular game title gets too high, the other game titles will be affected.
• If clients from different game titles join the same room, there will be trouble processing the replication and synchronization. This is because some information such as the type IDs of network objects becomes inconsistent, or the settings of various STRIX components become misaligned. To avoid this, you will need some control over the clients of different game titles to prevent them from joining the same room.

You can downgrade or upgrade your instance spec at anytime. However, please be aware that your server will need to be restarted upon doing so.

You can get an estimate of the total number of rooms that currently exist by searching for rooms using SearchRoom with the limit property set to a number greater than the number of rooms you want to search. You can then use this information to calculate the total number of rooms found.

By running this process, you may be increasing the load on your server. We recommend that you impose restrictions such as making this a debugging function so that only administrators can use it.

By adding up the number of participants in each room (the memberCount property), you can get a rough estimate of the actual number of connections that exist.
However, if there are a large number of rooms present, rooms may be created, deleted, or people may join or leave during your calculation, so consider the resulting number an approximation.

If you need to manage an application by a group of people, you can do so by creating a shared account for the group. However, shared accounts often cause security problems, so please be very careful if you do.

The fees of Strix Cloud consist of three separate charges: instance usage fees, instance management fees, and the data overage fees. Among them, instance usage fees and the data overage fees are not charged for stopped instances. However, instance management fees are charged even for a stopped instance if it is a paid instance.

Server instances of Strix Cloud are designed to allow stable operation even if it is run continuously for long periods of time. You don’t need to restart it periodically. Of course, if you make periodical restarts during the operation, it will run more stably. Strix Cloud, however, has no function to do so, and you need to do it manually.

Please note that restarting a server instance may be required if you change the number of room servers or their configurations. Restarting a server instance may also be required when a server’s load gets too high and the operation becomes unstable. To avoid such cases, you should limit the number of rooms or the number of messages per second appropriately for your game title.

STRIX supports the OAuth client type of public and is based on the native application profile. It also assumes the use of authorization code grant (though you can use other grants such as the client credentials grant, if necessary, based on your client program design.)

You need a server-side setup to use the token authorization. When using Strix Cloud, check the Authorization enabled checkbox on the options page of the application dashboard. Also specify in User Resource Url the URL of the endpoint of the “service to provide user’s identification information” (such as the UserInfo endpoint of OpenID Connect) of the resource server. The format of the identification information as a protected resource is assumed to be a JSON object (like the openid schema of OpenID Connect) and to contain a “user ID” (such as "sub" claim) and a “user name” (such as "name" claim).

The actual OAuth flow will be as follows:

(1) The game program starts the platform’s standard web browser to access the authorization endpoint of the authorization server to have the resource owner (i.e., the player) receive an authorization code.
(2) The game program receives the authorization code and accesses the token endpoint of the authorization server as an OAuth client to receive an access token.
(3) The game program passes the access token to the SDK. (When using Strix Unity SDK, set it to StrixNetwork.instance.authorizationAccessToken. When using Strix Unreal SDK, specify it as an argument of the InitializeStrixNetworkWithHttpAccessToken function.) Then, the token will be transferred to STRIX servers during the server connection.
(4) STRIX servers use the token to access the resource server as an OAuth client to receive the player’s identification information which is a protected resource (from the viewpoint of OAuth).

With that, the OAuth flow finishes, but the STRIX server will issue STRIX’s own client authentication token that is used for client authentication after that. Moreover, parts of the identification information received from the resource server (i.e., the user name and the user ID) will be automatically set to room member properties when a client (player) joins a room.

As an example, a calculation of the amount of communication data for synchronization in a room with 50 clients is as follows:

When a client sends a message, the server sends the message to 50 clients, meaning it sends 50 messages total. If each of the 50 clients sends a message, the server receives 50 messages and sends the total of 50 × 50 = 2500 messages. This value multiplied by the number of messages a client sends in a second gives the number of messages from a server in a second. You can estimate the amount of data per second from the server by multiplying it by the data size per message, by using the formula “50 × 50 × (messages per second per client) × (data size of a message)”.

The server configuration parameters in question limit the maximum of these values, so they can effectively cap the amount of data per second.

The size of a message depends on the contents. Considering a message from a text chat occupies the number of bytes of the chat text string (in UTF-8) plus a header (usually from 30 to 40 bytes) gives you a good estimation.

Replication by the StrixReplicator components or movement synchronization by the StrixMovementSynchronizer components generate messages, and they are included in the amount of data for calculating the data overage fees. StrixMovementSynchronizer sends a message during the period of time specified through SyncPeriodMin and SyncPeriodMax, and the data for movement synchronization occupies the majority of data in a typical game.

Accesses from the game clients to the master and room servers use a communication protocol that is different from web protocols such as http/https, and they can’t go through ordinary http/https-dedicated proxies. You will need a special proxy that transparently passes the TCP connections. It is recommended to use so-called “opening ports” technique instead if you need to access from behind a firewall.

If you choose WSS (Secure WebSocket) as the communication protocol, however, a relatively new proxy may be usable if it supports the wss protocol. Please consult your proxy’s specifications.

An IP address is assigned dynamically when a server instance starts up. It may also be changed upon restarting. Please consider there are no specific IP addresses that server instances of Strix Cloud use.

In Strix Cloud, it refers specifically to the number of clients that connect to a server instance.

Beginning with Strix Unity SDK version 1.5.0, builds for HTML5/WebGL platforms are supported. You will need to update the server configuration and several lines of script to run an existing STRIX client on WebGL platforms. Please consult the documentation for details.

Let’s consider the case when the lead player creates a room and then invites their friend players to join the room, using a function of your own user management server (which is separate from STRIX).

The information needed for identifying a room uniquely is the primaryKey property of the room. In addition, the address (the IP address and the port number) of the room server is required for connecting to it. The lead player will need to get this information and then pass it along to their friends. Each friend will then use the information they received to call JoinRoom to join the room.

A more specific write up of the process is written below:

A room’s primaryKey property becomes available via StrixNetwork.instance.room.GetPrimaryKey() after creating the room.
The address of the connected room server is available via StrixNetwork.instance.roomSession.messageChannel.GetRemoteAddress().
By receiving these, each friend can use the StrixNetwork’s JoinRoom method to join the room.

Let’s assume that the information to display to players is stored in room properties.
You can get the room properties of a room using its primaryKey after connecting to the designated room server by its address taken from the invitation.

You can connect to the room server without joining a room, using StrixNetwork.instance.roomSession.Connect().
Then, you can obtain the room properties by specifying the room’s primaryKey in StrixNetwork.instance.roomSession.roomClient.Get().

When a predefined object (a GameObject prefab) is dynamically instantiated, if it has a StrixReplicator attached to it beforehand, the object is automatically replicated, and its replicas are created on other clients. At the same time, the values of the object’s properties that are subject to synchronization are also synchronized. Ordinary object initialization events (such as the Start callback in Unity) are executed when a replica is created, so any processing triggered by the automatic creation of the object is possible using these events.

On the other hand, if you require that notifications of dynamically created non-replicated objects (i.e., GameObjects that have no StrixReplicator attached) be made, STRIX itself has no such feature, unfortunately. Instead, clients can implement this feature by sending a custom message from the client that created the dynamic object to other clients using RPCs or message relay features.

StrixNetwork.instance.roomSession.roomClient has two events: RoomJoinNotified notifies when someone has joined a room, and RoomLeaveNotified notifies when someone leaves a room.

The Strix Unity SDK has an event to notify when a room owner changes. The event is available as StrixNetwork.instance.roomSession.roomClient.RoomOwnerChanged. Its event handler is suitable for the processing in question.

Instead of using the event handler, if you would like to check whether the owner has changed in the middle of an Update or a coroutine, you can do so by keeping the UID of the previous room owner and comparing it with the current room owner’s. Use StrixNetwork.instance.room.GetOwnerUid() to get the UID that represents the current room owner, and compare it to the UID of the previous room owner. Note that the UID is an interface, so you should not use the == operator and should instead use the Equals method as in StrixNetwork.instance.room.GetOwnerUid().Equals(previousRoomOwnerUid).

If we can assume that the client has authenticated a user and that only the identification of users is needed, you can set the user’s identity in the room member property called "name". If your title distinguishes a user name to be shown to players and a user ID to be used internally by programs, you usually store the user name in the "name" property and the user ID in a custom property that you define. The convention is to use "userId" as the name of the custom property for your purpose.

If you want the server to receive an authenticated user information, a token authentication scheme is available. That is, you run an external authentication server to issue an authentication token, the client passes it to the STRIX server, and the STRIX server gets the user name and user ID from the authentication server. Under this scheme, the user name and the user ID that the STRIX server gets from the authentication server are automatically set to the "name" room member property and the "userId" custom room member property, respectively.

Please refer to the Strix Unity SDK User’s Guide for details about the token authentication scheme. Please refer to the Strix Cloud User’s Guide on how to set up your servers to perform the token authentication in Strix Cloud.

You can use the StrixNetwork.instance.roomSessionClosed event in Strix Unity SDK. This event is raised when the room server connection is closed, but it can also be used to detect the case that the network has been disconnected.

When using this method, the RPC is executed on the room owner’s GameObject, regardless of the owner of the target GameObject (i.e., the client that instantiated the original GameObject).

When using Strix Unity SDK, if you want to send a message to the clients that are not in the same room as you, you need a separate server. For example, Strix Messenger server allows you to send messages regardless of joined rooms as well as to broadcast to a large number of clients.

However, STRIX allows you to call an RPC on a designated player, so you can manage the group membership on your client and call RPC repeatedly for each group member to simulate the feature if the number of players in a group is small.

When the owner of a GameObject leaves a room, e.g., by calling LeaveRoom, the original GameObject and its replicas are usually all destroyed. This behavior, however, can be changed by the syncDestroy field available on StrixReplicator.

Setting the syncDestroy field on a particular GameObject to false prevents the GameObject from being destroyed.
For example, if you set syncDestroy to false when you create a prefab in the Editor, the original GameObject instantiated from the prefab as well as all its replicas will not be destroyed.

Details follow.

(Behavior when going to background)

When a mobile app that uses STRIX goes to background, it is usually disconnected from the server. The time before the actual disconnection differs for the OS and its version, and if it is Android, also depends on the manufacturer or the model, but anyway it will be in a second to about 2 minutes. Under the case that there is a long delay, if the app becomes active again before the disconnection, it will escape from the disconnection and continue running.

If it goes to background and is disconnected from the server when in a room, STRIX considers it left the room. All of its replicas will be deleted from other clients when it is disconnected. The backgrounded device will handle events such as for leaving the room after returning (i.e., after becoming active).

(In case the room owner goes to background)

When a room owner goes to background, it is disconnected and considered left the room.

There is a server setting on Room Owner Migration. If it is disabled, the room is deleted as the room owner leaves the room, and other room members are kicked. If Room Owner Migration is enabled, when the room owner leaves the room, another member automatically becomes the room owner, and other members can keep playing. The client the room owner is migrated to is chosen by the room server. Please consider it is at random.

When a mobile app that uses STRIX goes to background, it is usually disconnected from the server and leaves the room. The time before the actual disconnection differs for the OS and its version, and if it is Android, also depends on the manufacturer or the model, but anyway it will be in a second to about 2 minutes.

Unity has a callback called OnApplicationPause, which is called when a mobile app goes to background or returns to active. You can use it to shorten the delay before leaving. Call LeaveRoom when the app goes to background so that it leaves the room without waiting for disconnection.

When getting back from background to active state, the client is not in a room and replicas have been deleted. It can’t just continue playing. You need to perform an appropriate handling such as joining the same room as before again or transit to another appropriate scene (such as the home scene).

An argument of OnApplicationPause of Unity indicates whether going to background or returning. Consult your Unity documentation for details.

The synchronization is performed in a fixed frequency (specified by the sendRate property) when using the variable synchronization. However, it doesn’t send the values of all variables every synchronization tick, but it sends only variables whose values have been changed. As a result, both the variable synchronization and the RPC behave like sending information only when states have been changed, and there should be no significant difference in the traffic.

“How to Improve Performance” in the user’s guide says the RPC is more performant than the variable synchronization, but it is not on the traffic but is on the internal processing inside the SDK.

The variable synchronization has some overhead to detect whether a value of a variable has been changed. This overhead usually doesn’t matter, but if you have a lot of synchronized variables, and most of them rarely change, it could become measurable. If you cut down the synchronized variables and rewrite the codes to call RPC as a part of processing user inputs, for example, it may be possible to lighten the overhead.

Please note that, in Strix Unity SDK, changes to the values of the properties of StrixMovementSynchronizer are not synchronized automatically. You need to change them not only on the owner (the original object) but also on replicas when you change the property values.

If you stop all your (master and room) servers, clients become unable to login and all connections fail. You could show a “maintenance notice” triggered by a connection error to the master server, but it will be difficult to distinguish the case from other errors (such as a temporary network failure that retries will likely connect).

If you stop all your servers, all players are disconnected, but it is again difficult to distinguish from other disconnections, and such a “sudden disconnection” can be undesirable in some games.

So, we need to say it is not easy to enter to a maintenance state only using STRIX server functions.

However, you need a specific development environment to develop a console game title, which is not included in Strix Unity SDK. You need to get one from the appropriate platform provider separately.

Unity destroys GameObjects in the scene when finishing a play, and it reports the error in question if there were undestroyed GameObjects remained after the process. In general, it is often caused by instantiating a new GameObject when OnDestroy is being processed.

The entire error message will be:

Some objects were not cleaned up when closing the scene. (Did you spawn new GameObjects from OnDestroy?) The following scene GameObjects were found:
StrixNetworkManager

StrixNetworkManager is a GameObject that Strix Unity SDK uses internally. When a C# script refers to a singleton instance of StrixNetwork (StrixNetwork.instance), StrixNetworkManager is instantiated. It is usually destroyed at the end of a play together with the singleton instance of StrixNetwork.

When StrixNetworkManager is listed at the end of this error message, it is likely that the error in question is caused by an access to StrixNetwork.instance from inside a callback such as OnDestroy() that is called at the end of the play. You can avoid the error either by not referring to StrixNetwork in OnDestroy() or by performing any STRIX-related post-processing only after checking StrixNetwork.isInitialized returns true. (It returns true when the singleton instance of StrixNetwork is present. It returns false after it has been destroyed).

The value of MaxSpeed of the StrixMovementSynchronizer is the distance of movement in a second. Please set the MaxSpeed to the max speed of your GameObject.

Please also see a how-to article in Strix Unity SDK User’s Guide for adjusting movement synchronization parameters.

a) To update a room property value, you need to call the SetRoom method. Just writing a value into a class that Strix Unity SDK provides is insufficient to change the room property value that the room server holds. In particular, calling methods of StrixNetwork.instance.room, such as SetName(), doesn’t update the room properties.

b) Only the room owner can call the SetRoom method. If called by another client (player), it causes an error, (a failure handler is executed,) and the value is not changed.

c) There are cases that the name of a room property is specified as a string when setting or referring to its value (for example, when a set of room properties are represented as IDictionary<string, object> type). A wrong property name doesn’t cause any error in such cases (instead they are considered as a custom property of that exact name). You should check if the property name is correct, focusing on the following points:

• Cases are significant in property names. Presence and absence of spaces are, too. Please very cases are used correctly. (Note that all room property names that STRIX defines begin with a lower-case letter.)

d) Room properties have their data types. Some API accepts values of any type, but if you access a room property as a wrong data type, the access doesn’t work correctly, though no errors are detected.

• Please check the value is in a correct data type when setting a value to a standard property.
• Please check a correct data type is used when referring the value of a standard property.
• Please check the data type is consistent among setting and getting when accessing a custom property.

After connecting to the Master server and searching for a room by a method such as SearchRoom, when calling JoinRoom to join the found room, if you mistakenly specify the address (a host name or an IP address and a port number) of the master server instead of the room server, it may cause JoinRoom to become irresponsive. (In fact, the failure handler will be executed after about 30 seconds due to a timeout.)

There are several ways to pass the ID, but the use of room member property is recommended when the appearance of the player avatar is concerned. Define a custom property (such as "avatarId") and set an ID as the value of that property. Replicas can change meshes when they are created and when a property change event is triggered.

Let’s consider the case when the lead player creates a room and then invites their friend players to join the room, using a function of your own user management server (which is separate from STRIX).

The information needed for identifying a room uniquely is the primaryKey property of the room. In addition, the address (the IP address and the port number) of the room server is required for connecting to it. The lead player will need to get this information and then pass it along to their friends. Each friend will then use the information they received to call Join Room function to join the room.

A more specific write up of the process is written below:

You can obtain a room’s primaryKey property from the Id property of a Strix Room struct which you’ll be provided with by calling the Get Current Room function after creating the room. The lead player should also send the room server’s address that they specified when calling Create Room. By receiving this information, each friend will be able to connect to the room server by passing the room server address to the Connect To Room Server function and then specify the room ID on the JoinRoom function.

Please also read over a how-to article in the Strix Unreal SDK User’s Guide, which provides some related information.

Let’s assume that the information to display to players is stored in room properties.
After connecting to the designated room server by its address taken from the invitation, the room information will be available by searching for a room with the designated primaryKey. However, some C++ code is required to search for a room via a primaryKey.
Please refer to the how-to article in the Strix Unreal SDK User’s Guide on how to do this.

When a predefined object (an Actor) is dynamically spawned, if it has a Strix Replicator attached to it beforehand, the object is automatically replicated, and its replicas are created on other clients. At the same time, the values of the object’s properties that are subject to synchronization are also synchronized. Unreal Engine’s ordinary object initialization events (such as Event Begin Play) or STRIX’s synchronization events (such as On Sync Begin) are executed when a replica is created, so any processing triggered by the automatic creation of the object is possible using these events.

On the other hand, if you require that notifications of dynamically created non-replicated objects (i.e., Actors that have no Strix Replicator attached) be made, STRIX itself has no such feature, unfortunately. Instead, clients can implement this feature by sending a custom message from the client that created the dynamic object to other clients using RPCs or message relay features.

The Strix Notification Listener component has two events, Strix Room Join Notification Arrived and Strix Room Leave Notification Arrived. Strix Room Join Notification Arrived notifies when someone has joined a room, and Strix Room Leave Notification Arrived notifies when someone leaves a room.

The Strix Unreal SDK has an event to notify when a room owner changes. It is the Strix Room Owner Changed event of the Strix Notification Listener component. Its event handler is suitable for the processing in question.

If we can assume that the client has authenticated a user and that only the identification of users is needed, you can set the user’s identity in the room member property called "name". If your title distinguishes a user name to be shown to players and a user ID to be used internally by programs, you usually store the user name in the "name" property and the user ID in a custom property that you define. The convention is to use "userId" as the name of the custom property for your purpose.

If you want the server to receive an authenticated user information, a token authentication scheme is available. That is, you run an external authentication server to issue an authentication token, the client passes it to the STRIX server, and the STRIX server gets the user name and user ID from the authentication server. Under this scheme, the user name and the user ID that the STRIX server gets from the authentication server are automatically set to the "name" room member property and the "userId" custom room member property, respectively.

Please refer to the Strix Unreal SDK User’s Guide for details about the token authentication scheme. Please refer to the Strix Cloud User’s Guide on how to set up your servers to perform the token authentication in Strix Cloud.

The Room Context Closed event of Strix Notification Listener can be used.
This event is executed at certain timings such as when a room is deleted, when a player leaves a room, or when a player is kicked, but it is also executed upon disconnection from the network.

When using this function, the RPC is executed on the room owner’s Actor, regardless of the owner of the target Actor (i.e., the client that instantiated the original Actor).

Strix Unreal SDK allows you to join multiple rooms simultaneously using the channel feature, so you could create a room that all online players always join and send an RPC to all its room members. If you do so, however, please be aware that the capacity of the room caps the concurrent connections.

You could run a server separate from your STRIX game server to send messages. For example, Strix Messenger server allows you to send messages regardless of joined rooms as well as to broadcast to a large number of clients.

However, STRIX allows you to call an RPC on a designated player, so you can manage the group membership on your client and call RPC repeatedly for each group member to simulate the feature if the number of players in a group is small.

When the owner of an Actor leaves a room, e.g., by calling Leave Room, the original Actor and its replicas are usually all destroyed. This behavior, however, can be changed by the Should Receive Destroy Events property on Strix Replicator.

Setting the Should Receive Destroy Events property on a particular Actor to false prevents the Actor from being destroyed.
For example, if you set the Should Receive Destroy Events property to false when you define the Actor’s class in the Editor, the original Actor spawned from the class as well as all its replicas will not be destroyed.

The Blueprint functions of Strix Unreal SDK are defined in the UStrixBlueprintFunctionLibrary class. You can call these functions from C++, following the ordinary calling convention of the Blueprint functions. Also, most of the Blueprint functions have corresponding C++ API defined in the UStrixNetworkFacade class, and you can call them instead.

You can also define your custom messages and send and receive them via Message Relay API. Please refer to the Relay Message section in Strix Unreal SDK User’s Guide for details.

Details follow.

(Behavior when going to background)

When a mobile app that uses STRIX goes to background, it is usually disconnected from the server. The time before the actual disconnection differs for the OS and its version, and if it is Android, also depends on the manufacturer or the model, but anyway it will be in a second to about 2 minutes. Under the case that there is a long delay, if the app becomes active again before the disconnection, it will escape from the disconnection and continue running.

If it goes to background and is disconnected from the server when in a room, STRIX considers it left the room. All of its replicas will be deleted from other clients when it is disconnected. The backgrounded device will handle events such as for leaving the room after returning (i.e., after becoming active).

(In case the room owner goes to background)

When a room owner goes to background, it is disconnected and considered left the room.

There is a server setting on Room Owner Migration. If it is disabled, the room is deleted as the room owner leaves the room, and other room members are kicked. If Room Owner Migration is enabled, when the room owner leaves the room, another member automatically becomes the room owner, and other members can keep playing. The client the room owner is migrated to is chosen by the room server. Please consider it is at random.

When a mobile app that uses STRIX goes to background, it is usually disconnected from the server and leaves the room. The time before the actual disconnection differs for the OS and its version, and if it is Android, also depends on the manufacturer or the model, but anyway it will be in a second to about 2 minutes.

Unreal Engine has a class called Platform Game Instance. You can detect transition to and from the background state by using it (or its derived class) as the game instance. When an app goes to background, Application Will Enter Background Delegate is executed, and when it returns, Application Has Entered Foreground Delegate is.

You can use Application Will Enter Background Delegate to shorten the delay before leaving. Call Leave Room when the app goes to background so that it leaves the room without waiting for disconnection.

When getting back from background to active state, the client is not in a room and replicas have been deleted. It can’t just continue playing. You need to perform an appropriate handling such as joining the same room as before again or transit to another appropriate scene (such as the home scene), utilizing Application Has Entered Foreground Delegate.

Consult your Unreal Engine documentation for details on Platform Game Instance.

The synchronization is performed in a fixed frequency (specified by the Ticks Per Second property) when using the variable synchronization. However, it doesn’t send the values of all variables every synchronization tick, but it sends only variables whose values have been changed. As a result, both the variable synchronization and the RPC behave like sending information only when states have been changed, and there should be no significant difference in the traffic.

“How to Improve Performance” in the user’s guide says the RPC is more performant than the variable synchronization, but it is not on the traffic but is on the internal processing inside the SDK.

The variable synchronization has some overhead to detect whether a value of a variable has been changed. This overhead usually doesn’t matter, but if you have a lot of synchronized variables, and most of them rarely change, it could become measurable. If you cut down the synchronized variables and rewrite the codes to call RPC as a part of processing user inputs, for example, it may be possible to lighten the overhead.

In Strix Unreal SDK, properties of Strix Movement Synchronizer are synchronized, so those of replicas are changed when you change property values of Strix Movement Synchronizer of the owner (the original Actor). On the other hand, if you change the property values on a replica, they are not reflected to the owner. You should always change property values on the owner.

If you stop all your (master and room) servers, clients become unable to login and all connections fail. You could show a “maintenance notice” triggered by a connection error to the master server, but it will be difficult to distinguish the case from other errors (such as a temporary network failure that retries will likely connect).

If you stop all your servers, all players are disconnected, but it is again difficult to distinguish from other disconnections, and such a “sudden disconnection” can be undesirable in some games.

So, we need to say it is not easy to enter to a maintenance state only using STRIX server functions.

However, you need a specific development environment to develop a console game title, which is not included in Strix Unreal SDK. You need to get one from the appropriate platform provider separately.

Also, you need dedicated STRIX libraries for consoles provided by us, in addition to the development environments from the platform providers. The libraries are not included, however, in the Strix Unreal SDK that is available for download on Strix Cloud website. Please contact our STRIX support team if you need them.

This is normal behavior.

The connection to the master server is automatically disconnected if the client sends no request for a certain period of time, and it is automatically reconnected when the client sends the next request. The Is Master Server Connected function returns false when Disconnect Master Server is used to disconnect or when the SDK automatically disconnects on its own.

This automatic disconnection-reconnection cycle doesn’t affect the behavior of functions that communicate with the master server. You don’t need to check the connection status using Is Master Server Connected before accessing the master server.

You may experience the following symptom: after starting the game program, the steps to join a room, play a game, and then leave the room work as expected the first time around, but an attempt to join another room afterwards fails with an error “Room connection with id N already exists”. It occurs under a condition that the client tries to connect to a room server, but the channel has been connected to a room server already.

The Leave Room function only makes it so that a client leaves a room. After leaving a room by calling the Leave Room function after the first game is finished, the room server connection is internally kept in the Strix Unreal SDK. If the client directly calls Connect To Room Server in order to join a second room, the error in question occurs. (Using a NodeRoom function instead of explicitly calling Connect To Room Server may cause an attempt to connect to a room server internally and may trigger the same error.)

The value of Max Speed of the Strix Movement Synchronizer is the distance of movement in a second. Please set the Max Speed to the max speed of your Actor.

Please also see a how-to article in Strix Unity SDK User’s Guide for adjusting movement synchronization parameters.

The UStrixReplicatorComponent::IsReplicating member variable is for use by Blueprints, and there is a separate getter function. Call the getter function UStrixReplicatorComponent::GetIsReplicating() to refer to this flag in C++ codes.

a) To update a room property value, you need to call the Set Room function. Just writing a value into a struct that Strix Unreal SDK provides is insufficient to change the room property value that the room server holds.

b) Only the room owner can call the Set Room function. If called by another client (player), it causes an error, (a failure callback is executed,) and the value is not changed.

c) There are cases that the name of a room property is specified as a string when setting or referring to its value (for example, when the Strix Property Map struct is used). A wrong property name doesn’t cause any error in such cases (instead they are considered as a custom property of that exact name). You should check if the property name is correct, focusing on the following points:

• Cases are significant in property names. Presence and absence of spaces are, too. Please very cases are used correctly. (Note that all room property names that STRIX defines begin with a lower-case letter.)
• Strix Unreal SDK provides some structs that you can access standard properties as their members, but their names as variables are different from the names of the properties that you represent in strings. For example, the room property to represent the name of a room has the name Name in the Strix Room struct, but it is "name" when represented as a string.

d) Room properties have their data types. Some API accepts values of any type, but if you access a room property as a wrong data type, the access doesn’t work correctly, though no errors are detected.

• Please check the value is in a correct data type when setting a value to a standard property.
• Please check a correct data type is used when referring the value of a standard property.
• Please check the data type is consistent among setting and getting when accessing a custom property.

After connecting to the master server, when you call the Connect To Room Server function to connect to the room server, if you mistakenly specify the address (a host name or an IP address and a port number) of the master server instead of the room server, it may cause the success callback to be executed apparently indicating a successful connection but succeeding API that uses room server functions to become irresponsive. (In fact, the failure callback will be executed after about 30 seconds due to a timeout.)

There are several ways to pass the ID, but the use of room member property is recommended when the appearance of the player avatar is concerned. Define a custom property (such as "avatarId") and set an ID as the value of that property. Replicas can change meshes when they are created and when a property change event is triggered.

If you experience this symptom, you can work around it by adding a C++ class (that does nothing) to your project, following the steps below:

1. Choose New C++ Class from New Class on the Content Browser.
2. Choose None for Choose Parent Class, then click Next.
3. Enter a name that is unused in your project (such as MyUnusedClass) in Name on Name Your New Class, then click Create Class. (No need to change defaults other than for Name.)
4. Wait for a while as C++ files are compiled.
5. Visual Studio IDE should start and open the C++ source file (MyUnusedClass.cpp). Wait until it and then close the Visual Studio (without editing anything.)
6. Terminate the Unreal Editor, too.
7. Start your Unreal Editor again, opening your project, and create the package again.

Once the above steps are performed, the error in question should disappear.