Can confirm this too, was wondering why my capsule component attached to character animation was sometimes not registering… mind you this isnt best way to do this but it is related to problem.
its jittery kinda like animations on server are ticking too slow??
I’ve spent some time in my test project looking into it, but I’m not noticing any severe jittering with setup that I’m testing. I do notice that animations pop a bit when you activate slomo, but I would think that would be expected since they are running at a different speed, but let me know if I’m overlooking something.
Take a look at project I’ve provided and if you can replicate your issue in it, feel free to let me know and I can definitely take another look.
Will try to check this, basically here happen same I posted in forums, you can see it if you play with some real player, in local don’t happen need some kind of minimal 50ping or so from computer to computer and only server of listen server can notice it from clients, even I have seem problems with local bots happen to me in Survival Sample of Tom from Epic and Shooter Game of Epic aswell.
Affects to animation doing some lag, aswell player in general at move
As reference of problem you can see here clients moving not fluid compared to any other game https://www…com/watch?v=P0J77XYtmYY
Keep in mind as stated in thread that you’ve linked:
“Listen server smoothing for client meshes was added in release 4.12. issue that is backlogged is for forward prediction of capsule position. If something is attached to capsule it will not be smoothed, but mesh is, so we recommend anything that is attached and needs to be smoothed be attached to mesh. If there are cases where this is not working correctly, please let us know!”
I’m not sure what your component hierarchy looks like, but if you have components attached to capsule, you won’t see any smoothing which could lead to some jittering that you’re experiencing.
Let me know if you replicate it in test project I’ve provided.
As I reply him yeah still there problem even in 4.15 and 4.16 etc. Can’t try this as I don’t find any person that can/want try it.If someone from Epic can try it with me in europe area better then.
As second part we talk there is a problem with animations replication and your example have no animations what you want to check here then ? Aswell its Steam based and we are not using Steam.
1º First of all sample you provide don’t work with steam properly tried with other person.
2º Second of that don’t include animations so its impossible to test problem.
3º Don’t even work using direct connect.
4º Include content for test archivements, and not network at all.
5º A mate that works with you who made SURVIVAL TEMPLATE is public on Github you can see complete sample aswell complete hierarchy use it and check error, or even use SHOOTER GAME sample, have same problem.
6º Test it outside of lan/local network.
Sorry but no idea how many times I already wrote this and not sure if people read it…
Test any of this examples with other mate that have atleast 50 of real ping from you, and not from same office. Simulated on local are not working to see error as normal games…
I’ve done some further investigation, and it appears that there is not an easy solution for this at moment. I’ve found some threads that our developers have responded to internally that have provided suggestions for this issue and I’d like to share those here:
A few things that you could try would be to try to disable move combining on clients (p.NetEnableMoveCombining set to 0) which would come at expense of additional bandwith. Even with this change, you may still see jittering with lag variance or at low frame rates.
Also, if you’re not using networking Anim Root Motion, you could just allow animation to update at server’s rate. You could accomplish this by moving TickCharacterPose for remote clients into TickComponent in CharacterMovementComponent.
Another alternative approach would to smooth out pose on listen server, for remote clients. When you do an update of animation, it would create a new target pose to smoothly drive towards. Similar to how motion is smoothed out between client updates. It would make animation a little softer and mushier, but it might not be that noticeable. And that would be less work, and it would be more isolated, than previous solution mentioned.
Finally, you could look at how URO (UpdateRateOptimization) is smoothing out poses on client, and implement something similar for listen servers. Search for ‘AnimUpdateRateParams->ShouldInterpolateSkippedFrames()’.
URO works by skipping animation frames, essentially downsampling animation update. (For example skip every other frame, and animation update is running at half frame rate). But if ‘ShouldInterpolateSkippedFrames()’ is true, then these skipped frames are smoothly interpolated.
So on listen server rather than skipping a fixed number of frames, it would be a bit more dynamic, depending on when you receive an update from client, and when server needs to render a frame. But similar logic could be used.
After some investigation, it appears that we have an issue in our database (UE-3948) that related to motion on clients appearing jittery on listen server. I will update report with this post. Thank you for your report.
Ive been waiting since 4.10 for this issue to be fixed. I try every new version that comes out and still no fix. I need this to work because I am doing a multiplayer game at high speeds for flying and it looks like crap with no lag.
There are UDN threads that I think are unresolved aswell as some links are in net.
As another point "p.NetEnableMoveCombining " do nothing, tested time ago.
About last “UpdateRateOptimization” didnt tried it yet, will try in future.
Still I don’t feel like this is a problem users of a engine hav to resolve, as is a problem that affect us all, and should be working in engine as we can’t make a simple Coop or Listen Server multiplayer that work smooth…
Yeah I’m aware of that issue as well. I’d recommend trying solutions that I mentioned above, as those are currently what has been suggested when users are experiencing these issues in their projects. There are several tickets in related to this that are in various stages of investigation, so implementing one of solutions suggested above is your best bet to get this working correctly.
I appreciate feedback, and if you are able to implement solutions and are still running into errors, let me know and I can see what else we can try to suggest for you.
I came up with a solution that works for my case at least, unreal has a solution for normal characters default mesh and there children but it doesnt work for anything else and it doesnt work for papercharacter either.
offset is only visual because of course you dont want your server to ‘predict’ positions of colliders so it needs another method to visually blend movement of clients. So all you need to do is pull that predicted position out and set it in whatever object you are using. In my case papercharacter, here is my solution:
void AMythosCharacter::Tick(float DeltaSeconds)
{
Super::Tick(DeltaSeconds);
// forces method they use to visually offset meshes for normal characters to work with papercharacters.
if (GetNetMode() == NM_ListenServer && GetRemoteRole() == ROLE_AutonomousProxy)
{
FNetworkPredictionData_Client_Character* ClientData = GetCharacterMovement()->GetPredictionData_Client_Character();
GetSprite()->SetWorldLocation(GetActorLocation() + ClientData->MeshTranslationOffset + spriteOffset);
}
}
I just yank out that value (after internal tick) and assign it as an offset for sprite (spriteOffset is original relative position of sprite).
I came up with a solution that works for my case at least, unreal has a solution for normal characters default mesh and there children but it doesnt work for anything else and it doesnt work for papercharacter either.
offset is only visual because of course you dont want your server to ‘predict’ positions of colliders so it needs another method to visually blend movement of clients. So all you need to do is pull that predicted position out and set it in whatever object you are using. In my case papercharacter, here is my solution:
void AMythosCharacter::Tick(float DeltaSeconds)
{
Super::Tick(DeltaSeconds);
// forces method they use to visually offset meshes for normal characters to work with papercharacters.
if (GetNetMode() == NM_ListenServer && GetRemoteRole() == ROLE_AutonomousProxy)
{
FNetworkPredictionData_Client_Character* ClientData = GetCharacterMovement()->GetPredictionData_Client_Character();
GetSprite()->SetWorldLocation(GetActorLocation() + ClientData->MeshTranslationOffset + spriteOffset);
}
}
I just yank out that value (after internal tick) and assign it as an offset for sprite (spriteOffset is original relative position of sprite).
Also, if you’re not using networking
Anim Root Motion, you could just allow
animation to update at
server’s rate. You could accomplish
this by moving TickCharacterPose
for remote clients into
TickComponent in
CharacterMovementComponent.
Another alternative approach would to
smooth out pose on listen
server, for remote clients. When you
do an update of animation, it
would create a new target pose to
smoothly drive towards. Similar to how
motion is smoothed out between
client updates. It would make
animation a little softer and mushier,
but it might not be that noticeable.
And that would be less work, and it
would be more isolated, than
previous solution mentioned.
I am using networked root motion for one shot animations, do you think it’s possible to mix these two solutions? So that if an anim montage is playing it goes in animation lerping mode ticking as it does by default, and if it’s not playing it goes into tick at server’s rate mode.
If this is not possible, I will need to go with animation interpolation solution only, however, I get lost in SkeletalMeshComponent.cpp, can I ask for some guidance regarding where I could intervene to add this functionality?
As problem still exists in UE5 I decided to search for a simple way of getting around it. I came up with a solution even possible to implement in blueprints only. only downside of this solution is a SetActorTransform in EvenTtick for each client but no additional calls adding network traffic. If anyone is still searching for a solution I will attach a sample project for UE5 Early Access 2 below:
Maybe it relate to the ‘bOnlyAllowAutonomousTickPose’. If the bOnlyAllowAutonomousTickPose enabled, the animation timing to be driven by client’s network updates, in TickCharacterPose on CharacterMovement. But I can not find a good way to resolve it.