Host of Listen Server sees low fps clients’ animations incredibly laggy/jittery. I’m using default UE’s Character with Character Movement Component. Clients see everything just fine.
I’ve seen a lot of post about this issue but little to none solutions, atleast none that would work.
Does anybody have solution for this?
Is this in UE editor or Steam or somewhere else?
How many players are playing the game?
What kind of PC does hosting PC have? Fast internet connection?
Sorry for the lack of information,
Its on Steam, host has good hardware as well as internet connection, client has poor hardware and poor internet connection.
First I had issues with rubber banding on clients, that got solved by changing DefaultEngine config:
[/Script/OnlineSubsystemUtils.IpNetDriver]
MaxNetTickRate=30
NetServerMaxTickRate=30
LanServerMaxTickRate=30
NetClientTicksPerSecond=30
bClampListenServerTickRates=true
MaxClientRate=10000
MaxInternetClientRate=10000
Now client has 0 movement issues, but new issues occured on host, as mentioned, clients animations are incredibly laggy.
How many players, and is everything replicating properly on clients (and host)?
It happens when there is just 1 host and 1 client.
Proper replication of Animation Blueprints? Because in the terms of replicating ABP, I basically use default ThirdPersonTemplate approach, ABP gets reference to character’s movement component and updates animations based on velocity, direction, etc.
Maybe changing those settings puts a burden on hosting server.
Try with more players, see what happens.
Well so far (when testing with 1 host and 1 client), I was able to get a fix with setting bOnlyAllowAutonomousTickPose to false, but now the animations aren’t laggy, but way faster than they should be.
What do you mean by this? You shouldn’t be replicating anything out of ABP. Client and Server should be making their own calculations.
All deterministic values should be set in the character class. The Anim BP references those for its calculations, transition logic etc.
If you are replicating out of animBP, which processes after character class, then you’re changing values after they are set by the character. This will cause a huge corrections loop.
Yes I’m sorry for bad interpretation, all ABPs are using only reference to Character’s CharacterMovementComponent, which is being replicated, and they just get the resulting values, such as velocity.
Good good.
LP’s : Low ping (sub 60ms, <1% loss and jitter)
HP’s : High ping (> 100ms, >1% loss and jitter)… higher pings have higher loss and jitter.
Are the Autonomous characters laggy/jittery when moving or is it the simulated proxies that are that way?
If its the sims then you need to look into network smoothing. All CMC sim movement is interpolated and networked smoothed. How much is determined by many factors including the latency of the update… how old the move is.
LP’s will see HP sims warping and jittery. Montages and animations can be out of sync with the action. e.g. shooting while reloading etc. LP’s get less smoothing in their updates because they aren’t as old and they are more susceptible to corrections. Corrections can result in animation resets, interrupts etc and so forth.
HP’s will see sim proxies movement smoothed out and typically no warping/rubber banding.
More info… Character Movement Component | Unreal Engine 4.27 Documentation
Looking at the Low FPS side of things you’ll need to dive into the game thread and rendering thread pipeline.
In order to render a frame the CPU must send the GPU Drivers instructions on what to render…aka Draw Calls. These aren’t sent until the game thread has fully processed its current workload.
I’d definitely be doing some profiling before I jumped into code. Narrow it down a bit.
If I understand proxies correctly, it’s only Autonomous characters that are laggy/jittery, but only from the Host’s side (as for him everybody is autonomous proxy). Host sees himself fine, but all client’s characters are laggy/jittery. Meanwhile client sees everybody fine (including himself as Autonomous proxy).
So far the only progress I was able to achieve was setting bOnlyAllowAutonomousTickPose to false inside Character’s OnPossessBy function, which eliminated laggy/jittery animations on clients, but it also made them run 2 times as fast (the animations, actual movement speed is correct)
Also just to add, if Client has up to 30 fps animations on Host are also smooth, but if Client reaches around 10 fps, animations are pretty jittery on Host (client is an ancient laptop)
Your hosts specs need to be up to par because you’re running a character and handling all server logic. Servers don’t run animations, effects etc. So as a Listen server you’re adding extra load to the servers processing.
It can get confusing.
The hosts side (SERVER) view of clients are laggy/jittery…
This is generally a latency issue on the connected clients end. They are laggy. You being the server are getting instantaneous corrections instead of networked smoothed and interpolated movement. Correction → Snap, Correction → Snap.
Yet, it could be a processing bottleneck, which increases frame time/server tick…which can cause frame hitching and stutter on the host local client rendering process.
So does that basically mean that there is no decent fix for the Listen Server to smooth laggy clients? Because my understanding of corrections is that if Server needs to correct a client, corrected client will also notice it, by for example teleporting him to a different position where the client is supposed to be. But in this case clients isn’t getting any corrections.
Read the CMC documentation. It outlines the process of corrections.
But in general the server compares each savemove against it’s own move for the same action/inputs. If it differs by a set margin it’ll send a correction. Otherwise it’ll send an ACK for the move.
The correction is applied in one of two ways. Small offsets will use interpolation of many frames to smooth it out. Large offsets use teleport.
You need a beefier host machine. Ensuring the server has enough resources to begin with is solid first step.
The problem is not simple because as a server you’re supposed to hold truth, and interpolation/smoothness is not the truth.
As an example scenario, lagging client might send moves packets (1,2,3) but you receive them in order (2,3,1). Server cannot advance until it has packets in order so it performs all three moves at once when it receives the first (last).
Regardless, Epic still added interpolation for sims movement on listen server, at some point :
(also controlled by this Cvar, which should be enabled by default)
Their implementation interpolates the primary mesh of characters away from their root, so the character location still holds “truth” but the visual mesh is fake.
As you can see though, it has zero handling for animations. Animation is ticked in TickCharacterPose.
A quick search shows that TickCharacterPose is called from SimulateMovement (simulated proxies) and MoveAutonomous (autonomous proxies, servers).
For clients on listen server, MoveAutonomous is used to perform movement when receiving an update from the client. So we are only ticking animations when receiving an update from client. This is most likely the source of the issue. The comments suggest that this was intentionally designed this way, or maybe this was designed for dedicated servers without much thought put into listen servers :
A quick dirty solution would be to call TickCharacterPose every tick, rather than waiting for client updates. This is essentially what bOnlyAllowAutonomousTickPose=false does, directly from within the skeletal mesh component. However now animations are gonna tick both from skeletal mesh component and from CMC so they’re gonna run twice as fast (and still be jittery from CMC). You have to also cancel out animations ticking from the CMC in that case.
Be aware that if you are using AnimNotifies to drive any gameplay elements, chances are this solution is going to generate synchronization issues as your server is now predicting animations instead of waiting for client updates. This is probably the reason Epic is not doing it.
So is there any better solution if I want to support listen server mode. And avoid the host player animation performance?
