Impossible use UE4 for a coop or mp listen server game due the unfixed network errors since 4 years

General Feedback & Requests
1

Take me about one week to find out the problem that I see the clients in my game with teleporting/lag/jitter error. No one know or have clue and there is no docs about this, not even examples.
Many people told me is because the bad quality of the animations, others because the bad networking implementation I made. But actually the problem its worst than that.

After many test seems like the problem only happen in the Server at see the Clients, but the Clients see fine the server. Was looking into the sources of sample games and even UT4. Until I found the problem its Epic Games didn’t fix the engine since the release and still broken, any Listen Server see the clients with jitter issues because an engine bug, not present in UE3 but in UE4 since 4 years ago or more and not fixed. And Epic set this as backlogged not priority bug Unreal Engine Issues and Bug Tracker (UE-32005) that affect any user making a cooperative game in this engine or that actually bought any marketplace multiplayer asset affected by the core of the engine, they can’t even host a game without the dedicated server system to play cause all will the problem its not even possible to aim someone cause it semi teleports.

Epic didn’t fixed this cause they don’t need it for their games you can’t even make a Listen Server in UT4 what its actually free, rater all its controlled by their own servers, the people can keep buying in the marketplace products that won’t work correctly ever if they don’t fix it for any coop or non dedicated servers multiplayer game.

What this means ?

This means you CAN’T make any game based in characterpawn and playermovement with coop or multiplayer listen server based. In other hand you can work with normal dedicated servers, but don’t think anyone will make a coop game or some multiplayer games with dedicated servers as the dedicated server don’t even work correctly if you make it and play in the same computer.

Is not just me, a lot of people have this problems aswell you can find over the whole network
https://answers.unrealengine.com/que…en-server.html
https://answers.unrealengine.com/que…en-server.html
https://answers.unrealengine.com/que…he-perspe.html

https://udn.unrealengine.com/questio…called-on.html

This aswell but the command fix me nothing or near nothing in my end https://answers.unrealengine.com/questions/45287/shooter-dedicated-server-lag.html

Its even in UDN as you can see since 4 years ago and no one made nothing.

This errors can be seen in any video using the Listen Server:

You can notice the players that are not the host are having this problems in a small scale when you play with people that have 80-100 ping is x3 times worst, you can notice teleports and more issues. Only the bots that run in the server can seem properly. This is a game when you need interact with other players can be bad. And worst in a multiplayer game where you host for your friends.

Thanks.

2

Agreed that’s a massive issue with the engine.This shouldn’t be backlogged.

3

I think Epic should focus more their attention onto these topics, because it really breaks down the gaming experience on listen servers. I think aswell this shouldn’t be backlogged

2 Likes
4

Listen server smoothing for client meshes was added in release 4.12. The issue that is backlogged is for forward prediction of the capsule position. If something is attached to the capsule it will not be smoothed, but the mesh is, so we recommend anything that is attached and needs to be smoothed be attached to the mesh. If there are cases where this is not working correctly, please let us know!

6

The skeletalmesh of the CharacterPawn are begin no smoothed only visible in the server side tested in 4.15 and 4.17

Tried many different things and no one works, you can check it, feel free to create a game in ShooterGame and check it by yourself as listen server with a real client, the simulated network ping in the same computer is not affected.

You can see it in the Tom sample of Survival sample.

As already said that is why the post is there cause the problem keep, yes I already read that “fixes” that actually don’t fix it at all looks like. I’m not the only one with this problem there are others, but as always no one post nothing I have to post all.

I’m sorry but after 4 years reporting others problems and fixing others problems, I can’t do that anymore, I can’t record a video right now or send a test project. If someone can give you it, perfect, or even if Epic can check it. But sorry I can’t anymore work free for others to keep as always.

7

It IS being smoothed, it has a different base smoothing factor than on simulated client side, which is settable in the character movement component itself.

Listen server has: ListenServerNetworkSimulatedSmoothLocationTime and ListenServerNetworkSimulatedSmoothRotationTime

The difference in smoothing (assuming you are looking at meshes actually attached to the default mesh of a character because otherwise they aren’t smoothed) is because the servers smoothing time is 0.04 seconds while the clients is 0.1 seconds. When movement ends the transition to capsule location is significantly quicker on the listen server side than the clients side, but this is changeable with those two variables above.

The REAL difference between server / simulated client side is that the simulated client is predicting velocity which means that their smoothing tends to predict “forward” of momentum while the server is lerping between states so its smoothing predicts “backward” from momentum. This is visible when looking at the character stopping as the mesh lerps backward from the direction of velocity into its correct resting pose on the client while on the server it lerps forward towards the direction of velocity into its resting pose.

Not entire sure if the above smoothing difference is intended? Its more jarring on client side to have the character stop and bounce backwards from its momentum but it retains its position closer than the server does during the actual movement itself.

8

Snip ?

As I said and as my first post says the problem is with the default SkeletalMesh mesh.
The talk about attached meshes is something you guys just take from the nothing.

Already tried many of the different things but no one works in my end.

9

Yes? And that is the “default mesh” that is smoothed that other meshes also have to be attached to if you want them smoothed.

And as I said the listen server has seperate variables that control the smoothing time and they are set lower than the client.

Edit also sorry I am in the habit of writing Snip when I partially quote someone but I didn’t actually quote anything.

10

My only question is why doesn’t he calculate the interpolation lag and adjust the client and server to match each other. In C++ you would create a up time an down time rate base on bandwidth with a predetermine object. The client Jitter can be adjusted as its just network data sync with client data.

11

Yeah I see that aswell checked other parameters but still not working for me :rolleyes: so probably something is wrong or I’m missing something ?

*There is a different between the value in the location simulated replication between the normal network about 0.1 and the listen that is 0.04

12

Turn the capsule to not Hidden and remove the animation blueprint so the start / stop running animations don’t cover up the transition

Then run the character around and you’ll see the lerp on both client and server and that they are different, for listen server side you can set the Smoothing time to something like 0.06 or 0.1 if you want to see it easier.

13

Still waiting some fix from Epic tbh Unreal Engine Issues and Bug Tracker (UE-32005)

14

Why still backlogged?
The p.NetEnableMoveCombining 0 helps, but how this works? Makes this something wrong with replicated movement?

15

Are there any updates on this? It would be really great to have proper client interpolation from the view of the server. It’s causing greatly higher bandwidth on my game to use the workarounds like p.NetEnableMoveCombining but things work perfectly when clients are viewing other clients or the server, it’s only the server’s view that is affected. Using these bandwidth heavy workarounds are extra wasteful here since it’s only to fix the viewpoint of one player (the server), yet everyone pays a much higher bandwidth cost.

16

+1 on the need to have this issue resolved.

17

This is still a problem at 4.23, don’t know about 4.24.

18

Still no efforts in fixing this. Incomprehensible.

19

Would this also relate to “Vehicles” whether they are Skeletal based such as “Sedan or AdvVehicle” or even things on marketplace like BlueMan Physics?

The reason I ask is for many years on and off with UE4 we have tried to get smooth multiplayer replication on our vehicles and our clients joining always have jitter/lag to the extent it has held us up on any developments moving forward. If what I’m reading here is directly related it is no wonder we have gone in circles for years and any help with smooth non jerky client vehicles would be a massive bonus to the community.

Thanks

20

Isn’t related at all these systems need their own systems, this is just for the character movement of the actual characters build in engine system.

21

+1 Hard to believe this is still an issue :frowning: