This can be used to avoid several lookups for these traits, as well as allow Actor to provide specialised methods to deal with target types efficiently. This also reduces some code duplication.
Previously, the Refinery placement check would first collect all cells
with resources inside the MaxBaseRadius, then perform a full findPos check
for each cell until one of them would not return null. The problem was
that if all of the cells returned null (for example if there wasn't enough
space between base center and resource, or if all suitable space was
otherwise occupied), it would basically check all tiles with resources
only to fail finding a suitable position and fall back to the normal
findPos check.
Since nearbyResources already performs a shuffle, I simply made the check
use the first cell from the list and use the basic findPos fallback if
that cell is null.
Closes#4717.
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.
- Cache the shroud projection even for flat maps to avoid allocating single element arrays.
- Avoid LINQ in shroud and map projection queries to avoid enumerator allocations.
- Avoid LINQ in calculation of sync values.
- Cache enumerables in ProductionQueue.
- Cache delegate in HackyAI.
The AI code runs on only one hosts, so by having the AI use SharedRandom values, the host's random gets out of sync with the other players' and crashes the game.
Moved water checks before --waitTicks.
Use Water enum instead of multiple booleans.
Check for BaseProvider rather than BaseBuilding.
Move expensive ClosEnoughToWater check to last position for naval
production override.
Early game AI usually follows the same build order (power plant first, then refinery), which also means they all start producing them at the same tick. This adds a random factor to the production delay, so not all AIs produce on the same tick.
Since naval structures have their own safety measures now and therefore shouldn't count towards failCount under normal circumstances, we can now assume that 3 consecutive placement failures mean lack of space. Therefore, rather than unconditionally resetting the failCount and retry every N ticks, we now cache the number of buildings and construction yards at the time of the 3rd consecutive failure and if the number of buildings hasn't decreased and number of construction yards not increased, we assume there is still not enough space and reset the retry delay instead.
