Why Mesh->SetIsReplicated(true) but not other compoenents?

[acecase]

This is very close to the same question that we talked about early on when we first talked about enabling Component Replication, and we didn’t know why the component seemed to be replicated without it, but replication was only accurate with the property set to true.

This time, the Instructor flashes over what I feel like is an important distinction to understand. At about 4:50, the Instructor specifically turns on replication for the MeshComponent. He then shows that all of the other components have the same SetIsReplicated() fuction but says that “turning on replication on the Actor should also turn those on as well.”

The obvious question is, “what makes the difference?” What components, or maybe when, should we turn it on, and which components, or when, should we let them enherit it?

I know before that this seemed like it may be too much a beginner question for this course, but I disagree. I have been able to stay ahead of the Instructor over most of the course, so the fact that this question is one that I don’t understand, and it has come up twice, suggests to me that it’s not basic information. If I’m wrong, I’m sorry, but I think a lot of us would like to understand when we do and don’t explicitly set the property.

I’m going to attempt to answer my own question, because I believe I may know, but I would love to hear from someone more knowlageable and be corrected if I’m wrong.

From what I have found on my own, read it other forums, and from a really good breakdown in the other thread on this forum by the user MyCody, it seems like enherited replication is lower priority than explicitly requested replication.

So, in lay terms, if the replication, and its accuracy is important to gameplay, or if the lack of accuracy could lead to negative outcomes, you should probably explicitly set it, but it does come with minimal, but not zero, overhead, so you may sometimes choose to let it run in the lower-priority stack.

Again, I’m very very uncertain about my understanding here, so someone please correct me if I’m wrong.

[beegeedee]

Ok, I see why there may be confusion but given the fact this is maybe 3/4 of the way through the course, I think this shouldn’t need mentioning as it should be understood. I will however, again mention this to Kaan.

[acecase]

At this point, I feel like the basic understanding of “when” is there, but the question “why” still lingers. The “when” is something that I understand only because I’ve found answers outside the course.

I have to push back a little bit on the statment that 3/4 of the way in to the course this “should be understood.” The course has done almost nothing to help us understand this, so at no point during the course can you say it “should be understood.” We have been shown that it’s a thing twice, but have been given no explanation either time.

The best explanation we have is from MyCody in their response in the forum here.

[Pete_Baron]

I found this:

Component Replication

Infuriating language for a primary documentation page:
“cases exist where properties or events on components themselves need to directly replicate.”
what cases?
“Once the Actor is replicating, it may also replicate its components.”
may?
“These components may replicate properties”
may again! when do they? when do they not?

Somewhat more useful snippets (emphasis my own):
“Static components do not need to be made to replicate to exist on clients… [they do need] to replicate when properties or events need to be automatically synchronized between server and client.”

“Dynamic components are… spawned on the server at runtime” “[they] need to replicate to exist on all clients”
(and of course if properties or events need to be synced, same as the static ones)

Check out the Usage section in that page where the information is applied in an example. They make a Default Subobject (like in the lesson), which is a static component according to their definition: “static components are components created in the C++ constructor as Default Subobjects”. So it will automatically replicate to ‘exist’ on the clients but it has properties (with properties) that need to be replicated (e.g. GetNavAgentProperties()->bCanJump) so they SetIsReplicated(true).

I will add one thing after doing some searching for this topic… it feels to me like hardly anyone really understands it fully, and most people just turn it on when they think they’ll need it or if they see something that isn’t working properly. It’s not engineering when you’re guessing, but… games eh?

The Conan team made a really good and successful game but their explanation feels similarly vague and they often refer to those official docs pages for further information. The rest of this page is a goldmine of information about all types of networking concepts being used in an actual game with some nice concept summaries.
https://www.conanexiles.com/wp-content/wiki/2908586013.html#:~:text=Components%20replicate%20as%20part%20of,same%20way%20an%20Actor%20can.

[acecase]

I’m with you. It’s a topic that is discussed a lot and still no clean answers. I spent about an hour playing and it gets even more convoluted where physics is concerned. Specifically, when rigidbodies “go to sleep” it creates a situation where something that seemed to work fine without component replication no longer does, so a quick test may seem fine and then players will find the bugs later.

Seems like as much attention as this question gets, it would have a good description in the docs. This is very helpful though, so thank you.