always have velocity 0,0,0 (check by node/function “Get Velocity”) in first frame (frame of call move function).
Movement Component is one of the most complicated in Unreal Engine. When debug this component and related classes it can absorbed for hours or even days.
In many situations it is very important to reach target location and instantly go further to the next location. And when I reach location, so last Move To Function is finished I need to run next Move To function. Between them is one frame with 0,0,0 velocity which is visible in AI Movement.
Only solution I found is BEFORE last Move To function is finished, run next Move To function.
The only problem is performance. Always check vector distance or collision in tick is heavy when there are dozens of AI in scene.
Another problem is when I MUST put AI in exactly specific point. Then I cannot use mention method.
It is probably c++ solution, but maybe not. How do you guys solve this problem in your games ?
Rather than running on tick you could spawn a collision object with an acceptable radius at the location you are moving towards and on overlap run the next move to function. There is still a cost with spawning and having an object check for overlaps but it might be less impactful. (You also don’t technically have to spawn it, you could have a sphere collision component in your character that is moved to the next move to location, rather than spawning and destroying a new one each time)
What I want to achive is smooth motion between destination points
Without AI stop for one frame between “Move To Location()”.
The problem is when I have dozens of AI, collision is big and heavy deal.
Current solution is to check distance to Destination Location in Tick.
If I am close enaugh to Destination, run “Alternative Finish Action” - which call “Move To” another location. So, I have smooth movement without break for one frame.
But this is HACK, I should not do this. Every “Move To” should not be broken.
Guys from EPIC maybe don’t know it is a bug ?
If you go all the way to the end of the move, then… why would you still have velocity?
You reach the end of the move, you have nowhere left to move. It’s not a “bug”, it’s that you have a different requirement that is apparently more complex.
Overall, i’d say your solution isn’t terribly bad, but I would think that you can probably extend UPathFollowingComponent, and add some functionality to that, which would notify your AI Controller that it is almost to where it wants to be, so if there’s a new destination that should be calculated, go ahead and do that.
Yes, you are right. This is good functionality when acceleration and deceleration in ON. But when you turn off acceleration and deceleration then this functionality is an obvious a mistake or more probable bug.
I spent few full days (more than 50 hours) to read moving component code. Unfortunatelly zero velocity depends on many things, so I leave it as is and use my hack.
Unfortunately in UE 5.0.3 problem still persist.
I think moving possibility by Character on any Pawn is completly essential functionality and Epic should add bool to component to extend it’s functionality for option "in the same tick/frame I choose go someware without acceleration (component option), then speed should be it THIS frame. So move start instantly and NOT AFTER one frame. I thing many games or virtual productions met with this problem, because one frame break in movement is visible by human eyes.
Right, of course it’s still there. I don’t think most of us are waiting until a move is complete, unless we specifically want to do something at the end of the move. I haven’t actually implemented my suggestion before, as it’s not a problem I’ve run into, but it’s probably not a bad idea. Extending the path following system to give you a notification that you’re almost to the end of a move request seems pretty reasonable.
What I do with what I’m working on right now, is the AI tree runs a service that checks every 0.2 … 0.5 seconds to update where it’s going. My guys never stop unless they have a reason to stop (such as attacking).
No, of course most people don’t notice, because they don’t chain moves by waiting until the move stops before setting the next one. And even if they did, the Animation Blueprint usually has blends between various modes of animation, so you’re not going to see a big single frame transition into a stopped movement animation, you’ll see a smooth transition between two different movement animations (or if the same one, then it’ll blend out and right back in with no visible difference)
Just because you think something should behave differently than it does, does not mean it is a bug. Behavior Tree is not “very bugged”, in any way that I’m aware of (it might well be in ways I’m not, I guess, but for the most part, once you understand how it works, it does what it does quite well).
It is not a bug that velocity is 0 when you reach the end of a move. That’s the definition of the end of a move.
If you want it to act differently, you have different requirements than what Epic has, and you have the tools to implement it.
What specifically is the problem you are getting with a frame at zero velocity? (although honestly, i’d have to write a test to see if the velocity actually is zero, because if in the same frame your moveto ends, you set a new destination, it’s going to do that after the velocity is zeroed, so the new move should have a velocity)
…the Animation Blueprint usually has blends between various modes of animation…
Yeah, animation can mask problem but not solve zero in speed
Just because you think something should behave differently than it does, does not mean it is a bug.
“Use Acceleration for Paths” is false in “Character Movement Component” then it should …set velocity directly… as variable tooltip said So, when in frame 345 I set Character speed as 100, it should be 100 instantly as documentation said. Instead I have speed 0 in frame 345 and in frame 346 I have speed 100, until last frame.
Behavior Tree is not “very bugged”
I never meet senior ue4 programmer which not said “Behavior Tree is very bugged”. I’m also work with behavior tree a lot, and from the simplest like reading bad values from BlackBoard variables to most advance like graph condition nodes always redirect same route - regardless of the values of the conditions provided.
It is not a bug that velocity is 0 when you reach the end of a move .
In the last frame of move velocity is still maximum. The problem is with the first frame of move when “Use Acceleration for Paths” is set to FALSE. Velocity should be instantly maximum. But in first frame is 0,0,0.
If you want it to act differently, you have different requirements than what Epic has, and you have the tools to implement it.
O course you’re right. But Epic himself try to adapt Unreal Engine for as many types of project as possible.
Another problem is: I don’t want to write two thousand lines of code for achieve one little things. Especially if Epic programmers can change Engine in few lines probably.
What specifically is the problem you are getting with a frame at zero velocity?
I am creating a system for AI traveling between previously selected positions.
I don’t want to overload CPU with putting check location to next destination point in Tick
In many situations I need very precise movement, and change direction even one frame before destination is unwanted.
Some situations e.g. camera flying throu specific locations if stop for one frame is visible as distortion. Human eye can see pictures very clearly in 1/400 second.
If player are as FPP in automatic move, then stop for one frame is obviously visible (depends on current computer FPS).
You have access to the complete engine code. Or you can simply override whatever class implements the problem behavior, and implement your own.
Implement your own Movement component, or your own PathFollowingComponent, and just… do it. Or find where in the engine code it sets vel to 0, and remove that. Although then you’ll complain that Velocity is in the wrong direction, I suspect.
You have access to the complete engine code. Or you can simply override whatever class implements the problem behavior, and implement your own.
Implement your own Movement component, or your own PathFollowingComponent, and just… do it. Or find where in the engine code it sets vel to 0, and remove that. Although then you’ll complain that Velocity is in the wrong direction, I suspect.
Please don’t argue emotionally. It add nothing to the discussion.
I create tool (plugin for marketplace) and cannot modify engine for my plugin needs (Epic does not allow).
As I told before: I can write the whole MovementComponent. Write several thousand lines of code. Or ask epic to change few lines of code.
The next thing is compatibility with other parts of engine. With my own movement component will be a problem. My main direction in plugin development is to achieve maximum compatibility with current tool - because my tool extend engine should extend functionality - not to replace them.
eblade if you do not have anything constructive to say, please don’t insult me and tell me to program everything myself because I might as well create my projects in pure assembler.
I know there is possibility to write by myself Movement Component, but for me is NOT a good solution.
I have no idea what you people are talking about but logic say that if in this frame I tell something to move, it will start moving next frame. It can’t have velocity because it didn’t started to move yet.
I’m not attempting to be insulting, I’m attempting to provide you with ideas for how you can implement it, because Epic isn’t very likely to just go and “fix” something that isn’t broken.
Though I did just actually start reading through the MovementComponent and PathFollowingComponent code, I haven’t actually built a test to see if this would have the effect that you’re looking for …
Have you tried bStopMovementOnFinish = false in your PathFollowingComponent? It looks like setting that false would avoid the call to StopMovementImmediately that normally occurs at the end of a path. You might need to mix that with the Use Acceleration toggle in one way or another, not sure.
If you were to write your own PathFollowingComponent, it looks like all you’d have to do is override OnPathFinished() or OnSegmentFinished(). Certainly not several thousand lines, only about 40 if you have to completely override the functionality of it, a lot fewer if you can just do what you need and Super:: from it.
Alternatively, you could also implement something that interfaces with the MetaPathUpdate system to issue changes in the path before the AI arrives, sending them in advance in the direction you want to go.
There are many many different ways you could go about this.
I’m currently developing an alternative AI move to in my blueprints. I think it might solve your issue also, if you’re interested I could share it in another post and link it here. It cast to character blueprint via interface, giving an input every frame.
You mean that velocity is 0 while changing directions without being supposed to stop, right?
The problem I’m actually facing is that simple parallel is not working, so I created a node that do 2 things at same time that has also issues: I want to make a AI aim to one place while moving to other, which is already implemented and working in my character.
The one I created solved it! But it doesn’t avoid obstacles, like trees. So I was looking for similar posts.
