April 24, 2018 at 21:33 #23129
I’ve noticed that my units sometimes escape the grid that they are on. When they do, they refuse to go back on the grid (they’ve tasted freedom, and they like it!). This happens if I get a unit to chase me to the edge of the grid. I’ve noticed that there is no way to make pathfinding more strict as to disallow this. https://imgur.com/nKCcyJ1
In the image, you can see that the dead space exists between the walkable and unwalkable areas. When the player jumps across this gap, enemies constantly fall off grid and down into the unwalkable grid area
April 25, 2018 at 11:00 #23138RamiKeymaster
- This topic was modified 10 months, 4 weeks ago by EmanTs.
Thanks for posting.
In Apex Steer there is a component called something like ‘Steer For Containment’, which will provide small forces to attempt to keep units on-grid.
Another option is to use invisible colliders at the edges of grids to keep units on them.
A third option is to adjust their movement capabilities on the speed component, such as the acceleration and deceleration, since units will typically fall off grid due to not being able to turn quickly enough or stop quickly enough.April 25, 2018 at 21:33 #23157
Steer For Containment did not suffice – it just made them fall down the cliff slower because they were trying to get back to their grid.
Invisible colliders are not really possible, as it would require way too much micro designing .
As for the speed component, we want enemies to instantly stop when they need to, so their deceleration is already at 9999999 (compared to an acceleration of 100) – that should be more than enough to stop[ before the end of the grid, no?April 27, 2018 at 19:33 #23166
To ensure that units stop on the spot, you also need to set the stopTimeFrame on the SteerableUnitComponent to 0.April 28, 2018 at 18:53 #23174
The path finder will never accept a position outside the grid, so unless the path is modified in a post processor to include such a position, the unit will never attempt to move off grid.
If given a position right on the edge, it can theoretically happen that it overshoots, but since you have the unit set to stop instantly, the only way it could happen that I can think of, is if the arrival threshold is set too low.
I kinda doubt that is the cause though and I am fresh out of other ideas.April 30, 2018 at 21:54 #23180
Solved: Essentially, what was happening was that the enemy was calling unitfacade.moveto the player every frame. If the move is not possible, the unit facade doesn’t care at the moment – it is a frame later that a stop is signaled. I needed to use some delay >0 for recalculating the path and it is good nowJuly 26, 2018 at 16:49 #23547
So I thought this was solved, but it is not really. It’s still happening, and I even did some regression testing – went back to when I said it was solved, and was able to recreate it. Enemies keep finding themselves off grid and then they are unable to walk a straight path to the player because no route exists. I even put higher “escape cell distance” values, but they stay stuck when just a unit or two away from the nearest node.
Shouldn’t they put an effort into getting themselves back on the grid? otherwise what does “Max Escape Cell Distance If Origin Blocked” mean?
EDIT: Come to think of it, I believe the wrong error is being thrown – unitFacade.lastNavigationEvent should be StoppedUnitOutsideGrid, but it’s StoppedNoRouteExists.
July 27, 2018 at 09:21 #23553
- This reply was modified 7 months, 3 weeks ago by EmanTs.
Areas outside the grid are not considered blocked, they are undefined with regards to path finding.
There is no functionality in place to steer a unit back onto the grid should it somehow get off grid, but you can create a steering component to do so, e.g. find the nearest grid and then the nearest cell on said grid and steer the unit to that location.
You could also modify the the path request logic such that if a unit is not on the grid, it will instead return a path back onto the grid.
That way you don’t need a custom steerer. You can achieve such a change using a path pre processor, there a some examples in the examples project.
Of course the best option would be to prevent units from moving off grid in the first place.
Steer For Containment set to the proper priority (highest) should still be the solution.
With regards to the event message, StoppedUnitOutsideGrid is returned if the unit requests a path while off grid (provided the requested destination is on grid).
So if you get StoppedNoRouteExists it would suggest that the unit is in fact on the grid.July 27, 2018 at 20:46 #23565
“Areas outside the grid are not considered blocked, they are undefined with regards to path finding.”
Well it’s off grid-ish. it’s within the constraints of the grid – there are just no nodes there – talking about ledges here. the player can jump between ledges, but the enemy cannot. Perhaps that’s why it’s not “out of grid”? Take a look at the image i shared in my opening comment of this thread. There’s the walkable area, the unwalkable area (the bottom of a pit), and then the area between (the area that Apex could not place any nodes – due to placement constraints, I suppose)
“Steer For Containment set to the proper priority (highest) should still be the solution.”
This does not help the problem at hand, and it just makes the enemies walk… very strangely.
I tried creating and queuing a CallbackPathRequest and checked that the path is valid before moving and when the enemy is stuck like i described, the pathresult status is “NoRouteExists” as opposed to “StartOutsideGrid”, so I think it technically counts as being in the gridJuly 30, 2018 at 13:55 #23578
Ok I see, it would appear that I misunderstood the issue, since in my terminology off-grid means outside the actual grid.
What appears to be the case is that units move onto blocked cells. They are on the grid but on an invalid cell.
For that situation ‘Max Escape Cell Distance If Origin Blocked’ is indeed a setting that will control the extent to which units will attempt to escape their invalid position. It will do so relative to the intended destination (i.e. sample towards that).
However what I am sure you want is for it not to happen in the first place.
My assumption is that when the unit is following the player, it has a pursue steering behaviour that disregards the grid and simply moves towards the player?
Otherwise I fail to see how it can move into a blocked cell.
You want to use SteerForObstacleAvoidance set at a high prio to prevent this from happening.
You must be logged in to reply to this topic.