v2.6.0 Changes List

[Steve Walmsley (OP)]

Enhanced Precursors

v2.6 adds an additional option for Precursors. This is a separate checkbox called 'Enhanced Precursors' and will only function when the normal 'Precursors' option is active.

When Enhanced Precursors are active, Precursors are not immediately deployed when a ruin is generated. Instead, they are held in 'Tombs' deep underground and will deploy at some point after ruin generation. This deployment is known as Emergence.

The ground forces and each operational group will have a emergence clock, generated when the ruin is created. The ground forces will always have the shortest clock and will therefore emerge first to secure the surface. The bases and ships will emerge at some point after the ground forces and not all at once. This clock is randomised, so different ruins of the same type may have very different emergence timescales. Bases will tend to have shorter clocks than ships, but not always, and the small ruins will tend to have faster clocks overall, as their forces will tend to be small and easily deployed.

The timeframe for ground force emergence can be as long as twenty years, with the ships up to five years later. However, the emergence clock will run down faster than real time if there is activity on the surface or in space close to the planet. This includes ground forces and populations. Larger forces will have a greater effect on the clock, although this is not linear. Combat with Precursor forces will have the greatest impact on speeding up the emergence clock.

Unlike normal precursors, there is a significant chance a ruin is completely undefended. This is as high as 50% for a destroyed outpost and gradually reduces for the larger ruins, but a Partially Intact Colony still has a 20% chance of being undefended. When a ruin is defended, it will tend to have larger forces than normal precursors, with a 50% greater chance of each operational group type appearing.

These changes should add some more interesting decisions to exploiting ruins. While it is certainly possible to have a defending force waiting for emergence, they could wait years and there might be no defenders anyway. As time passes and more ruins appear, it will become more difficult to have defenders stood by in every location. Maybe a quiet approach is better, risking minimal forces to quietly exploit any resources without waking the defenders? Establishing a population is also risky on ruin worlds, even if the ruin itself has been exploited, there may still be entombed ground forces and ships, so populations will need to be guarded. Even different planets in the same system may be under long-term threat.

I may modify the detail behind the mechanics based on playtest, but the general principles should remain. I intended to run a playtest campaign on this relatively soon (which will of course be 40k )

[Steve Walmsley (OP)]

Enhanced Star Swarm

v2.6 adds an additional option for Star Swarm. This is a separate checkbox called 'Enhanced Star Swarm' and will only function when the normal 'Star Swarm' option is active.

When Enhanced Star Swarm is active, the initial chance to encounter the swarm in a newly-generated qualifying system (suitable mineral source) is reduced from 1 in 30 to 1 in 50.

This first encounter will be the only one that occurs 'normally' via exploration, as it is just the start of a Swarm Invasion. After that point, there is a 30% chance per year that new Swarms will be generated. As this is done per 5-day increment, there could be multiple swarms in the same year, or none for several years.

If a new Swarm is generated in a real stars game, it will arrive in proximity to the original invasion system in real 3D space. This is not necessarily close in terms of transits, but due to the way connections work, it should be in the general area. The arrival system is checked by arranging all known system locations (including those that have not been generated) in order of real space distance from the original invasion site and checking each one in turn with a 20% chance of selection.

If this is a random stars game (which does not have real space coordinates), the normal system number selection process will be followed, using the invasion as a start point and using the local chance and local spread settings to generate a 'destination' system. This could be an existing system, or an unused system number.

If an unused known stars location or unused system number is generated, the associated system will be generated and the new Swarm placed within it. This will be completely invisible to the player and any NPRs as they will have no knowledge of the system until they discover it (or something emerging from it discovers them). If this is an existing system, the Swarm will be placed in deep space, around twice the distance of the outer survey location ring. This could be an NPR system or player system.

The new Swarm will be generated in the normal way and may have different designs and technology to the original swarm. Later arrivals will generally have better technology. When a new "Invasion Swarm" is generated, there is a 20% chance the invasion will end and no further Swarms will be generated in the game.

[Steve Walmsley (OP)]

Ground Unit Training Costs by Population

