When moving at high speeds in a dedicated server setup, other player’s character set to flying mode appears to jitter, unsure about which location to be at.
Increasing the NetUpdateFrequency to 60.0f seems to substantially diminish the issue (not in packaged dedicated server though, only in PIE dedicated server).
After a bit more testing, it would appear that the movement is fluid even at high speeds, but ONLY when no acceleration is being applied. Clearly, it would appear that the current velocity of the charactermovementcomponent isn’t taken into account.
I am of course using bReplicateMovement = true, and this is in C++.
Could you provide a video of this issue occurring so I can have a visual for context?
Is this also occurring if you test using a listen server, or is it only occurring while connected to a dedicated server?
Would you be able to provide a set of repro steps, a test project, or modify the attached project if possible (you’ll have to convert it most likely as it’s originally a 4.14 project) so that it reproduces the issue you’re experiencing?
I am marking this topic as resolved to tracking purposes, as we haven’t heard from you in a few days. Feel free to reopen the thread when you get a chance to provide the requested information.
Upon opening it you should land in the Game map, with dedicated server ticked, and two players already setup. Simply hit play and see for yourself, the characters are set to auto move forward so I’d suggest not turning the camera too much
I have the same issue and have tried numerous replication ways around this for over a year and a half… I hope this gets solved.
Ive researched other people having similar issues but not the same… I have gotten speeds for twice what the video shows and its a bit more jittery.
Also this happens for not only character but pawns as well…
Thanks !!! I am seeing the same issue in UE4, the video that Altrue posted is exactly what I see as well. I haven’t been able to successfully compile the core engine yet, but I was wonder if it has to do with the server receiving truncated rotations of pitch and roll float to shorts when it packs the data? Since rotators are floats, I could imagine if the server received a less precise value, and the client has a more precise value, the client is always being re-adjusted.
After even more testing (coding my own pseudo “MovementComponent” - actually an ActorComponent) in a pawn (instead of a character), I have been able to once again find the bug
It clearly appears that there is an issue with the replication of the pawn’s position between the server and the ROLE_SimulatedProxy. I know that my code isn’t at fault here, because, well, I have exactly zero lines handling that. The pawn’s default code is the only thing propagating my server location changes to clients.
I say that the issue is between the server and simulated proxies because :
1- On Dedicated Server, each client sees its own pawn move smoothly at high speed without any issue. But sees other pawns jitter at high speeds.
2- On Listen Server, the listen server client sees everything moving smoothly at high speed, both its own pawn and everyone else’s pawn.
So that leaves us with an issue in the way pawn replication to clients is done.
EDIT:
After printing extensive logs of the SimulatedProxy location, it would appear that the SimulatedProxy’s pawn location is only updated every 2 or 3 ticks.
I believe the jitter comes from the fact that the simulated proxy is basically motionless 50 to 66% of the time, and then suddenly teleported two to three frames forward at once.
EDIT 2:
I can now confirm that simulating the motion of the SimulatedProxy in between server updates does indeed solve most of the jitter.
I however need to stress that this is using my custom implementation. With a Character and a proper CharacterMovementComponent, with unmodified code, the jitter is still present.
Over a year later and this is still backlogged. Falling from great heights causes this issue and I think that’s a reasonable thing to expect to work properly. Just giving a friendly prod, if that’s OK. For now I’ll have to override something in there with my own functionality.
I’ve gotten around to testing this in 4.20 and can confirm the behavior is still occurring when following the repro steps in the bug report. I’ll go ahead and update the affected versions to ensure our developers are aware that this issue is still occurring in 4.20, but keep in mind that this might not be prioritized or fixed soon.