---

Relevancy

---

Overview

---

As mentioned previously, the purpose of replication is to determine a limited subset of actors which the client needs to know about, so that bandwidth is not wasted sending information about other clients.

Checklist

---

First, the general checklist (for all actors except PlayerController, Pawn and Vehicle):

1. If the actor has a RemoteRole of ROLE_None, it is not relevant
2. If the actor's NetUpdateTime is larger than the current time, it is not relevant
3. If the actor is bAlwaysRelevant, it is relevant
4. If the actor is owned by a viewer (could also be the client), it is relevant
5. If the actor is owned by the client, it is relevant
6. If the actor is the viewer, it is relevant
7. If the viewer is the actor's instigator, it is relevant
8. If the actor's Base is set it is relevenat if the Base actor is relevant
9. If the actor does not have bBlockActors and is bHidden or bOnlyOwnerSee, it is not relevant
10. If the actor is visible according to a line-of-sight check between the actor's Location and the player's ViewLocation, then it is relevant
11. If the actor is visible according to a line-of-sight check through a portal, it is relevant
12. Otherwise, it is not relevant

Now, the discussion of what this means. In a nutshell, one can generalize these rules as:

An actor is relevant if one of the following holds up:

• bAlwaysRelevant
• Recently visible to the player or the player's ViewTarget
• Owned by the player or the player's ViewTarget

As a programmer, if you need your actor to be relevant to the client, you're probably safest using one of the above three settings. Since a player may not always be visible, and hence not relevant, it is important to store player information (name, score, etc) in an actor that is always relevant, hence PlayerReplicationInfo. Since the GameInfo actor is not relevant to the client, it sends Game information to the client through the use of GameReplicationInfo. ReplicationInfo is a good base class for bAlwaysRelevant type actors that are warehouses for information needed by clients.

All inventory in the level or in your possession are relevant, as are all nearby players. All visible projectiles are relevant. Anything that affects the client's world is relevant. Actors that plays music or provide collision are relevant. And just in case that pawn that ducks behind a wall comes back out into view again, Unreal keeps an actor relevant for five seconds after they disappear so the overhead of sending the actor's set of properties upon relevancy does not occur. And to top it off, Unreal takes into account that you may be viewing the world from somewhere other than your own body for those out-of-body experiences, and so will use your ViewTarget and/or ViewLocation in determining your relevant set of actors.

PlayerController checklist

A PlayerController is only relevant when it's the client's PlayerController. Other clients will never replicate another game instance's player controller as it is never required by other clients.

Pawn checklist

Between #7 and #8 of the general list:

1. If the pawn is BasedOn(...) the viewer, it is relevant
2. If the viewer is BaseOn(...) the pawn, it is relevant
3. If the viewer has bReplicateAllPawns, it is relevant
4. If the pawn is within the always relevant distance, it is relevant
5. If the pawn has an audible ambient sound, it is relevant

Between #9 and #10 of the general list:

1. If distance fog is compiled in and the actor beyond the fog, it is not relevant

Vehicle checklist

Between #7 and #8 of the general list:

1. If the vehicle is BasedOn(...) the viewer, it is relevant
2. If the viewer is BaseOn(...) the pawn, it is relevant
3. If the viewer has bReplicateAllPawns, it is relevant
4. If the vehicle is within the always relevant distance, it is relevant
5. If the vehicle has an audible ambient sound, it is relevant

Between #9 and #10 of the general list:

1. If distance fog is compiled in and the actor beyond the fog, it is not relevant

No line-of-sight checking is done for vehicles.

Relevancy is not recursive

---

It is important to note that relevancy is not recursive. If a relevant actor references another actor through a replicated variable, that actor will not necessarily be relevant. That second actor must be meet the relevancy requirements outlined above on it's own grounds. If a relevant actor A references an irrelevant actor B, actor A's reference to B will be None on the client, since actor B does not exist on the client.

NetPriority

---

Not all actors are created equal. For example, a pawn's movement should have higher precedence over some person's ping changing. With Unreal, every actor has a NetPriority variable which is used to indicate that actor's precedence in network play. Actors that have not been updated in awhile should be more important than actors that were updated one tick ago. All of these factors are handled by NetPriority.

The values of NetPriority used are:

• Actor - 1.0
• Inventory - 1.4
• MatineeActor - 2.7
• Pawn - 3 for possessed pawns, 2 for unpossessed (ambient) pawns
• Pickup - 1.4
• PlayerController - 3.0
• Projectile - 2.5
• Vehicle - 3 for driven vehicles, 1 for undriven vehicles

NetUpdateFrequency

---

In addition to NetPriority, some actors don't need to be updated as frequently as others, and so there is NetUpdateFrequency. By default, Actor has a NetUpdateFrequency of 100. So assuming the server is running at less than 100 ticks per second, (by default, the game runs at 20 ticks per second), then it should be more than enough to cause the server to send updates for that actor to the client each tick. For the real actors that actually change their variables less than 100 times per second, the NetUpdateFrequency value is overriden to be more realistic. The value stored in the actor itself is a rough approximation of how frequently the actor should be updated.

Here are the values of NetUpdateFrequency for the base classes.

• Actor - 100
• Info - 10
• DroppedPickup - 8
  • Only applies if they are sitting on the ground (and thus are bAlwaysRelevant).
• TeamInfo - 2

Unreal performs this by making sure that the actor is only relevant once every 1/NetUpdateFrequency seconds. So the actor is effectively culled from all the later processing tasks if it's NetUpdateFrequency says it should not be updated yet.