Quick answer: Verify Iris is enabled in Project Settings + DefaultEngine.ini. Configure relevancy on the actor (always relevant, owner only, distance based) via IrisReplicationComponent.
A multiplayer game opts into Iris replication for its efficiency benefits. Some actors stop replicating to clients post-switch. The actors weren’t configured with Iris-aware relevancy.
Confirm Iris Active
Console:
Net.Iris.UseIrisReplication
> 1
Confirms Iris is on. If 0, enable in Project Settings → Engine → Iris.
Per-Class Config
Each AActor subclass can declare:
UCLASS(meta=(UseIrisReplication))
class AMyActor : public AActor
{
AMyActor() {
bReplicates = true;
bAlwaysRelevant = false; // or true for HUD pieces
}
};
Iris also looks at the FNetIrisConfig in ClassRep tables. Generated at startup.
Relevancy in Iris
Iris uses ReplicationFilter and ReplicationSubObjects to decide reach. Default:
- Spatial: range-based on NetCullDistance.
- OwnerOnly: only the owning connection sees.
- SubObject: only when parent replicates.
Set filter via subsystem during BeginPlay if you need non-default:
UReplicationSystem* RS = UE::Net::UReplicationSystem::Get();
RS->SetFilter(NetHandle, FNameSpatialFilter);
Mixed Iris/Classic Pitfall
Some classes default to classic in 5.3/5.4. Check ConfigureClassReplicationSystem; verify it routes to Iris for your class. Forcing classic on one actor while others use Iris causes confusing missing-replication symptoms.
Verify with Network Profiler
Window → Developer Tools → Network Profiler. Capture session; inspect per-actor replication frequency and size. Missing actors absent from the report.
Verifying
Server + clients. Actor appears, properties update, RPCs fire. Network profiler shows traffic for the actor. Latency under target despite Iris’s overhead.
“Iris is opt-in per project. Verify the flag, then verify relevancy. Two layers, both required.”
Iris shines for many-player games. For sub-16-player Co-op, classic is often sufficient and easier to debug — only adopt Iris when scale demands it.