For v2.6, the training costs of ground formations with special capabilities may be reduced depending on where they are trained, based on the conditions at the time training begins. If a ground unit class has special capabilities, such as desert warfare capability, high gravity gravity capability, etc., those capabilities will be provided for free if the formation is trained on a planet where those conditions occur naturally.

For example, assume a new type of infantry unit is designed (Desert Raider), with personal weapons, heavy armour (x2), desert warfare capability (x1.25) and extreme temperature capability (x1.5), which will cost 0.375 BP. A formation of 2000 Desert Raiders has a size of 10,000 tons and cost of 750 BP. If the formation is trained on a desert planet, the formation cost will be 600 BP (750 / 1.25). If it is trained on a desert planet with a temperature outside the range of the species population, the cost will be 400 BP.

This is to simulate that it is more effective to train ground forces for extreme conditions or environments, if the training takes place within those environments. It also adds interesting decisions about where to train ground forces, rather than stacking all ground force construction complexes in a single location, and should create a more interesting force mix.

It is possible that conditions on a planet may change over time, so to avoid complexity, the cost is determined at the time the task begins. If formations are in a queue, the cost will be checked at the moment they begin training.

The 'normal' cost for formations will be shown on the ground forces window. Any reduced cost for training will be shown on the GU training tab of each population.

The following capabilities are free under the listed environments

• High Gravity. Planet has gravity higher than population species maximum.
• Low Gravity. Planet has gravity lower than population species minimum.
• Extreme Pressure. Planet has pressure higher than population species maximum.
• Extreme Temperature. Planet has temperature lower than population species minimum or higher than population species maximum
• Mountain Warfare. Planet has a dominant terrain type that includes the words 'Mountain' or 'Alpine'.
• Desert Warfare. Planet has a dominant terrain type that includes the words 'Desert' or 'Arid'.
• Jungle Warfare. Planet has a dominant terrain type that includes the words 'Jungle' or 'Rainforest'.
• Rift Valley Warfare. Planet has a dominant terrain type that includes the word 'Rift Valley'.

[Steve Walmsley (OP)]

Galactic Map Class/Admin Display

The Galactic Map sidebar has a new tab called Icon Display. It has two check boxes called Class Icon and Admin Icon, each paired with a dropdown containing all currently active classes (1+ ship) and all admin commands respectively.

• If the Class Icon box is ticked, the ship icons on the galactic map will only display for systems that contain ships of the class selected in the associated dropdown.
• If the Admin Icon box is ticked, the ship icons on the galactic map will only display for ships within the hierarchy of the admin command selected in the associated dropdown.
• If both boxes are ticked, icons will appear only where the system has ships of the selected class that are within the hierarchy of the selected admin command

This will allow you to quickly identify systems that contain assets of a specific type or function, such as survey ships or terraformers or combat vessels. The Naval Forces tab on the sidebar will function normally, so you will still see all ships of all types in a selected system.

The Class/Admin icon option will override any display setting for Warships or All Ships on the Display tab.

The new Flag Status and Current Alien Contacts sections have also been moved to this new Icon Display tab. The above Class/Admin icon will not function if the Current Alien Contacts option is active.
https://aurora2.pentarch.org/index.php?topic=13463.msg171414#msg171414
https://aurora2.pentarch.org/index.php?topic=13463.msg171618#msg171618

[Steve Walmsley (OP)]

Removal of Low Gravity Infrastructure

I've removed low gravity infrastructure from the game. Instead, a population on a body with a lower gravity than its species minimum will require twice as much infrastructure as an equivalent colony cost planet with tolerable gravity. Low gravity bodies will still have a minimum colony cost of 1.

This should make it easier to manage infrastructure, especially for the civilians and NPRs, and reduce micromanagement, while retaining the same principle of low gravity being a more difficult environment for colonists.

[Steve Walmsley (OP)]

Galactic Map Zoom

The Galactic Map can now be zoomed in and out using the mouse-wheel, in the same way as the Tactical Map. There is no limit to the zoom beyond usability. Each click of the mouse wheel zooms in or out by 1.25x

