Does anyone know if actor rotation replicates in all channels? I’m only seeing yaw update on the clients. The world is round so I have to extend the character movement component to get movement on a round planet. I’ve a RPC that updates the rotation on the server, which replicates to the clients. But right now only the location and the yaw of the character is replicating. When I test with multiple players I can see on the server player that the rotations are correct on the server. But the clients fail to get the roll and pitch rotations.
I’m a little further into this now so an update… I can fix the remote pawns rotation by having a rotation replicate, and then manually rotate them. This works, sort of. But as I move the client that controls that remote pawn on an adjacent client I can see its rotation twitches (big twitches not little) on the adjacent client (as a remote pawn). This leads me to believe that the servers rotation of this pawn is actually replicating, because it appears that it is setting the rotation using only the Yaw. Which has the effect on the client of first being set in the wrong rotation, and then the client updating the remote pawn with the proper rotation. Does anyone know where I can either disable the server from replicating this rotation automatically (just the rotation, I want the movement to replicate)? Or even better, does anyone know where I can force it to replicate the Pitch and Roll alongside the Yaw?
I have everything working except the rotation of the capsule on the clients side. My code is as follows:
The server function to modify the servers capsule and control rotation.
void AKoreChar::SERVER_ChangeFacing_Implementation(FVector inVec)
{
Capsule->SetRelativeRotation(FRotationMatrix::MakeFromZX(Capsule->GetComponentLocation(), inVec).ToQuat());
Controller->SetControlRotation(Capsule->GetComponentRotation());
pawnFacing = Controller->GetControlRotation();
}
The replication list (only using one FRotator value)
void AKoreChar::GetLifetimeReplicatedProps(TArray< FLifetimeProperty > & OutLifetimeProps) const
{
Super::GetLifetimeReplicatedProps(OutLifetimeProps);
//Gravity Scale, Adjustments in In-Game Editor
DOREPLIFETIME(AKoreChar, pawnFacing);
}
The AKoreChar Initialization
AKoreChar::AKoreChar(const FObjectInitializer& ObjectInitializer)
: Super(ObjectInitializer.SetDefaultSubobjectClass<UKoreCharMoveComp>(ACharacter::CharacterMovementComponentName))
{
bReplicateMovement = true;
bReplicates = true;
}
And finally the tick function
void AKoreChar::Tick( float DeltaTime )
{
Super::Tick( DeltaTime );
FVector lastInVec = GetLastMovementInputVector();
if (lastInVec.Size() != 0)
{
SERVER_ChangeFacing(lastInVec);
Capsule->SetRelativeRotation(pawnFacing);
}
}
Every tick I check the inputs vector size to see if we need to update anything. If so I call the server function with the last input vector. In that server function we get the new rotation for the capsule (pointing its feet towards the center of the world and its forward vector towards the last input vector), then I update the control rotation and store the value in the replicated FRotator. Back on the client, after the server call we update the clients capsule to the rotation on the server using the replicated FRotator. The movement and rotation work as expected on the server, unfortunately the client suffers from twitch effect. If I skip setting the clients capsule rotation and instead, set the capsule in the initialization to be replicated I get the exact same effect. So if I replicate the value manually - twitch, and if the capsule replicates itself - twitch. To add to the madness if I set bReplicatesMovement = false the twitch goes away. But then it’s not replicating the movement. It seems that replicatesMovement is also replicating a rotation. To test this further, I calculate the rotation on the clients side, abandon using the pawnFacing FRotator replicated value to ensure the rotation is correct. If I turn bReplicatesMovement back on, I get the twitch - even though I’m setting the rotation using the working calculation. This suggests that it’s not a wonky/ dirty value in pawnFacing but rather a rotation that is being forced to replicate in.