Replicated Character-Movement Keeps Resetting Mesh-Component-Transform!

I’ve got a really strange problem here… I am not sure, but it might as well be a bug.

I am using “morphing-algorithms” on my character meshes that change the overall size of the mesh (and many other things). This requires me to adjust the character’s collision capsule and the Z-translation of the mesh-component afterwards. There’s no problem with that. I’ve got a network setup and the adjustments are correctly carried out on server and clients.

The problem starts when I give characters (they all have an AI-controller) move-orders and character-movement starts replicating. At that moment, only on client-side, the translation of the character’s mesh component gets reset to the class default, cancelling my procedural adjustments and resulting in characters floating in the air or walking with their legs in the ground.

I disabled ACharacter::bReplicateMovement and the issue was gone. Other character-properties still got replicated, including animation-related stuff, but as long as they stood in place, the transform of the mesh-component remained intact - no floating. So I can be 95% sure replicated character movement is the cause.

Now, how can I fix this issue? I would like visual studio to do a “break” and show me the call-stack when the RelativeTransform-member of the character’s mesh component gets changed. I’m just not very experienced with debugging. I mean, I can use break-points (which is often enough), but in this case a break-point just won’t do. Any help, please?

But a break-point in Tick() won’t give me any info about what function-call is responsible for resetting the location-vector, would it? I mean, if the call-stack is at Tick() at the time of the break, it has already happened and I still don’t know how :confused:

you can setup conditional breakpoint at tick.

Right click on a breakpoint in visual studio, you will find Conditions item where you can setup what matches your “change” behaviour.

here is a picture

I tested some more and I’m narrowing down the cause of the problem. I know now that the reset happens on clients when replicated movement begins and that the value is taken from the character’s UClass::DefaultObject, all strictly client-sided (no replication involved here).

It looks like anyone can “replicate” the problem I am having.

Just create a new BP class from ACharacter in the editor. On BeginPlay, have it change the Z-translation of the mesh component. Give it something that deviates from the deafult value. Then place it in the map and start a server/client PIE. Everything should be as expected until the character moves, at which point the mesh-translation gets reset to the class default value.

… I call this a bug. And an annoying one that has already cost me a whole day.

I was finally able to figure out how to watch memory adresses by adding data-breakpoints. It’s like I expected: replicated character-movement keeps playing around with the transform of the character’s mesh component and changes it back and forth all the time. I haven’t yet understood how, but somehow it manages to revert the transform (from whatever you set it to after construction) back to the mesh-transform of the character-class’ DefaultObject…

Is this the intention, dear Epic staff? Is there something I can do about it without turning off replicated movement and/or smoothing?

This is the call-stack:

 	UE4Editor-Engine.dll!FScopedPreventAttachedComponentMove::FScopedPreventAttachedComponentMove(USceneComponent * Component) Line 1316	C++
 	UE4Editor-Engine.dll!UCharacterMovementComponent::SmoothCorrection(const FVector & OldLocation, const FQuat & OldRotation, const FVector & NewLocation, const FQuat & NewRotation) Line 6481	C++
	UE4Editor-Engine.dll!ACharacter::PostNetReceiveLocationAndRotation() Line 1343	C++

The transform also gets changed again from the destructor after that: FScopedPreventAttachedComponentMove::~FScopedPreventAttachedComponentMove()