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

[Steve Walmsley (OP)]

Small Craft Refuelling System

I've added a Small Refuelling System to v2.0. This is 50 tons and has a flow rate of 10,000 litres per hour. It can only be mounted on ships of 1000 tons or less and only used to refuel ships of 1000 tons or smaller. This is envisaged as closer to the modern systems used for aerial refuelling rather than the more complex system on replenishment ships which is why it is only suitable for use with small ships.

The Small Refuelling System can interact normally with Refuelling Hubs and Colonies. When tankers are checked as the destination for conditional orders, the size of the ships in the fleet will be taken into account. Fleets with ships larger than 1000 tons will ignore tankers equipped with the Small Refuelling System.

Here is an example of a 1000-ton jump-capable tanker:

Raptor-T class Tanker      1,000 tons       12 Crew       70.7 BP       TCS 20    TH 64    EM 0
3201 km/s    JR 1-50      Armour 1-8       Shields 0-0       HTK 6      Sensors 0/0/0/0      DCR 0      PPV 0
Maint Life 1.45 Years     MSP 50    AFR 200%    IFR 2.8%    1YR 26    5YR 395    Max Repair 32 MSP
Captain    Control Rating 1   
Intended Deployment Time: 1 month    Morale Check Required   

Apollo-10 Military Jump Drive     Max Ship Size 1000 tons    Distance 50k km     Squadron Size 1
Zeus Drive Systems ZDS-64 Gas Core Drive (1)    Power 64    Fuel Use 100%    Signature 64    Explosion 10%
Fuel Capacity 350,000 Litres    Range 63 billion km (227 days at full power)
Refuelling Capability: 10,000 litres per hour     Complete Refuel 35 hours

Artemis-2M Missile Detection Sensor (1)     GPS 3     Range 2.1m km    MCR 192.7k km    Resolution 1

[Steve Walmsley (OP)]

Launch All

A "Launch All" button has been added to the Naval Organization window. This will appear when a Fleet, Sub-Fleet or Ship is selected and parasites are present.

Pressing the button will launch all parasites from the selected ship, sub-fleet or fleet into a single new fleet. If the parasites are attached to one or more squadrons, those squadrons and their attached parasites will be created as sub-fleets within the new fleet. Empty squadrons will be ignored.

Below is an example of the fleets created by first using 'Launch All' on the Galactica and secondly on the Battle Fleet.



And yes, Squadron 10 wasn't very imaginative with their nickname, but that is an actual squadron on the TV show.

[Steve Walmsley (OP)]

Non-Combat Resupply

Ground forces will resupply out of combat in v2.0 if they are at a population and logistics units are available.

The amount of supply required will be reduced by the formation commander's logistics bonus. In the existing combat resupply, the commander's logistics bonus is the chance of 'free' supply for each combat round.

[Steve Walmsley (OP)]

Academy Commandant Display

For v2.0, the Academy Commandant at each colony with one or more military academies will be displayed under the planetary governor on the Governor tab of the Economics window.

[Steve Walmsley (OP)]

STO Targeting

This isn't a mechanics change per se, but an update to the AI.

I've noticed that the AI doesn't always make sensible decisions on STO targeting, mainly due to prioritizing low chance/impact shots against warships, while ignoring much closer commercial or unarmed targets. Therefore I've added a little more intelligence to the AI STO targeting code and it will use a custom priority list based on distance, size and known capabilities, rather than the player options (largest, fastest, random, etc.).

[Steve Walmsley (OP)]

AI Ground Offensives

Currently, the AI will only launch ground offensives with certain formation types, such as armour. This can lead to situations where a player can land ground forces on a planet defended by AI infantry and then avoid combat by setting everything to support or rear echelon.

For v2.0, the AI will assess the option of mounting offensive operations with formations that would normally remain in a frontline defence field position. The AI will base this decision on what it knows about player forces, including armour, hit points, offensive capabilities etc., based on the same 'Alien Ground Unit Class' intelligence available to a player. If no information is available, the AI will assume basic infantry until it finds out information to the contrary. This means that an AI may launch offensive operations against a reluctant landing force and then move back to a defensive posture once it learns more.

The AI will take into account the benefits of retaining fortification bonuses vs launching offensive operations.

(you might guess there is a ground invasion happening in my current campaign)

[Steve Walmsley (OP)]

Mobile Repair Bays

A new component type, Mobile Repair Bays, has been added for v2.0.

Each Mobile Repair Bay is 2000 tons, costs 120 BP and adds 1000 tons of Repair Capacity to a ship. They are a commercial system and stack in the same way as hangar bays. The development cost is 5000 RP.

