Search public documentation:
Rolevalue will generally be
ROLE_Authorityon the server, and be one of
ROLE_AutonomousProxyon the client, corresponding to three fundamental different roles that an actor can play in netplay. The
Roleof the actor on the client is normally specified in
RemoteRole's value in the defaultproperties of the actor, but one is free to change the value dynamically in-game without any problems. The value of the Role is set in the current
Roleis set on the other side of the connection. This allows code on the server, where
ROLE_Authority, to check what kind of simulation is being provided on the client. In general, the
ROLE_Authorityfor whatever machine spawned the actor. If an actor is spawned on the client, the client will have a
ROLE_Authority, but the actor will not be replicated to the server, due to the ease with which one could cheat and create weapons for themselves, on the client. Now that you understand how Roles and RemoteRoles work, let's go through an overview of each of the various roles individually. This document is part of the NetworkingTome.
Roleon the server. On the server, all Roles will be= ROLE_Authority=, and the
RemoteRolewill be one of the following values. On the client, the reverse will be true. This role doesn't have any real significance, beyond it's use in replication statements, which are described later.
ROLE_None, then there would be two seperate, non-connected instances of the actor on the server and the client. This is used rather often for special effects for which replication is not needed, and can instead be spawned on both machines independantly.
bClientAnim. In summary, an actor with this role is force-fed data from the server. It's intended for actor's that don't move (except in jumps like transportation, respawn, etc), yet still need to be relevant. This role type is used rather infrequently in practice. In most cases you can use Simulated Proxy with some code to handle every case you'll need.
Controllersuse this role as well, since when a player is running, he's more than likely to continue to run, and so they can take advantage of the simulation as well. It's the best prediction method that can be used, for unpredictable players. The only exception to this guideline for players is the pawn you yourself are playing as, since you don't want to simulate your own behavior. In practice, there are two types of Simulated Proxy actors. Simulated Pawns and Simulated Non-Pawns both have different but similar behavior. The differences are delineated below.
ROLE_SimulatedProxygives you an initial Location, Rotation, and Physics. It then keeps you updated with the Velocities, should they change. These variables should enable the client to perform full client-side prediction on this object, assuming it continues along the physics prediction. In the case of
PHYS_Projectile, this is the case. There can be no aberration from these behaviors, (unless you play around with the Physics variables
bBounceand such, which are very useful in prediction.) Finally, for this role, you also get animation updates, assuming the client is not the owner and it's not set for client-side animation. In summary, this Role is for actors that smoothly predict their data on the client.
ROLE_SimulatedProxyis combined with Pawns, a different sort of simulated proxy is created, that act differently in netplay. Pawns are one of the most complex actors in terms of replication, because of their need for clientside prediction, yet inherent unpredictability in their movement. There is no way to duplicate this behavior except by subclassing pawn, so don't expect to achieve it in your projectile subclass. A Simulated Pawn gets the best of dumbproxy and simulatedproxy. It gets velocity updates for the clientside prediction, while at the same time getting location updates from the server to 'readjust' the player's locations. You might then wonder why the pawn does not jump when a new location update comes in. Again, there is native code that causes the actor to smoothly head towards the location given by the server if the location position is too far off from the player's real position. This again ensures seamless movement of player's while keeping them accurate to the server's version. All non-players will get by with velocity-only client-side prediction. No physics will be taken into account for these pawns. This is because some non-players can be
PHYS_Spider, or a variety of other physics that don't work with the following always-walking/falling prediction. Only player pawns get the special client-side prediction to have falling/walking physics. This physics is an assumed physics, which is accomplished by applying the zone's gravity if the player is not on the ground. This logic will be bypassed if the pawn's
bCanFlyvariable is set, which frees it of the clientside physics, but must be accounted for in your code, since there is no physics replication in pawns. This logic is also bypassed if the pawn is in a water zone, which also differs from the default walking/falling physics. In water zones, actors are predicted using velocity alone, which is sufficient with the low amount of gravity that exists in those zones. The actor's get their locations 'adjusted' anyway, so it doesn't make any real difference in the long run. Finally, pawns get rotation updates. Since rotation (which is directly based off the ViewRotation?, or the direction the player is looking) can change quite radically, no prediction is done with it. Instead, the player's rotation is adjusted as new player rotation information comes in from the client. Animation is handled the same as any other non-pawn simulated proxy.
owner->owner->owner...), which should be a PlayerController. If this Top Owner is not the player we are currently replicating to, we change the
UnChan's UActorChannel::ReplicateActor This allows Autonomous Proxy actors to be treated as Simulated Proxy actors to eveyone else, and treated as Autonomous Proxy actors to ourself. When the actor's
RemoteRoleis set to
ROLE_AutonomousProxy, it appears to be a Simulated Proxy for everyone BUT the owner of the actor. Note that this technique is also used with the guided redeemer, to ensure that it works the same way and lets the controlling player have a different proxy setting from the other clients that are just simulating it. Having the server tell you where your guided redeemer is flying would not be appropriate. Rather, you want to tell the server where your guided redeemer is. While Autonomous Proxy doesn't make this just 'work' for you, it does differentiate you from the other people viewing your redeemer, which is what is needed to have it act differently for you, as compared to everyone else.
ROLE_Authorityis used for the server or the machine which is controlling the actor.
ROLE_Noneis used to indicate the actor should not be relevant at all.
ROLE_DumbProxyis used for actors that have no need for clientside simulation or behavior. It's used rarely in practice.
ROLE_SimulatedProxyis used for any actor that needs clientside simulation based upon initial rotation, location, and velocity settings. Simulated pawns get those three varviables over time in addition to everything Simulated Proxies get.
ROLE_AutonomousProxyis used for client-controlled actors which need to be treated seperately for their owner, which will provide client->server movement information, versus other players in the game, which will use Simulated Proxy to simulated the actor on their client.