How to – Units move up to blocked path

  • August 23, 2018 at 19:02 #23650


    If I were to completely block a path with a wall – then move command behind that wall, the unit does not move because there is no path. The behavior I am trying to get is have the unit move up to the wall and then stop because it cannot go around.

    I see an option called “navigateToNearestIfBlocked” but it is obsolete. But I dont think the path is considered blocked, just not available – to which the unit will not move at all.

    Any help appreciated, love the product.

    August 24, 2018 at 13:19 #23653

    The navigateToNearestIfBlocked property is the option you are looking for, however you will find it on the PathFinderOptions. It is deprecated on the SteerForPath component (many properties were moved to PathFinderOptions).
    It is important to know that performance wise, navigateToNearestIfBlocked is expensive since the path finder will exhaust all path options before realizing that no path exists at which point it can return the closest node to which a path exists.

    The only way to potentially avoid such a cost is to preprocess the destination if it is already known that it will be inaccessible, and then pick a valid destination before asking the path finder for a path.
    That is of course not necessarily possible or trivial to do. One tool that could be helpful is the GridEvaluatorClosestMatch which can do a brush fire search of nodes to meet some requirement.

    August 24, 2018 at 15:00 #23657

    Thanks for the reply, I will get to work on that!

    Id like to pose one more issue im having and can’t seem to fix. I have Path and Steer and the default steer strategy.

    If I were to spawn a unit and MoveTo() it goes to the waypoint like expected. If I spawn 2 units and MoveTo(), then select them and right click a new waypoint – they wont cancel the original path and go to the new one, they continue on. gif to demonstrate –


    • This reply was modified 9 months, 3 weeks ago by apolybus.
    • This reply was modified 9 months, 3 weeks ago by apolybus.
    August 29, 2018 at 13:05 #23675

    I missed your follow up question, sorry about that.
    Using the built-in input receiver, right clicking will simply issue a MoveTo command to selected units, so there is no difference between that and calling it from code.

    If the second argument (append) to MoveTo is set to true, the unit will add the requested destination as a waypoint to be moved to once it has reached all previously added waypoints.

    Using the standard input receiver, holding shift while right clicking will do this.

    Are you perhaps issuing path requests in a tight loop, which puts units back on their original path until they reached the first way point?
    I can’t really come up with any other reasons for the shown behaviour.

    I can only suggest that you set up some break points in the code to see the flow when issue the move command using the mouse.

    September 7, 2018 at 02:22 #23727

    This is default behavior using example from the steer. All I am doing is calling SpawnUnits() every 2-5f.
    Nothing else is custom code.

    It has to do with Unit Grouping Strategy and it is not reacting properly.
    If I select them single – it works
    If I remove the grouping strategy – it works
    If I select multiple spawned units they do not waypoint to my right-click moveTo.

    Here you can see units have spawned and are waypointing. When I issue a new MoveTo command (the perpendicular green debug path) they are not going to the new path – but rather stay on the original waypoint. It is easily to replicate.

    SteerIntro Group Pathing

    • This reply was modified 9 months, 1 week ago by apolybus.
    September 10, 2018 at 11:00 #23744

    I am unable to reproduce that behaviour.
    Please send the project to support(at) and I will give it a look.

    September 11, 2018 at 22:46 #23761

    The issue is that the newly created group is not stopped before being given a new path.
    This issue only happens if units start out pathing solo and are added to a group and given a new path mid-way.

    The SteerForPath component will continue to give input since it hasn’t been told to stop.

    So the fix for this is to ensure that you stop units before issuing a new move command. You can do this for all, or condition it so only units who are not part of a group are stopped first.

    The place to do this is in InputController.cs or your own replacement of same. In the original it’s line 122.

    Inject a call to Stop before issuing the move. You probably want to condition it on the append parameter as well.

    An alternative would be to alter DefaultSteeringTransientUnitGroup.cs line 260 and change StopInternal to simply Stop, but it won’t work equally well.

    I hope this gets you past that hurdle :).

The forum ‘Apex Path’ is closed to new topics and replies.