I’ve also (after countless hours spent tracking it down) figured out how the Navigation system talks to a Movement Component. It calls ‘Apply Requested Move’, and feeds in a ‘Velocity’ value which is basically the full-length vector from it’s target position (the next pathpoint) to it’s current position. In the case of character Movement, it normalizes that vector and applies velocity in that direction. Since CMC auto-magically orientates the character to face the direction it’s moving in, it’s quite simple to do. In my case, I overrode ‘Apply Requested Move’ and it checks the dot product of the normalized direction to the target, and the crafts forward vector. It then applies rotational input based on that so that it ends up facing the right way, then it can apply the linear thrust/acceleration.
This is also where I started. I wasn’t entirely sure as shown in my question on the answers site, but knowing that others, or at least someone else, have also found this, makes me more confident in taking this approach. This is the kind of thing I was imagining when I first thought of doing this.
Somewhere , there’s also a path-finding manager (I think part of the blackboard / behavior tree system maybe?) which tracks whether the AI object is getting closer to it’s path destination or if it’s stuck. if it doesn’t get closer after ‘x’ seconds, then the move fails and the pawn stops moving. I Think this check is ticked in the actual AI task, so you may be able to override that behavior and somehow check if the vehicle is trying to steer or if the steering is stuck.
This is an interesting point that will have to be overcome. I will look into overriding this for vehicles.
That latter part makes sense for characters, but in the case of vehicles which can’t turn on-the-spot or want to turn BEFORE they jet off in that direction (or even those that need to go back and forth several times, like wheeled vehicles for instance), it’s blood irritating because the pathing fails if you’re not moving towards that location. Also, because of the steering problem, the majority of your “smart” movement for the object has to be handled in the actually movement component as part of RequestMove() or whatever it’s called, though that’s probably intended since different movement components would move differently anyway.
This is something that is ideal for what we are trying to do, because the movement isn’t hard-coded, it can be overridden, we (the users) can extend Unreal Engine to accommodate more pawn types.
I’m not sure this is relevant to your question tbh, but I’m all for diversifying the AI engine beyond just characters! I want to keep the awesome flexibility of Navmesh, but I need more control than the AI engine currently seems to give.
This is definitely relevant
I’m glad to hear that others are interested in this sort of thing as well.