#Replicating a Character/Pawn with physics based movement

1 messages · Page 1 of 1 (latest)

bleak pebble
#

As I understand the Character class uses a Character Movement component which has a fully implemented networking, with server-client correction and so on.

Let's say Instead of a Character the player controls a physics based pawn who's movements are controlled by Forces via AddForce(). When testing I get mismatch in motion between Client and Server with Replicates checked on the blueprint. Is it possible to replicate physics? I would like for the pawns to be able to collide with each other and simply move around the map. I am a little stuck so any suggestions are appreciated, thanks!

Edit:
From what I understand so far, the client shouldn't be able to addForce() to its controlled pawn directly, but it should send request to the server, the server side applies the force and sends the updated location/rotation to the client side. I am still not sure how to call functions on client pawn from the server. Will keep looking.

Edit2:
Just found out about RPCs. Have the client send an rpc to request that its mesh be changed by the server.

visual rune
#

I'm not an expert in physics, but I remember reading this from one of Delgoodie's YT videos comments (not sure which one)

Commenter:


We still have a little problem when client do collision with an actor with physics sim. Any idea about how to solve this to look smoother ? Could I change the ball to be a character and use the same client prediction system to reduce these desync ?
https://youtu.be/p2k9bzyKBh8```

Delgoodie:

Hmm. This is a whole beast of its own because as you can see its not just a slight desync but the ball becomes completely different on the client and server and this is because the ball itself is not replicated (or at least doesn't have replicated movement turned on).
The problem lies in client side prediction. See, you can just enable replicated movement and the ball will be synced up with the server, but with client side prediction the client is moving before the server and thus when it collides with the ball, it needs to move the ball before the server moves the ball. This means for the ball to feel 100% completely natural on the client, we need the ball to be client side predicted, and OWNED BY THAT CLIENT. This works well for a character because the user is the only owner of their character but if multiple users want to influence the ball, all in the "future" the server has to do some tricky compromises for this. To get a feel for this check out this video on the production of rocket league: https://www.youtube.com/watch?v=ueEmiDM94IE.

All this to say, I would try just using the bool Replicated Movement since it will do a decent job. If the main mechanic of your game is interactions with this ball, however, and they need to be physics based with high precision, you will need to get your hands seriously deep.


Hope that helps
#

That first video there might be the same thing you're experiencing