I hope Epic takes Mover seriously and finishes the project in a reasonable amount of time with adequate documentation/examples. After working with the Network Prediction Plugin, GAS, and Lyra, that seems like a tall ask tbh 😅
@@Rukgul Yea, maybe there are systems already in place in Fortnite that can be leveraged. Of course with a game like that they need to keep networked data to a minimum. However, you can do so many complex movements now in the game, maybe there are character movement innovations they haven’t yet ported directly to UE or Lyra 🤔
Hello, I cant run the test maps plugins. no idea why, but simply not showing on content browser after plugin install and reboot as suppose to, can any one give me any idea ? (and no, its not under engine/plugins)
tough to give a 100% answer. Mover is much easier to understand and expand. So for that I would say no, however I don't know how long Mover will be experimental vs CMC production ready.
Hi, Great Video! Got a question for you. I have always wanted to add the ability for my characters to climb a ladder. Could you create a new movement mode to do such a thing with this system? If so, any possibility I can convince you to create a tutorial for that? Thanks
You absolutely can. I can look into it. My biggest challenge is when should we make the shift from standard ABP state machines (like Lyra was designed on) to motion matching and when should we shift from CMC to Mover.
so I'm wondering now if you swap movement modes, it should be locally predicted? so if you test it out with some lag, it should look fine for the client
I have not done a lot of multiplayer testing on the new code. since we are at version 0.0001 I am sure they will improve the local predication logic. My take is they have started to move away from the hard-coded CMC model. This release is far from perfect but it does signal a shift away. Just like Niagara took several releases to fully replace Cascade - I see the same model being applied here.
it has network replication built in - HOWEVER it is an experimental release so it is not production ready. Look at the desync test maps. they are designed to test network desync correction.
Exactly, I gave up trying to add a climbing or flying system to my multiplayer exploration game when I realized that I was going to have to spend months and months researching and trying to code it all in to the CMC. With this new component on the horizon im gonna take a break working on character movement and maybe see if I can integrate it into my project later
Id love to get a simple example of how to make a move mode(and maybe transition) in blueprint. Doesnt have to be complicated As a noncoder, its difficult been difficult to wrap my head around.
This is just bad. People are going to get used to the workflow, then realize its too slow to actually use for more than a handful of characters/objects. Then when they want to change designs, the code for this OOP movement is split up among a ton of different classes. Unreal didn't know how to implement components, and now they have another bad implementation of components inside of other components, with hierarchies of overridden virtual functions... They are using a map data structure for a list of movement modes that will never be more than 16 entries. linear lookup in an array would be faster than a map at that scale, but a compiled C++ switch case would be the fast way to do it. The animation blueprint is a state machine, the behavior tree is another state machine, the movement component is another state machine, and they have a few other state machine systems, and they all suck. A game engine should only need 1 hierarchical state machine system, that should work for animations, movement, behaviors, dialogue, quests, cutscenes, etc... This would all be better as a scripting language that transpiles to c++, and compiles down into switch cases and constants.
Instead of bolting crooked plugins to the engine, it would be more productive to develop the classes existing in the engine with support for backward compatibility.
Plugins add modularity. Helps keep the plugins self contained where you get the workflow of if you dont want it, dont turn it on. If it was part of the engine then it would, well be part of the engine.
I hope Epic takes Mover seriously and finishes the project in a reasonable amount of time with adequate documentation/examples. After working with the Network Prediction Plugin, GAS, and Lyra, that seems like a tall ask tbh 😅
me too. I know they have wanted to upgrade the CMC for a while but the task is complex.
@@Rukgul Yea, maybe there are systems already in place in Fortnite that can be leveraged. Of course with a game like that they need to keep networked data to a minimum. However, you can do so many complex movements now in the game, maybe there are character movement innovations they haven’t yet ported directly to UE or Lyra 🤔
@@everything-bagel You can do flags, in combinations to do different things. IE holding jump pressing crouch when landing transitions to a slide.
Thanks for the video. It was very informative and a good update on what's to come.
Hello, I cant run the test maps plugins. no idea why, but simply not showing on content browser after plugin install and reboot as suppose to,
can any one give me any idea ? (and no, its not under engine/plugins)
i can defo see this as the future along side motion matching
Since Mover 2.0 isn't tied to ACharacter, shouldn't Mover 2.0 instead be referred to as "Actor Movement Component"?
One thing I can’t find any NFO on is how the new Mover Plugin can work with Motion Matching
Just working on a video to upload for adding a mode. I can look at that next.
thanks for the summary!
Is still important to learn how to extend CMC? I would to like your opinion please
tough to give a 100% answer. Mover is much easier to understand and expand. So for that I would say no, however I don't know how long Mover will be experimental vs CMC production ready.
@@Rukgul Awesome thanks for the answer!
Hi, Great Video! Got a question for you. I have always wanted to add the ability for my characters to climb a ladder. Could you create a new movement mode to do such a thing with this system? If so, any possibility I can convince you to create a tutorial for that? Thanks
You absolutely can. I can look into it. My biggest challenge is when should we make the shift from standard ABP state machines (like Lyra was designed on) to motion matching and when should we shift from CMC to Mover.
so I'm wondering now if you swap movement modes, it should be locally predicted? so if you test it out with some lag, it should look fine for the client
I have not done a lot of multiplayer testing on the new code. since we are at version 0.0001 I am sure they will improve the local predication logic. My take is they have started to move away from the hard-coded CMC model. This release is far from perfect but it does signal a shift away. Just like Niagara took several releases to fully replace Cascade - I see the same model being applied here.
hopefully we can change the capsule shape and transform for prone movement
That appears to be the goal. they are breaking the hard link to the capsule.
I want to know about how works mover in multiplay games
it has network replication built in - HOWEVER it is an experimental release so it is not production ready. Look at the desync test maps. they are designed to test network desync correction.
Exactly, I gave up trying to add a climbing or flying system to my multiplayer exploration game when I realized that I was going to have to spend months and months researching and trying to code it all in to the CMC. With this new component on the horizon im gonna take a break working on character movement and maybe see if I can integrate it into my project later
thanks for this vid
Id love to get a simple example of how to make a move mode(and maybe transition) in blueprint. Doesnt have to be complicated
As a noncoder, its difficult been difficult to wrap my head around.
I am going to do something like that. there is a lot of interest in mover. have to figure out if I want it in Lyra or as a stand alone
@@Rukgul my vote would be standalone.
Cool video but image quality is low, don`t know why.
Its just a youtube thing, sometimes it takes a while after upload to show the other quality settings.
my end shows the 4k version just finished processing!
This is just bad. People are going to get used to the workflow, then realize its too slow to actually use for more than a handful of characters/objects. Then when they want to change designs, the code for this OOP movement is split up among a ton of different classes. Unreal didn't know how to implement components, and now they have another bad implementation of components inside of other components, with hierarchies of overridden virtual functions... They are using a map data structure for a list of movement modes that will never be more than 16 entries. linear lookup in an array would be faster than a map at that scale, but a compiled C++ switch case would be the fast way to do it. The animation blueprint is a state machine, the behavior tree is another state machine, the movement component is another state machine, and they have a few other state machine systems, and they all suck. A game engine should only need 1 hierarchical state machine system, that should work for animations, movement, behaviors, dialogue, quests, cutscenes, etc... This would all be better as a scripting language that transpiles to c++, and compiles down into switch cases and constants.
Instead of bolting crooked plugins to the engine, it would be more productive to develop the classes existing in the engine with support for backward compatibility.
Plugins add modularity. Helps keep the plugins self contained where you get the workflow of if you dont want it, dont turn it on. If it was part of the engine then it would, well be part of the engine.