Why did Replicate components work?

Could you quickly say why enabling that component setting allowed the client boxes to go full height?
Were the text items slowing it down unless they were included, or was it something else?

Can you clarify exactly what you are asking?

In the video, the client-side boxes were not hopping to the same height as the server-side version.
The instructor ticked a box to replicate components which fixed the problem.
I’m just not sure why that was needed, it wasn’t explained.

1 Like

The replication checkbox enables the server to be in control. If this is not the case, clients move the box and other clients do not see that movement.

Generslly,in multiplayer game all clients take movement from the server, except for the player themselves. The player moves at the instruction of the client and it sends that to the server so all other clients Cs br updated. This is covered in a lot ore detail in section 4 of the coursem

I think what Pete is talking about is at around 11 minutes the instructor explains that, while the cube is being replicated, and clients do see its position being changed by the code, it isn’t moving as far on the clients as it is on the server. He explains that the fix is to turn on "Component Replication for the static mesh and it does “fix” it.

Since the code is running on the server, it is automatically replicated, but it’s acting slightly different on client and server.

However, it’s unclear why having replication enabled for the entire object and having Component Replication on has that affect.

This is the kind of thing that could cause bugs for new devs, since they see that replication seems to be working, but may not notice that it isn’t acting the same for clients and server, so a good description of what’s going on would be helpful.

1 Like

Ok, that makes sense. The course is not targeted at beginners however and more for those who have some experience (beyond taking a beginners course)

I’ll mention it anyway.

edit: You were right. The canned response comment was rude. I’m sorry for that. :edit

If we were talking about how to get an object to move, I would agree that it’s a beginner subject and a little too beginner for this course, but the course is obviously for beginners as multiplayer is concerned, and the question that Pete posed is perfectly in that arena. It’s no less “beginner” than many other things that are covered and explained.

The answer, according to me (also taking this course, so obviously not an expert) is this…
Components that are part of a replicated actor (the cube static mesh is part of the MyBox actor in this case) will “follow” the actor, and their position will be replicated on a kindof “best effort” scale even if Replicate Component is disabled. This is the part of very fuzzy on and I should have probably looked up before responding here.
When you enable Component Replication, it (the component : the static mesh cube here) is explicitly replicated, so it should be mostly consistant. It’s still not guaranteed every frame, but should update frequently enough to be “mostly” perfectly replicated.

I’m sure I said a lot of that wrong. This being a good question, it deserves a better answer. Hopefully, someone more knowlageable than me will correct me and/or fill in the gaps.

This is what a LLM (AI) had to say about it…
What you’re describing is a common source of confusion and frustration for developers using Unreal Engine. The reason the static mesh component is moving, but not consistently, is because of the way Unreal Engine handles actor replication. Even if component replication is disabled, the actor’s location is still being sent to the clients, which causes the static mesh component to move. However, because the static mesh component’s position is not being explicitly replicated, there is no guarantee that it will move in the same way on all clients. This can lead to inconsistencies and visual artifacts, as you’ve noted.

@Acecase as a TA, I will advise this. To prefix something with “not to be rude but…” usually means, I’m going to be rude. In those circumstances, I suggest not saying what you are going to say.

With that being said, l’ve been the TA for the other multiplayer course for over 2 years now and now this course so when I say it is not a beginners course, I know from experience that it is not. It is not canned response. Some questions I get often take me 8 hours or more to investigate and usually they are from experienced developers. Those taking the course should have done a project or 2 in unreal ideally (and like I said before not a beginners course) and usually have 2 years of industry C++ experience at least.

The course expects you to be able to research on your own and resolve issues which is why the course jumps in and does not hold hands. It will not provide all the answers.

As I said before, I’ll pass the original remarks onto the instructor

What I meant by “not to be rude” was that what I’m about to say could be misunderstood and taken as “rude,” but that is not my intention. I was disagrying with you, but not to be rude. The material that this section of this course is covering is basics of replication, and the thing that Pete_Baron asked about is something that stumps A LOT of people.

If covering turning on Replication for the Actor and explaining why is not too basic for this course, then covering why components have their own replication setting and why is not too basic.

I’m sorry if I came off as rude, but typically disagreeing with someone can do that; which is why I prefaced it.

