Hello,
I am trying to avoid an actor from being created on the replay client.
There is a MulticastRPC in the actor that triggers code that should not be ran in replays.
I have set AActor::bRelevantForNetworkReplays to false, as well as bAlwaysRelevant to false for good measure.
Shouldn’t that prevent the actor from being created on replay clients? Or even if it is created, why is it receiving the MulticastRPC even after being removed from the list of networked actors during the recording of the replay, the very first time it is detected in UDemoNetDriver::TickDemoRecordFrame.
Use the Replay SubSystem Is Playing bool to control logic flow and usage.
This is how we implemented it, but I was trying to find a better solution than this.
By checking this condition, we do not prevent the replication of the actor inside replays, meaning the actor still exists and we need to prevent any of its behaviour manually…
The variable bRelevantForNetworkReplays seemed like it was intended to prevent replication of the actor, or at least prevent the Multicast RPCs and replicated variables from being sent to the replay client (i.e. recorded into the replay’s data). But it is not what we observed.
Keep in mind we do not have issues with Client or Server RPCs, as they are intended to be sent to a specific client (the one controlling the actor) or to the server, meaning by default they are not sent to replay clients (the RPCs do not get recorded into the replay data)
There’s no way around preventing the creation/inclusion of the actor in replays. It’s bypassing net relevancy conditions because it executed a network event in normal gameplay.
It’s execution of a Multicast RPC makes it net relevant. It Owns the network action of the RPC. The RPC event references the Parent actor.
The only thing you can do is use conditional logic to prevent further action in replay via the subsystem is replay conditional.