Hi, I wrote several feature requests what can be useful.
Perhaps something has already been implemented.
1). Immediate Pathfinding feature. (Very necessary!)
There is a bug without this feature: when many units send to target located on large distance from units - a part of units do not pathfinding a some time.
2). I wrote earlier: http://www.arongranberg.com/forums/topic/problem-with-getting-nearest-path-to-target
I see 3 solutions:
a) your solution: move the requested point to unit direction. (fast, but not for all cases)
b) get boundary nodes of target and sorting its by distance to unit; for boundary nodes: move the requested point from center of boundary node to unit direction and check that path is possible. (for all cases, but does not determine the shortest path)
c) same as case b, but with determine the shortest path. (slow)
3). Different scales of units do not take into account.
For example, a big unit will follow the same path as and little unit even if a path is too narrow for him.
4). GetNodesInBounds function
The AstarPath.active.UpdateGraphs(collider.bounds) function can determine nodes in bounds and do nodes walkable update. It would be useful also to create a GetNodesInBounds(Bounds bounds) function.
5). maxNearestNodeDistance will be better set in every seeker instead AstarPath.active.maxNearestNodeDistance
I understand as an alternative I can write custom modifier - http://www.arongranberg.com/astar/docs/_ending_condition_8cs-example.php, but it not a very comfortable solution for so simple feature.
Please, ask me if I wrote incomprehensibly something.
If I understand correctly, you mean that if you send a group of units to a far away region, there is a noticeable delay between when the first units start to move and all units moving? This is because pathfinding is not calculated instantly, it does take some time to calculate long paths. The solution would be to lower the search space which will make pathfinding requests faster.
Will be present for grid graphs in version 3.2. GridGraph.GetNodesInArea.
Yes, you understood correctly.
The problem is that in rts games sometimes need to send a many units to long distances, but at current api I do not see possibility to make it correctly.
I think it would be better to provide two variant:
a) current - StartPath();
b) immediate calculating (without use AstarPath.pathQueue) - StartPathImmediate(). It can to provide with ample opportunity independently to optimize a pathfinding calls for programmers.
In version 3.2 there will be a WaitForPath call which will force the unity thread to wait for a specific path to be calculated. I cannot make a separate call to calculate a specific path immediately because A* requires tons of temporary data for each path calculation, that’s why there are only one or a very low number of paths calculating in parallel. And since the project uses time-slicing, there can be a number of paths being calculated and thus using that temporary data already.
You can increase A* Inspector -> Settings -> Max Frame Time to increase the time the pathfinding is allowed to use per frame. It does not change much when using multithreading, but can have a very drastic effect when not using multithreading.
@aron_granberg
Is there any way to use GraphUpdateScene to get the graph updated immediately(without using AstarPath.graphUpdateQueue) - ApplyImmediately()?
We really need a immediately version of your pathfinding project.