Morpheus RPCs

RPC arguments can contain any number or type of replicated property which Unreal supports, again with the exception of non AMorpheusActor pointers.

Server RPCs

In Morpheus, any client can call any Server RPC on any AMorpheusActor. The RPC is handled on the server.

Checking bool AMorpheusActor::AuthoritativeClientCalledServerRpc() during the handler of a Server RPC will emulate standard Unreal RPC semantics, where only the authoritative client can call a Server RPC.

The server can also call a Server RPC itself, in which case it will be executed locally. The server may also use bool AMorpheusActor::ServerCalledRpc() during the handler of a Server RPC to determine whether it was executed locally.

Another useful function is ServerRPCCallerOwnsActor which accepts an AMorpheusActor*. This checks whether the actor is owned by the connection that made the current Server RPC request. This is useful for Singleton type actors that need an auth actor passed in to do their work.

There are also corresponding methods (with the same names) on UMorpheusActorComponent. Please note that if an RPC is called on the component, you should check these methods on the component directly, not the owning actor.

Using the caller connection

In some cases, you want to use the calling client connection in the RPC's implementation. A canonical example would be player spawning, which is usually implemented on a singleton actor, where the RPC uses the calling connection to determine which connection should have authority over the newly spawned actor.

You can do this in Blueprints by making the name of the Sender Required Rpc to end with SenderRequired but make sure to either set PopAfterNextRpc bool to true or manually pop the Rpc sender connection after calling the Sender Required Rpc.

An example of the blueprint usage of this would be something like:

Client RPCs

In Morpheus, the server or any client can call any Client RPC on any AMorpheusActor. The RPC is handled only on the authoritative client.

During the handler of a Client RPC, the client may use the method bool AMorpheusActor::ServerCalledRpc() to determine if the server called the Client RPC.

Checking bool AMorpheusActor::ServerCalledRpc() during the handler of a Client RPC will emulate standard Unreal RPC semantics, where only the server can call a Client RPC.

NetMulticast RPCs

In Morpheus, both the server and clients can call NetMulticast RPCs. All NetMulticast RPCs will be executed locally when called and then additionally, if executed from:

• the authoritative server: all clients with this AMorpheusActor in the foreground network level

• the authoritative client: the server and all clients with this AMorpheusActor in the foreground network level

• a non-authoritative client: nowhere else

During the handler of a NetMulticast RPC, you may use bool AMorpheusActor::ServerCalledRpc() to determine if the server called the RPC. This can be used on the clients to determine that the RPC was called by the server as opposed to another client, or on the server to handle the local execution of the RPC. Use it in conjunction with bool AMorpheusActor::IsOnClient() to handle these cases separately.

RPC Guarantees

The morpheus system has semantics and behaviour that may not be immediately obvious. This is a non-exhaustive list of semantics we offer for external developers to use as a reference, and for internal developers to refer to when making changes.

Morpheus offers some ordering guarantees in order to try and match some Unreal semantics. See this doc in the morpheus-core repository for more information on what these are and how we offer them. Because this repository is available to Improbable developers only, a subset of the doc relevant to Unreal development is exposed here:

Salient Ordered Channels

Multicast RPCs from clients and Client Authoritative Entity Data offers ordering when sent from the same client.

Server to Client RPCs and Authoritative Client Entity Deletions offers ordering as both will be sent from the server.

Multicast RPCs from servers, Server Authoritative Entity Data and Server Authoritative Owner Only Entity Data offers ordering as all will be sent from the server.

Ie, in Morpheus, RPCs of the same type on the same actor are guaranteed to be processed in the same order they were called. For example:

1. Server called NetMulticastRPC_1 followed by NetMulticastRPC_2 on MorpheusActor_A.

2. Client processes NetMulticasRPC_1 first then processes NetMulticastRPC_2 on MorpheusActor_A.

Non-Ordered Channels

An example of a pair of channels that you might think would be ordered but are not is Server Authoritative Entity Data and Authoritative Client Entity Deletions

In Morpheus, different types of RPCs are NOT guaranteed to be processed in the same order. For example:

1. Server called ClientRPC_1 followed by NetMulticasRPC_1 on MorpheusActor_A.

2. Client will NOT necessarily process ClientRPC_1 first on MorpheusActor_A.

Reliability

Morpheus RPCs are always reliable even if you marked them as unreliable.

As long as your client is connected, it will receive all RPCs sent to it.