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.
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.
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.
Edit:
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
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.
if(HasAuthority())
{
FVector NewLocation = GetActorLocation() + FVector(0.0f, 0.0f, 200.0f);
SetActorLocation(NewLocation);
}
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.
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).
UActorComponent::SetIsReplicated()
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!
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.