The system graphics, ship or flag icons and text all zoom with the system locations. You can set a minimum text size if you want to make the text more readable, although at some point the text will clash with that of nearby systems.

The dragging and movement of systems, including multiple systems, centering, system search, etc. all work at different zoom levels. Here are three screenshots showing standard zoom, zoom in and zoom out.







You can also remove all text and icons simultaneously with a new 'System Icon Only' display option, which overrides everything else. This will make arranging larger maps much easier.

[Steve Walmsley (OP)]

Crew Quarter Design Efficiency

I've added a new tech line called Crew Quarters Design. Researching this tech reduces the amount of space required for crew quarters, by improving the efficiency of the design, so the crew can spend months travelling in relatively small space without feeling cramped. After spending 11 of the last 14 months travelling with my wife in a 25' motorhome, this is a technology I can relate to

The levels are similar in progression to fuel efficiency tech and start at 10% for 1000 RP, up to 75% for 120,000 RP. The HS required for crew quarters will be reduced by the specified percentage. This is a Logistics technology.

When a class is created, it uses the crew design efficiency (CDE) for the owning race at the point of creation, in the same way as armour. The class will retain that same CDE until manually updated using the Update CDE button, which functions in the same way as the Update Armour button and can only be used when the class is Unlocked.

If the CDE is greater than zero, it will be displayed on the crew deployment line of the class summary.

[Steve Walmsley (OP)]

Class Component Summary

I have added an optional summary section to the top of the Components tab of the Class design window. This summarises various components into different types, such as Defence (shields, armour, EW, decoys), Combat - Energy (weapons, reactors, fire controls), Propulsion (engines, fuel, jump drives), etc.

There are eight summary types in total: Combat - Energy, Combat - Missile, Defence, Essential Systems, Production, Propulsion, Sensor Systems, Transport and Logistics.

[Steve Walmsley (OP)]

Refuelling Changes

Refuelling systems are changed from 500 tons to 2000 tons.

A ship may mount multiple refuelling systems and the total refuelling rate is equal to their combined flow rate.

The tech progression for the Refuelling System components has changed. Previously, the steps started at 50,000 litres and went up to 500,000. The same number of steps now progresses from 20,000 to 900,000, so each step is much more meaningful.

Refuelling Hubs in their current format have been removed from the game. All orders, standing orders and conditional orders relating to refuelling hubs have also been removed.

This will make orders and conditional orders more simple, as you no longer need to specify refuelling hub as a separate destination. Tankers with multiple refuelling systems are still just tankers, but with higher refuelling rate. I will also be making some changes to standing and conditional orders, which I will explain in a separate post.

[Steve Walmsley (OP)]

Transfer Fuel and Return

The current 'Harvester unload fuel and return to gas giant' conditional order has been replaced by "Transfer Fuel and Return".

This can be used by any fleet, not just harvesters. If triggered, the fleet will unload fuel at the closest colony in the same system that can receive fuel.

If the fleet starts in orbit of a system body, it will return to that system body after the fuel transfer. If not in orbit of a system body, the fleet will drop a temporary waypoint and return to that waypoint after transferring fuel.

[Steve Walmsley (OP)]

Changes to Standing and Conditional Orders

For v2.6, you can set unlimited Standing and Conditional Orders for each fleet. They will be checked in order of priority.

To facilitate this change, the UI of the Standing Orders tab on the Fleet Organization window has been changed. This new UI should make visualizing the order lists easier and creates the necessary space to add new order types and conditions.

To set a standing order, select one from the Tree view and click Add Standing. It will be added as the lowest priority standing order. To set a conditional order, select a standing order from the Tree view, plus a Condition from the list, and click Add Conditional. It will be added as the lowest priority conditional order. Some orders are conditional-only and cannot be using for standing orders. They have their own section on the treeview.

Both standing and conditional orders can be deleted or moved up and down their respective priority lists by the buttons on the bottom right.

In addition, checking of standing and conditional orders will occur for increments longer than one minute, rather than increments longer than one hour.

