Clients destroy vital actors when seamless traveling and server broadcasts a multicast RPC using Replication Graph

Development Programming & Scripting Multiplayer & Networking
, ,
1

I’ve found a bug in the replication graph for multicast RPCs not considering whether the receiving connection is even ready to receive a new actor channel. We’ve gone ahead and made the following changes to ReplicationGraph.cpp, around like 2477:

Mainly posting for visibility, or if this is not the correct fix, advisement on a more proper fix. But this has fixed the issue for us when the server performs a reliable multicast rpc on an actor that does not go dormant, where the client would prematurely destroy said actor when completing its seamless travel and never receive further updates.

          //UE_CLOG(ConnectionActorInfo.Channel == nullptr, LogReplicationGraph, Display, TEXT("Null channel on %s for %s"), *GetPathNameSafe(Actor), *GetNameSafe(Function));
          if (ConnectionActorInfo.Channel == nullptr && (RPC_Multicast_OpenChannelForClass.GetChecked(Actor->GetClass()) == true))
          {
             // There is no actor channel here. Ideally we would just ignore this but in the case of net dormancy, this may be an actor that will replicate on the next frame.
             // If the actor is dormant and is a distance culled actor, we can probably safely assume this connection will open a channel for the actor on the next rep frame.
             // This isn't perfect and we may want a per-function or per-actor policy that allows to dictate what happens in this situation.

             // Actors being destroyed (Building hit with rocket) will wake up before this gets hit. So dormancy really cant be relied on here.
             // if (Actor->NetDormancy > DORM_Awake)
             {
                bool bShouldOpenChannel = true;
#if WITH_ENGINE_CHANGES
                // Kyle - 6/29/2026. Fixing a bug where we are opening a channel for an actor that shouldn't be. e.g. not the same level.
                if (!NetDriver->IsLevelInitializedForActor(Actor, NetConnection))
                {
                   bShouldOpenChannel = false;
                   UE_LOG(LogReplicationGraph, Warning, TEXT("Multicast RPC opening channel for actor that is not initialized on connection. Actor: %s Target: %s Function: %s"), *GetNameSafe(Actor), *GetNameSafe(TargetObj), *GetNameSafe(Function));
                }
                else   
#endif
                if (ConnectionActorInfo.GetCullDistanceSquared() > 0.f)
                {
                   bShouldOpenChannel = false;
                   if (ActorLocation.IsSet() == false)
                   {
                      ActorLocation = Actor->GetActorLocation();
                   }

[Attachment Removed]

2

Steps to Reproduce

  1. Create a new project using any template, and use the replication graph as the net driver.
  2. Have a client connect to the a server
  3. Have the server perform a seamless travel to another level
  4. Before the client has completed its seamless travel, have the server perform a reliable Multicast RPC on the GameState
  5. Client receives a reliable multicast RPC on a newly opened actor channel, spawns the game state in the seamless travel level
  6. Upon client finally loading the destination level, transitions from the seamless travel level to the new level, destroying all actors in the seamless travel level, including the spawned game state

Observe that the client will never spawn a game state in the new level, and all replications of the game state from the server will be dropped by the client as it sits in limbo

[Attachment Removed]

3

Hi,

Thank you for the report! This is a known issue with seamless travel and replication graph: https://issues.unrealengine.com/issue/UE\-361443

I’ve added the info provided here to our internal tracker for the issue.

In the meanwhile, others have worked around the problem by adding a check to UReplicationGraph::ProcessRemoteFunction in order to determine if the client has the actor’s level loaded, similar to how the base UNetDriver handles checking this when processing a remote function.

Thanks,

Alex

[Attachment Removed]