Hey, I too was having the same problem with root motion animations with motion warping on them being jittery on the originating client (instigator) but being extremely smooth and working as intended on the other clients.
After some tinkering about, I figured this out:
- The transform of the instigating actor which is set to be replicated by default through the details panel - conflicts with the root motion movement data that is fed locally on the client side.
- The play montage does not replicate & only runs locally on an event fire, and therefore any root motion applied does not automatically seem to get picked up for replication until the actor transform itself updates.
- As there is a disparity between the update rate of change of the transform by the root-motioned vs the Net update frequency of the replication - this causes jitter.
This thread already exists for replication of root motion, and I urge you to have a look:
Solution that works for me as of now: (this might not be the best way to go about it, please let me know if a more efficient or correct way exists)
- The way you have set up the RPCs are correct and will work (even though they are heavy on the bandwidth), however instead of the functional Play Anim Montage node, use the Latent Action Play Montage node
This will allow you to run useful logic when the animation completes and also work with Anim Notifiers if you require it. - Using this node, we can now replace the play anim montage on the origination client. We use the set replicate movement node to disable & re-enable the movement replication at runtime, so that only while the root-motion animation plays, movement is not replicated.
Screenshot:
Note:
-
Only do this on the originating/owning client, it is not required for the Multicast call. [in your case only for Event Trigger Anim Montage]
-
Option 1 works well for me, as in my use case the player move input is entirely ignored when RPC-replicated root-motion montages are played.
If you want changes made by player input to the pawn transform to be replicated alongside the root motion maybe try Option 2 and run the re-enable node from blend-out rather than on completed (as in the picture above), so during the blend-out time of the animation the server has time to get the updated replicated movement data. -
For root-motion animations which have motion warping, and the target for the motion warping (be it an actor, or a transform related to an actor) is being network replicated, then this method might cause motion-warping to fail - in the case the other client is currently in a root-motion animation, and our player enters into a motion-warped root-motion animation with that client, its transform or some component of it as a target, then on completion of that client’s animation, the target transform can warp (as the server will catch up after getting the new replicated movement data) and the motion warping can seem like it did not work - but this was because the target transform updated after the motion warping occurred on our client. This is a very specific case albeit that might occur rarely in some of action animations.
Hope this helps 
