Per this doc: Replicating object references | Unreal Engine Documentation
Pointers to actors can be replicated as properties as long as they are either marked for replication or stably named.
You can do this with RPCs as parameter too, but there is a downside. Because RPCs typically invoke ASAP and there is no guaranteed order of operations between spawning an Actor during runtime and invoking RPCs on a different actor, it’s possible for the Actor pointer to be NULL on the receiver when the RPC is processed. The parameter simply has not spawned yet on the receiver, so it can’t resolve the pointer yet.
I was wondering if that is a problem with Properties as well?
For example:
Server spawns SomeActor, then immediately invokes an RPC on the PlayerController with the reference to the newly created SomeActor. The receiving player may receive NULL in the RPC
But, what if SomeActor was a UPROPERTY(replicated) AActor* on the PlayerController? Even if do a ForceNetUpdate to avoid the NetUpdateFrequency delay, I cannot seem to get a NULL pointer here. Is this guaranteed behavior if the SomeActor is marked as replicated?
This doubles for Blueprint properties too. So if you’re not into C++, the equivalent in blueprints would be a Variable on the Blueprint set to Replicate or RepNotify and typed as a SomeActor reference
I was able to find this (Google Translate) that explains it decently:
Compared with attribute synchronization, RPC data packets are different from attribute synchronization. Bunch is generated immediately when called and placed in Sendbuffer. According to the execution sequence of one frame of UE4 (packet receiving-Tick-sending), generally RPC data is more important than attribute synchronization. Put it in the buffer early, so there are often synchronization problems caused by the wrong order of RPC and attribute synchronization …
We can allow the client to wait until the object is generated by setting the console variable net.DelayUnmappedRPCs 1, but only for reliable RPCs.
So RPCs do differ in handling these pointer parameters than replicated Properties.
But it appears that like RPCs, Actor pointers can still be NULL on properties if the timing of packets or the order of operations when parsing packets:
For example: there are two replicated Actors A and B on the server, the A object saves a replicated B type attribute, and the B object saves a replicated attribute of the A object. When A is synchronizing, because B has not been synchronized, the attribute of A is temporarily empty. When B is synchronized to the client, Beginplay will be executed first, but at this time the B property in the A object is still empty.
This will lead to the failure of the logic related to finding attribute A in B::Beginplay and trying to process the B attribute in A.
Basically says that if Actor A has a property for Actor B, and if B has not spawned yet, A will be a NULL pointer for B in its properties.
BUT when Actor B does spawn, it will “go back and fix” Actor A’s pointer after B has finished spawning. So at least it has that.