Movement Replication/Prediction Snap

I’ve got a fairly simple, if not silly question about the way movement replication and prediction works.
As you can see in this webm http://webmup.com/2A43b when the other character has a certain velocity, it keeps moving and then snaps back into position a split second later when stopping.

Is this the way it’s intended to work, or am I doing something wrong? It just feels like I’m missing something obvious here.
The movement code is exactly the same as the Third Person Template and the snapping only happens when playing as the client, meaning that the server always sees the movement perfectly.

Hi Wisk,

Can you show me how your blueprint is set up with the replication data?

As I mentioned, it’s exactly the same as in the Third Person Template, no modification for the movement itself.

I’ve watched this videowww…com/watch?v=htdI2dh-aek&index=5&list=PLZlv_N0_O1gYwhBTjNLSFPRiBpwe5sTwc
And he didn’t add anything to the movement code, so I assumed that the movement replication is already set up internally for Characters ?

Hi Wisk,

In your player character, go to the defaults tab and look for Replicate Movement and Replicates. Make sure both of these are checked.

22169-replication.png

Yes they are.

I hope I’m not getting misunderstood, the character movement is replicated, meaning that I see both characters move around.

My problem is with the slight snapping that happens when the character stops. English is not my first language so sorry for any confusion created.

Hi Wisk,

Your English is quite good! I was checking to make sure that both were checked so I knew if the snapping was being caused by a confusion on the part of the editor. For instance, if you were telling it to both replicate and not replicate it may have been experiencing an error. I will continue to look into this to see if I can see what might be occurring.

Hi Wisk, I am running into the same issue. I believe this is caused by the simulated proxy actors in the client trying to predict where they should be based on their previous location and velocity, as you said. Check out the code in CharacterMovementComponent::SimulateMovement.

I am going to experiment with adjusting acceleration values to try and cut down on large changes in velocity, which is where this kind of prediction would introduce the most amount of error. This is not ideal since I want my controls to be pretty snappy, so if anyone else has any ideas that would be awesome.

Hi ,

Just to be certain, in your blueprint do you have both “replicates” and “replicates movement” set to true?

Hi , yeah I have both of those checked off. I am using a custom class I made based on Character and CharacterMovementComponent, but I was able to recreate this with the basic Character class as well: Make a project using First Person Game template, and add a mesh onto the HeroFPP pawn blueprint so that other players can see the pawn when playing in multiplayer. Launch a game with 3+ players. You will notice that, if you watch the window of client 1, the movements of, say, client 2 as seen by client 1 have a visible overshoot similar to what Wisk posted in their video. You will not see a similar overshoot effect when watching the server’s window, because the server is not doing any movement prediction.

From what I can tell this seems like an unavoidable side effect of clients predicting their movement before the server responds to their input? If you remove the client prediction, movement on the client side feels laggy and stuttery, which is worse.

With my pawn class, this overshooting is very exaggerated (and unpleasant looking) because the movements can be sudden and the acceleration is very high because instantaneous starting and stopping is the desired control style. The movement style is similar to that of a flying spectator.

Anyways, thanks for getting back to me, I am just curious if there might be any techniques for reducing this kind of overshooting on clients, I am relatively new to this, but willing to dig into the cpp and muck around with it. I’m thinking if I track the amount of time the user has been applying input, I could perhaps slowly blend in the amount of prediction used over this input time, to cut down on overshooting effect for short, abrupt inputs.

Cheers

Hey just a follow up: I was seeing this snapping when running in editor with 4 separate windows (1 server, 3 clients). Now that I am testing the game out where the server and client are on separate machines, this overshooting I was seeing is much less pronounced, and is more like a tiny wobble now. So, perhaps I was overtaxing my system running that many local multiplayer clients. Things seem pretty fine now. Cheers