v2.0.0 Changes List (also known as v1.14.0)

[Steve Walmsley (OP)]

Largest Planet Selected

When you click on the map and there are multiple bodies that could be selected, the highest mass planet within a 5 pixel radius will be selected. The dots for planets and moons have a 5-pixel radius.

This means when you click on a zoomed out planet with multiple moons, you will always select the planet rather than one of the moons.

[Steve Walmsley (OP)]

Wide System View

v2.0 has a wide system view option, similar to the wide view for the class window. The only difference is an extension of the system body list to show an extra six columns. The wide version of the window is 1900 pixels vs 1440 for the normal view.

The system view also has several new fields connected to eccentric orbits.

[Steve Walmsley (OP)]

Colony Cost Projection

One of the challenges with eccentric orbits will be comprehending future colony costs, so you can plan ahead accordingly. So far, you have the current colony cost plus the costs at perihelion and aphelion. Those are useful for understanding potential worst case scenarios, but with some orbits taking years, decades or even centuries, it is useful to have a more granular knowledge of how colony cost will change over time.

The colony cost projection view on the System View window projects the colony cost into the future based on weeks, months, quarters, years, etc. up to centuries. On the wide view you have up to twelve periods ahead for each level of granularity, unless SM mode is active in which case you will only see 8 due to space constraints. That is further reduced to 7 for normal view without SM mode.

The granularity extends to a single orbit for planets and for a single orbit of the parent body for moons. For example, you will see twelve future months for Mars, but only two future years. For Pluto, you can see 300 years into the future due to the 248 year orbit. In this latter case, the colony cost doesn't change much because Pluto can't get much colder.

[Steve Walmsley (OP)]

Sub Fleet View

On the Naval Organization window, you can now view the summary details of a sub-fleet in the same way as a fleet. The two screenshots below show the differences between selecting a fleet and a sub-fleet. In both cases, the movement orders, standing orders and history tabs apply only to the fleet (or the parent fleet if a sub-fleet is selected).

[Steve Walmsley (OP)]

Fleet Interception Interrupt

Due to the time advancement system, it is possible for an undetected alien fleet to suddenly appear on top of a friendly fleet. This is caused by the alien fleet passing through detection range within a single sub-pulse of the increment - 30 minutes for a 1 day increment for example.

In v2.0, for increments of one hour or more, Aurora will check the movement of all ships where the destination is either a hostile ship contact or a waypoint where hostile ships are also present. The latter case is because NPRs sometimes use waypoints to mark hostile ship locations. If the moving ship will move within 500,000 km of the destination, the increment is reduced to the length of time it would take to each that point. This is then rounded to an increment length which is a multiple of a standard sub-pulse length.

For example, a one day increment is selected. The moving fleet will reach 500k from the target in 25768 seconds. Increments between three and eight hours use 15m (900s) sub-pulses, so the increment length is rounded down to the highest number of 15m sub-pulses within the available time. In this case, that would be 25,200 seconds.

While this will still place the alien ship anywhere from 500,000 km to low millions of the friendly ship, it will no longer appear at point-blank energy range. This may not be 100% accurate, due to the wide variety of situations that can occur in Aurora, but it should massively reduce the chance of the unexpected, point-blank encounter.
           
EDIT: Testing has shown that a situation can occur where one fleet is chasing another but not catching it, in which case the shortened increments can repeat for a long time. Trying to calculate all the relative movements of the respective fleets would be one option, but would be complex and hit performance. Therefore, I've added a simpler solution. After five shortened increments of the same length, another shortening of the same length will be ignored.

[Steve Walmsley (OP)]

Starting Tech Points for NPRs and Spoilers

Currently, newly generated races ignore the research speed modifier for their starting tech points and apply it only for subsequent research. For v2.0, the research modifier will be applied to starting tech points for NPRs, Star Swarm, Rakhas and Aether Raiders

Regardless of modifier, the minimum starting points are 100k for Rakhas, 120k for NPRs, 400k for Raiders and 600k for Swarm (to ensure that key components and the essential nature of the threat are preserved). Precursors start with 600k tech points or 20% greater than the maximum player race starting points, whichever is higher. Invaders start with 1m tech points or 50% greater than the maximum player race starting points, whichever is higher.

