# Is order of RPCs and property replication guaranteed between actors? Is it different with Iris?

**URL:** <https://forums.unrealengine.com/t/is-order-of-rpcs-and-property-replication-guaranteed-between-actors-is-it-different-with-iris/2642972>\
**Category:** Multiplayer & Networking\
**Tags:** Networking, playercontroller, hud, actor, client, Replication, Server, beginplay, rpc, seamless-travel, order, unreal-engine, Widget, CPP, question\
**Created:** [August 15, 2025, 3:47pm UTC](https://forums.unrealengine.com/t/is-order-of-rpcs-and-property-replication-guaranteed-between-actors-is-it-different-with-iris/2642972 "2025-08-15T15:47:43Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kaltxi](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Kaltxi](https://forums.unrealengine.com/u/Kaltxi)\
**Post date:** [August 15, 2025, 3:47pm UTC](https://forums.unrealengine.com/t/is-order-of-rpcs-and-property-replication-guaranteed-between-actors-is-it-different-with-iris/2642972/1 "2025-08-15T15:47:43Z")

</div>

I’m working on migration to Iris and found a peculiar problem. We have Widgets in the `AHUD` which initialize a cached HUD variable from `APlayerController` on `NativeConstruct`. With traditional replication it works fine, the order is as follows:

- `APlayerController::ClientSetHUD` RPC comes in, `APlayerController` creates HUD, but doesn’t initialize widgets, since the `OnRep_ReplicatedHasBegunPlay` hasn’t come yet so no `BeginPlay`s.
- `OnRep_ReplicatedHasBegunPlay` comes in, `BeginPlay`s are dispatched
- In `BeginPlay` of `AHUD` widgets initialize and can retrieve the pointer to HUD from `APlayerController`

But with Iris I have non-100% repro where sometimes these come in a different order like this:

- `OnRep_ReplicatedHasBegunPlay` comes in first
- `APlayerController::ClientSetHUD` RPC comes second and while creating HUD it also runs `BeginPlay` and initializes widgets, which try to retrieve HUD from `PlayerController`, but can’t - we’re in the middle of `AHUD` creation!
- Widgets end up without HUD and misbehave until we refresh the UI manually.

Creation of HUD happens in `APlayerController::ClientSetHUD_Implementation`:

```cpp
MyHUD = GetWorld()->SpawnActor<AHUD>(NewHUDClass, SpawnInfo );

```

This happens during `SeamlessTravel` to the server I see the following snippet of code in `FSeamlessTravelHandler::Tick` at the very end:

```cpp
AGameModeBase* const GameMode = LoadedWorld->GetAuthGameMode();
if (GameMode)
{
	// inform the new GameMode so it can handle players that persisted
	GameMode->PostSeamlessTravel();					
}

// Called after post seamless travel to make sure players are setup correctly first
LoadedWorld->BeginPlay();

```

`PostSeamlessTravel` is the one that sends `APlayerController::ClientSetHUD` RPC and `BeginPlay` is the one that sets the replicated begin play which has `OnRep_ReplicatedHasBegunPlay` `RepNotify`. So it seems like it is meant to first all the player/HUD setup and only then perform `BeginPlay`s.

In the docs ([Replicated Object Execution Order in Unreal Engine | Unreal Engine 5.6 Documentation | Epic Developer Community](https://dev.epicgames.com/documentation/en-us/unreal-engine/replicated-object-execution-order-in-unreal-engine)) it says that replicated properties indeed come after RPCs, but it is not clear if this only holds true for a single actor or between actors also. In this case we have an RPC for `APlayerController` and property for `AGameModeBase`, which are different actors.

If replication order should be guaranteed here, then Iris seems to break this guarantee. If not - then I suppose our widgets should not try to get HUD during construction, since it can happen during HUDs own construction. Also the seamless travel comment then must be misleading, since players would not necessarily have the time to be setup first. Could someone clarify?

EDIT: Actually on the second thought I’m not sure how not to use HUD here since we need data it has during initial widget setup.

---

<div class="post-metadata">

**Author:** ![Rev0verDrive](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/rev0verdrive/32/907214_2.png) [@Rev0verDrive](https://forums.unrealengine.com/u/Rev0verDrive)\
**Post date:** [August 16, 2025, 11:07pm UTC](https://forums.unrealengine.com/t/is-order-of-rpcs-and-property-replication-guaranteed-between-actors-is-it-different-with-iris/2642972/2 "2025-08-16T23:07:36Z")

</div>

Order is never guaranteed. In an ideal world, ample bandwidth, low ping/loss w/fast machines and abundant resources, the docs flow is accurate. Realistically you cannot code multiplayer this way.

How long it takes a joining player to get a replicated copy of the controller varies based on ping, loss, and system performance. You have to setup your executions based on “who knows when” I’ll get x,y,z.

Typically properties get replicated on creation (server-side). So the OnRep’s should be fired along side the replication of the controller itself. When/Where the RPC gets fired (top/bottom stack) depends on current load, how much is currently being replicated and reliability.

I personally wouldn’t rely on an RPC to create a needed component. You can just create it on initialization, set pointer and then hide it. Or have the onreps check validity of the pointer and create it if needed.