Net dormancy and Net relevancy

UE V4.8.2

Hi we currently have a world full of building blocks in a multiplayer environment. When the actors become relevant on the client they add themselves to a structure but with large amounts of blocks becoming relevant at once this can cause a freeze on the client. We then tried setting bAlwaysRelevant=true to prevent the actors getting deleted on the client when they were out of relevancy range but this caused the replicate actors time to be huge when looking at it with the profiler.

I have been looking into Net dormancy and noticed it’s something that is used in Fortnite from reading this post CLICK HERE. You mention that you set the actors to dormant when not being interacted with but there seems to be a few different dormancy settings and I was wondering which ones should be used in this situation?

Ideally we would like to not have the blocks destroyed on the client unless they have actually been destroyed on the server but we also dont want to send any information about them if they are outside of a certain range of a player or they have not been interacted with. With these requirements should we use bAlwaysRelevant = true or false and how should we go about setting the actor dormancy for each channel?

Any help would be greatly appreciated.

Thanks,

Tristan

Hello!

Sorry for the delay. For Fortnite’s setup, we have all of our building actors in the world using net dormancy. We set them up in their constructor with:

NetDormancy = DORM_Initial;

which means that when we load in, each building will initially be dormant. We do not use bAlwaysRelevant, as we have far too many actors in our game for that to be viable. Keep in mind that if you want finer control over the relevancy checks, you can either adjust NetCullDistanceSquared on your actors, or directly override IsNetRelevantFor on your actors to do whatever you’d like.

If you’re using dormancy, there are two things you’ll want to keep in mind. One, right before you change any value that is replicated, you’re going to want to place a call to FlushNetDormancy in order to make sure that the clients actually receive the change. Two, to retain its effectiveness, especially during initial load-in, you’ll probably have to do some work on what you actually replicate. In Fortnite, we tried to do a pass that minimizes the chance we’ll have to wake a building out of dormancy during initial setup by trying to structure data such that the client can deterministically figure out some initialization on its own so that we don’t immediately force every actor to awake and negate the point of dormancy in the first place.

I’ll also ping the network team to see if they have anything else helpful to add, I’m just going from our experiences on Fortnite.

2 Likes

Thanks for getting back to me. Would you not need to have all the structures that are relevant wake out of dormancy when a new player connects in order to send transform data and class etc? We noticed there is a DORM_Partial setting which looks as if its for setting dormancy per channel using AActor::GetNetDormancy. It sounds like it would be useful for a situation like this with late joiners but the default implementation just returns false. Any tips on how to use this functionality?

Thanks again for the help,

Tristan

When a new connection is made, they will get latest info, even from things that were previously dormant for other connections. Dormancy is tracked per connection.

DORM_DormantPartial is meant to give a connection more control over when a particular actor goes dormant for that particular connection through AActor::GetNetDormancy.

Hope that helps, let us know if you have further questions!