RAINNavigator and Path Calculation

[MithionParticipant]

Hello,

I have a project that I am using RAIN for, and it’s now using a custom nav mesh. This is because the navigation needs to be able to update in real-time, which from my understanding the RAIN meshes can’t do.

The nav mesh is a grid of squares, and needs to be able to update pathable to true/false from any grid to each adjacent grid square to it (think of a field that you build a building in - the path needs to update to account for walls and a door).

I have all that working now, and have moved towards path finding, and path following. I have the path able to generate correctly, but the problem is that I can’t seem to figure out where I should actually put the function call to calculate the path. I have a custom RAINNavigator class that I’ve been trying to use (based on the forum examples that integrate the A* pathfinding project into RAIN), but that one focuses on having a predefined waypoint set. In my game, there is a game object that the character always tries to move towards. So if I use something like the example where the target position is set in GetNextPathWaypoint(), it’s constantly shifting the target point around between the actual move target and the current position for the character. This causes the character to move around very sporadically. However, if I don’t put it in there, the path finder’s target position is never set (as nothing else I’ve tried seems to be getting called).

I put a breakpoint in at GetPathTo and GetPathToMoveTarget, but they don’t seem to be getting called. Are there any recommendations? Should I be looking to create a custom motor as well? I don’t feel like I should need to given the fact that I can just use the navigator to tell it where to move to, but maybe I’m missing something.

Any help would be greatly appreciated!

Edit:
I’d ideally like the path to be calculated based on a callback of some sort from a Move behaviour node.

• This topic was modified 6 months, 4 weeks ago by  Mithion.

[SigilKeymaster]

So in the Basic Navigator, we basically assume the motor will call GetNextPathWaypoint over and over as it needs to. We probably need a better name for the function, but essentially the Waypoint the function is referring to is a turn or point on the path you are currently heading towards. If your path isn’t smoothed it could be every grid square you hit on your way to the target if you like.

So essentially when GetNextPathWaypoint gets called we do the following checks:

• Is it a new target or is our path empty? If so start a new path.
• Is our target in the same spot? If not start a new path (keep the old one while it is made though).
• Is our path still being made? Keep making it (keep following an old path if it doesn’t finish though).

We keep all the information we need about the current state of the AI in our navigator: the last target, the last path point (waypoint) we were heading to, the current path we’re following, etc.

After that, we determine how far along we’ve gotten on our path. In our case, we call GetNextWaypoint on BasicNavigator.CurrentPath which does the dirty work of finding how far on the path we’ve gone. We return the position of the next path point as the result for GetNextPathWaypoint.

[MithionParticipant]

Ok, I understand. I think I can fill in the blanks from there, but I’ll post here again if I’m still stuck.

Thanks for the quick reply!

[MithionParticipant]

I’ve made some progress based on your answer, but was wondering if there is any additional documentation on the MoveLookTarget class - specifically what the fields are for.

Example: TransformTarget, VectorTarget, and WaypointTarget. These seem like they’re the next location to move to in the path, but when I set them it’s causing the values in the MoveLookTarget to be destroyed. Here’s what I have so far, maybe something will jump out at you?

public override MoveLookTarget GetNextPathWaypoint(MoveLookTarget aPathTarget, bool aAllow3DMovement, bool aAllowOffGraphMovement, MoveLookTarget aCachedMoveLookTarget = null)
{
    if (aPathTarget == null || !aPathTarget.IsValid)
        return null;
    _aiPath.TargetPosition = aPathTarget.Position;
    aPathTarget.VectorTarget = _aiPath.TargetPoint;
    Debug.DrawRay(_aiPath.TargetPosition, Vector3.up * 4, Color.yellow);
    return aPathTarget;
}

Setting _aiPath.TargetPosition to aPathTarget.Position alone will cause the path to calculate, and the character to move directly to the target point, but ignoring the calculated path. However, when I set the VectorTarget to the _aiPath current waypoint, it causes the MoveLookTarget’s position to change from the end goal and causes the pathing to jump all over the place. Is there some other value I should be using?

[SigilKeymaster]

So MoveLookTarget is supposed to be a helper class to represent the different kind of targets we can head to. The intent is for you to set a target based on its type, and then use Position and Orientation without having to care that its a Waypoint, NavigationTarget, or Vector3.

In your case though, the mistake is changing aPathTarget. Instead create a new MoveLookTarget with your position and return that. Perhaps we should change MoveLookTarget to a struct internally, that would solve this confusion, I’ll look into that.

You can also check aCachedMoveLookTarget to see if has a value and use that instead.

So something like this:

public override MoveLookTarget GetNextPathWaypoint(MoveLookTarget aPathTarget,
                                                   bool aAllow3DMovement,
                                                   bool aAllowOffGraphMovement,
                                                   MoveLookTarget aCachedMoveLookTarget = null)
{
    if (aPathTarget == null || !aPathTarget.IsValid)
        return null;
    _aiPath.TargetPosition = aPathTarget.Position;
    MoveLookTarget tReturn = aCachedMoveLookTarget;
    if (tReturn == null)
        tReturn = new MoveLookTarget();
    tReturn.VectorTarget = _aiPath.TargetPoint;
    Debug.DrawRay(_aiPath.TargetPosition, Vector3.up * 4, Color.yellow);
    return tReturn;
}

[SigilKeymaster]

Sorry, to clarify what I meant by checking aCachedMoveLookTarget: it is just an optimization, to avoid creating new MoveLookTargets in a function that is called a lot (which will hit the garbage collector at some point). The actual value contained in it isn’t of use to you in the function, it’s just provided so that the calling class can say “Here, use this MoveLookTarget I’m keeping around just for this purpose, instead of creating a new one”.

[MithionParticipant]

Ok I will try that. I also found out that I had forgotten to reverse the path waypoint array after calculating it, and that was causing some of the issues. While the character is now moving through the points more or less, I’m still seeing the path jumping around (though I haven’t yet implemented your suggestions). I will do so and update here.

Thanks again!

[Author]

Posts