Ok so I’ve been trying various methods to accomplish this for ages, but haven’t found a way around it.
My problem comes about when I introduce network latency, say 100ms. I have a tank blueprint that is based off of the pawn class. I have set up a location offset for when the player moves forward, I rotate the turret of the tank when they move the mouse, things like that. I have set it up so that when they press forward, if they are a remote client, they send a command to the server to move forward, and also run the move forward command locally too. I use the same method to rotate the turret. This works great when there is no latency for multiplayer, everything works as it should.
When there is latency however, When the player moves forward, they move forward on their screen, and then once the server runs the code, it teleports the player back a bit and then runs the offset commands until the client is where it should be. I know that the character class fixes this somehow, but that class isn’t suitable for what I’m trying to do. I need to find a way for the server to recognise that the client is where it should be on their screen, but finish executing the script on the server. From what I’ve read this is Server Reconciliation, but i have no idea how to do it. I really hope there is a way to do this, otherwise my game just won’t work in a multiplayer setting.
That’s what I was afraid of. I’m not the best when it comes to C++. I read through the Character Movement Component Class, but I just couldn’t make sense of how the replication works. I saw a lot about timestamps and getpredictiondata, but I just cannot figure out the steps required to accomplish this somewhere else. It’s just frustrating because I built the game around multiplayer, but if I cannot find a way to deal with network latency, I can’t continue.
I don’t think it can be either, at least not efficiently. I took a look through the movement component and the NetworkInterface and there definitely is some move saving and smoothing that happens. The problem is that it is pretty daunting. Unfortunately even the wheeled vehicles use server side control so the only example is the ACharacter class. I wish Epic would have implemented it for all controllable classes. Or at least the initial framework. Probably asking for too much though.
A good starting point i think is to setup movement input saving. Then comes the hard part of movement smoothing using prediction algorithms. Ive also read somwhere that “timeshifting” does wonders (offsetting client side inputs by a very small latency to give the network some breathing room).
I speak purely from hearsay, speculation and theory though. Making good netcode is a pretty daunting task
A good starting point i think is to setup movement input saving. Then comes the hard part of movement smoothing using prediction algorithms. Ive also read somwhere that “timeshifting” does wonders (offsetting client side inputs by a very small latency to give the network some breathing room).
I speak purely from hearsay, speculation and theory though. Making good netcode is a pretty daunting task
Any more information on this? I can predict user movement and camera rotation, but I would like more information or perhaps an example project on how to implement client prediction and server reconciliation.
/*
========================================================================
Here’s how player movement prediction, replication and correction works in network games:
Every tick, the TickComponent() function is called. It figures out the acceleration and rotation change for the frame,
and then calls PerformMovement() (for locally controlled Characters), or ReplicateMoveToServer() (if it's a network client).
ReplicateMoveToServer() saves the move (in the PendingMove list), calls PerformMovement(), and then replicates the move
to the server by calling the replicated function ServerMove() - passing the movement parameters, the client's
resultant position, and a timestamp.
ServerMove() is executed on the server. It decodes the movement parameters and causes the appropriate movement
to occur. It then looks at the resulting position and if enough time has passed since the last response, or the
position error is significant enough, the server calls ClientAdjustPosition(), a replicated function.
ClientAdjustPosition() is executed on the client. The client sets its position to the servers version of position,
and sets the bUpdatePosition flag to true.
When TickComponent() is called on the client again, if bUpdatePosition is true, the client will call
ClientUpdatePosition() before calling PerformMovement(). ClientUpdatePosition() replays all the moves in the pending
move list which occurred after the timestamp of the move the server was adjusting.
*/