[Steve Walmsley (OP)]

Class Design UI Update

The various component types on the class design tab of the class design window have been organized into the same summary types as the component window (see http://aurora2.pentarch.org/index.php?topic=13463.msg173305#msg173305)

The components of the selected class are now grouped by summary type instead of component types.

These changes should make it easier to navigate the growing number of different components and to understand the systems present in a class design vs the options available. The extra nodes all remember their open/close states when the window is closed.

I have also renamed some of the component type nodes to make them more consistent in nomenclature.

There are eight summary types in total: Combat - Energy, Combat - Missile, Defence, Essential Systems, Production, Propulsion, Sensor Systems, Transport and Logistics.

[Steve Walmsley (OP)]

Standing & Conditional Order Templates

You can create templates for the new unlimited standing and conditional orders.

Clicking Create Template will save all the standing and conditional orders for the current fleet and pops up a dialogue box for you to enter a name. The saved templates are displayed beneath the condition options.

Selecting a different fleet and clicking Load Template will replace the standing and conditional orders of that fleet with those in the template. There is a warning popup if the fleet already has either standing or conditional orders.

[Steve Walmsley (OP)]

Fleet Waypoints

A Fleet Waypoint is a new waypoint type that is associated with a specific fleet. A fleet can only have one Fleet Waypoint and if a new one is created, the one old disappears. The Fleet Waypoint will also disappear at the point of arrival, if the associated fleet uses a movement order with that waypoint as the destination.

A Fleet Waypoint can be created in several ways.

• There is a new Create Fleet Waypoint movement order, that will create the waypoint at the selected destination.
• On the military tab of the Tactical window, selecting a fleet and clicking 'Create Fleet WP' will create a Fleet Waypoint for that fleet at the fleet's current location.
• On the same military tab of the Tactical Window, 'Set Fleet WP' functions in the same way as Normal WP on the waypoints tab. The cursor changes to a cross and clicking on the map will create a Fleet Waypoint at the clicked location.
• There is also a 'Create Fleet WP' on the Movement Orders tab of the Fleet Window, although this doesn't immediately update the tactical map.
• There is a checkbox called 'Set FWP' next to the Add Condition button (see screenshot below). If this is checked when a Condition is created, that condition will be flagged to create a Fleet Waypoint at the fleet's current location when triggered.

"MV: Fleet Waypoint" is a new standing or conditional order that will cause the fleet to move to its associated 'Fleet Waypoint'.

This new functionality provides a number of different options for fleet orders. For example, the fleet in the screenshot below has "MV: Fleet Waypoint" as its first standing order. Most of the time this will not trigger as no Fleet Waypoint will exist. If however, the fleet triggers the Refuel conditional order, that order will generate a Fleet Waypoint. Once the refuel order is completed, the first standing order will be checked and the Fleet will return to the location at which the conditional order was triggered. On arrival, the fleet waypoint will be removed.

Alternatively, a fleet with survey standing orders could add "MV: Fleet Waypoint" standing order after the survey orders, then use a movement order to drop a fleet waypoint at its entry location. Once there are no remaining survey targets, it will move to the fleet waypoint.

The "MV: Fleet Waypoint" standing orders works for multi-system journeys. If a Fleet Waypoint is created on a system body, or by a fleet in orbit of a system body, it will move with that body.

[Steve Walmsley (OP)]

Replenish At Colony Standing Orders

The new "LG: Replenish at Colony" standing order will trigger a refuel and resupply from colony order, followed by a load ordnance order. The order will check for colonies with fuel, refuelling capability, supplies and supply capability. It will not check for for the presence of ordnance when the orders are issued, although the ordnance will be loaded if available.

The "LG Replenish Overhaul" order replaces the previous "Refuel, Resupply and Overhaul" order. It will trigger a refuel and resupply from colony order, followed by a load ordnance order, followed by an overhaul order. The order will check for colonies with fuel, refuelling capability, supplies, supply capability and maintenance capability. It will not check for for the presence of ordnance  when the orders are issued, although the ordnance will be loaded if available.