Hello,
I have a level with many replicated actors of the same type (they’re called jelly hoops).
They have only one variable inside them that is replicated with a repnotify and only replicates when a pawn overlaps the actor.
Since the engine verifies all the time if the actor must replicate that frame or not, and the variable only replicates during overlaps, the server is wasting a lot of cpu cycles with that actor class because I have many of it in the level, as stated by the network profiler:
However, if I set the dormancy to DormantAll, the actor will still trigger the replication events (I don’t have to call FlushNetDormancy), however it will fix my problems with the cpu cycles:
So how dormancy really works? I thought it was used so I could tell the engine to make my actor awake at key moments, so I can specify exactly when I want it to replicate. However, a DormantAll actor is triggering replication events normally.
When you set the actor as “dormant”, it waits for the latest property states to be acked by all clients the actor is relevant for, then closes the actor channel (destroying the history/shadow state along with it).
Waking an actor from dormancy is effectively like spawning a new actor in that ALL replicated properties will be sent, even COND_InitialOnly properties. Just keep that in mind, as many don’t realise this.
If you Flush dormancy or “wake” the actor, then you must set it back to dormant if you want it to go dormant again, otherwise it will stay awake. Like relevancy, dormancy takes a few seconds to take effect, to avoid potentially spamming new actor channels.
IIRC setting a replicated property from Blueprint automatically flushes dormancy, but I never write networking code in BP so can’t remember if that’s accurate.
Hello, TheJamsh, thanks for your time and explanation!
Yes, apparently NetDormancy is pretty much ignored in bps, as stated here:
Right now, replicating a variable (even without rep notify) will simply set the actor to awake, the variable will replicate, then it will be set back to DormantAll. This only happens in bps.
I’m gonna write this class in C++ and avoid using bps for networked actors.
By the way - the information that the actor takes a while before becoming dormant again and that the COND_InitialOnly is replicated again when flushing dormancy is key, I don’t remember hearing it elsewhere (don’t remember if the videos I linked above talk about this), but knowing that saved us a lot of time and effort.
