Relevance is a concept in Unreal Engine replication. Often there are Actors in the level (like server actors, pathnodes, some keypoints) that cannot be seen by, and will not influence, a particular client. Any bandwidth used to update these Actors is wasted, so replication uses the concept of relevance to avoid this waste.
The Unreal engine uses a set of conditions to determine whether an Actor is relevant or not:
- If the Actor has bAlwaysRelevant set to true, then this Actor is relevant.
- If an actor's owner is set to the local player, then that actor is relevant.
- If an actor has bOnlyRelevantToOwner set to true, it will not be replicated to any other clients. It exists only on the server and the actor's owner. (But note that bAlwaysRelevant overrides bOnlyRelevantToOwner, which is.... weird)
- If an actor is a subclass of Weapon and it is owned by an actor who is visible, then it is relevant.
- If the actor has bHidden set to false, bBlockPlayers set to true, or an AmbientSound set, then the actor is relevant.
- If the actor is visible on the client's screen, then it is relevant. Note that this goes by the center of the mesh so actors with very large meshes can sometimes become irrelevant while some part of them is still visible.
- If the actor is not visible on the client's screen but was recently visible, then it is still considered relevant. The amount of time it remains relevant varies based on bandwidth availible, and will vary from 2 to 10 seconds.
- The linked lists Level.ControllerList (UT2003) and Level.PawnList (UT) do not exist on network clients. If you attempt to reference them the list will appear empty. Level.Game is also never replicated and does not exist on the client at all. If you need to access the game's GameReplicationInfo, it can still be referenced by the locally controlled player's PlayerController (PlayerController.GameReplicationInfo) or PlayerPawn. See Netcode Idioms for an explanation of how to do this.
Notes
A warning for the programmer: Actors deemed irrelevant may be destroyed on the client side while continuing to exist and be updated on the server. You must keep this in mind when checking a reference to another object in client-side script: the object and the reference still persist on the server and will be linked back up automatically once the server decides it is relevant again.
Related Topics
Comments
Tarquin: Where is bAlwaysRelevant defined?
SuperApe: bAlwaysRelevant is defined in Actor, but only used in subclasses.
Tarquin: I think it's missing on Actor
Kohan: What's the thing about ZoneInfo always being relevant? bAlwaysRelevant isn't set in it, though it is set in LevelInfo.
Dimension4: ZoneInfos are bNoDelete, so they are always relevant
Buggie: Not really. this rule not work at all. Proved by source code and by real tests. So I remove it. ZoneInfo always being relevant because bAlwaysRelevant set by default to true. If you override it to false, then no any replication occur. You can check it with make simple map, which change ZoneLight and run it on dedic server.
Category:Legacy To Do – Work in with Replication family of pages, as per Replication/Discussion.