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:

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.