When in orbit of a population, each ship with Repair Capacity will appear in the population's shipyard list and will function exactly the same as a Repair Yard of the same capacity, except they do not require workers and cannot be expanded or otherwise modified. The shipyard name displayed in the shipyard list is the name of the parent ship. Ships with Repair Capacity can perform repair and scrapping tasks. If a ship-based repair yard is active, the parent fleet cannot be given orders.

The build cost of Repair Yards has been reduced to 1200 BP, although their upgrade costs remain the same as commercial shipyards. In general, Mobile Repair Bays are a little more expensive than Repair Yards, especially for greater capacities, and cannot be expanded, but have much greater strategic flexibility. In effect, Mobile Repair Bays allow forward repair bases to be established without the need for supporting colonists. Here is an example ship:

Phoenix class Repair Ship      58,446 tons       1,160 Crew       3,354.2 BP       TCS 1,169    TH 1,500    EM 0
1283 km/s      Armour 1-134       Shields 0-0       HTK 106      Sensors 6/8/0/0      DCR 1      PPV 0
MSP 35    Max Repair 120 MSP
Captain    Control Rating 1   BRG   
Intended Deployment Time: 3 months   
Repair Capacity: 20000 tons

Commercial Ion Drive (5)    Power 1500    Fuel Use 2.48%    Signature 300    Explosion 4%
Fuel Capacity 250,000 Litres    Range 31.1 billion km (280 days at full power)

Artemis-30NB Navigation Sensor (5)     GPS 1920     Range 31.5m km    Resolution 120
Themis TH-6 Passive Sensor (5)     Sensitivity 6     Detect Sig Strength 1000:  19.4m km
Themis EM-8B Passive Sensor (5)     Sensitivity 8     Detect Sig Strength 1000:  22.4m km

And yes, I know I said I wasn't adding anything else to v2.0

[Steve Walmsley (OP)]

Changes to Commercial Hangar Repairs

Due to the addition of dedicated Repair Bays, the repair capabilities of commercial hangars are being changed for v2.0.

Commercial hangars can perform repairs on commercial ships as they do now.

Commercial hangars cannot perform repairs on military ships. Military ships in commercial hangar bays can perform their own repairs, but without the benefit of the parent ship's damage control rating or maintenance supplies. Military ships in commercial hangar bays will still replenish maintenance supplies from the parent ship as normal. In effect, this means that a military ship in a commercial hangar bay cannot perform a repair unless it has sufficient inherent maintenance capacity for that repair and it cannot repair armour. It is treating the parent ship as a supply ship instead.

Military hangars can still repair both military and commercial ships and will repair the armour on both.

[Steve Walmsley (OP)]

Deep Space Populations

v2.0 introduces a new type of system object known as a Deep Space Population (DSP).

A DSP can be created in the same way as a named waypoint, by clicking the ‘Create Deep Space Population’ button on the Miscellaneous tab of the Tactical Map, selecting a location on the map and choosing a name. A new population will be created at that location and it will be displayed on the map as a yellow dot with the associated population name. The DSP will appear in the Economics window like any other population, except for the suffix (DSP)

The DSP will function as a normal population with the following exceptions:

• There is no associated system body, which means:
• There is no line on the System View window and no mention in any summary of system bodies.
• It will not act as a destination for survey orders.
• There will be no mineral deposits.
• There will be no surface location to place installations, ground forces, fuel, ordnance or MSP.
• Due to the lack of a physical location, no ground combat can take place at a DSP, although any ships or stations at the location can be attacked via boarding combat.
• Minerals can be delivered to the DSP and collected from it, as it assumed these are stored as free-floating resources. They will be displayed as per a normal population.
• For the purposes of population display, the DSP has a colony cost of ‘Not Habitable’ and there are no physical characteristics such as gravity, atmosphere, etc.. It cannot be terraformed.
• Any population for DSP will have to be provided in Ark Modules (see next post)
• The DSP will act as a location for shore leave, if a sufficient population is available.
• Maintenance modules at the DSP will provide a maintenance capacity and allow overhauls, although MSP will have to be drawn from supply ships or supply bases at the location.
• Shipyards can operate at the DSP, as they are orbital, but they will require population based in Ark Modules.
• Repair Bays can operate without population.
• Due to the restrictions, the movement orders that can use the DSP as a destination are more limited than for a planetary population. In general, they will be the same orders available for waypoints, plus mineral-related load and unload orders.
• Orders that have a destination of a fleet in orbit of a DSP will function normally.
• The default order when double-clicking on a DSP is 'Move To'.
• Deep Space Populations do not orbit any stars, with one exception (see next bullet). They remain in their original position.
• When creating a Deep Space Population, if you click on a gas giant or superjovian instead of empty space, the DSP will be created in orbit of the gas giant and will move with the planet. In this case, fleet movement orders will have both the DSP and the gas giant as separate destinations, with one suffixed by (DSP) and the other by (Planet).
• Deep Space Populations have EM and Thermal signatures with the same rules as normal populations.
• A governor can be selected as normal, or set for automated assignment.
• Deleting a DSP on the Economics window will remove it from the Tactical Map.
• DSP cannot be made independent.
• Buttons for instantly adding ground units or installations will not be visible, even in SM mode.
• The Environment tab will be blank
• DSP will appear on the 'All Bodies' tab of the Tactical Map as the first item(s) on the list. Clicking on them will centre the Tactical Map on the DSP.

