i have been trying motion matching (with replication) with lyra animation pack, but there seems to be a problem when spamming A and D keys repeatedly the owing client seems to predict the pose correctly while the other client seems to be stuck with just one animation (while the mesh is moving) please refer the above video and help me diagnose the problem
Problems with replicated motion matching usually stem from the fact that the trajectory component doesn’t replicate properly across the server.
I wrote a plugin that fixes this, and does so by replicating a minimal amount of data to prevent increased server load. Check it out!
https://www.unrealengine.com/marketplace/en-US/product/replicated-character-trajectory-component
4 Likes
Well the problem is root motion and any system based on root motion does not or will ever play nice over a network connection. Your example is a typical case of how network latency will always drop event packets if cleared by the sending client. If your ping is say 200 and you tap A fast then your sending start/stops with in a very small window.
Best practice advice is to stick with inplace animation when network play is required and leave root motion and motion matching for local.
In-place solves a lot of your network issues by using the movement component which keeps track of the network rep0lication requirement and error correction as well as current location in world space.
Not saying don’t use RM over network but the problem is the world orientation is controlled by the animation keys contained with in the root of the data and not by the the movement component as part of the character BP
Motion matching doesn’t use root motion, though.
In most cases, motion-matching systems use the default character movement component, and reference pre-calculcated root motion data to select animations based off the character movement component’s current state. No root motion information needs to be communicated across the server.
The current problem is simply to do with the fact that the trajectory component relies on the local information about a character’s controller.
This is fine on the owning client and the server, because they can access the controller. However, a client on the network cannot access another character’s controller information, which is where the in-built trajectory calculations fail.
My solution (the plugin linked above) makes sure that clients are kept up to date with other clients’ controller information, so they can perform local trajectory calculations correctly.
Advising to keep away from root motion for multiplayer, because it uses root motion, is a sweeping statement 
Granted, you can use root motion with motion matching, but I’d advise against it, and the official Epic tutorial content doesn’t do it either.