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 levelthe authoritative client: the server and all clients with this
AMorpheusActor
in the foreground network levela 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:
Server
calledNetMulticastRPC_1
followed byNetMulticastRPC_2
onMorpheusActor_A
.Client
processesNetMulticasRPC_1
first then processesNetMulticastRPC_2
onMorpheusActor_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:
Server
calledClientRPC_1
followed byNetMulticasRPC_1
onMorpheusActor_A
.Client
will NOT necessarily processClientRPC_1
first onMorpheusActor_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.
Last updated