The A* Inspector
Brief overview of the various settings in the A* inspector.
The inspector of the AstarPath component has 5 sections.
Graphs: holds a list of all graphs in the scene
Settings: various pathfinding and editor settings
Save & Load: allows you to save and load graphs from files
Optimization: various optimizations that can be applied to the system using compiler directives
About: info about which version you have and some links to the documentation
There is also the 'Show Graphs' toggle which enables or disables the graphs from being rendered in the scene view, and lastly there is the 'Scan' button which recalculates all graphs. In the editor graphs are not scanned unless you press this button (or use the keyboard shortcut, see Keyboard Shortcuts).
Graphs
In the graphs tab you can see all graphs that are in the current scene. You may have multiple graphs and they are all stored in the AstarPath component (you do not create multiple AstarPath components). If you click on the 'Add New Graph' button you will see a list of all graph types that you can create.
Next to each graph there are 4 icons. 
They are:
eye: Shows or hides the graph from being rendered in the scene view. When the graph is hidden this icon will turn red.
pen: Click on the pen to rename the graph. This can be very useful if you have many graphs and it is becoming hard to keep track of which one is which.
i: Clicking on the 'i' shows some information about how many nodes there are in the graph. Note that you must scan the graph for it to show anything relevant.
x: Clicking on the x will delete the graph.
Take a look at each graph's respective documentation for more info about their settings.
Settings
Pathfinding
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.
Note
WebGL does not support threads at all (since javascript is single-threaded) so no threads will be used on that platform.
A* Pro Feature:
This is an A* Pathfinding Project Pro feature only. This function/class/variable might not exist in the Free version of the A* Pathfinding Project or the functionality might be limited.
The Pro version can be bought here
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
Warning
Reducing the heuristic scale below 1, or disabling the heuristic, can significantly increase the cpu cost for pathfinding, especially for large graphs.
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.
Warning
Reducing the heuristic scale below 1, or disabling the heuristic, can significantly increase the cpu cost for pathfinding, especially for large graphs.
Advanced
See
heuristic-opt
Game AI Pro - Pathfinding Architecture Optimizations by Steve Rabin and Nathan R. Sturtevant
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 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 AddWorkItem.
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.
If a startup cache has been generated (see Saving and Loading Graphs), it always takes priority to load that instead of scanning the graphs.
This can be useful to enable if you want to scan your graphs asynchronously, or if you have a procedural world which has not been created yet at the start of the game.
Debug
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.
Note
Only relevant in the editor
This will show the search tree for the latest path.
Note
Only relevant in the editor
Note
Only relevant in the editor
Colors
Here you can set the colors to be used in the scene view to visualize the graphs.
Here you can set the names of all tags.
Editor
Save & Load
In this section you can both save the graphs to files which you can later load, or you can configure cached startup: a way to avoid the sometimes long calculation time at the start of the game when the graph is being calculated.
Optimization
Compiler directives are a way to tell the compiler to exclude or include some parts of the code in the compilation. This allows for very drastic changes like removing or adding fields to a class or changing what a method does with no runtime overhead at all. This package has a few different options which can for example disable certain features to reduce the memory usage or improve the performance of the package.
About
This section shows the current version and links to the documentation.
Note
This always links to the latest non-beta documentation, however you can find the documentation for older versions or beta releases by clicking on the 'Show Older Versions' button on the download page: https://www.arongranberg.com/astar/download
Show Graphs
