UE 5.1 & 5.2 Client - Server seemingly out of sync constantly

[Codyn6263 (HSTech)]

Hey there! So I have 2 projects I’m working on, one really small and simple, and the other a larger project.

Small Project: 5.1 & EOS
Large Project: 5.2 & Steam

In both projects when I join a P2P listen server with my friends, all of the connected clients are incredibly laggy. Not in terms of performance, but rather the server seemingly resetting the clients location constantly. For the small project, it was literally just using enhanced input with add movement input nodes, that’s it.

I’ve tried smoothsync (the plugin), I’ve tried running the movement code on the client and server, I’ve tried adjusting config files, I’ve tried just about everything I can think of. I’m at my wits end here as to what to do one of my friends is less than an hour away from me and I still get the same lag when joining him. It’s not just movement either, but everything, including a box with simulate physics set to true and is replicated. It jitters and sometimes teleports.

I’ve gotten this to work fine with them in 5.0.1 as well as in UE4 previously so I’m confused as to what’s changed since then. No solutions I’ve found through constant google searches have fixed or even changed anything.

[Ullanar]

Same here. But we are using dedicated server. Ping ~63ms which is definitely not enough for those lags

[Codyn6263 (HSTech)]

Update: I made a fresh project in UE 4.26 with the exact same setup as I did in UE 5.2 and I had 0 jitter. I am now beyond confused

[Humanasset]

There is a lot of unknown variables here with your movement logic. If we assume it is setup correctly then you could try to increase your network update frequency. I can’t remember the default of the top of my head, but its relatively low as a default for player movement. Documentation says that it should be(I think) 20 hz, but I find that incredibly laggy and it needs to be much higher to run a smooth experience, especially when players are moving relatively fast and they are a good distance from each other on the network.

edit: If its not relative to your network update frequency, then it may be safe to assume your client and server are out of sync and its a code issue…

[Codyn6263 (HSTech)]

NOTE: I use advanced sessions for this. Every time the clients all run at 63ms ping which was seen using stat net in the console, this stayed the same through all changes

Here’s a list of things that I remember having tried

• Increasing the player blueprints update frequency
• Checking replicate movement on the player blueprint
• Replicating all the components including the movement
• Running the movement on the server and multicast
• Creating my own movement by manually moving the actors location and such
• Using both EOS & SteamOS
• Changing engine versions between 4.26, 5.1, and 5.2
• Increasing tick rates
• Using different friends as hosts with varied locations
• Adding a section to the config that’s suppose to increase net tick rates
• More that I can’t remember

It’s not just the player though. I setup a level with just a bunch of cubes with physics enabled and are set to replicate movement that would get an upward impulse randomly which was run on all clients (multicast) from the server. All the cubes would jitter occasionally as well as teleport at times. This also happened with just normal meshes dragged into the level with simulate physics on and replicate movement checked when they were moved.

As for the most basic setup I’ve tried, it was quite literally just the input action event for the directional input and camera input (vector with add movement input on it and the player set to replicate movement. Which you can see attached below.

Maybe I’m missing a step here, but isn’t add movement input networked by default when you check replicate movement? Even still, I ran it through a server event which called a multicast event, which then added the movement input and that still had jitter. All PCs used to test this are high spec and the lowest network speeds used are around 500mbps download and 30mbps upload.

[Humanasset]

Yeah, generally what is said across the spectrum is that movement is replicated out of the box, but I find that to be far from the truth. Maybe in a sense of local multiplayer idk.

As far as any kind of movement replication over the network from various points in the real world, I find it absolutely needs replicated events across the client and network simultaneously. The default add movement nodes don’t satisfy any of that and on dedicated servers you’ll likely find the character won’t move at all even on the client with it set up like that.

Given that the movement is updating very quickly, it’s a good place to setup these rpc events on the input axis values and you’ll get a nice smooth prediction over the network. The data transfer is actually very small, so it’s pretty effective, but if you run to much and or make them reliable, your connections can become saturated and kick the client.

So basically, what you have posted above, if you’d like to try the method I’m suggesting, you can setup just like you have posted in your screenshot above with a couple changes.

For the client, create a RunonOwningClient event and put your movement nodes behind it. Feed the axis float values from those nodes into that RunonOwningClient event. Call that event from your input and feed the axis values into that event.

On the server, create a RunonServer event and also a multicast event. Do the same thing on the multicast event in the exact same manner as the client event. Feed the axis values from the multicast into the server event. Also from the same line of logic from the original input source, call the server event as well and feed the axis values into that RunonServer event as well.

Now you’ll have a nearly perfect synchronized line of code over client and server. It’s probably good to set up duplicate add movement setups for the client and server so you can exclude certain things in the future from either if necessary. You will however need to call them from the same input. This also applies to left/right movement.

Given that you are updating and sending these very quickly, you can also run some branches, enums or whatever to switch on different speeds depending on stuff going on elsewhere in your code on the tail end of this and it’ll do a great job of picking up changes in variables without getting out of sync by trying to update movement speeds on other areas of logic.

I’ve heard others suggest other methods that I do not find to work at all, so idk what they are talking about, but what I suggested, I can attest to 100% does in fact work great with dozens of players over the network all over the world without any disconnections at all.

After setting up like this you’ll want to fine tune your network update frequency to the lowest possible amount to maintain smooth gameplay while also utilizing the least amount of bandwidth as well.

Docs say 20 hz or something low, but I see a lot of jitters in that in a fast-paced environment. I run much higher without issue, but that is on dedicated servers with nearly unlimited bandwidth. Locally run servers on client machines will have a dramatically less amount of upload bandwidth so that should be a consideration…

[Codyn6263 (HSTech)]

Its been awhile but I finally got around to trying your solution and it worked! I can’t believe it was that simple, all I was missing was the run on owning client. Thank you!