The A* Inspector

Multithreading puts pathfinding in another thread, this is great for performance on 2+ core computers since the framerate will barely be affected by the pathfinding at all.

• None indicates that the pathfinding is run in the Unity thread as a coroutine

• Automatic will try to adjust the number of threads to the number of cores and memory on the computer. Less than 512mb of memory or a single core computer will make it revert to using no multithreading.

It is recommended that you use one of the "Auto" settings that are available. The reason is that even if your computer might be beefy and have 8 cores. Other computers might only be quad core or dual core in which case they will not benefit from more than 1 or 3 threads respectively (you usually want to leave one core for the unity thread). If you use more threads than the number of cores on the computer it is mostly just wasting memory, it will not run any faster. The extra memory usage is not trivially small. Each thread needs to keep a small amount of data for each node in all the graphs. It is not the full graph data but it is proportional to the number of nodes. The automatic settings will inspect the machine it is running on and use that to determine the number of threads so that no memory is wasted.

The exception is if you only have one (or maybe two characters) active at time. Then you should probably just go with one thread always since it is very unlikely that you will need the extra throughput given by more threads. Keep in mind that more threads primarily increases throughput by calculating different paths on different threads, it will not calculate individual paths any faster.

Note that if you are modifying the pathfinding core scripts or if you are directly modifying graph data without using any of the safe wrappers (like AddWorkItem) multithreading can cause strange errors and pathfinding stopping to work if you are not careful. For basic usage (not modding the pathfinding core) it should be safe.

When searching for the nearest node to a point, this is the limit (in world units) for how far away it is allowed to be.

This is relevant if you try to request a path to a point that cannot be reached and it thus has to search for the closest node to that point which can be reached (which might be far away). If it cannot find a node within this distance then the path will fail.

The heuristic, often referred to as just 'H' is the estimated cost from a node to the target. Different heuristics affect how the path picks which one to follow from multiple possible with the same length

If a value lower than 1 is used, the pathfinder will search more nodes (slower). If 0 is used, the pathfinding algorithm will be reduced to dijkstra's algorithm. This is equivalent to setting heuristic to None. If a value larger than 1 is used the pathfinding will (usually) be faster because it expands fewer nodes, but the paths may no longer be the optimal (i.e the shortest possible paths).

Usually you should leave this to the default value of 1.

If toggled, graph updates will batched and executed less often (specified by graphUpdateBatchingInterval).

This can have a positive impact on pathfinding throughput since the pathfinding threads do not need to be stopped as often, and it reduces the overhead per graph update. All graph updates are still applied however, they are just batched together so that more of them are applied at the same time.

However do not use this if you want minimal latency between a graph update being requested and it being applied.

This only applies to graph updates requested using the UpdateGraphs method. Not those requested using RegisterSafeUpdate or AddWorkItem.

If you want to apply graph updates immediately at some point, you can call FlushGraphUpdates.

If batchGraphUpdates is true, this defines the minimum number of seconds between each batch of graph updates.

This can have a positive impact on pathfinding throughput since the pathfinding threads do not need to be stopped as often, and it reduces the overhead per graph update. All graph updates are still applied however, they are just batched together so that more of them are applied at the same time.

Do not use this if you want minimal latency between a graph update being requested and it being applied.

This only applies to graph updates requested using the UpdateGraphs method. Not those requested using RegisterSafeUpdate or AddWorkItem.

Graphs will be prioritized based on their order in the inspector. The first graph which has a node closer than prioritizeGraphsLimit will be chosen instead of searching all graphs.

Additional searches will normally only be done on the graph which in the first fast search seemed to have the closest node. With this setting on, additional searches will be done on all graphs since the first check is not always completely accurate.
More technically: GetNearestForce on all graphs will be called if true, otherwise only on the one graph which's GetNearest search returned the best node.
Usually faster when disabled, but higher quality searches when enabled. When using a a navmesh or recast graph, for best quality, this setting should be combined with the Pathfinding.NavMeshGraph.accurateNearestNode setting set to true.

This does not include loading from the cache. If you disable this, you will have to call AstarPath.active.Scan() yourself to enable pathfinding. Alternatively you could load a saved graph from a file.

Use less debugging to improve performance (a bit) or just to get rid of the Console spamming. Use more debugging (heavy) if you want more information about what the pathfinding scripts are doing. The InGame option will display the latest path log using in-game GUI.

This will show the search tree for the latest path.