This page describes the properties of Actor that have bearing on the behavior of Replication
- NetPriority
- This floating-point value is used to determine how much network bandwidth is allocated for keeping the actor up-to-date across the network. The ratio of an actor's NetPriority and another actor's NetPriority is the same ratio as the bandwidth that will be allocated to each. The default value for actors is 1.00 (Checked in UT99 and in UT2004).
- NetUpdateFrequency
NetUpdateFrequency allows you to throttle back the amount of network traffic generated to keep an actor up-to-date. This is useful when the data changes frequently but you only want periodic updates. For example, PlayerReplicationInfo contains a lot of data about the client. Stuff like the various players' pings may change quite frequently, and having the client keep track of such information would be quite a network hog. But since PlayerReplicationInfo has a NetUpdateFrequency of 2, it is only updated twice a second, which is much better for that player's, and of course the server's, bandwidth.
Here are some example NetUpdateFrequencies for some UT2004 classes:
| Class | NetUpdateFrequency |
| Actor | 100 Hz |
| Pawn | 100 Hz when possessed, or 5 Hz when unpossessed |
| Mover | 1 Hz |
| Pickup | 0.1 Hz, or 8 Hz when just dropped |
| PlayerReplicationInfo | 1 Hz |
As you can see from the table, it's perfectly fine to alter the actor's NetUpdateFrequency to reflect periods of increased or decreased activity.
- bNoRepMesh
- don't replicate mesh
- bNotOnDedServer
- destroy if on dedicated server and RemoteRole == ROLE_None (emitters, etc.)
The following const bool flags are maintained by the engine and are only relevant during replication:
- bNetInitial
- It is true if this is the first time this actor has been replicated to the client. It is false otherwise. This is useful for things like projectiles that only need to have their location and velocity replicated once and their movement can then be predicted reliably.
- bNetOwner
- Indicates whether the client we are considering replicating to is the owner of the actor we are replicating.
- bNetRelevant
- Only valid server side, indicates that the server considers the actor relevant to the client.
- bDemoRecording
- Are we currently demo recording?
- bClientDemoRecording
- True if we are currently recording a client-side demo
- bRepClientDemo
- True if remote client is recording demo
- bClientDemoNetFunc
- True if we're client-side demo recording and this call originated from the remote.
- bDemoOwner
- Demo recording driver owns this actor.
Related Topics
- Actor class, which contains the properties governing replication behaviour
- Introduction to Replication
- Replication Block
- Role and RemoteRole, and NetMode.
- Netcode Idioms
- Simulated Function
- Replicated Function
- Animation Replication
- Another Look At Replication
- Replication examples