This is a completely new concept so I will probably edit the post over the next few days as I encounter things I haven't thought of yet

[Steve Walmsley (OP)]

Population Changes and Ark Modules

Based on discussion on the forums, I've decided to change the way that colonies distinguish between surface and orbital populations. Currently, orbital habitat modules function as a form of infrastructure. If you add one to a population, it creates extra room for the population to grow into. However, if you remove the habitat, the entire population remains on the planet. This is because the population is associated with the planet, not the habitat.

For v2.0, Orbital Habitat modules are being renamed as Ark Modules. They will be able to transport colonists in the same way as cryogenic modules, although they are far larger because the colonists are not frozen in cryogenic chambers. The Cryogenic Transport category on the Class window has been renamed Colonist Transport and the Ark Module will appear in this category once developed. Ships will have distinct Cryogenic Transport and Colonist Transport capacities, with the latter reflecting the Ark Module capacity. A ship can have both cryogenic and Ark modules, but only the latter will contribute to a colony while the colonists are still on board.

When a ship or station with an Ark Module is in orbit of a colony, any colonists in the Ark Module will be considered as 'orbital population' for that colony. The colonists on the surface will be 'surface population'. The two populations are distinct and growth on the surface will not affect the colonists on board the Ark Modules. In effect, the Ark Modules are acting in a similar way to maintenance modules or terraform modules, in that they are 'lending' their capabilities to the colony. In this case, the colony gains extra population. If the ship or station with the Ark modules leaves orbit, it will take its colonists with it.

This new function also allows huge Ark ships that can transport populations through space and then hold position at temporary DSPs to conduct ship-building, etc., without the need for a suitable habitable world that would be required in the case of cryogenic transport.

Any ship loading or unloading colonists will interact only with the surface population, although the ship with Ark Modules could load colonists that a different ship has just unloaded. Depending on playtest, I may also add load/unload colonist orders that have an Ark ship as a target, although I suspect this would be seldom used in practice. Ark Modules will more likely load colonists once and then retain them indefinitely (with the exception being an orbital colony that builds its own Ark ships).

As the population in Ark modules is awake and functional, there will be some population growth if there is space capacity. This growth will be at an annual rate of 5% x (Space Available / Total Capacity). For example, if an Ark Ship is only carrying 75% of capacity, the annual pop growth will be 1.25%. Available space is likely to be a rare situation, but it could happen after damage and repair, or if an Ark loads a surface population less than its capacity.

Ark Modules have built-in life support and do not need any agricultural/environmental population (as is the case now with orbital habitats). Therefore, the orbital population does not have to be the same species as the surface population and multiple different species can contribute from orbit.

In most cases, colonies will function in a very similar way to now. However, the distinct division between surface and orbital populations does result in some changes:

• The infrastructure requirement for a colony, and any associated unrest for overcrowding, only considers the surface population.
• Only the surface population is considered for PPV requirements and any associated unrest.
• Even though only the surface population generates unrest for the above reasons, any resulting impact on political stability affects the whole colony.
• If a colony is conquered, the population in the Ark Modules will not be affected, unless the Ark itself surrenders. The Ark will be unassigned from the conquered colony. The same is true for colony transfers
• Both orbital and surface population generate trade and an orbital-only colony, including a DSP, will produce trade goods.
• Both pops are considered for EM/Thermal signatures and for the 1m requirement for ancient constructs
• Standing orders for civilian colony ships will only consider the surface population.
• Shipping Lines require two surface populations to begin producing ships.
• Editing the population amount in SM mode only affects the surface population

[Steve Walmsley (OP)]

One Second Sub Pulses

For v2.0, increments of 5 seconds will run with 1-second sub-pulses.

