Unreal Net Dormancy Explored - UE C++ Tutorial

Dormancy is a useful way to optimize network performance in the Unreal engine. Dormancy allows an actor to be removed from the list of actors to consider for replication. Dormancy basically allows you stop sending network updates from the server to the client. Unless you flush-or-awake and change variables. Here I explore various Dormancy modes. I note differences between blueprint and C++ code. We explore high level over view on a white board. Then explore documenation for some specifics. Then I go though a code example of putting an actor dormant and exploring behavior. Note, you should flush (or awake actor) before changing replicated state. Doing that ensures the shadow state is correct, and that it can correctly determine what replicated state changes, in order to reliably replicate to the client. Note there are some a mistakes in the video, that I called out after editing. 1) you should flush or awake an actor before changing replicated state, not after. 2) you should not modify replicated state while an actor is dormant; you can end up missing updates. I called these out in the video explicitly where they occur. I had already made the video before I realized the mistake. And while the example isn't the best in terms proper managment of network state, it does show how dormancy will stop replication of properties while an actor is dormant. So it seems to me that it is worth while to explore dormancy with this less-than-ideal-example, as long as we take note that in practice you shouldn't modify replicated state without flushing or awaking first. Recorded in UE 5.4 Documentation for this engine version https://dev.epicgames.com/documentation/en-us/unreal-engine/actor-network-dormancy-in-unreal-engine?application_version=5.4 0:00 Whiteboard Introduction 3:57 Documentation Highlights 4:30 Documentation flush before change, and don't modify replicated state while dormant 4:54 Documentation Highlights pt2 6:10 Documentation - Waking Guidance 7:00 Documentation Highlights pt3 7:45 Disclaimer, mistakes in video changing replicated state while dormant, and late flushing 8:36 Example 1: Dormancy disables C++ variable replication 9:19 Setting an actor's dormancy to DormantAll stops replication without flushing 9:40 The C++ Code for replicating variable, RPC, and dormancy flush 12:45 Exploring RPC behavior, RPCs essentially cause a flush 13:47 Changing a CODE c++ doesn't flush dormancy like blueprint does 14:20 Frequent changes (eg with tick) can keep your actor from returning to dormancy 16:00 Quick summary of some code specific behaviors 16:14 Testing Legacy replication (previously using push) 16:49 Code Dormancy Summary 17:01 Reminder: Flush before changing, don't modify dormant state 17:15 Blueprint and Dormancy behaviors 18:09 Modifying a blueprint replicated variable forces a flush 19:17 You can bypass the blueprint behavior accidentally, if you modify the variable in a way it can't detect 20:02 RPCs flush dormancy 21:16 Destroying Replicated Components - Example of where you must flush before changing replicated state 23:15 Types of Dormancy 23:57 DORM_Initial - Dormant Initial explored 26:58 DORM_DOrmantPartial - Dormant Partial explored, custom logic for dormancy. 29:09 Closing Summary 30:23 Outro