We are working on this now, stay tuned!
The two conditions you might be referring to are COND_SimulatedOnly, and COND_AutonomousOnly.
An autonomous proxy actor is simply an actor that has a role of ROLE_AutonomousProxy. By default, APlayerControllers are actors that will have this flag set, and for machines that don’t own that player controller, the role will be downgraded to ROLE_SimulatedProxy. For machines that do own that player controller, it is assumed that a human will be driving the inputs and will be controlling that actor on that machine.
Look at APawn::GetNetConnection. Then take a look at UActorChannel::ReplicateActor, and notice:
UNetConnection* OwningConnection = Actor->GetNetConnection();
if (OwningConnection == Connection || (OwningConnection != NULL && OwningConnection->IsA(UChildConnection::StaticClass()) && ((UChildConnection*)OwningConnection)->Parent == Connection))
{
RepFlags.bNetOwner = true;
}
else
{
RepFlags.bNetOwner = false;
}
This check is server side, and is what the low level check looks like to determine if you own the actor. A little bit further down, if you don’t own the actor, it will be downgraded for your connection:
// Save out the actor's RemoteRole, and downgrade it if necessary.
ENetRole const ActualRemoteRole = Actor->GetRemoteRole();
if (ActualRemoteRole == ROLE_AutonomousProxy)
{
if (!RepFlags.bNetOwner)
{
Actor->SetAutonomousProxy(false);
}
}
So if you use the COND_AutonomousOnly condition, only actors that have a role of ROLE_AutonomousProxy (and not downgraded) will receive these updates. This is implementation dependent, but can be useful when you don’t want simulated actors receiving that update. Maybe this property represents some client side prediction correction or something, and only autonomous actors need this update.
If you used the COND_SimulatedOnly condition, only actors that have a role of ROLE_SimulatedProxy will receive updates. This could be useful when you want to avoid updating actors with a role of ROLE_AutonomousProxy, which might make sense if you are changing that property locally while predicting the movements of that actor, and don’t want updates from the server for that property (since you will just overwrite it anyhow).
I can’t make promises on this particular example, but we definitely intend to expose this type of stuff, and more OSS (online subsystem) related features in the future.
This would be correct for the server. It would have 100 channels opened for 100 connections (100*100). This is an extreme case that we would eventually like to get better at, but unfortunately haven’t been able to get to yet.
The current push is to get dedicated servers which are expected to run on a single core with other instances, which wouldn’t make sense to run multi-threaded, but this is another wishlist feature we eventually want to get to since we understand that listen servers running on multi-core machines would greatly benefit from this.
Each connection has a list of active properties that want to be checked for replication, considering conditions and active overrides. This is the pre-computed part. We can do stuff like align memory how we need to most efficiently loop over and scan for changes.
For each connection that will be receiving this actor, we need to loop over these properties, and compare them to the last known state for that connection, and build a change list for the properties that have changed. For connections that are on the same frequency and phase, they can skip this step, and share the change list that was generated from the first connection that did the actual work.
Hope that clears some things up!