What is the proper way to rotate character with replication?

Hello, thank you for taking the time to read the my issue.

I am trying to manually rotate my character to a replicated rotation variable but i see some jitter on the owning client.

I have:

ThirdPersonCharacter(Self) :

  • Use Controller Rotation Yaw: Unchecked

CharacterMovement :

  • Orient Rotation to Movement: Unchecked
  • Use Controller Desired Rotation: Unchecked

I am using “Play in new editor window” with 2 players and “Run Dedicated Server”.

Please see example of issue here: [Video showing rotation jitter][2]

As you can see in the video, the replicated rotation works, but is jittery. When using the built in “Use Controller Rotation Yaw” it works silky smooth.

I am trying to rotate like this so I can have more control over it. I would like to add an rInterpTo for example so my character can have rotation lag (smooth rotation lag hopefully).

  1. Is there a different way (different node/method) I should be rotating my character?
  2. Should the rotation logic be done in the PlayerController?
  3. Is this an issue with blueprints, i.e. this is easily done in c++?

Again, thank you for any help/insight into this issue.

1 Like

I have also had this major problem. so laggy, Have you found a way around the issue yet? Or is it still happening?

I have discovered the anwer on how to fix this if you are interested,

I’m Interested!

Can you please tell us how you fixed it?

Hey caelanim8ter, I would love to know how you solved it.

This is happening, because the Client Fights with multiple GetControlRotation values.

Make sure to only pass ONE Value, and let everyone use that one value.

Here is the Solution that uses the Event Tick. The Control Rotation is set via the InputAxis Turn.

The Character is NOT set to use any Control Rotation on default. So everything is done via the Events.

Local Client tells Server the Control Rotation. That one then Multicasts it to the Network Clients. The Local Client sets the Actor Rotation directly too, so he doesn’t fell a lag.

If a Listen Server Calls this, we need to make sure that not any other Server Version of a Network Client calls this, so we make sure the Server Version is Locally Controlled. If that’s the case, we skip the Server RPC and directly Multicast and also set the Actor Rotation directly, to fight any lag caused by the Multicast.

http://puu.sh/omkAJ/e767fb0290.jpg

I, myself, wouldn’t use the Event Tick for this. I would hook the InputAxis Turn up with the Rotation and I would add the Axis Value to the Current Rotation and then use the resulting *Actor Rotation the same way as I used it in the Event Tick Version. Difference is, the InputAxis Turn is only called locally anyway. So we need no SwitchHasAuthority node and also no extra Server Logic. We can simply call the ServerRPC and the Multicast for Clients and the ListenServer.

But, well, in the end, it’s up to you guys (:

Cheers!

eXi, thank you for taking the time, very much appreciated!

I have tried a very similar setup to what you have in the screenshot, and your description. I was still seeing some stuttering on the local character though.

I’m going to give it another go and see what results I can get.

Thanks!

This does in fact work as described. Thank you very much eXi!

One follow up question:
How would you handle adding interp to, to this?
My original goal was allow the camera to rotate around the character, then smooth rotate the actor to the controller rotation.

Just do all of this on the Client and replicate the final rotation back to everyone, like i showed you (:

I tried using this example to improve my lookat rotation function, it caused the server jitter on the client even more. Any idea how you would get 2 players to constantly lookat eachother without jittering?

I’m having the hardest time to apply interpolation to this. It all works fine until I add the “Net PktLag=” command. Not really sure how to make this example function with the interpolation.

This fixed my problem with pawns whose location is physics-driven but whose rotation is controller-axis-driven