I am working in Unreal Engine 5.7 and implementing a mounting system where a Rider actor attaches to a Mount. I am running into an issue where the Rider does not move along with the Mount after attachment. Instead, the Rider maintains its original world position.
It appears that the Rider’s Mover Component is not accounting for the actor being attached to a socket, effectively overriding the attachment transform with its own movement logic.
Is there a specific setting in the Mover Component I should toggle to ensure it respects parent attachment, or should I be disabling the component entirely while mounted?
I will be looking into this for you. Initially I was wondering if you have tried using a different attachment rule? Specifically one that has bWeldSimulatedBodies set to true?
Thank you for the suggestion. I investigated further and found that the issue persists regardless of the attachment rules. However, I managed to resolve the behavior by modifying
UMoverComponent::SetFrameStateFromContext()
as follows:
void UMoverComponent::SetFrameStateFromContext()
{
if (!IsActive()) { return; }
// … rest of the logic
}
It appears that even when the movement mode is set to “Null”, this function continues to execute and overrides the valid transformation gained from the bone attachment with stale data from the previous frame.
What is the recommended “Epic way” to handle this? Should I manually deactivate the component upon mounting, or would it be better to implement a custom “Attached” Mover Mode that explicitly pulls the updated transform from the
Your investigation is correct. The issue is related to how the Rider’s Mover Component determines whether to generate a relative transform based on the Mount.
One possible approach is to set updated component to the Mount’s root component. By doing this, the Rider’s Mover Component should generate a relative transform instead of a world transform.
[Image Removed]
Please let us know if this resolves the issue or if you have any additional questions.
This partially solved the issue, but this approach isn’t suitable for my specific implementation for two main reasons:
Mover Logic Separation: I need the horse to be moved by its own Mover Component, as it contains specific logic and settings that differ from the rider’s. While I am forwarding input requests correctly, I need both components to operate independently.
Physics State Issues: SetUpdatedComponent
overrides certain physics settings that are not being properly restored after re-assigning the original root component upon dismounting.
Do you know of any other way to ensure the Rider’s Mover Component respects the attachment transform without reassigning the Updated Component?
Thanks for the detailed follow-up. The additional context is very helpful.
We use SetUpdatedComponent because the Mover requires a valid UpdatedComponent to operate. In scenarios where the rider has no relative movement, using the horse’s root as the UpdatedComponent can be a reasonable solution. After calling SetUpdatedComponent, the horse can still be driven by its own Mover, and just need to forward some inputs to it as needed.
An alternative approach that keeps both Movers fully independent is to implement a dedicated UBaseMovementMode (for example, UFollowParentMode). This mode would drive the rider’s transform directly from the parent attachment’s transform.
From a physics perspective, collision channels typically need to be adjusted when mounting or dismounting, and the PhysicsVolume can be updated via SetUpdatedComponent.
Hope this helps. Feel free to reach out if you have any further questions.
Thank you for the recommendation. Following your advice, we implemented a dedicated Mover Mode to drive the rider’s transform. This has successfully resolved the issue while maintaining the independence of both components.