Mostly optimizations.

[hemoridos]

Started as a commit to reduce memory usage of the AI when copying planet surfaces, turned into a collection of optimizations and also fixed some of my bugs I found while playtesting.

Added a new class for storing basic information about the surface of a planet. This data is used for pathing and building placement so it only stores what kind of object is in a surface cell. The class consists of a byte array where each element represents a surface cell, and methods for accessing this array, converting location coordinates to indices etc. This data is now also used for handling surface pavements.

Optimizations:

• Planet surface data for AI building placement is copied to AIPlanet only when needed.
• Did the same for the list of buildings on a planet.
• Rearranged a few conditions so cheaper ones are evaluated first.
• Added a flag for planets that indicate to the AI that it has no paveable locations left.
• Use squared distance instead of Math.hypot when fleets check for nearby planets.
• Set a limit of 1000 on the length of the message history.
• Minelayer handling of groundwar AI is only executed if the AI has any minelayers.
• Extended location caching to cover spacewar locations.
• Added a collection for the list of neighbor locations for each location object. It is only populated if a location's neighbors are fetched.

Fixes:

• Fixed rocket sounds not playing correctly.
• Fixed Garthog virus carriers not moving to the other side of the battle space in some cases.

Misc:

• In spacewar clicking an enemy to attack will now attempt to target the smallest and closest target under the mouse pointer ie. the player can more easily target a fighter that is in the shadow of a battleship. Same as with selection.

[hemoridos]

Is the concern here the consistency of the data in AIPlanet (ie. building/surface data loaded later might not be consistent with planet statistics loaded at AI assign, though I'm not sure this is possible) or "just" a possible race conditions? If the latter, then I would rather make an attempt at implementing some thread safety around the fetch operations first. I believe the possible savings here would still worth it, as it turned out during testing (Level 5 mid-to-late game) that around half of started planning operations get to the point where buildings data is needed. This is even less for surfaces, around 5%.

Note: For what it's worth this time around I did a campaign playthrough to make sure I did not break much.

[akarnokd]

Consistency is one aspect. Accessing mutable state from a background thread so freely is the main concern and a big no-no. Trying to make it thread safe is very very difficult and causes inefficiencies elsewere. Today, memory is not a concern. We can just up the requirements to 1-1.5GB.

Please just leave the state-copy as it was.