If your criteria for “too beginner to cover” is “someone should already know it before taking this course” then I think it’s resonable to assume that people enrolling in a course named “Unreal Engine 5 C++ Multiplayer: Make Your Own Co-Op Game” really shouldn’t be expected to know much about replication. You certainly shouldn’t expect them to understand nuanced topics like why a component has its own Replicaed property.

In fact, now that I’m thinking about it, if anything, the question of “why” is too advanced for a beginner course if anything.

Again, disagreeing is not rude. I’m sorry if you feel like it was, but what you said to me in response made me defensive, so by those standards, you were rude to me.

@acecase has nailed my question exactly. I haven’t marked this as solved because the answer I was given appeared to be for a different question, although I may have misunderstood it.

The replication checkbox enables the server to be in control.

This appears to be talking about the general replication system, which is covered clearly and effectively in the course and was not the point of my question. acecase restated it nearly perfectly in this quote:

However, it’s unclear why having replication enabled for the entire object and having Component Replication on has that affect.

(emphasis added)

In regards to the beginner comments, I am a veteran games programmer of 40 years standing. I’m taking what should be a nearly trivial course given my experience level in order to nail down exactly this type of issue before I attempt an Unreal multiplayer project of my own. I have written and released multiplayer games and networking components in C, C++ and JS, I’ve also spent a reasonable amount of time learning the Unity multiplayer components for home experiments.

The issue at hand seems to be obscure at the least, and even if the explanation is only one quickly penned line, I would greatly appreciate it if you could share the correct answer instead of blaming my lack of immediate understanding.

Ok, so let’s clarify this. Not everything is replicated in a blueprint unless you tell it to. So, when you are running as multiplayer, the root component replicates as well as everything in the code that was specified. However, the shape is an ActorComponent (i.e. child component) and as default, actor components do not replicate - this would be sensible as you want to minimise traffic. So, as you create your BluePrints/classes, actors and so on, you can control which parts replicate and which do not.

This is why the shape moves on the server but not the client - the shape is not the root but is a component and therefore does not replicate as default.

There are a number of options that can be set for replication and the docs are surprisingly good for covering this. This specific scenario is explained in the link. I’ve given you the link to the Actor Replication section but the whole page is worth a read over.

Networking Overview for Unreal Engine | Unreal Engine 5.3 Documentation

Something of note. Pressing [control] and [alt] while hovering over a field gives you a better description of the field. This can be handy. This actually also explains what is going on and why it was checked.


The curious thing is why, before enabling Component Replicates, DID the static mesh move for the client and server, just differently on the client(s) and the server.

If the mesh didn’t replicate at all before ticking Component Replicates it would be simple to understand. However, it does seem to follow the actor to some degree; it just isn’t “the same” or “in sync”

The best explanation that I’ve found is that the children of the actor do “kind of” follow the parent, but they aren’t expressly put on the stack to be sync’d. It’s like they are on a seperate, and lower priority stack to be replicated and therefore they A. Aren’t replicated each frame/tic and B. Aren’t guarenteed to replicate at all. But, that was someone on Reddit who sounded good to me, so that may be way off.

I need to go back to check, but I think what we were seeing was actually non-replicated movement on the Actor. If the application of the force from the input is done on the client and the server, that would account for some movement but not ‘the same’ movement.

Of course if that is the case there may be follow-up questions :smiley:

Why apply force on clients if we’re replicating from the server? My guess: to help cover lag issues.
Why was it quite so different if the force being applied was equal? My guess: the force could be accumulating for as long as the input continues, and/or the box was not in the exact same starting state because it wasn’t replicating deeply enough.

I’m pushing forward with the course now because I understand enough Unreal MP to achieve my goals, but as a relative new-comer to this engine I’m finding the Unreal Editor UI very annoying to work with. Working through a nice simple game example should help me get used to its quirks.

Thanks for the clarification @beegeedee - I’m not able to mark as solved until I’ve checked it, but I do appreciate the effort you’ve put into that answer. The ctrl-alt combo for better tool-tips will be particularly useful.

I double checked myself to confirm. The mesh is an Actor Component and so doesn’t replicate as detault. This check box is only available on a tor meshes.

Now you have me doubting this again so I’ll check again but the checkbox is called (I think) “Replicate this Component” which means the mesh is a child in the main blueprint.

