So I stated doing multiplayer in c++ and already got my movement working with network prediction (crouch, crawl, sprint). Now I started working on an Interaction system for doors etc. But everything I could find online wasn´t network predicted, so any Ideas how you could accomplish a Interaction system/door system already tryed for serveral days now but I can´t find an solution to it.
thx for any help!
Character movement network prediction is client-side prediction. You input a move, execute that move locally then send the server the move and the result. The server in turn executes the same move and compares its results to your results. If they differ the server sends a correction, otherwise it sends an ACK. This is fully covered in the Character Movement Component docs.
World interaction is usually server authoritative which requires the server to validate and init the action. Standard flow would be: the client attempts interaction. If valid it RPC’s the server to interact. The server in turn does so and determines its own results. If valid it inits the action such as setting a repnotify state on a door. The door class in turn executes its onrep function for the state… effectively opening or closing via timeline lerp.
The client could RPC to the server to interact, then set the door state on its copy, thus forcing the onrep function to execute immediately.
You’d have to write your own correction logic incase the server fails interaction. RPC owning client to force set the local state to match servers state. This would reset the door.
The problem that’s going to cause the most havoc is RPC’s being dropped.
For example you interact and locally open a door. Your outbound RPC (interact) never reaches the server. Now you’re stuck with an open door you cannot walk through. The server will correct the character movement once you penetrate the door locally. Effectively rubberbanding you back.
It’s my personal opinion that you let the server determine gameplay. Allowing clients to manipulate the game world in such ways increases desync between clients and allows for unfair advantages.
Lets say we have a two player scenario. Player A has a 30ms ping and Player B has a 150ms ping. The server is running at 30Hz (33.333ms tick interval).
Player A interacts with the door. It’ll take 15ms to get their packet to the server. 33.3333ms for the server to process and update the door state. 15ms for Player A to get the result and 75ms for player B to get the result.
Advantage here is Player A. His door will start opening 60ms before Player B’s.
This offset doesn’t matter because Player B still has the same exact delay for every one of Player A’s movements AND Vice Versa. Player A is seeing Player B’s movement further in the past.
Player A inputs movement: 15ms to server, 33.333ms for the server to process and send out update, 75ms for Player B to receive.
If you add client-side prediction to the door then player A has now gained another 48.3333ms against Player B (108.333ms total on door opening). He doesn’t have to wait for a response from the server to start moving through the door and spotting Player B.
If this was a shooter game then the increase in desync could have Player B being hit/dead before the door even opens on their client.
1 Like
After reading your explanation I’m not sure if this particular case is related to prediction.
Look, I have a cylinder and it is replicating movement.
I move it only on the server side (in the Tick function).
The pawn does not interact with it.
-When the pawn moves in the same direction as the cylinder the cylinder stutters.
-When the pawn moves in the opposite direction to the cylinder, the cylinder does not stutter. (I think the problem it has something to do with relative position of the pawn respect to the cylinder).
I fixed the pawn prediction a few days ago. You helped me to do it.
When the pawn prediction was the problem the whole world stuttered (the camera stuttered).
In this case only the cylinder stutters and the rest of the world does not move.
So if the pawn isn’t the problem, then the problem is the cylinder…
So if is not a prediction problem… what do you think the problem could be?
Just in case… the problem only occurs on the client side… on the server the movement is perfectly fluid.
Thank you so much!!
Replicating movement on clients is pretty much a catch up and correct situation. Server is sending one update per tick. 30Hz server is once every 33.333ms. Meanwhile clients are ticking at 100hz +. Clients also have the collision in one place, while the server has it in another. unhide the collisions (rendering section) and turn on netshow corrections in console.
1 Like
Do you are referring to this, correct?
The p.NetShowCorrections 1 command does not show corrections in this case.
(Neither in cylinder nor in pawn).
Just in case… The cylinder is not a pawn… it is just an actor.
This is the movement code:
Did I do what you told me correctly?
If everything is correct and there are not error corrections… Any other idea?
Thank you so much!!
Hidden in game: false, is correct. This will render the collision.
Error corrections will be on your character. Red and Green capsule debug shapes. Only happens on clients.
I just to install the plugin " Network Prediction Insights" following this video…
I ran the p.NetShowCorrections 1 command as well (As you can see in the video)
both show nothing…
I know… Last week I spent three days using this tool (until I fix the problem)
This fixed the problem In the Character(But not in the cylinder):
#BaseGame.ini
ClientNetSendMoveDeltaTime=0.0166
ClientNetSendMoveDeltaTimeThrottled=0.0222
ClientNetSendMoveDeltaTimeStationary=0.0166
ClientNetSendMoveThrottleAtNetSpeed=10000
ClientNetSendMoveThrottleOverPlayerCount=10
Ah… I forgot… I also had to remove the replication of the capsule…
So I’m not sure that it really solved the problem… But the problem was fixed…
Only the cylinder is having problems now