UDN
Search public documentation:
ReplicationRelevancy
日本語訳
中国翻译
한국어
Interested in the Unreal Engine?
Visit the Unreal Technology site.
Looking for jobs and company info?
Check out the Epic games site.
Questions about support via UDN?
Contact the UDN Staff
中国翻译
한국어
Interested in the Unreal Engine?
Visit the Unreal Technology site.
Looking for jobs and company info?
Check out the Epic games site.
Questions about support via UDN?
Contact the UDN Staff
UE3 Home > Networking & Replication > Relevancy
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):
- If the actor has a RemoteRole of ROLE_None, it is not relevant
- If the actor's NetUpdateTime is larger than the current time, it is not relevant
- If the actor is bAlwaysRelevant, it is relevant
- If the actor is owned by a viewer (could also be the client), it is relevant
- If the actor is owned by the client, it is relevant
- If the actor is the viewer, it is relevant
- If the viewer is the actor's instigator, it is relevant
- If the actor's Base is set it is relevenat if the Base actor is relevant
- If the actor does not have bBlockActors and is bHidden or bOnlyOwnerSee, it is not relevant
- 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
- If the actor is visible according to a line-of-sight check through a portal, it is relevant
- Otherwise, it is not relevant
- bAlwaysRelevant
- Recently visible to the player or the player's ViewTarget
- Owned by the player or the player's ViewTarget
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:- If the pawn is BasedOn(...) the viewer, it is relevant
- If the viewer is BaseOn(...) the pawn, it is relevant
- If the viewer has bReplicateAllPawns, it is relevant
- If the pawn is within the always relevant distance, it is relevant
- If the pawn has an audible ambient sound, it is relevant
- 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:- If the vehicle is BasedOn(...) the viewer, it is relevant
- If the viewer is BaseOn(...) the pawn, it is relevant
- If the viewer has bReplicateAllPawns, it is relevant
- If the vehicle is within the always relevant distance, it is relevant
- If the vehicle has an audible ambient sound, it is relevant
- If distance fog is compiled in and the actor beyond the fog, it is not relevant
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