would you be able to please confirm whether or not Root Motion is working with Multiplayer and replication?
I cannot find any examples of it, and also no-one seem to be able to reply to confirm on my recent forum thread.
I haven’t found any other thread that shows a working setup either.
Please if you could take a look?
I can provide a scene if you want to make sure I am not making any mistakes.
I would love to know so that I can just abandon the whole idea of using Root Motion for my game.
At the root of it all. pun intended, character animation does not replicate period but rather the event that has been assigned as part of the movement component of the pawn or character BP is what gets replicated via proxy of the capsule or bounding box. The resulting animation is outputted as a conditional state of the velocity of the movement component with the character model hot glued to the bounding box and to trigger the animation you tell the animagraph to us such and such clip. It’s just super simple playback of a much more complex controller and you can see “all” of the stuff that the movement component handles for you by selecting it in the character BP and looking at the details panel.
Now the reason root motion doe not replicate out of the box is there is not a movement component designed for root motion use as in how the movement component works for inplace as animation authored as root motion contains both speed and direction so animation assigned as being root motion will conflict with a component designed for inplace animation and usually just kinds of twitches.
That out of the way the question as to does root motion work with in a project that requires network connectivity the simple answer is yes it does but to make things move you will need to replicate the controls that moves the character model and can not make use of the movement component that handles a lot more of the back end requirements than just replication. Example if using WDSA for movement control then you will need to replicate the movement keys and not the speed or direction of the movement component.
I’ve talked to more than a few coders on the subject and although root motion will give you much better looking animations it’s not a worth while trade off of tossing out the baby along with the bath water if your project is about making a game and not about doing cool stuff.
Hi Frankie, I am not sure if you looked through my original thread that was linked? But that is how I believe I have indeed set up my latest test scene, I am just replicating a bool that then locally to each player should trigger the root motion animation. That doesn’t work in the simplest setup. It just seems buggy.
Until I see a tutorial or example that is showing an exact working setup I think that I will now have to abandon the idea of using that and just go for a traditional animation playback, which is a shame because I really wanted to have feet sticking as it is a VR game and you are getting really close to those feet on the ground and having lots of sliding will look a bit shoddy. But as you say now making progress is more important than hoping for something that might never work.
I do think that if Epic knows this to be true, it should say clearly in the docs not to use root motion for multiplayer agents, to save people wasting countless hours on it.
Yeah trying to change a state with in a state machine using a nested argument is one of the many issues of networked root motion as in what I explained as root motion being more or less direct drive on input control and not as an event glued to a bounding box. Changing the state on the local client by argument does not change the state on the networked client as a replication of function but as behavior of the bounding box, capsule, and the animation being glued to a device that is triggered “after” the event has been replicated from client A to client B.
Root motion as a data set contains the required information for speed, direction as well as distance traveled over X number of frames and can be bound directly to any form of input creating a purely data driven system and replication becomes a lot more difficult as compared to pulling a ready made feature off the shelf.
As a concept how and where the use of root motion could or should be used is one of those feature additions that can do a lot of things in a lot of different ways but until there is a root motion movement component one can save themselves from a lot of suffering sticking with in-place.