This change won't make much difference to the early game (or to Precursors/Invaders for most games), but it will mean that later-game NPRs and Swarm in particular are not overpowered in low research rate games. If the early game is a concern, the options for minimum player systems can be used.

[Steve Walmsley (OP)]

Military Restricted Jump Points

Aurora already has the concept of 'Military-Restricted Systems', which prevent civilian traffic from entering a system. V2.0 adds 'Military Restricted Jump Points'. Applying this restriction prevents civilian traffic from entering either side of a jump point, but does not restrict civilian traffic from entering the systems connected by that jump point.

The restricted status of the jump point is set on the system view window, where an (MR) tag is added to the jump point destination. When a jump point is set as restricted, or the restriction is removed, the change applies to both sides of the jump point.

The Galactic Map has an option to display the restricted connections.

[Steve Walmsley (OP)]

Galactic Map Restricted Distance

A new 'Distance From Selected System (Restricted)' checkbox has been added to the Galactic Map.

This functions in the same way as the 'Distance From Selected System' checkbox, except the distance calculation will ignore any military restricted jump points. See below for a comparison between 'normal' distances on the left and 'restricted' distances on the right.

     

[Steve Walmsley (OP)]

Additional Conventional Systems

After reading a discussion on the forum, I've added a few extra systems to make conventional starts more interesting.

• Conventional Active Sensors - Strength 2
• Conventional Geological Survey Sensors - Strength 0.2
• Troop Transport Bay - Conventional
• Cryogenic Transport - Conventional

The troop transport bay and cryogenic transport are double the size of their standard TN equivalents, but otherwise equal in function and cost

[Steve Walmsley (OP)]

Hydrosphere Changes

Currently, when hydrosphere type changes from liquid to vapour there is an immediate conversion of all water on the surface into water vapour in the atmosphere. Conversely, when hydrosphere type changes from vapour to liquid there is an immediate conversion of all water vapour in the atmosphere into water on the surface, except for the small amount of water vapour that always remains in the atmosphere for a liquid hydrosphere. On the rare occasions where there is a direct change from ice to vapour or vice versa, the same principle applies.

Also currently, when terraforming a planet with a liquid or ice sheet hydrosphere type, adding water vapour to the atmosphere results in that water vapour gradually condensing to increase the hydrosphere at the rate of 0.1 atm per year, which adds 4% hydrosphere per year.

For v2.0, planets that change between vapour and liquid hydrosphere types will also use the gradual process. For vapour hydrosphere types, the water on the surface will evaporate at 4% hydro extent per pear. (so 50% would drop to 46% for example). Planets that change from vapour to liquid hydrospheres will follow the existing terraforming rules with no immediate condensation of existing vapour.

In effect, this means that vapour hydrosphere types can retain surface water and their main characteristic is now gradual evaporation of any surface hydro extent, rather than instant conversion to water vapour.

As a result, planets with relatively short but high eccentricity orbits will no longer have rapid changes between hydro extent and atmospheric water vapour. A planet that spends the majority of its time in the liquid water zone will tend to retain most of its water, whereas a planet that spends the majority of its time at a high temperature will end up with most of the water in the atmosphere. This also means that if you terraform a planet from the latter to the former, it can be made relatively habitable and won't revert to colony cost 2.00 due to instant evaporation of its water.

A planet that moves between ice and vapour during its orbit will still go through albedo changes, but this is much more manageable than the 'instant colony cost 2.00' issue of vapour hydrospheres.

[Steve Walmsley (OP)]

Dominant Terrain Change

For v2.0, any system bodies with an orbital period of less than six months, or bodies that are a moon of a planet with an orbital period of less than six months, can only be assigned dominant terrains that fall within the minimum and maximum temperatures of their orbit.

Bodies that fall outside this category will change dominant terrain based on their current temperature, which may change as they move around their orbits.

[Steve Walmsley (OP)]

New Planetary Terrains

Fourteen new planetary terrain types have been added for v2.0, taking the total to thirty-eight.

Seven of the new terrain types (Arid, Arid Mountain, Arid Rift Valleys, Grassland, Alpine Grasslands, Boreal Forest and Boreal Mountain Forest) have larger acceptable temperature ranges than any of the existing terrain types, but also have a minimum orbital temperature variation of thirty degrees.

