Based on Mover previous documents and video, rootmotion in design would no longer be the first citizen, and we can blend rootmotion with other LayeredMove. But whether it is FLayeredMove_AnimRootMotion or FLayeredMove_RootMotionAttribute, their mixmode is OverrideAll. And even if I change Mixmode to AdditiveVelocity, it still doesn’t work. Because the velocity generated by LayeredMove will leak into UBaseMovementMode::GenerateMove, thereby generating additional unnecessary velocity. Theoretically AdditiveVelocity typed LayeredMove is incompatible with UBaseMovementMode::GenerateMove. In the CharacterMovementComponent, there is a variable named FRootMotionSourceGroup::LastPreAdditiveVelocity specifically designed to subtract the additional velocity generated by RMS. I think Mover also needs the same treatment. Do you have any plans to support AdditiveVelocity MixMode RootMotion?
Thanks for reporting this. It’s a known unresolved issue, and it should be supported. As a dev user, do you have any input about how you might want this represented? For example, would including the prior frame’s pre-additive velocity in Mode::GenerateMove’s context be enough? That could include velocity from the movement mode and/or any higher-priority overriding layered moves. Would you find the velocity just from the mode helpful as well?
It’s my pleasure to receive your reply. Our typical use case is that one character is being attracting (by traps, black holes, etc) while he is playing root motion ( attack s or hit reactions, etc). Also, we have complex movement projectiles which could be controlled by multiple layered move ( surrounding, homing, avoidance, etc) while they can have their own movement mode to implement something similar to MoveAlongFloor or SlideAlongSurface in CMC. I think including prior frame’s pre-additive velocity(only from movement mode) is enough for us currently, also, including higher-priority overriding layered moves sounds awesome. Thank you!