What would account for the movement (jitter at best) is the client moves the object, the server which takes priority resets it again so for a brief moment it looks like it moves but is forced back. This is only because the container actor is moving and it is a form of anti cheating to prevent bots controlling things in the gaming. It is also the same reason the cube on the server moves but not the client before check is switched on, only the server does not allow this behavior on clients.

To see what we’re talking about, go to the RepNotifies video at about 10:35 and watch to about 11:00 to see how it acts without the “Replicate Component” option turned on for the static mesh. It doesn’t just jitter. It almost seems to be working correctly. Just not quite.

Then if you go to 11:20 and watch to 11:40 you see where he explains that we need to turn on Component Replication and shows the difference.

So, what happens commonly to new players is we create a blueprint (or whatever) with a mesh component and enable replication for the actor, but not for the component and everything appears to be fine. The component appears to replicate, so we think we are good to go until we get a but report that the replication isn’t quite right.

To be fair, it’s good enough to just know that we need to enable replication for components, and beegeedee’s explanation that it’s a feature is a good one, and really all we “need” to know. We have the option to decide what parts of our “thing” need to have replication be important and which don’t for performance.

Why, on a low level, does it seem to “kinda” replicate without enabling Component Replication is still an interesting question though, and the new question to me now is, “what if I want the actor to replicate, but I want the static mesh component to never move?” That question is definately beyond the scope of this course though, IMO.

FVector NewLocation = GetActorLocation() + FVector(0.0f, 0.0f, 200.0f);

On the server the object is moving the 200 units, but on clients it appears to be moving about half, or 2/3, that much. This is WITHOUT Component Replication.

1 Like

This is a great question! OP, I understood what you were asking, but it was a little vague to anyone who hadn’t just watched the video.

First, I want to point out that it’s probably more important to know that enabling Component Replication on a replicated actor makes it more accurate over how it works. Reading around it seems movement components, inventory components are key targets for this.

What does it cost is the next most important thing for me to know. The UEDocs say, “The overhead for component replication is relatively low. Each component within an Actor that replicates will add an additional NetGUID (4 bytes) ‘header’ and an approximately 1 byte ‘footer’ along with its properties. CPU wise, there should be minimal difference between replicating a property on an Actor vs replicating on a component.” Seems low, if I thought it was more of an issue I would set up a stress test.

It seems a little academic to me, but here’s the link to the source code (We do have that) if you want to follow it:
AActor::SetReplicates() (Replicate movement is right after).
Might be worth following it in a debug build

I do believe that, although UE comes with a replicated CharacterMovementComponent (CMC), we’ll have to make our own replicated movement component, because it’s not that great. It’s decent, and may work for your projects. Alternatively, The Lyra Characters move smoothly even over a poor connection. I just played around with it, I didn’t do exhaustive research, but you can. I’m assuming the Lyra Sample Project has good example replication algorithms. However, the movement component is tightly coupled with the Character class, this seemed even more true in the Lyra code I read. The Character should handle the Character and the Movement Component should handle the Movement. I think that something to keep in mind if/when you start to make your own movement component. I couldn’t move a car or a dog with the CMC well. Moreover, I can’t make child Blueprint classes of the CMC, which is strange.

It’s important to think about what you need for your project. I’m not to concerned with cheating, so that make replication a little easier for me bc I don’t need the cheating algos. I can spend more time on open world HLODs and AI. Maybe you’re making the next competitive FPS counter strike.


Thanks @MyCody that’s answered the gist of my question (although I now have a lingering ‘why’ regarding “makes it more accurate” because that sounds like a weird API design choice!)

The source links (even the fact that we can look at it and debug into it) are going to be incredibly useful for answering future questions of this type.

Primarily I’m doing this course to try to get comfortable with the UE editor and API, without struggling through a bunch of introductory tutorials (which gloss over too many of the real-world problems with those elements, and often concentrate on the language and design issues that total beginners face). It’s working well, I’m at a point where I can watch the start of the video where he talks about what he’s going to show, pause it until I’ve tried it myself, then watch his version to see what he does differently and work out why (or sometimes, ‘if’) it is better his way!

I’ve noticed that the replication seems a bit janky sometimes, even with two instances running on the same PC. I’ll take a look at the Lyra system you mention, it sounds like they might have baked in a slightly better prediction/smoothing model.

Good luck with your project, and Thanks again!

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms