A little info about PrimalStructure Network Variable Replication for programmers:
PrimalStructures specifically are flagged to use “Network Dormancy” and in our custom implementation, that changes how variables are replicated. For such Actors (which is just PrimalStructures currently), changed (“dirty”) variable values are not replicated to already-connected clients automatically over time (EXCEPT newly joining clients do get all the replicated variable values when they first connect/receive the Actor).
Instead, for PrimalStructure (NetDormant Actors), which incidentally also includes PlayerStates due to bOnlyReplicateOnNetForcedUpdate, to get variables to replicate to existing clients you must call either ForceNetUpdate() to flush ALL the changed values to all relevant clients (expensive and not recommended on such Actors), OR check the “Multi Cast” value to TRUE on the SET Blueprint Action for that Replicated variable (which will immediately Replicate the new value of that specific variable it to all relevant clients when that Set executes – however note it will only do this if the value on the server is different than the input going into the SET action, i.e. it filters out redundant values to save perf).
RepNotifies will fire as normal. Also to save a bit of perf, unless need a RepNotify – in which case flag them RepNotify – all new replicated variables within a NetDormant Actor ought to be marked ReplicatedInitialOnly; since they can’t replicate dynamically in NetDormant Actors anyway, it won’t change their functionality and helps reduce some overhead in the networking system.
Multicast FUNCTIONS work regularly, of course. An example of a complex but well-constructed Blueprint PrimalStructure functionality, for reference, is: Blueprint’/Game/PrimalEarth/Structures/TekTier/TekCloningChamber.TekCloningChamber’
Also note there is a system for two way client/server communication on arbritrary NON-CLIENT-OWNED network Actors, which can be useful if you need to pass data or actions (beyond the simple ID action that the MultiUseEntries system already provides) between server and some client for a network Actor that is not explicitly owned by the client’s PlayerController. You can investigate the use of these functions in TekCloningChamber to see how it works to send & process command for an Actor from Client to Server:
Client To Server Action: ClientSendNetExecCommandToServer
Server-side Handler Event: BPServerHandleNetExecCommand
And from Server to Client, in Daedon_Character_BP:
Server to Client Actions: ServerSendExecCommandToPlayer, ServerSendExecCommandToEveryone (the “Everyone” version is similar to a Multicast function, but sometimes useful in order to keep the same event flow as ServerSendExecCommandToPlayer)
Client-side Handler Event: BPClientHandleNetExecCommand
(Of course, you can use both sets in combination to support an “action and response” system.)
Note that if you use this system, on the SERVER BPServerHandleNetExecCommand in particular it’s important to explicitly check for security (such as same-TargetingTeam and distance to target, and validate any data parameters) since the client can arbritrarily call the function at any time with any potential parameters. You’ll see that the TekCloningChamber BPServerHandleNetExecCommand does this, by checking structure access allowance before it processes the named command.
One other useful feature about the NetExecCommandToServer functions, and “Multi Cast” functions in general (which is unique to our custom UE4), worth mentioning:
Exec Command Actions and Events, and Multi Cast Events, will work on any pre-placed Map Actors (non-dynamically-spawned), EVEN if those pre-placed Actors are not Replicated! This can be useful sometimes if you just wanna have some networked events which trigger on non-replicated pre-placed actors within the map (we use this trick on our “Boss Arena Managers” and “Dungeon Arena Managers”, which are not replicated Actors but whose Blueprints still send & handle event messages to the players “within” them, when the arenas are active.)
