Basics

Fusion RPC Targets

Every Fusion RPC specifies a target. Targets are explicit because shared authority does not have a built-in "the server" recipient — the RPC has to say what it means by destination.

Targets must be fusion networked actors or subobjects of fusion networked actors with replication enabled.

Defining a Fusion RPC in Blueprints

Blueprint RPCs use the Custom Fusion RPC node.

Create a corresponding custom event in the blueprint graph and specify parameters if any. Then in the Custom Fusion RPC select that event in the dropdown as the RPC target.

If custom targeted event parameters have changed the Custom Fusion RPC node may need to be manually refreshed with the updated binding. Please use the button "Refresh Pins".

The Custom Fusion RPC node can now be invoked anywhere in the graph and will call the RPC accordingly.

The Custom Fusion RPC node will once bound to an event generate an internal blueprint function to serialize parameters, it will carry the event's name plus suffix _Call.

Defining a Fusion RPC in C++

C++ RPCs use the SEND_FUSIONRPC macro defined in FusionMacros.h. Mark the call-site function with SEND_FUSIONRPC(target)

Fusion C++ RPCs also need to generate C++ code to generate bindings, ensure the following header exists above the *.generated.h Unreal header *.fusion.h

C++

#include "MyUnrealClass.fusion.h"
#include "MyUnrealClass.generated.h"

add FUSION_BODY(); to the class body below GENERATED_BODY().

C++

GENERATED_BODY()
FUSION_BODY();

Example code of a defined fusion RPC. The _Receive suffix function will run on the selected target similar to how Unreal's _Implementation function works, it's up to the developer to implement it. The body of SendValue in this case is generated by Fusion's UBT plugin.

C++

SEND_FUSIONRPC(TargetEveryoneElse)
void SendValue(float Amount);
void SendValue_Receive(float Amount);

Reliability and Ordering Semantics

Fusion RPCs are reliable and in-order per (caller, target object). Two RPCs sent from the same caller to the same target object arrive in the order they were sent, and neither is silently dropped.

RPCs are not replayed for late joiners. A client that joins after the RPC fired never sees it. Anything that must survive a join belongs in a replicated property on a networked actor, not in an RPC — see Replicated Properties for the persistent path.

Behavior Under Owner and Master Client Changes

TargetObjectOwner re-resolves the recipient on the receiving side. Sending towards a target owner does not guarantee that client remains the owner once the RPC arrives — see Ownership for how that resolution works.

TargetMasterClient re-resolves the recipient on the receiving side, not on the sender. An in-flight Master Client migration — the original master left while the RPC was on the wire — is delivered to the new host, not bounced. Application code does not need to retry the call across master changes.

Using Built-in Server, Client, and NetMulticast Markup

Fusion routes Unreal's built-in NetMulticast UFUNCTION markers through UFusionNetDriver, which forwards each call into UFusionOnlineSubsystem::SendCustomRPC with ERPCMode::UnrealRPC. Existing UE projects can use stock RPC markup without rewriting to SEND_FUSIONRPC, although the new C++ path is the recommended one for shared-authority code because it makes the target explicit.

Supported Argument Types

FObjectProperty, FWeakObjectProperty, and FSoftObjectProperty require the encoded object to be either networked under fusion or part of the loaded level. Level objects are encoded as string paths and are deterministic between clients.

Global RPCs

Deriving a class from UGameInstance and defining RPCs allows sending RPC to everyone connected to the same ongoing session within the room regardless of what world or objects they have. This is true for both c++ and Blueprints.