The other seven are 'normal' terrain types and include Cold Steppe, Coniferous Forest, Rainforest, Mountain Rainforest, Subartic, Subartic Mountain and Alpine Forest.

As an example, the existing desert and cold desert terrain types have temperature ranges of 10C to 200C and -50C to 10C respectively and both have a maximum hydrosphere of 30%. The new Arid terrain has a range from -50C to 200C and the same max hydrosphere. So if a planet's orbit has too much variation for either desert or cold desert, it might still be suitable for Arid.

Grasslands and Alpine Grasslands vary between -40C and 80C, covering many of the existing types such as Steppe, Prairie, Savanna, etc. but will only be chosen for planets with a temperature range of at least 30C. Boreal Forest and Boreal Mountain Forest have a range between -50C and 40C with same 30C minimum range.

[Steve Walmsley (OP)]

Combat Capabilities vs Planetary Terrain

For the purposes of specializing ground units, any mountain or rift valley terrain type, including combined terrain such as Jungle Mountain, is treated as Mountain terrain for the purposes of Mountain Warfare.

Any desert, cold desert or arid terrain, including combined terrain such as Arid Mountain, is treated as Desert terrain for the purposes of Desert Warfare.

Any jungle or rainforest terrain, including combined terrain such as Jungle Mountain, is treated as Jungle terrain for the purposes of Jungle Warfare.

If a unit is specialised for the terrain type, the environment modifier is halved. These can be combined, so a unit with both Jungle and Mountain Capabilities would benefit from both in Jungle Mountain terrain and divide the environment modifier by 4.

[Steve Walmsley (OP)]

Admin Command Required Ranks

For v1.13, the required rank for an admin command is one rank higher than either the highest ranked ship commander directly under that admin command, or the highest required rank of any subordinate admin command, whichever is greater.

For v2.00, the required rank for an admin command will be the highest rank of the following:

• One rank higher than the highest ranked ship commander directly under that admin command
• One rank higher than the highest required rank of any directly subordinate admin command,
• One rank higher than the highest ranked commander of any directly subordinate admin command
• The manually assigned minimum rank for the admin command - see next post.

[Steve Walmsley (OP)]

Automated Assignment for Naval Admin Commands

Assignment of admin commands has been manual until this point, due to the difficulty in knowing a player's intentions for a given admin command. For v2.0, I've added the option for players to specify what type of commander they need for an admin command and then let auto-assignment handle the selection. A new section on the Admin Command tab on the Naval Organization window provides options for selecting a suitable commander. The options work as follows:

• Automated Assignment Checkbox: Toggles automated assignment for the specific admin command, which has two effects. Firstly, if no commander is assigned, the colony will undergo automated assignment checks during the construction phase. Secondly, if the current commander is promoted, they will be unassigned.
• Admin Command Priority: When automated assignment takes place, admin commands are checked in ascending order of required rank, followed by descending order of priority.
• Required Bonus: A potential commander must have this bonus to be assigned to the colony.
• Secondary/Tertiary Bonus: Commanders with the Required Bonus are ranked based on descending value of the required bonus, then by descending value of the secondary bonus, then by descending value of the tertiary bonus. The secondary and tertiary bonuses are not required for a commander to be assigned. They are used for ranking purposes only.
• Assign Admin Commander: Clicking this button removes any current commander and then assigns the highest ranked available candidate, which may result in re-assignment of the current commander.
• Assign Admin Vacancies: Checks every admin command without a commander in ascending order of required rank, followed by descending order of priority, and and assigns the best candidate. This is effectively a manual triggering of the construction phase auto-assignment.
• Reassign All Admin Commands: Removes all existing admin commanders then checks every admin command in ascending order of required rank followed by descending order of priority and and assigns the best candidate to each.

Manual assignment will still be the best option for important admin commands or where the player wants to assign a commander above the required rank, but the above should significantly reduce micromanagement.

In addition, an optional Minimum Rank can be set for the Admin Command using the fourth dropdown in this section. This option may be used to prevent regular changes in the Admin Command Required Rank when subordinate fleets with commanders of different ranks are frequently moved in and out.