also reduces amount of headings with only a single entry
SendAirStrike() - now listed under "Support Powers"
Guard() - now listed under "Combat"
FindResources() - now listed under "Movement"
Deploy() - now listed under "General"
SendParaTroopers() - now listed under "Support Powers"
Paradrop() - no listed under "Transports"
Teleport() should probably be listd under "Movement", but I don't know how to change that (currently listed under "General").
note that I changed "ScriptGlobal" to "ScriptPropertyGroup" for SendAirStrike() - I hope that does not screw up anything
In places where arrays were being treated as a set, just create a set directly. This reveals the intention of such collections better, and also improves performance by allowing set based methods to be used.
By providing a comparer that could change over time (as estimated costs on the graph were updated), this meant the priority queue could have its heap property invalidated and thus not maintain a correct ordering. Instead we store elements into the queue with their estimations at the time. This preserves the heap property and thus ensures the queue returns properly ordered results, although it may contain out of date estimations.
This also improves performance. The fixed comparer need not perform expensive lookups into the graph, but can instead use the readily available value. This speeds up adds and removes on the queue significantly.
The path caching works on the assumption that the time saved from reusing a cached path outweights the cost of caching it in the first place.
For unit paths, this assumption holds. For path searchs, we spend more time caching them then we save when we get to reuse these cached paths. This is because they are reused less often, and calculating their key is more expensive in comparison.
The caller can enumerate the list more efficiently without the IEnumerable indirection, and the reduced memory allocation is marginally faster than allocating a linked list and several nodes.
As the world tileset is fixed, the pathfinder can look up the terrain information for that tileset on creation. This is implemented by the WorldMovementInfo struct. When calculating node costs, this allows the pathfinder to avoid having to repeat this expensive dictionary lookup on every node.
