We’re currently evaluating the experimental Mover plugin for future production use and we have some items we’d like to clarify before we can fully adopt it.
Note: we’ve been using the default UE example character set for our exploration. The situation was the same in a 5.7 project, however we are currently working in 5.6.1.
--
First, we have not been able to get Layered-Moves to apply animations additively - they always behave as a total override.
Attached is a video of our attempt to layer a hit reaction (implemented as a layered movement), and a quick screenshot of one of our test setups. The character gets stuck midair when the layer is applied, and from the code it looks like animation driven root motion is disabled.
We expected the new animation to play without impacting the existing motion on the character. Is there a better way to handle setups like this?
(Note: We changed the `Backend Class` to `MoverStandaloneLiasonComponent` since our game is SinglePlayer. However the results are similar as with the default `MoverNetworkPredictionLiasonComponent`)
--
Secondly, there is a mention in the documentation about “Reciprocal Velocity Obstacles (RVO) avoidance is not yet supported.”.
Is it something on the roadmap for Beta or Gold? Any rough ETA there can help us plan ahead
--
Lastly, as the plugin moves to Beta, is there any expected upgrade path for data that we author with the existing version
(Should we expect to redo all our data / is it likely to be able to port over existing data etc.)
Is there usually any support for data created in an experimental plugin?
First up, the anim root motion layered move by default has a mix mode of OverrideAll, which is what’s causing your character to hang in mid-air. If you want the animation’s root motion to be additive, the layered move needs its MixMode set to EMoveMixMode::AdditiveVelocity. I don’t see a good way of doing this in Blueprint right now, but you could affect the change in UPlayMoverMontageCallbackProxy::PlayMoverMontage after AnimRootMotionMove is created, maybe expose additive vs override as an option on the UPlayMoverMontageCallbackProxy.
Second, for RVO support I do not anticipate the Beta version will have identical functionality as CMC. However, there are a few options here:
We have an example of avoidance using the Detour Crowd System. The MoverExamples plugin has a L_DetourCrowdMovement map that shows this. This map is a recent addition for 5.8, so only available on our public Github so far.
Some of our internal teams and licensees have leaned on Mass Avoidance.
Most of the pieces for classic RVO support are in place, and could be rigged up yourself. A colleague recommends creating an “avoidance” additive layered move, along with a subclass of UNavMoverComponent and follow CMC’s RVO support as a pattern.
Finally, I expect most of the data will convert, but there are no guarantees against data loss or API breakage with Experimental features. I fully expect breaking API changes between now and Beta. For instance, if you have implemented a custom movement mode, the function signature for generating moves will have to be updated. Hopefully you will not need to rebuild everything from scratch, however.
I’ve added a task for our team to expose mixing options for root motion from montages. Look for it in an upcoming release of UE. Thanks for the feedback!
We’re going to try exposing AdditiveVelocity as suggested. We would still like to highlight this as a feature request as well - it was one of the first things we went looking for in the new system and having a built-in Blueprint option would avoid us having to deal with engine merge conflicts in the future
For RVO, it looks like there are enough options to continue as without it being a big risk for us.
And for carrying data forward between versions, it is understandable that Experimental features cannot have the same guarantees. Likely the best we can do is peek at the latest versions of the plugin as they are being released.