In general, this is to make very short-ranged enemy combat more realistic in terms of moves and counter-moves and prevent some odd situations. For example, when fast units are trying to follow an enemy fleet at a certain range, that distance can vary significantly from what was intended if they move first. It can also create situations where fast units with a speed advantage and relatively short-ranged weapons (fighters) cannot get into weapon range of a slower ship that can move more than their weapon range in a 5-second increment.

A 5 second increment will only be interrupted at the end of the increment, not after one of the sub-pulses. Because of this, you may see explosion or energy impact contacts in the wake of ships, rather than on top of them, because point defence and missile impacts will happen mid-increment.

There is a new game option to disable 1-second sub-pulses if this causes a performance issue.

[Steve Walmsley (OP)]

Cease Fire All Ships

I've added a 'Cease Fire All Ships' button to the Miscellaneous tab of the Tactical window. Clicking this will apply a cease fire order to every fire control of every ship in your empire.

This is for convenience in large battles, but also to make it easier to avoid a situation where an unknown ship is triggering 'active firing' interrupts.

[Steve Walmsley (OP)]

Detailed Combat Events

Many different types of combat events, such as point defence, ship to ship combat and damage, all fall under a single event type - Combat Summary. This limits flexibility for hiding a subset of those events or using different event colours. As an example, in a fighter-heavy campaign, this would allow you to prevent the event window being spammed by fighter point defence or hundreds of small attacks.

For v2.0, Combat Summary events have been split into eighteen different types:

• Energy Point Defence.  The result of a ship of more than 500 tons firing at missiles.
• Fighter Point Defence.  The result of a ship of 500 tons or less firing at missiles.
• STO Point Defence.  The result of an STO weapon firing at missiles.
• AMM Point Defence.  The result of AMMs from a specific ship intercepting missiles.
• Ship Combat - Energy.  The result of a ship of more than 500 tons using energy weapons in offensive mode
• Fighter Combat - Energy.  The result of a ship of 500 tons or less using energy weapons in offensive mode
• Ship Combat - Missile.  The result of missiles launched by a ship of more than 500 tons intercepting their target
• Fighter Combat - Missile.  The result of missiles launched by a ship of 500 tons or less intercepting their target
• STO Combat.  The result of a ground element with STO weapons attacking a target in offensive mode
• Missile Vs Ship.  The result of missiles without ship-based direction intercepting their target
• Attacked By STO.  Summary of hits and damage suffered as a result of attack by STO weapons
• Attacked By Energy Weapon.  Summary of hits and damage suffered as a result of an attack by ship-based energy weapons
• Attacked By Missile.  Summary of hits and damage suffered as a result of missile attack
• Attacked By AA Fire.  Summary of hits and damage suffered by a ship attacked by surface-based AA weapons
• Boarding Damage.  Summary of collateral damage suffered by a ship undergoing boarding assault
• Acid Damage.  Summary of internal damage resulting from acid-based attacks
• Collateral Damage.  Damage suffered as a result of bombardment against a population, where the damage was not to the primary target.

[Steve Walmsley (OP)]

Fleet Point Defence Summary

A new event has been added for v2.0 that summaries all energy-based point defence by weapon type within each fleet. Here are two example event texts from my current campaign:

Leonidas Attack Force: Ares Kinetics AK-25 Railgun  18 / 320 / 5.6%   Ares Kinetics G20-8 Gauss Cannon Turret  20 / 92 / 20.8%
Viper Squadrons: Ares Kinetics VC-2 Viper Cannon   19 / 146 / 13%

The above reads as the Leonidas Attack Force used two different weapons for point defence. The AK-25 Railgun, which scored 18 hits from 320 shots for a hit rate of 5.6%, and the G20-8 Turret, which scored 20 hits from 92 shots for a hit rate of 20.8%. The Viper Squadrons used only one weapon, the VC-2 Cannon, which scored 19 hits from 146 shots for a hit rate of 13.0%

This new event will allow players to hide some of the more detailed events if desired and just see a summary of the fleet's point defence performance. In this case, there are four Battlestars and two hundred and eighty Vipers, so I will probably keep the individual Battlestar results, plus the summary, but hide the individual fighter events and just use the summary.

[Steve Walmsley (OP)]

Sol Bodies with Water

I've added frozen water to the following Sol system bodies:

• Europa 50%
• Ganymede 20%
• Callisto 10%
• Luna 10%

There are some smaller bodies such an Enceladus that likely have water, but their gravity is too low to support an atmosphere so the presence of water would not help in colony cost terms.