Change Categories
Crew, Commanders and Control Systems
Deployment, Overcrowding, Under-manning and Life Support Failures
Direct Fire Weapons and Power Plants
Ship Components (exc. Weapons/Engines)
Space Stations and Orbital Habitats
Low Gravity Infrastructure
Underground Infrastructure is replaced with Low Gravity Infrastructure (or LG-Infrastructure). This will be built and transported in the same way as regular infrastructure, except it will be twice as expensive - 4 BP instead of 2 BP.
Any low gravity bodies (below the minimum gravity of the colonising species) will now have a normal colony cost calculation (based on atmosphere, temperature, pressure, etc.) and an ‘LG’ suffix will be added. For any bodies with an LG suffix, the maximum supported population will be based on the available LG-Infrastructure.
For example, for a colony cost 2.00 world you need 200 infrastructure per 1m pop. For a colony cost 2.00(LG) world, you will need 200 LG-Infrastructure per 1m pop and normal infrastructure will have no effect.
Both normal infrastructure and LG-Infrastructure can be used on a world with gravity in the tolerable range. Worlds with gravity above max species gravity will not be colonizable.
Civilian infrastructure production on a low gravity world will be LG Infrastructure, produced at one third of the normal rate (same overall cost). Trade in infrastructure will be low gravity to low gravity or acceptable gravity to acceptable gravity .
I believe this change will maintain the concept of colonising low gravity bodies at a higher cost but will be a lot cleaner and easier.
Forced Labour Camps
As part of the ground combat overhaul, Forced Labour ground units will be removed. They will be replaced by two new installations; the Forced Labour Construction Camp and the Forced Labour Mining Camp. These each cost 40 BP to build and have the same output as a construction factory and a mine respectively. Transport size is 100,000 cargo points, or 4x that of a construction factory.
Forced Labour Camps can be built at any population, not just occupied ones. However, they consume 100,000 population and instantly cause 5 points of unrest. Once built they only require 5000 population to man them (serving as overseers), as the bulk of the workers, plus associated basic survival-level infrastructure, is provided during construction.
This installation has a few different uses. Making an conquered population productive is one, as you can build three of these for a single construction factory or mine cost, offsetting much of the production modifier penalty for occupation status. You can achieve more overall production in one of your own colonies for lower cost, if you are prepared to accept the unrest penalty, or you can build these in occupied populations and ship them to your own colonies.
Finally, because they have a minimal requirement for a supporting population, you can move them to a hostile world using only a small amount of infrastructure for the overseers. In effect, you can create the Dilithium mines of Rura Penthe if you wish. There are role-playing consequences, as you may not want to play the type of empire that convert its citizens into slaves and sends them to mine asteroids.
Labour Camps are affected by all the production modifiers that affect construction factories and mines (such as radiation, unrest, economic and political modifiers, etc.), although their cheap build cost allows you to offsets these modifiers with triple production. The transport requirement take into account the number of integral workers and supporting infrastructure. However, you could ship the potential workers as colonists (in a quarter of the tonnage) and create the Forced Labour Camp at the desired location.
While Labour Camps might seem low cost and tempting, they do have drawbacks. The large transport size means you could use the same freighter lift for 4x as many mines or construction factories. In addition, the 100,000 population cost is actually much higher in reality as you lose all the potential future growth & wealth provided by that population. They will be suitable in certain situations though; where you need to ramp up production and have excess population to support it, if you don’t want to wait for a conquered population to improve its political status or you need a fast way of producing an equivalent to automated mines.
The unrest penalty for creation might be a little low so I will see how that works in play-test.
Ground Forces Construction Complex
For C# Aurora, the Ground Force Training Facility becomes the Ground Force Construction Complex. They remain the same size as a research facility and now require one million population to operate.
The build rate for the complex starts at 250 BP per year and can be increased through research. For example, 500 BP per year is 8000 Research Points and 1000 BP per year is 60,000 Research points.
These changes reflects the amount of effort that will be required to construct, train and support the new ground forces.
Genetic Modification Centre
Genetic Modification Centres now produce one million conversions per year (250k in VB6). They also require 250,000 workers (zero in VB6).
Conventional Industry
In VB6 Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.05 refineries and 0.1 mines.
For C# Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.05 ordnance factories, 0.025 fighter factories, 0.05 refineries, 0.1 financial centres and 0.15 mines.
Worker Requirements
Workers are required to man a variety of facilities in C# Aurora. This is only required in game terms where there are sufficient workers to potentially require additional infrastructure in hostile conditions. For example, an ‘Automated Mine’ does not have a worker requirement even though in reality it may have a small workforce for maintenance. In these cases, it is assumed the installation itself provides sufficient accommodation for the small workforce. A secondary consideration here is micromanagement, in that it would not add to game play if every refuelling station or mass driver required the transportation and housing of a few hundred workers, but it would add additional micromanagement.
With that in mind, the following installations require workers.
5,000 workers. Forced Labour Construction Camp, Forced Labour Mining Camp.
50,000 workers: Construction Factory, Ordnance Factory, Fighter Factory, Fuel Refinery, Mine, Conventional Industry, Maintenance Facility, Financial Centre.
250,000 workers: Terraforming Installation, Ground Force Construction Facility, Genetic Modification Centre
1,000,000 workers: Research Facility, Spaceport.
The following installations do not require workers
Infrastructure, Deep Space Tracking Station, Automated Mine, Military Academy, Sector Command, Mass Driver, Civilian Mining Complex, Refuelling Station, Naval Headquarters, Ordnance Transfer Station, Cargo Shuttle Station.
Installations without Required Tech
Given the player starts with certain installations in a conventional start, it does not make sense to make additional construction of those installations dependent on Trans-Newtonian Theory. The full list of the installations that can be constructed before Trans-Newtonian Theory is researched is as follows:
Naval Shipyard Complex
Commercial Shipyard Complex
Research Facility
Spaceport
Ground Force Construction Complex
Military Academy
Naval Headquarters
Refuelling Station
Ordnance Transfer Station
Cargo Shuttle Station
Maintenance Facility
Financial Centre
Deep Space Tracking Station
Infrastructure
Removal of Planetary Defence Centres
Planetary Defence Centres (essentially a ground-based ship) will not exist in C# Aurora. They will be replaced by a much more detailed ground-combat system, including ground units capable of engaging ships within energy range of the planet.
Spacemaster Changes to Installations
When in Spacemaster Mode, the Civilian Economy tab gains an extra dropdown and three extra buttons. These allow the Spacemaster to change the number of installations at a colony, or add new types. This replaces part of the functionality from the VB6 SM Modification window.
Planetary Installations
There are a few additions and changes for planetary installations, including changes to mineral requirements. Here is a table of the current situation.
Shipbuilding Changes
I’m using this post as a placeholder to post any shipbuilding changes. So far the changes are:
- You can’t refit a damaged ship.
- Scrapping/Deleting is much more intelligent about moving commanders, teams and ground units from a ship to the scrapping population (in case you accidentally scrap or delete a ship with them on board). Fuel, maintenance and ordnance are also automatically unloaded.
- When a ship undergoes refit, fuel, maintenance and ordnance are moved from (or to) the refitting population to account for the differences post-refit.
Repair Task in Shipyards Window.
When selecting the repair task in the shipyards window, only classes / ships needing repair and currently in orbit will be displayed. In VB6 Aurora, all classes / ships in orbit are displayed and you have to cycle through to find the damaged ships.
If no ships in orbit are in need of repair, the class and ship drop downs will be empty.
Continual Capacity Upgrade Target
In C#, you can set a target capacity when using the Continual Capacity Upgrade shipyard task. The upgrade will end when it reaches that target capacity.
Shipyard Worker Requirements
Shipyards in VB6 require one million workers as a base, plus 100 workers for each ton of capacity in naval shipyards and 10 workers for each ton of capacity in commercial shipyards.
For C#, the base requirement is removed. Instead, naval shipyards will require 250 workers for each ton of capacity and commercial shipyards will require 25 workers for each ton of capacity. This is intended to bring shipyards in line with other major industry sectors such as construction factories, mines and research facilities
As an example, here are the shipyards from my current test campaign with the old and new requirements:
Auto Refit Tasks
A new shipyard task has been added for C# Aurora, the Auto-Refit.
This is exactly the same as a Refit Task except for one difference. When the task is finished, the shipyard will automatically start a new refit task using the same target class. For example, if you auto-refit Class A to Class B, when the task is finished the shipyard will check for another Class A in the same location to refit. If one is found, the shipyard will automatically create the task.
You can refit fighters in shipyards in C#, so this new task will remove a lot of micromanagement that would otherwise be necessary.
Refit Size
The ‘size difference’ element of refit cost has changed for C# Aurora. In C#, the size difference acts as a modifier to the refit cost, rather than as a standalone cost.
In VB6 the size element cost is: ABS(Current HS - Refit HS) * 5.
For C# the size element cost is: (ABS(Current HS - Refit HS) / Current HS) * Refit Cost.
While this change is more realistic in general, it can lead to some weird situations where the refit cost from a large ship to a small ship is relatively low because the small ship is a version of the large ship with systems removed and no other changes. Therefore, C# adds a new restriction that you cannot refit to a design that is more than 20% smaller or 20% larger than the existing design. This also avoids cluttering the ‘Refit from’ dropdown when you have a lot of classes.
This change affects what can be built in shipyards. As in VB6, you can build the class for which the shipyard is tooled, or any other class to which the build class can be refitted for less than 20% of its cost. The new size restriction will prevent some classes from being eligible in this situation.
Refuelling Changes
In C# Aurora, refuelling is no longer instant and ships without specialised equipment cannot exchange fuel in space. A ship can only refuel at a Spaceport, a Refuelling Station, a ship with a Refuelling System or a base with a Refuelling Hub.
A new technology line - Refuelling Systems - provides the basis of the rate of refuelling and allows ships to mount systems to refuel other ships. The baseline system (Refuelling System: 50,000 LPH) sets the racial refuelling rate at 50,000 litres per hour and allows the use of the first ship-mounted Refuelling System. There are ten further steps in the tech progression with the highest tech system allowing refuelling at 500,000 litres per hour.
Spaceports, Refuelling Stations or Refuelling Hubs will always use the highest tech refuelling rate and can refuel an unlimited number of ships simultaneously. However, the ships being refuelled must be stationary.
Spaceports have doubled in cost to 2400 BP but can now be moved by freighters. They are equal to four research facilities for transport purposes (or 80 factories). They retain their existing bonuses to loading and unloading cargo.
Refuelling Stations are a new installation with a cost of 1200 BP. They do not require workers and can be moved by freighters. They have a transport size equal to 10 factories. Essentially, they are a cut-down version of a spaceport intended to facilitate refuelling in forward areas, transferring fuel from the surface of a planet to the waiting ships. They have no bonuses for loading or unloading cargo.
A Refuelling Hub can be mounted on a ship. It is a commercial system with a research cost of 10,000 RP, build cost of 2400 BP and a size of 100,000 tons. In practical terms, this is likely to form part of a large, deep-space station, due to the size and cost, rather than being deployed on tankers that will accompany fleets
A Refuelling System is 500 tons and has a cost ranging from 10 BP to 100 BP, depending on the tech level. A ship with a Refuelling System can refuel a single ship at once, so will take some time to refuel a whole fleet, although this will improve with higher technology. At the early tech levels, the Refuelling System can only be used if both ships (tanker and target ship) are both stationary. Another new tech line, Underway Replenishment, allow the refuelling to take place while both ships are in the same fleet and underway. Priorities can be set for the refuelling order when multiple ships are involved. The first Underway Replenishment tech allows refuelling at 20% of the normal rate (2500 RP), rising to 100% with the highest tech (40,000 RP).
Refuelling order types will be adjusted to deal with the new requirements. Fuel will be transferred during each movement increment as time passes until the target ship has full tanks. I may add some other options regarding partially filling as well.
I will be adding some rules along the same lines regarding ordnance transfer.
Refuelling Orders
With the new refuelling rules, I am changing how some of the refuelling orders work.
You can flag a tanker as being at one of three refuel statuses; None, Refuel Fleet or Refuel Sub-Fleet. When this flag is set to Refuel Fleet, the tanker will constantly refuel its own fleet as that fleet continues with normal orders (the refuel itself is not an order). Essentially, the tanker will keep the fleet’s fuel tanks topped up. The rate of refuel will be based on the refuelling system of the tanker multiplied by the parent race’s underway replenishment tech (unless the fleet is stationary). If the flag is set to Refuel Sub-Fleet, the tanker will follow the same rules as above but only for ships within the same sub-fleet (you can use this distinction to control which ships are refuelled within the fleet)
Each tanker class has a minimum fuel setting (in the class window) and will not refuel ships once it falls below that level. Each class & ship has a ‘refuel priority’, with higher numbers equalling higher priority. The tanker will refuel in descending order of ship priority, then by descending order of class priority. The tanker will automatically move to a second ship (or more) if there is sufficient time and fuel remaining in the sub-pulse.
The current ‘Refuel Fleet’ order has been replaced with ‘Join & Refuel Fleet’. The fleet containing the tanker will become part of the target fleet and switch to a ‘Refuel Fleet’ status (if not already set).
A new ‘Join & Refuel Sub-Fleet’ order has been added. The fleet containing the tanker will become part of the target sub-fleet and switch to a ‘Refuel Sub-Fleet’ status (if not already set). A Join Sub-Fleet order has also been added for more general use.
A new ‘Refuel from Refuelling Hub’ order has been added. This order requires a second fleet containing at least one refuelling hub as the destination. On arrival, the fleet will be refuelled until all its tanks are fuel, or the refuelling hub runs out of fuel. All ships in the fleet will be refuelled, including tankers. Once completed, the fleet will move on to its next order. If the fleet containing the refuelling hub has any movement orders, the refuelling will not take place and the refuelling order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of refuelling (a ship can only refuel from one hub at once) but they can all contribute fuel.
The existing ‘Refuel from Colony’ will remain but can only be used at colonies that have either a Spaceport or a Refuelling Station. On arrival, the fleet will be refuelled until all its tanks are fuel, or the colony runs out of fuel. All ships in the fleet will be refuelled, including tankers. Once completed, the fleet will move on to its next order. Multiple spaceports or refuelling stations at the colony will not increase the rate of refuelling.
The ‘Unload 90% Fuel to Colony’ order now becomes ‘Transfer Fuel to Colony’. Any class designated as a tanker can transfer fuel to any colony with either a spaceport or a refuelling station. The transfer is done at the refuelling rate of the tanker. If multiple tankers are in the fleet, they can transfer fuel simultaneously. Note this means that more planning will be needed in this version of Aurora to ensure fleets can be refuelled at the frontier. It will no longer be possible to dump fuel on the nearest available rock. Colonies will require a spaceport or a refuelling station before they can support fleets. Alternatively, tankers can accompany fleets, or a deep space base with a refuelling hub can be established.
A new ‘Transfer Fuel to Refuelling Hub’ order has been added. Any class designated as a tanker can transfer fuel to any ship with a Refuelling Hub. The transfer is done at the refuelling rate of the tanker. If multiple tankers are in the fleet, they can transfer fuel simultaneously.
Load & Unload Cargo
In VB6 Aurora, ships load or unload cargo, colonists, etc. on arrival and then undergo a wait period before their next order (based on how long it takes for the load/unload process).
In C# Aurora, the wait period will take place first and then the cargo will be loaded or unloaded at the end. Because of this change, if the fleet abandons the order before it is complete, no transfer of cargo will have taken place.
Logistics Bonus
The cargo handling speed of any ship is modified by the ship commander’s logistics bonus and by any bonus from the parent admin command of the ship’s fleet (assuming the fleet is within he command radius). Setting up a network of Logistic-focused Admin Commands has the potential to boost cargo handling considerably.
Ordnance Transfer Mechanics
In C# Aurora, transferring ordnance is no longer instant and ships without specialised equipment cannot exchange ordnance in space. A ship can only receive ordnance at a Spaceport, an Ordnance Transfer Station, a ship with a Ordnance Transfer System, a base with a Ordnance Transfer Hub or in a military hangar bay.
A new technology line - Ordnance Transfer Systems - provides the basis of the rate of ordnance transfer and allows ships to mount systems to transfer ordnance to or from other ships. The baseline system (Ordnance Transfer System: 40 MSP per Hour) sets the racial ordnance transfer rate at 40 MSP per hour and allows the use of the first ship-mounted Ordnance Transfer System. There are ten further steps in the tech progression with the highest tech system allowing ordnance transfer at 400 MSP per hour.
Spaceports, Ordnance Transfer Stations or Ordnance Transfer Hubs will always use the highest tech ordnance transfer rate and can transfer ordnance to or from an unlimited number of ships simultaneously. However, the ships involved must be stationary. Hangar Bays also use the highest tech ordnance transfer rate (mainly to avoid multiple hangar bay types).
Spaceports have increased in cost to 3600 BP but can now be moved by freighters. They are equal to four research facilities for transport purposes (or 80 factories). They retain their existing bonuses to loading and unloading cargo.
Ordnance Transfer Stations are a new installation with a cost of 1200 BP. They do not require workers and can be moved by freighters. They have a transport size equal to 10 factories. Essentially, they are a cut-down version of a spaceport intended to facilitate ordnance transfer in forward areas, transferring ordnance between the surface of a planet and ships in orbit. They have no bonuses for loading or unloading cargo.
An Ordnance Transfer Hub can be mounted on a ship. It is a commercial system with a research cost of 10,000 RP, build cost of 2400 BP and a size of 100,000 tons. In practical terms, this is likely to form part of a large, deep-space station, due to the size and cost, rather than being deployed on ammunition colliers that will accompany fleets.
A Ordnance Transfer System is 500 tons and has a cost ranging from 20 BP to 200 BP, depending on the tech level. A ship with an Ordnance Transfer System can transfer ordnance to or from a single ship at once, so it will take some time to replenish a whole fleet, although this will improve with higher technology. At the early tech levels, the Ordnance Transfer System can only be used if both ships (collier and target ship) are both stationary. Underway Replenishment allows the transfer to take place while both ships are in the same fleet and underway. Priorities can be set for the ordnance transfer order when multiple ships are involved. The first Underway Replenishment tech allows ordnance transfer at 20% of the normal rate (2500 RP), rising to 100% with the highest tech (40,000 RP).
Ordnance transfer order types will be adjusted to deal with the new requirements (which I will list in a separate post). Ordnance will be transferred during each movement increment as time passes until the target ship has full magazines.
Ordnance Transfer Orders
With the new ordnance transfer rules, I am changing how some of the ordnance transfer orders work.
The first major change is that a collier within a fleet can be set to automatically transfer ordnance to or from other ships in the fleet. You can flag a collier as being at one of seven ordnance transfer statuses; None, Load Fleet, Replace Fleet, Remove Fleet, Load Sub-Fleet, Replace Sub-Fleet, Remove Sub-Fleet.
When this flag is set to Load Fleet or Load Sub-Fleet, each collier will load ordnance into the magazines of non-colliers within its own fleet (or sub-fleet) as that fleet continues with its normal orders (the transfer itself is not an order). Essentially, the collier will keep the fleet’s magazines topped up. The rate of ordnance transfer will be based on the ordnance transfer system of the collier multiplied by the parent race’s underway replenishment tech (unless the fleet is stationary). The missiles being loaded will be based on what is missing from the ship’s magazine when compared to the class loadout, starting with the largest missiles first (although smaller missiles will be loaded if there is insufficient time in the sub-pulse to load a larger one). However, missiles will only be added using this order and missiles that do not match the current class loadout will not be removed.
When this flag is set to Replace Fleet or Replace Sub-Fleet, each collier will remove any missiles that do not match the current class loadout and replace them with those from the class loadout (assuming the collier has a sufficient stockpile) for any non-colliers within its own fleet (or sub-fleet). The collier will remove non-loadout missiles from the target ship while it has magazine space remaining, then add class loadout missiles to create space. Essentially, the collier will alternate loading and unloading as necessary to create the correct loadout.
When this flag is set to Remove Fleet or Remove Sub-Fleet, the collier will unload all missiles from non-colliers within its own fleet (or sub-fleet), as long as it has space to store them.
The current ‘Provide Ordnance to Fleet’ order has been replaced with several new orders to facilitate the above. These include:
Join and Add Ordnance to Fleet
Join and Add Ordnance to Sub-Fleet
Join and Replace Ordnance in Fleet
Join and Replace Ordnance in Sub-Fleet
Join and Remove Ordnance from Fleet
Join and Remove Ordnance from Sub-Fleet
The fleet containing the collier will become part of the target fleet and switch to an appropriate ordnance transfer status depending on the order. You can also use an ‘Absorb’ order to collect a collier with an existing status set. I may look at adding ship-level conditional orders (rather than fleet) so that colliers/tankers can detach when empty and return home without player supervision.
A new ‘Load from Ordnance Transfer Hub’ order has been added. This order requires a second fleet containing at least one ordnance transfer hub as the destination. On arrival, any ships in the fleet with magazines will receive ordnance according to their class loadouts until all magazines are full, or the ordnance transfer hub runs out of ordnance. No ordnance will be removed by the hubs. All ships in the fleet will receive ordnance, including colliers. Once completed, the fleet will move on to its next order. If the fleet containing the ordnance transfer hub has any movement orders, the ordnance transfer will not take place and the ordnance transfer order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of ordnance transfer but they can all contribute ordnance.
A new ‘Replace at Ordnance Transfer Hub’ order has been added. This order functions in a similar way to above except that any ordnance not in the class loadout will be removed by the hubs. The mechanics of this process are the same as the ordnance transfer within fleets above.
A new ‘Unload to Ordnance Transfer Hub’ order allows colliers to deliver ordnance to the hubs.
The existing ‘Load Ordnance from Colony’ order will remain but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station. On arrival, the fleet will receive ordnance until all its magazines are full, or the colony runs out of appropriate ordnance. All ships in the fleet will be receive ordnance, including colliers. Once completed, the fleet will move on to its next order. Multiple spaceports or ordnance transfer stations at the colony will not increase the rate of ordnance transfer.
The ‘Unload Ordnance to Colony’ order also remains but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station.
Any order involving the transfer of ordnance to or from a colony or ordnance transfer hub will use the current racial ordnance transfer tech to determine the rate of transfer.
Note this means that significantly more planning will be required in this version of Aurora to ensure missile-armed ships can be reloaded at the frontier. It will no longer be possible to dump ordnance on the nearest available rock. Colonies will require a spaceport or an ordnance transfer station before they can support missile-armed fleets. Alternatively, colliers can accompany fleets, or a deep space base with an ordnance
Logistics and Ground Combat Research
Due to the increase in Logistics techs for C# Aurora and the planned revamp of ground combat design, the Logistics / Ground Combat research field will be split into two separate fields. There are now nine research fields in total.
Cargo Shuttle Bays
Part of the background in C# Aurora will be that large TN ships function only in space and cannot move any closer to planetary bodies than low orbit. Small craft below a limit of 500 tons, such as fighters and shuttles, are capable of landing on planets. Ship are built in orbit and habitats are assembled in orbit. Only fighters can be built on the ground.
As part of this change, Cargo Handling Systems have been replaced by Cargo Shuttle Bays. They function in a similar way, although they are larger (10 HS) and more expensive.
Because large ships cannot land on planets, a freighter or colony ship cannot load / unload unless it has at least one Cargo Shuttle Bay, or the target population has either a Spaceport or a Cargo Shuttle Station (new installation, 1200 BP). Spaceports and Cargo Shuttle Stations can service any number of ships simultaneously but they do not stack. In effect they count as a single Cargo Shuttle Bay for any ship at the population.
All races start with conventional shuttles available for their cargo shuttle bays and stations. Conventional shuttles do not reduce loading time but do enable cargo deliveries to planets without Spaceports or Cargo Shuttle Stations. Three levels of advancement in shuttle technology are available:
- TN Shuttles (5000 RP): This reduces loading time by 2 per bay (so two bays means speed reduced by 4, three bays means speed reduced by 6).
- Improved Shuttles (15,000 RP): Reduces loading time by 3 per bay.
- Advanced Shuttles (40,000 RP): Reduces loading time by 5 per bay.
All bays and stations use the new shuttles once they are available.
Base cargo load times have been reduced by about 45% for all situations (36s per cargo point to 20s per cargo point and 18s to 10s per colonist), which means a ship with a standard cargo bay and a single Cargo Shuttle Bay with TN Shuttle tech will take slightly longer than the same ship with a cargo handling system in VB6.
This will affect troop transport in a different way and that will be covered in a separate post.
Resupply Changes
In C# Aurora, resupply is no longer instant and ships without cargo shuttles cannot exchange maintenance supplies in space. A ship can only resupply at a population with a spaceport, a cargo shuttle station or at least one maintenance facility, or from a ship with cargo shuttles.
Maintenance supplies are transferred at the rate of 10 per hour, multiplied by the number of cargo shuttle bays and the racial shuttle technology. Spaceports, cargo shuttle stations and maintenance facilities can resupply an unlimited number of ships simultaneously. However, the ships being resupplied must be stationary.
Resupply order types will be adjusted to deal with the new requirements. Maintenance supplies can be transferred by supply ships during each movement increment as time passes until the target ship has reached capacity (in the same way as underway replenishment of fuel).
Combination Orders
Given the number of new logistics options, I am adding some combination orders to C# Aurora where functions can happen simultaneously. For example, “Refuel and Resupply from Colony” will carry out both activities simultaneously, assuming that the ships / colony are equipped with the necessary logistical facilities. The order will complete when the activity with the greater duration is complete.
Other combination orders so far (I will edit here as more are added):
Refuel, Resupply, Load Ordnance from Colony
Join, Refuel and Resupply Target Fleet
Join, Refuel, Resupply, Add Ordnance to Target Fleet
I will add more combination orders during play testing, depending on which are useful, although I can’t go overboard or I risk cluttering the orders list.
Minimum Fuel and Supply
Because of the new rules for transferring fuel and supplies, ship classes can be given a minimum maintenance supply level and a minimum fuel level. Ships will not unload or transfer fuel and supplies beyond these levels. These functions replace the VB6 rule where a tanker would only unload 90% of its fuel.
Non-Player Race Fuel
In C# Aurora, NPR ships consume fuel and therefore require refuelling. They also need to use the same refuelling infrastructure as players (fuel transfer stations, refuelling systems, etc.) and require the same time to refuel (allowing for technology differences). NPR Tankers will move fuel from harvesters and populations with excess fuel to populations with logistical infrastructure that require fuel. As NPR ships become low on fuel, they will return to the nearest population or tanker that has fuel.
NPR ships and fleets have a concept of Mission Capable Status, which is affected by a number of factors such as fuel status, damage status and ordnance status. When an NPR fleet is very low on fuel, it will be unable to do anything except search for refuelling options. However, to avoid the NPR getting into any logic issues, NPR ships will still be able to move with zero fuel while they move to a refuelling point.
This should add more constraints to NPR deployment, add an interesting layer to NPR operations and provide the player with a new way to attack NPRs (attacking their fuel supplies instead of their ships). While it isn’t completely the same as players due to the ‘search for fuel while empty’ concept, I think that is the best trade-off between realism and avoiding any unforeseen logic issues.
Logistics Reports
A new Logistics Report tab on the Fleet window lists all relevant ships for each of five categories. Fuel, Maintenance Supply Point, Ordnance, Deployment Time (for crew) and Time Since Overhaul. A dropdown is used to select each category and the ships are sorted by those most affected in the selected category. Screenshots below show examples for four of those categories. MSP is very similar to fuel.
Naming Themes
In VB6 Aurora, we have racial themes that include system names, class names and rank names, plus a variety of ship name themes.
For C# Aurora, they are all amalgamated into Naming Themes, which can be used individually for Classes, Systems and Ships. Ranks will be handled separately.
A race will select a Class Naming Theme, a System Naming Theme and a Rank Theme (so you can use current Ship name themes at the Race level). Each Ship Class can also have a Naming Theme.
The Naming Themes comprises everything previously used for Ships, plus the existing Racial Themes separated out into the System and Class elements (and named appropriately so you can replicate existing Race Themes if desired).
This should be a lot more flexible while allowing everything you can do now. It will also make it a lot easier for players to add customised themes.
System Naming
In C# Aurora, you can optionally assign one of the new Naming Themes to a system. Any future exploration beyond that point will use the selected naming theme. This allows you to have different naming themes for different warp chains.
The order of name selection for new systems will therefore be:
- Actual System Name (for known stars)
- Next name for Naming Theme associated with the system from which the exploring ship originated (if a theme is set)
- Next name for Racial System Theme
- “System #” + System Number
You can still rename systems directly and will be able to use text, or select any name from any name theme.
Commander Name Themes
C# Aurora allows a Race to have an unlimited number of Commander Name Themes. This is handled on the Race window.
When a Race is created, a single theme is selected as part of the creation process. Unless the player makes changes, 100% of commanders will use this initial theme. The player can choose additional themes, assigning each one a weight. When a new commander is generated, the name will be randomly assigned a theme based on the weight of each theme.
The first screenshot shows a race with a single commander name theme. The second shows the same race with multiple additional themes. The top left section of the Race window shows the main theme (the greatest weight) plus the number of additional themes.
Mining Company Names
This is only a ‘miner’ cosmetic change 
When civilian mining companies are created, they will be given a company name which will become the population name. This is similar to shipyard naming using a family name from the racial naming theme plus a ‘company name’ such as Smith Minerals & Ores or Jones Resources Group. This is purely cosmetic and has no game play impact, but serves to differentiate the civilian mining outposts.
Note that this doesn’t rename the system body. Population and system body names are separate in C# Aurora, so you can still create your own population with a different name on the same system body. The Economics window already has an option to show both system body name and pop name if they are different so you can still see the locations if desired.
Adding Your Own Naming Themes
Adding your own naming themes is very simple in C# Aurora.
- Create a text file with one name per line.
- Click the button shown below
- Enter the theme name in an input field that pops up
- Select the file using a standard windows file dialog box.
The name theme is added to the database for the current game and all future games.
Naming Options for Ships
In C# you can choose a naming theme for all the ships of a certain class, just as you can in VB6. C# also adds some new options.
You can choose for each class whether you want the names from the theme to be selected in order or selected randomly.
Each class has Prefix and Suffix name options. I’ll steal Father Tim’s example from the suggestion he made: Wind-class destroyers could be auto-named Arctic Wind, Bitter Wind, Cold Wind, Desert Wind, or Dragon-class carriers could be auto-named Red Dragon, Night Dragon, Gold Dragon, Shadow Dragon, etc.. So if you create a Colours naming theme for example, you can apply it to many different classes but with a different prefix or suffix.
Adding Your Own Commander Name Themes
Adding your own commander name themes was not possible in VB6. I’ve added that option for C# where the theme follows the pattern of First Name - Surname, with the option for both male and female names.
- Create three text files with one name per line for Male First Names, Female First Names and Surnames. There is no naming convention for file names.
- Click the second button shown below
- Enter the theme name in an input field that pops up
- Select the male names file using a standard windows file dialog box. You are prompted which file to select.
- Select the female names file using a standard windows file dialog box. You are prompted which file to select.
- Select the surnames file using a standard windows file dialog box. You are prompted which file to select.
The new commander name theme is added to the database for the current game and all future games.
<br
‘Battlestar Greek’ Commander Name Theme
I’ve added a new Naming Theme for my latest test campaign. It mixes names from Battlestar Galactica with names from Greek Mythology, so I’ve called it Battlestar Greek. It is a little weird 
but matches the theme for the campaign so I’m going to make it one of the standard themes. Here is a sample of some randomly generated names.
Shipping Line Names
You can rename shipping lines in C# Aurora. Just click on the ‘Admin Command’ that represents the shipping line on the Naval Organization window and click Rename. You provide a full name for the shipping line and a short name for the ship naming.
Colony Cost
The colony cost algorithm has been updated for C# Aurora to include hydrosphere extent, low gravity and tide-locked worlds and to change the rules for dangerous gases and max pressure. The new calculation is as follows:
Gas Giants, Super Jovians and worlds with a gravity higher than species tolerance cannot be colonised and therefore have no colony cost. Every other body has a colony cost that is equal to the highest colony cost factor from the following list:
Temperature: If the temperature is outside of the species tolerance, the colony cost factor for temperature is equal to the number of degrees above or below the species tolerance divided by half the total species range. For example, if the species range is from 0C to 30C and the temperature is 75C, the colony cost factor would be 45 / 15 = 3.00. The colony cost factor for tide-locked planets is 20% of normal, so in the example given the colony cost factor would be reduced to 0.60.
Atmospheric Pressure: If the atmospheric pressure is above species tolerance, the colony cost factor for pressure is equal to pressure / species max pressure; with a minimum of 2.00. For example, if a species has a pressure tolerance of 4 atm and the pressure is 10 atm, the colony cost factor would be 2.50. If the pressure was 6 atm, the colony cost factor would be 2.00, as that is the minimum.
Breathable Gas: If the atmosphere does not have a sufficient amount of breathable gas, the colony cost factor for breathable gas is 2.00. If the gas is available in sufficient quantities but exceeds 30% of atmospheric pressure, the colony cost factor is also 2.00.
Dangerous Gas: If a dangerous gas is present in the atmosphere and the concentration is above the danger level, the colony cost factor for dangerous gases will either be 2.00 or 3.00, depending on the gas. Different gases require different concentrations before becoming ‘dangerous’. Halogens such as Chlorine, Bromine or Flourine are the most dangerous at 1 ppm, followed by Nitrogen Dioxide and Sulphur Dioxide at 5 ppm. Hydrogen Sulphide is 20 ppm, Carbon Monoxide and Ammonia are 50 ppm, Hydrogen, Methane (if an oxygen breather) and Oxygen (if a Methane breather) are at 500 ppm and Carbon Dioxide is at 5000 ppm (0.5% of atmosphere). Note that Carbon Dioxide was not classed as a dangerous gas in VB6 Aurora. These gases are not lethal at those concentrations but are dangerous enough that infrastructure would be required to avoid sustained exposure.
Hydrosphere Extent: If less than twenty percent of a body is covered with water (less than 20% Hydro Extent), the colony cost factor for hydro extent is (20 - Hydro Extent) / 10, which is a range from zero to 2.00.
Low Gravity: If the gravity of the body is lower than the species tolerance, the colony cost factor for gravity is 1.00. In addition, the overall colony cost for the body will be suffixed by ‘LG’, for example 2.00 LG, which indicates that low gravity infrastructure is required for any population on that body. Normal infrastructure will not count toward the supported population.
Colony Cost of Comets
In VB6 Aurora, the colony cost of comets was not a major concern as there was no low gravity infrastructure. For C#, comets could potentially contain populations, albeit small ones.
Therefore temperature and colony cost now update as comets move towards and away from the sun. This means the population supported by infrastructure will change as well over time. The distance displayed on the system view is the current, rather than maximum, distance. You can flip between current and max colony cost on the System View and it is displayed on Colony Summary of the Economics window and on the Body Info tab of the Tactical Map.
The Unload Colonists Standing Order will ignore comets, so civilian traffic will not attempt to place colonists on comets about to disappear into the void.
I may add some larger comets to make this more interesting. Longer-term, I may also add eccentric planetary orbits with a similar approach to the above. This is an experiment on a small scale to see what issues I encounter
Population Capacity
A new concept, Population Capacity, has been added to C# Aurora. This represents the maximum population that can be maintained on a single body and is primarily determined by surface area. This is the total of all populations on the same body, not per population.
The Earth’s population is currently seven billion. However, the rate of population growth peaked at 2.1% at four billion, has been dropping since then (now 1.2%) and is projected to reach close to zero around eleven billion
https://ourworldindata.org/world-population-growth/
Therefore, I am going to use twelve billion as the baseline max capacity for an Earth-sized planet and four billion as the point at which growth rates are affected. Growth will follow the normal rules for up to 1/3rd of max capacity and then will fall off at a linear rate, hitting zero growth at max capacity (replicating the situation on Earth). The max capacity of a body will be equal to: (Surface Area / Earth Surface Area) * twelve billion. I will add some tech options to improve that capacity, particularly for smaller bodies. A planet can physically hold more people than the max capacity but this will result in unrest due to overcrowding in the same way as insufficient infrastructure.
While 70% of the Earth’s surface is water, that plentiful water also improves living conditions (the majority of the world’s population is less than 100 km from the nearest coastline). However, there does come a point when too much water will reduce the available living space. Therefore, once water covers more than 75% of the planet, capacity will drop at a linear rate, falling to 1% of normal capacity at 100% water. The 1% assumes a few, small, scattered islands or some form of colony floating on the surface.
Tide-locked worlds (one side always facing the star) have only 20% of normal capacity (after taking into account surface area and water). This is to simulate that the population will be living in a narrow band between the light and dark hemispheres of the planet. To compensate, these worlds also have an 80% reduction in the colony cost factor for temperature (as they are living in the temperate band).
Regardless of the result of the above calculations, a body with gravity at or below the species maximum that is not a gas giant or super-Jovian will always have a capacity of at least 50,000.
The above rules result in the following population capacities
Each Species has a population density modifier. This is normally set to 1 but there a small chance it can be higher or lower for random species. Player-created species can specify this density.
Delete Empty Colonies
With the new ground survey rules, I find I am creating colonies for the purpose of the survey and then being left with empty colonies scattered throughout the Imperium. I also have colonies that were created for various purposes but are now abandoned or never exploited.
Therefore, I have added the ‘Delete Empty’ button to the Economics window. This button will remove any colonies where all the following conditions are true.
There are no colonists
There are no installations
There are no abandoned installations
There are no ground forces at the colony
There is no ordnance stored at the colony
There are no components stored at the colony
There are no fleets orbiting the colony
There are no fleets with this colony as a destination
There is no ground survey potential
The colony is not exempt from deletion (see below)
A second button ‘Empty Exempt’ toggles a flag to prevent the colony from being deleted when the ‘Delete Empty’ button is pressed. The exempt status is noted on the colony summary. This is for those worlds that you do plan to exploit at some point, even though it currently meets the conditions for deletion.
Potential Colony Locations
VB6 Aurora has a window entitled Available Colony Analysis, which is used to search for new colony sites.
In C# Aurora, this function has been built into the System View window. If you click the ‘All System View’ button, the Stars section is replaced with search filters. Several areas that are not required in this mode, such as the jump point list, are hidden from view. The All System View button changes to the Normal View button, which will return you to the standard single system view.
While in the All System Mode, you can narrow the search for potential colony sites across all systems while retaining all the functionality of the system view window.
For example, here the Jovian Federation is looking for worlds with a colony cost of 4 or less that have minerals present. The results are sorted by Colony Cost and then Hydro Extent descending. The Federation has yet to develop jump tech so all the bodies are from the Sol system.
The second screen shot is from my previous campaign and shows a search for worlds with acceptable gravity, oxygen present, not in an alien-controlled system, below a colony cost of 4, with a pop capacity of at least one million and that have minerals present. This is sorted by colony cost and size of mineral deposits.
Automatic Pop Selection from Galactic Map
A minor but useful change. If you select a system on the galactic map and then click one of the buttons for the Economics window (Summary, Industry, Research, etc.), the Economics window will open with the most important population in that system (if one exists) already selected. Important in this context uses the same rules as the orders of populations in each system on the Economics tree view.
Trade Good Modifiers
In VB6 Aurora, civilian production of trade goods is affected by the population size, the race wealth creation rate, the production rate of each specific trade good, the political status of the colony and the wealth modifier of the planetary and sector governors.
In C# Aurora, it will also be affected by radiation and unrest.
Shipping Lines
A Shipping Line will start building freighters and colony ships when the parent race has two colonies (including the capital) with populations greater than zero.
A Shipping Line will start building passengers liners when the parent race has two colonies (including the capital) with populations greater than zero in two different systems.
A Shipping Line will start building harvesters when the parent race has two colonies with populations greater than zero and there is Sorium present at any gas giant or superjovian in a system with a parent race population of at least ten million (including the capital).
The number of civilian freighters and colony ships will be kept relatively even.
Creation of new shipping lines will only be possible once the starting shipping line has created its first ship.
Shipping Line Earnings and Tax
For C# Aurora, the distance a civilian ship has travelled (in terms of systems) will affect how much the shipping line receives in payment and how much tax is generated.
All VB6 payment rates will be halved as a baseline but multiplied by the number of systems travelled. So a civilian ship travelling to a destination two transits away will receive the same payment as in VB6 Aurora. A ship travelling to a destination five transits away will receive 250% of the current payment. This applies to trading and to player contracts.
Government tax rates on civilian shipping will work in the same way, except rates will not be halved as a baseline. This will increase the overall tax revenue from civilian shipping.
A civilian ship travelling within the same system will be paid half of the one-system rate (which is half what is currently paid in VB6). This applies to both the payment to the shipping line and the tax.
This should reduce some of the early game bloating of civilian traffic but make it workable for the later game with longer distances (especially with the new jump point generation in v7.1 of VB6 Aurora).
Civilian Trade
For C# Aurora, I’ve updated civilian trade to use a better algorithm.
In VB6, civilian freighters without orders will move to a ‘Trade Location’, which is defined as a population with a balance in one or more trade goods that is greater than the capacity of the freighter. On arrival, the freighter will check the trade balances and try to find a suitable destination for one of them. If a destination is found, the move will be plotted. If not, the freighter will search for a new trade location. It could be more intelligent but not without a larger performance overhead.
In C# Aurora, a freighter without orders, regardless of current location, will search known space for the closest population that has export trade goods, taking into account any other freighters already en route to collect that trade good (and any path finding restrictions such as danger). If a suitable trade good is located, the freighter will look for the population closest to the pick up point which has an import requirement for that trade good (again taking into account any freighter already en route to drop off the same good at that destination). If no destination is found, the freighter checks the pick up point for any other trade good options with suitable destinations. If that doesn’t work, the freighter checks the next population based on distance, etc., until it has checked every possible combination of populations and trade good routes in known space. If a valid route is found, all the orders are plotted including any Lagrange short-cuts. Then the next freighter repeats the process, etc..
Infrastructure is checked first at each population before any other trade good. Freighters understand the difference between low gravity infrastructure and normal infrastructure and will move the correct type of infrastructure to appropriate destinations.
Given that every civilian freighter without orders is checking every system, population and trade good in known space to find a suitable trade route, there might be a concern regarding performance. My current campaign is an ideal test bed, as I have removed every order from every fleet due to the incompatibility of the VB6 and C# database structures. Which means in the first trade phase after program start, the code is checking all 364 civilian freighters in a universe with 495 star systems, 1343 jump points, 380 Lagrange points, 345 populations and 23 different races. That first trade phase, including identifying routes for all freighters and creating 1896 individual movement orders (including load/unload, transits and LG points) required 1.01 seconds.
Colony fleets follow similarly complex rules, explained in the link below. Routing 198 civilian colony fleets using these rules, along with every other ship with Standing Orders, added a further 619 movement orders and required 0.56 seconds.
Civilian Destinations
In VB6 Aurora, civilians will treat any population of less than 25m as an automatic destination. Once a population is above 25m, the player can choose whether the population is a destination for colonists, a source of colonists or neither.
For C#, the population level at which the player can intervene has changed to the lower of 10m or half the capacity of the system body. Since the jump point generation changes in the later versions of VB6, the universe is more ‘stretched out’, so populations are much slower to reach the 25m mark.
I’ve also changed the population at which all trade goods become available to 10m (it was 20m for five trade good types).
10m aligns with the point at which civilians will consider creating mining colonies in the same system.
Civilian Movement Restrictions
A system can be flagged as ‘Military Restricted’ on the Miscellaneous tab of the Galactic Map. Once flagged, civilians will avoid the system. Civilians will also avoid any system flagged as alien-controlled.
A population can be flagged as ‘Military Restricted’ on the Civilian Economy tab of the Galactic Map. Once flagged, civilians will avoid the population.
When a system or population is flagged as restricted, any colony ships en route will be diverted to other destinations. Freighters en route will abandon their cargo and seek new trade runs. You will receive a popup warning on that basis before confirming the new status.
N.B In the past, I have been very reluctant to have restrictions on civilians, mainly because this would allow the players to effectively exercise direct control and consequently the civilians would just become an extension of the government. For example, using the above option, you could restrict every system except the one that you would like civilians to colonise. However, there are many ways to exploit Aurora if that was the goal of the player, so I’ve decided to leave it to players to role-play their preferred way of handling civilians.
Civilian Movement of Installations
As in VB6, Civilians will still transport installations for player races. However, there are changes to the UI, the path finding and the costs for the this service.
In terms of cost, in VB6 the cost was a set fee of 10 wealth for multi-system transportation and 5 wealth for same system, regardless of freighter size. In C# Aurora, the cost is:
5 x Number of Installations x Systems Travelled x (Installation Type Cargo Points / 25000)
So for a standard freighter (single cargo hold) transporting a construction factory to a destination four systems away, the cost would be 20 wealth. The calculation is 5 x 1 x 4 x (25,000 / 25,000). Destinations in the same system as the start point count as half a system.
For path finding, civilian ships will use the same logic as transporting trade goods. They will search for player contracts before searching for trade goods. Note this means you can effectively commandeer civilian shipping for your own needs in an emergency, but doing so will disrupt normal civilian operations such as moving infrastructure.
There is a Civilian Economy tab on the Economics window, which has three lists. To the left is a list of installations at the colony, the centre has a list of installations demanded and the right has a list of installations supplied. Above the centre list is a dropdown with all types of known installations. Above the right-hand list are the installations that the colony can supply. For both the latter lists, there is an Amount column, which is the amount Demanded or Supplied, and an Assigned Column, which is the number of the installations for which a freighter contract is already assigned (this is a sub-set of the Amount). The lists can be managed with the buttons below. Adding or editing will trigger a popup box so you can type in the amount required.
The screenshots below show:
-
A colony in Zeta Herculis with Supply contracts for various installations. Most are already fully assigned.
-
The Avalon colony with several Demand contracts. Again, most are already assigned.
-
A civilian freighter has been assigned one of the above contracts and is en route to the pickup point. Note that Shipping Lines will show up on the Naval Organization window if desired, although you can’t give them orders.
Civilian Mining Colonies
VB6 Civilian Mining Check
In VB6, a check is made each construction phase to see if new civilian mines are checked. The chance of this check is based on a random number of one million with a successful check equal to annual wealth or less. There must also be two populations for that race.
If a check takes place, the code orders all systems that contain a population of 10m or more (on a single body) and then steps through them in descending order of population. In each step, there is a 50% chance the system will be checked. Once a system is checked, no more will be checked in that phase.
The code then searches that system for bodies without a current population, less than 80 AU from their star, that have at least 15,000 tons of Duranium or Sorium and accessibility 0.7 or higher. The one with the highest combined amount of minerals of any type where accessibility is at least 0.5 accessibility is chosen.
The above can lead to a situations where good mining sites can be ‘blocked’ by higher population systems with no good mining sites and there are also some issues with potential locations. Therefore, C# uses a different method.
C# Civilian Mining Check
Each construction phase, if a race has at least two colonies with population or infrastructure, that race rolls a random number from 1 to 50,000. If that random number is less than Annual Wealth * (Construction Phase Seconds / Year Seconds), a check is made for a potential new civilian mining complex. For example, for a race with 20,000 annual wealth checking during a construction cycle that is exactly five days, the number needed to pass would be 274 (20,000 * 432,000 / 31,536,000), which is 0.55%. This is a lower chance for a check than in VB6 to account for the following changes.
If that check is passed, a list is made of all suitable locations for a civilian mining complex. A suitable location is a system body with at least 10,000 tons of Duranium that has an accessibility of at least 0.7. That system body must be in a system with at least one population of ten million and must be less than 80 AU from its parent star. If orbiting a non-primary star, that star must be within 80 AU of the primary or have an Lagrange Point within 80 AU that can link to a Lagrange Point within 80 AU of the primary.
Once all suitable locations are determined, each location is given a score based on the total amount of minerals with accessibility of 0.5 or higher. Duranium scores double. The new mining complex is created at the location with the highest score. Population is not a factor beyond the ten million limit required for consideration of the parent system.
For each existing civilian mining colony, a similar check is made in the construction phase to determine if an additional complex is added. For this check, the roll is 1-100,000.
Naval Organization
Instead of the Task Forces and Task Groups in VB6 Aurora, C# Aurora takes an approach similar to the optional functionality of the VB6 Naval Organisation tab, albeit with much easier and more flexible UI. There are four primary components of Naval Organisation; Admin Commands, Fleets (VB6 Task Groups), Sub-Fleets and Ships. Every race starts with a single top level Admin Command (which can’t be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy.
Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command
Sub-Fleets can only be attached to a Fleet, or to another sub-fleet. You can have an unlimited number of levels within the sub-fleet hierarchy. These are used to organise the ships within the larger fleets. Sub-fleets have no on-map function and all ships within the sub-fleet hierarchy move within the parent fleet. You can detach a sub-fleet, at which point it becomes a full fleet in its own right. Any sub-fleets further down the sub-fleet hierarchy become sub-fleets of this new fleet. A new ‘join as sub-fleet’ order is available. When one fleet joins another using this order, its ships will automatically form a sub-fleet within the joined fleet, allowing them to subsequently detach as a whole unit.
A Ship can be attached to a Fleet or to a sub-fleet. When attached to a sub-fleet, it is still a member of the parent Fleet at the top of the sub-fleet hierarchy.
The sidebar tree of the new Naval Organisation window (see Screenshots thread) has full drag and drop functionality so you can move Admin Commands, Fleets, Sub-Fleets and Ships around as long as the above rules are followed. You can also drag ships and sub-fleets between different fleets as long as they are in the same physical location. Entire sections of the tree can be moved with a single drag-drop. Also, you can open up multiple Fleet windows and drag and drop between the trees in two different windows.
Admin Commands
This post provides more details. Every race starts with a single top level Admin Command (which can’t be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy. Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command.
An Admin Command can be created at a population with a Naval Headquarters (a new installation). Each level of a Naval Headquarters costs 1200 BP and can be moved with the same cargo requirement as a research facility. Naval Headquarters function in a similar way to Sector Commands, with each doubling of the level adding +1 to the command radius. For example, level 1 has a Radius of 1, level 2 has a radius of 2, level 4 has a radius of 3, level 8 has a radius of 4, etc.. The command radius of the Admin Command is based on the Naval Headquarters in which it is based (with modifications for certain types of Admin Command). A single Naval Headquarters can support multiple Admin Commands.
If a fleet is within the command radius of its parent Admin Command, each ship within the fleet gains benefits based on the type of command and the bonus of the commander assigned to the Admin Command. There are seven different types of Admin Command, with the following capabilities.
Naval: Provides 25% of the Admin Command commander bonus for Crew Training, Reaction, Engineering and Tactical. (For example, if the commander has a 20% Reaction Bonus, a 5% bonus would be provided).
Patrol: Provides 25% of the Admin Command commander bonus for Reaction and Engineering. This command type operates at twice the command radius of the parent naval headquarters.
Survey: Provides 25% of the Admin Command commander bonus for Survey and Engineering. This command type operates at twice the command radius of the parent naval headquarters.
Logistics: Provides 25% of the Admin Command commander bonus for Logistics (cargo load/unload speed) and 10% of the bonus for Mining (including Harvesting) and Terraforming.
Industrial: Provides 25% of the Admin Command commander bonus for Mining and Terraforming, plus 10% of the bonus for Logistics.
General: Provides 10% of the Admin Command commander bonus for Crew Training, Fleet Training, Reaction, Engineering, Tactical and Survey, plus 5% for Industrial and Logistics.
Training: Functions differently to the others. Fleet Training can only take place within the command radius of a Training Admin Command (see later rules post for details). The crew training rating of the Admin Command commander is used as the basis for the speed of training.
Each Admin Command also gains additional bonuses if it is within the command radius of its own parent command. For example, if a survey fleet is within the command radius of a Survey Admin Command it will provide 25% of the bonus of the commander of that Survey Admin Command. If that Survey Admin Command is within the command radius of a parent Survey Admin Command, that bonus would be multiplied by 25% of the parent admin command commander bonus. So if both Admin Commands each had a commander with a 30% survey bonus, the total provided bonus to ships in the command radius of the lower Admin Command would be 15.56% (1.075 * 1.075). If a third layer existed above those two and that also had a commander with a 30% bonus, the overall bonus would rise to 24.23%.
This isn’t as easy to achieve as it might seem as each of these Admin Commands will need an assigned commander or the chain will be broken. Also each superior Admin Command requires a commander of higher rank than the inferior Admin Command and any Admin Command with fleets directly attached requires a higher rank than the highest-ranked ship captain in those fleets. If an Admin Command does not have a commander of sufficient rank, it will not provide bonuses. Therefore, large hierarchies are difficult to achieve. However, this does give meaningful commands for those higher ranked commanders that currently are used as the captains of major warships. It also means that if you establish the necessary command infrastructure required to support your fleets across your territory, it can have substantial benefits.
The required rank for each admin command is updated when the commander or naval organisation windows are loaded and during each construction phase. The check for the required level of commander is performed during each construction phase. If this check fails, the player will be notified and the admin command will be ineffective until the next construction phase.
Each increment, the command radius of all admin commands is checked so that all activity within that increment will use up-to-date information. This is dynamic during the turn, so the position of a ship or fleet at the moment it checks a bonus is used to determine the effect of the command network. The command hierarchy is checked each increment and whenever you modify that hierarchy so that you will always have up to date information on what rank is required for each Admin Command.
This command network is created using the new Admin Command tab on the Naval Organization window (see below). The Admin Commands are in green on the main structure chart. Each one is prefixed by the type abbreviation and suffixed by the required rank and current location. Selecting an Admin Command shows the systems within range and any Naval Headquarters in those systems. There is also a list of all Naval Headquarters within your Empire and a breakdown of the different Admin Command types. New commands can be created by selecting a parent Admin Command, a host population and an Admin Command Type. Fleets can be dragged and dropped between Admin Commands as desired. I will also add a movement order specifying a change in Admin Command.
None of this functionality has to be used as all new fleets will be assigned to the single, starting Admin Command. However, for those players who wish to set up their own command structures, I hope this will add an interesting extra dimension to the game. As with all these changes, I may modify things a little as a result of play testing but the essential principles should remain the same.
Assignment of Ships to Populations
In VB6 Aurora, ships such as terraformers or asteroid miners have to be assigned to populations in order to provide that population with any applicable production. This is because an empire may have multiple populations on the same world and the ships can only provide support to one of them. When a fleet reaches a population, the ships within it are automatically assigned. However, there are still situations (such as transferring between fleets) when this assignment is not always picked up. While the problem can easily be fixed by ordering the fleet to the population, it is not always obvious it needs to be fixed. This can lead to ships sitting idle in orbit.
In C# Aurora, the assignment to the population will be at the fleet level, rather than by ship, and the same auto-assignment will happen when a fleet moves to a population. However, when a population checks orbital space for any assigned fleets during production, it will automatically grab any unassigned fleets in orbit and assign them to itself. This should avoid any situations where ships remain idle.
Command & Control Rules
I am introducing new command and control rules for C# Aurora. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill). However, additional officers can be assigned to the ship with each officer applying his full bonus for his chosen speciality (more on that later). The commander of the ship is now a jack-of-all-trades, applying a portion of his bonus while the specialists provide the larger bonuses. Larger ships gain an advantage as they can afford the space to accommodate the specialists, while smaller ships have to make do with the commander handling everything (at half efficiency). Any bonuses not mentioned here (such as Reaction or Production) will still be at full value for the commander.
Five new command and control modules have been added, the cost of the bridge has been doubled and the role of the flag bridge has been changed. Each module adds one to the Control Rating of the ship.
-
Bridge is 1 HS and costs 20 BP. The required rank for the ship commander is the racial minimum.
-
Auxiliary control is 1 HS and 15 BP. Allows the assignment of an Executive Officer to the ship who will apply his full Crew Training Bonus. The required rank for the ship commander is one above the racial minimum.
-
Science Department is 2 HS and 50 BP. Allows the assignment of a Science Officer to the ship who will apply his full Survey Bonus. The required rank for the ship commander is one above the racial minimum.
-
Main Engineering is 3 HS and 75 BP. Allows the assignment of a Chief Engineer to the ship who will apply his Engineering Bonus to affect maintenance and damage control. The required rank for the ship commander is two above the racial minimum.
-
Combat Information Centre (CIC) is 3 HS and 75 BP. Allows the assignment of a Tactical Officer to the ship who will apply his Tactical Bonus to various combat-related function (TBD). The required rank for the ship commander is two above racial minimum.
-
Primary Flight Control is 4 HS and 100 BP. Allows the assignment of a Commander Air Group to the ship who will apply his full Fighter Operations Bonus. The required rank for the ship commander is one above the racial minimum.
-
Flag Bridge is 5 HS and 125 BP. A fleet that includes a ship with a flag bridge can assign a ‘fleet commander’ senior to the commander of the ship. If a fleet has multiple flag bridges, the most senior officer assigned to any of them will be the fleet commander. The fleet commander will improve the fleet’s overall reaction rating by his Reaction Bonus. If there are no flag bridges in a fleet, the senior ship commander will be the de facto fleet commander, but his reaction bonus will not affect other ships. The required rank for the ship commander of the ship with the flag bridge is two above the racial minimum. There are no longer any task forces or staff officers. Any commander assigned to a flag bridge who is not the most senior in the fleet will be referred to as a ‘Flag Officer’.
In cases where different control stations have different required ranks for the ship commander, the highest rank takes precedence.
An officer can be killed if his station is damaged. I may also add ‘temporary promotions’ if the commander is killed, with the most senior surviving officer taking over as commander until relieved or promoted.
Except for the ship commander and the executive officer, the bonus from each specialist will only apply if their associated module is undamaged. Bonuses from the commander and XO will only apply if the ship has a control rating greater than zero (they can command the ship from any of the surviving control spaces). Ships smaller than 1000 tons automatically have a control rating of 1, even without a bridge. This is to simulate that small ships do not require a dedicated centralised command function.
I don’t plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won’t be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.
For auto-assignment purposes, each ship class now has a specific rank requirement for its commander, based on its command and control modules. The rank requirement for the XO, CAG and Science Officer is one lower than for the ship commander. The rank requirement for the Chief Engineer and Tactical Office is two lower than the ship commander. The rank requirement for a fleet commander is one higher than for the ship commander. You can manually assign higher-ranked ship commanders and fleet commanders if desired but other officers can only be assigned at the specified rank. The commander priority setting for each class of ship remains as before and is still set manually. It also applies to the other officer types as well. Auto-assignment will work in the following sort order:
- Class Priority
- Survey Ships by descending size
- Warships by descending PPV
- Unarmed Military Ships by descending size
- Construction Ships by descending construction speed
- Terraformers by descending terraforming capacity
- Sorium Harvesters by descending harvesting capacity
- Asteroid Miners by descending mining capacity
- Salvage Ships by descending salvage capacity
- All other ships (primarily freighters and colony ships) by descending size
Ship commanders will be assigned first (checking every category above), followed by executive officers, science officers, air group commanders, chief engineers and tactical officers. The ships will cycle through in priority order and commanders will be assigned if they meet the criteria for the ship type (correct rank and suitable bonus).
These changes should make ship design more interesting, create better histories for commanders (as they progress through different roles) and provide lots of potential roles for the junior commanders.
Commander Careers
In C# Aurora, the rules for accidental death and commander health remain as they are in VB6 Aurora.
Retirements are handled differently. An naval officer will be checked for the potential for retirement from service once the length of his career exceeds the minimum retirement time for his rank. The minimum retirement point is 10 years for the lowest rank. For other ranks it is equal to 10, plus 5 years for every level of rank above the minimum. So assuming lieutenant commander was the lowest rank, minimum retirement would be 10 years after career start for a lieutenant commander, 15 years for a commander, 20 years for a captain, etc..
For ground forces commanders the minimum retirement is 20 years for the minimum rank. For other ranks it is equal to 20, plus 5 years for every level of rank above the minimum.
For scientists and administrators the minimum retirement is 40 years.
The chance of the retirement occurring is 20% for each year beyond the minimum retirement date. This is doubled if the commander has no assignment. Each increment the chance is checked using: (Increment Length / One Year) * Retirement Chance.
The VB6 concept of ‘tour length’ does not exist in C# Aurora, so there will no longer be mass-reassignments every couple of years. In addition, the removal of officers after six years with no command will no longer happen. Instead, C# should have a more realistic progression because of the different mechanics. Firstly, inactive or low ranked commanders will tend to retire relatively early, which will keep overall officer numbers down and open up their commands (if one exists) for new assignments. Secondly, ships can potentially have multiple officers, which creates many more assignments. Thirdly, each ship (or other officer position) can only be assigned to an officer of a specific rank. As soon as that officer is promoted, he has to leave that position, which opens it up for another officer. Finally, naval officers in non-command positions (XO, Tactical Officer, CAG, Chief Engineer, Science Officer), will be automatically assigned to any ship command position that becomes available, assuming they have suitable bonuses, opening up their previous role.
Ship commander ranks are based on the following rules:
- Assume lowest rank if none of the following conditions exist. Otherwise use the highest applicable rank for any condition.
- Lowest rank + 1 for any ship class equipped with any of the following: Geological or Gravitational Sensors, Auxiliary Control, Science Department, Jump Drive
- Lowest rank + 2 for any ship equipped with any of the following: Weapons, Military Hangar Bay, Main Engineering, CIC, Flag Bridge
- Regardless of the above, any ship of 1000 tons or less will be the lowest rank, unless it has one of the control stations (Auxiliary Control, Science Department, Main Engineering, CIC)
Additional officers on the same ship have the following rank requirements:
- One rank lower than required ship commander rank: Executive Officer, Science Officer, Commander Air Group
- Two ranks lower than required ship commander rank: Chief Engineer, Tactical Officer
For example, the executive officer on a warship would be lowest rank + 1 (one lower than commander requirement) while the executive officer on an unarmed geological survey ship would be the lowest rank.
Overall, the variety of positions available at different ranks, combined with the positions opening up due to retirements, promotions and assignment of junior officers to ship command, should provide a more interesting career progression.
Auto-Assignment of Naval Commanders
Auto-Assignment of naval commanders is similar to VB6, although the process is now more detailed.
Every class of ship has a Commander Priority, a Primary Assignment Priority and a Secondary Assignment Priority. The Commander Priority, is set by the player, with 0 being the highest priority (until v1.12 when 0 is lowest), while the others are set by Aurora. Each class also has a Primary Bonus Type. When the list of ships without commanders is created every construction phase (during the auto-assignment phase) it is ordered by Commander Priority then by Primary Assignment Priority and then by Secondary Assignment Priority.
The ships are cycled through in that order, searching the available commanders (which is any unassigned commander or any commander assigned to a non-command position on a ship) for a suitable match for each ship. During the first run through of all ships, a suitable commander must have the primary bonus for the ship or they will not be assigned. In C# Aurora, unassigned commanders still have a small chance of gaining experience, including new bonuses, so they may be assigned in the future even if they currently do not have a suitable bonus.
Primary and Secondary Assignment Priorities and the Primary Bonus are set based on the following rules. Secondary Assignment Priorities are based on descending order for the ship class and the Primary Bonus is based on descending order for the commander.
Geo Survey or Grav Survey
Primary: 1
Secondary: Size
Bonus: Survey
Protection Values > 0
Primary: 2
Secondary: Protection Value
Bonus: Crew Training
Military Vessel
Primary: 3
Secondary: Size
Bonus: Crew Training
Construction Ship
Primary: 4
Secondary: Class Cost
Bonus: Production
Terraformer
Primary: 5
Secondary: Number of Terraforming Modules
Bonus: Terraforming
Harvester
Primary: 6
Secondary: Number of Harvesting Modules
Bonus: Mining
Asteroid Miner
Primary: 7
Secondary: Number of Mining Modules
Bonus: Mining
Salvager
Primary: 8
Secondary: Number of Salvage Modules
Bonus: Production
All Others
Primary: 9
Secondary: Size
Bonus: Logistics
Bear in mind that all of the above is secondary to the priority given to each class by the player, so if you want a particular type of ship to get the best commanders assigned, give it a high priority.
After ship commanders are assigned, the non-command positions are assigned. Ships must have the appropriate command module for each non-command position in order for a commander to be assigned and the commander must have the required bonus. For each of the non-command positions (in the order below), the ships with an available position are ordered using the same rules as above, including the player priority. The positions and requirements are as follows:
Executive Officer
Command Module: Auxiliary Control
Bonus: Crew Training
Science Officer
Command Module: Science Department
Bonus: Survey
Commander, Air Group
Command Module: Primary Flight Control
Bonus: Fighter Operations
Chief Engineer
Command Module: Main Engineering
Bonus: Engineering
Tactical Officer
Command Module: CIC
Bonus: Tactical
Crew Grade
In VB6 Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to the commander’s crew training rating. The maximum number of points is 2000.
In C# Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to 50% of the commander’s crew training rating, plus 100% of the executive officer’s crew training rating. This training will only happen if the ship has at least one command & control system undamaged. The maximum number of points is 1000.
A ship’s crew grade bonus is equal to SQRT(Grade Points) - 10. So for VB6 Aurora the maximum is 34% and for C# Aurora it is 21.6%.
The net effect is that the grade bonus will be received more quickly but has a lower maximum value. The gap will be made up by the bonuses of other officers, such as the Tactical Officer or Chief Engineer.
Crew Morale
An issue in VB6 is that crew morale is checked for all ships, yet for many ships (anything that is not a military ship or doesn’t mount survey sensors), the morale is effectively irrelevant.
Therefore in C# Aurora, only ships for which morale is a potential issue will be checked for exceeding deployment time. This check is indicated by the addition of ‘MCR’ to the end of the Intended Deployment Time row of the class summary.
The requirement for a ship to have at least a 3 month deployment time in order to be classed as a non-military vessel still remains.
Flight Crew Berths
In VB6 Aurora, the player has to remember to add additional accommodation for the crews of parasite warships when designing a carrier, even without knowing the potential future parasites. These are known as Flight Crew Berths.
In C# Aurora, due to changes in the way crew morale and overcrowding are handled, the design process will automatically add 20 flight crew berths for each hangar bay. These berths are assumed to be sufficient for whatever parasite warships are present.
Academy Commandants
Commanders can be assigned as an Academy Commandant on any population with at least one military academy. Any type of commander can be assigned with the following restrictions:
- A civilian administrator must have an Admin Rating equal or greater than the number of military academies at the population
- A scientist must have a Research Administration rating (new bonus for C# which is the max number of labs) at least five times the number of military academies at the population
- A naval or ground forces officer must have a rank (with 1 being the lowest rank) at least equal to the number of military academies
The normal distribution of new commander types from the academy is 60% Naval, 25% ground, 8% Admin, 7% Scientist. While a Commandant is assigned, a check is made to see if an commander of the same type as the Commandant is generated. If the check fails, the normal distribution is followed. The chance is 14% for a Scientist Commandant to generate a Scientist, 16% for an Administrator Commandant to generate an Administrator, 40% for a Ground Forces Commandant to generate a ground forces officer and 80% for a Naval Commandant to generate a naval officer.
When a new commander is generated, a check is made to see which bonuses he receives. If the Commandant has at least 20% in any percentage-based bonus or 150 for crew training / ground unit training, all commanders graduating from the academy at that population will take two rolls for each qualifying bonus, and use the higher of the two results. If the Commandant is a scientist, there is a 25% chance any scientist from that academy will have the same research specialisation. If that check fails, the research specialisation will be chosen randomly (as normal).
This new rule should allow specialisation of academies on different worlds. Don’t forget that you can set up a military academy on any colony, not just those with a population.
Fleet Training
Fleet Training in C# Aurora provides the same benefits as VB6 Aurora. The mechanics by which it takes place are quite different.
Any fleet assigned to an Admin Command with a ‘Training’ specialisation will automatically take part in Fleet Training. Attaching a fleet to a Training Admin Command will start Fleet Training, while removing it will end Fleet Training. For details on Admin Commands, see above.
Each construction phase, each ship in a fleet assigned to a Training Admin Command will gain Fleet Training Points based on the following formula:
Crew Training bonus of the Admin Command Commander * Ship Crew Grade * Ship Morale * (Construction Phase Length / One Year)
Unlike VB6, a fleet undergoing Fleet Training can perform normal duties and can be given orders if desired (although this is not required). There are no fixed movement or locations for training. However, only military ships can benefit from Fleet Training. While in training, a ship is under the following restrictions:
- The parent fleet must remain in a system that is within range of its parent Training Admin Command
- The ship cannot use maintenance facilities
- The ship does not benefit from a Recreational Location
- Maintenance Failure Chance is 2x normal
- The ship’s Maintenance Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
- The ship’s Shore Leave Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
- Fuel is used as if the ship was running its engine at 10% power for the period of training (this is on top of any fuel used in normal movement). The fuel is consumed during each movement phase. A ‘ship’ without engines does not require fuel for this purpose
- Training will not take place if the ship is out of fuel or the Training Admin Command does not have a sufficiently senior commander.
These mechanics are intended to simulate that ships assigned to ‘Fleet Training’ are carrying out intensive training (drills, etc,) during the course of their normal activities. This places a strain on the ship systems and the crew, resulting in increased maintenance and fuel use and a lower overall deployment time. The ship also sacrifices the benefits that would come from a different type of Admin Command.
Ground Commander Bonuses
Ground force commanders have a much greater variety of bonuses in C# Aurora. The most straightforward are:
-
Ground Combat Defence (GCD): When elements of a formation are fortified, their fortification level is increased by the formation commander defence bonus
-
Ground Combat Offence (GCO): Increases the to-hit chance of all direct-fire weapons in the formation
-
Ground Combat Artillery (GCA): Increases the to-hit chance of all indirect-fire weapons in the formation
-
Ground Combat Anti-Aircraft (GCAA): Increases the to-hit chance of all anti-aircraft weapons in the formation
-
Ground Combat Logistics (GCL): Represents the chance that a formation element will not draw supply during a combat round.
-
Ground Combat Manoeuvre (GCM): Increases the chance that a formation will make a breakthrough in combat
-
Ground Combat Occupation (OCC): Boosts the occupation strength of a formation
-
Survey (SURV): Increases the output of geosurvey modules in ground units
-
Production (PROD): Increases the output of construction modules in ground units
-
Xenoarchaeology (XEN): Increases the chance of successfully recovering abandoned installations
In addition to the above, each ground commander has a ‘Ground Combat Command’ rating, which represents the size of the formation he can effectively command. This rating is given a relatively high score for promotional purposes so officers with high command ratings will tend to progress though the ranks.
If an officer is commanding a formation that is larger than his command rating, the effectiveness of his other bonuses will be reduced by (command rating / formation size). For example, an officer with a 20% defence bonus and a command rating of 5000 is commanding a regiment with a size of 7000. The defence bonus is reduced to 14.3%. In addition, if the largest HQ in a formation has a rating less than the formation size, the effectiveness of the formation commander’s bonuses will be reduced by (HQ rating / formation size). These penalties (command rating and HQ rating) are cumulative. Note that if all HQ capacity in a formation is eliminated, no commander bonuses will apply.
Finally, ground forces officers have a Ground Combat Training bonus, which affects morale. Each construction phase, any formation element with less than 100 morale will regain that morale at a rate of 100 per year, plus the commander training bonus (so a 20% bonus would increase morale recovery to 120 per year). Formation elements can continue to improve morale above 100, using the following process:
-
The training bonus percentage (after any reduction for command rating and HQ rating penalties) is converted into a morale bonus at 1% = 1 morale point (so 10% training bonus = 10 morale bonus).
-
Maximum formation element morale is 100 plus 5x the morale bonus
-
Formation element morale increases at a rate equal to the morale bonus per year multiplied by the ‘Morale Gain Modifier’
-
The ‘Morale Gain Modifier’ is calculated as 1 - ((Element Morale - 100) / (Maximum Morale - 100))
For example, a formation element has 140 morale and the commander of the parent formation has a Ground Combat Training bonus of 30%. However, he is commanding a formation that is slightly too large for his Ground Combat Command rating, so he has a Command Modifier of 0.8. The training bonus is 24% (30% x 0.8), which converts to a morale bonus of 24. The maximum morale for the formation is therefore (100 + (5 x 24)) = 220. The morale gain modifier is 1 - ((140-100) / (220 - 100)) = 0.667. Therefore, the formation will gain morale at 24 * 0.667 = 16 points per year.
Ship Commander Rank
The required rank of a ship commander is set automatically by Aurora and will be the lowest race rank, unless one of the following component rules is activated. Component rules are not cumulative so only the highest requirement applies.
If a ship is greater than 1000 tons and has any of the following component, the required rank is lowest rank + 1: Weapons, survey sensors, a jump drive, a hangar deck.
If a ship has any of the following component, the required rank is lowest rank + 1: Auxiliary Control, Science Department, Primary Flight Control.
If a ship has any of the following component, the required rank is lowest rank + 2: Main Engineering, CIC, Flag Bridge.
The Class Window has a checkbox entitled Senior C.O. If this is checked, the class will have a required rank one higher than the above rules require (to allow the player to designate certain classes as worthy of a more senior officer than normal).
Story Characters
A commander can be flagged as a ‘Story Character’. A Story Character will not suffer accidents or ill health and will not be automatically retired. This could be abused for scientists but I will leave it up to players how they want to use this option.
You can also flag a commander as ‘Do Not Promote’. The commander will remain in his current rank and not undergo automatic promotion.
Change Scientist Research Field
There is a new option on the Commander window to change the research field of a scientist. Any field can be chosen, but the current research bonus is reduced by 75%.
This is the same effective rate at which a scientist can already operate in a different field. However, they will now start to gain experience in the new field.
New Maintenance Rules
In VB6 Aurora, the maintenance facilities of a population, aided by ships in orbit with maintenance modules, have a maximum maintenance capacity measured in tons. Any ship of that size or less can be maintained. Fighters cannot be maintained in this way and have to be stored in hangars.
In C# Aurora, maintenance facilities and modules are handled differently:
-
Each maintenance facility or maintenance module has a basic capacity of 1000 tons. A new tech line exists that can raise this capacity in increments, starting with 1250 capacity for 2000 RP. The 2000 ton capacity is at 8,000 RP and the max is currently 6250 tons at 250,000 RP.
-
Any location that contains a population with maintenance facilities or a ship with maintenance modules is known as a ‘Maintenance Location’. This does not need to be in the same location as a population. A Maintenance Location consisting only of ships with maintenance modules could be in deep space.
-
The maintenance capacities of all populations and maintenance ships of the same race in the same Maintenance Location are added together to create a ‘Total Maintenance Capacity’.
-
A Maintenance Location can fully maintain ships in its location if the total tonnage of those ships is equal to or less than the Total Maintenance Capacity. In other words, maintenance is now based on summing the tonnage of ships to be maintained, rather than supporting all ships under a set tonnage.
-
If the total tonnage of the ships to be maintained is greater than the Total Maintenance Capacity, each ship will be partially maintained. This is known as the ‘Effective Maintenance Rate (EMR)’ For example, if the Total Maintenance Capacity is 80,000 tons and the total tonnage of the ships requiring maintenance is 100,000 tons, the EMR is 80%. Each ship will use 80% of the normal amount of MSP required for maintenance. Each’s ship maintenance clock will advance at 20% of normal and their chance of system failure will be 20% of normal.
-
The maintenance capacity of maintenance facilities on a population is modified by the population’s Manufacturing Efficiency (available worker / required workers), Radiation Production Modifier, Political Stability Modifier (based on unrest) and Political Status Production Modifier (Conquered / Subjugated, etc.). The capacity of both maintenance facilities and maintenance modules is modified by the racial Economic Production Modifier (amount of debt vs annual income).
-
Ships can enter overhaul in the same way as they do now, except they can also do this at a deep space Maintenance Location as well as at a population. Overhauls will proceed at a slower rate (and use fewer MSP) if the total tonnage of the ships being maintained exceeds the Total Maintenance Capacity. However, ships undergoing overhaul will not suffer maintenance failures in this situation.
-
Fighters can be maintained by Maintenance Locations and do not need to be stored in hangars (because now they use capacity whereas the VB6 rule was implemented to prevent unlimited fighters being maintained).
Use of Maintenance Supply Points (MSP):
-
MSP are used in a very similar way to VB6 Aurora. While a ship is being maintained, it requires total MSP per year equal to Class Cost / 4. A ship undergoing overhaul requires total MSP per year equal to Class Cost.
-
If the ship is being maintained in a situation where the total tonnage of the ships being maintained is greater than the Total Maintenance Capacity (EMR less than 100%), the MSP requirement will be reduced accordingly (see above).
-
The ship being maintained will use up MSP from any racial populations in the same location, in descending order of MSP stockpile. If no populations are available, or have no MSP, the maintained ship will use MSP from any Supply Ships in the same location, in descending order of available MSP. Finally, if no other option is available, the maintained ship will consume its own MSP. A ship can use a combination of the above to locate sufficient MSP.
-
If the ship cannot locate sufficient MSP to meet the requirements for maintenance, this also has an impact on the Effective Maintenance Rate (EMR) for that specific ship. For example, assume a Maintenance Location with a capacity of 80,000 tons is maintaining 100,000 tons of shipping. The EMR for that Maintenance Location is 80%. A ship with a class cost of 1500 BP is being normally maintained and will require annual MSP equal to (Class Cost / 4) * EMR or (1500 / 4) * 80% = 300 MSP. If the ship can only locate 240 MSP, the EMR will be reduced by the proportion of available MSP to required MSP: (240 / 300) * 80% = 64%. The ship will now consume 240 MSP, the maintenance clock will be advanced at 36% of normal and the chance of system failure will be 36% of normal. (in reality the MSP numbers will be much smaller as during a single increment the ship is being maintained for only a small fraction of a year).
-
The order in which ships are checked for available MSP is based on Class Maintenance Priority, then by Overhaul vs. Normal Maintenance, then by highest maintenance clock.
-
The chance of system failure, whether away from a Maintenance Location or while being partially maintained, is reduced by the crew grade bonus (or increased for crews with a negative bonus) and the ship’s Engineering bonus (50% of commander bonus and 100% of Chief Engineer bonus).
These new rules remove many of the maintenance restrictions on larger ships and make maintenance of FACs and fighters more realistic. They introduce the same economic factors to maintenance that exist for production. In addition, I believe this creates a more realistic environment where the required maintenance facilities / modules are tied to the absolute amount of ships to be maintained, rather than just their maximum size. Finally, maintenance can now be carried out away from population centres, making deep space bases a possibility.
Maintenance Locations View
There is a new display option on the galactic map to highlight Maintenance Locations. They are displayed as a dashed blue circle.
Change to Maintenance Facility Cost
Because of the changes to maintenance in C#, maintenance facilities have become much more important for two reasons:
- You can no longer use the same maintenance facilities to support multiple ships, so you need far more maintenance facilities in general. For example, if you build a 20,000 ton ship, you also need 20,000 tons of extra maintenance facility capacity to support it.
- The only source of maintenance supply points is from maintenance facilities as you can no longer build them with construction factories.
Because of the above, the cost of maintenance facilities has been reduced to 60 BP. They remain the same in other aspects, such as transport size, manning requirements, target size, etc.
Note: In general I am very happy with the maintenance changes. They allow you to setup distant bases capable of handling larger ships much more easily and, together with the new shipyard worker requirements and the need for more financial centres, they are putting much more pressure on the number of available workers.
Minerals for Maintenance Supplies
One of the major practical game play changes I have found through play-testing C# Aurora is the ease with which new naval bases can be created (because of the new maintenance system).
However, that brings a new issue. As you can no longer build MSP using construction factories in C#, you need to make full use of the MSP production of maintenance facilities or you start to run out of MSP (which is happening to me now because I am not doing that). The reason I am struggling to build MSP at the new bases is that MSP require eight different minerals. 1 MSP costs 0.25 BP and requires the following minerals (in tons): Duranium 0.05, Neutronium 0.025, Tritanium 0.025, Boronide 0.025, Mercassium 0.025, Uridium 0.025, Corundium 0.025, Gallicite 0.05. There is a lot of micromanagement required in either mining those minerals locally or moving them manually.
Therefore, for game play reasons and my own sanity I’ve decided to reduce the number of minerals required. I summed all ship components subject to maintenance for all military ships in my current game (including AI) to determine the most common minerals. Duranium and Gallicite were about the same, Uridium was about half of those and everything else was much lower, around one sixth or less of Duranium. Therefore I am going to change MSP minerals to Duranium 0.1, Uridium 0.05, Gallicite 0.1. That is much easier to remember and more reflective of reality. While that does increase overall Duranium consumption a little, I have also changed some buildings to use less Duranium, which I will post about separately.
Abandon Overhaul
In VB6, a fleet can issue an Abandon Overhaul order and one month later, any ships in overhaul within that fleet will be returned to a normal maintenance state.
For C#, each individual ship (or a whole fleet) can choose to abandon overhaul at any point. It immediately returns to a normal maintenance state but suffers severe after-effects as the crew try to return the ship to normal working order. The ship has an ‘Overhaul Factor’ that starts at 0.01 immediately following the abandon overhaul decision and increases to 1.00 over the course of thirty days. The increase takes place in each movement phase sub-pulse, following movement in that sub-pulse. The ‘Overhaul Factor’ is used in a similar way to crew grade and morale and affects the following:
- Weapon Chance to Hit.
- Engine Power
- Maximum Shield Strength
- Maintenance Failure Chance
- Jump Shock Length
- Fleet Training
For example, a ship six days after abandoning overhaul will have an overhaul factor of 0.2. Assuming no crew grade or morale modifier, engine power and maximum shield strength will be 20% of normal, combat to hit chance will be 80% lower than normal. Maintenance Failure will be 80% higher, Jump Shock length will be 80% longer and Fleet Training will be at 20% of normal.
This rule allow ships to leave overhaul immediately if absolutely necessary (such as hostile vessels closing in), but the short-term penalties are considerable. The Abandon Overhaul order has been removed.
Ships undergoing overhaul in C# Aurora are zero speed for purposes of incoming missile or weapon fire, cannot fire weapons or launch missiles and have zero shield strength.
Terraforming Update
In terms of the general mechanics, terraforming works as it does in VB6 Aurora. Atmosphere measured in atm (atmospheric pressure) is added by terraforming ships or installations. However, there are several significant changes for C# Aurora.
-
The base terraforming technologies have their atm rates reduced by 75% at the lower tech levels. The rate of tech increase has improved so the higher tech levels are reduced by around 60%. The starting racial tech rate per module/installation is 0.00025 atm per year.
-
Smaller planets are much faster to terraform. The terraforming rate in atm is modified by Earth Surface Area / Planet Surface Area. For example, the rate at which atm is added to Mars is 3.5x faster than on Earth (90% of VB6 Aurora speed), Ganymede is 6x faster and Luna is almost 14x faster (3.4x faster than VB6)
-
System Bodies with gravity of less than 0.1G cannot retain atmosphere and therefore cannot be terraformed
-
Carbon Dioxide is now a dangerous gas.
-
Water is now a significant factor in terraforming planets. Any planet with less than 20% water has a colony cost factor for water equal to (20 - Hydro Extent) / 10 (see colony cost rules).
-
Water vapour can be added to the atmosphere just like any other gas.
-
Water vapour will condense out of the atmosphere at a rate of 0.1 atm per year and increase the planet’s Hydro Extent
-
Each 1% of Hydro Extent requires 0.025 atm of water vapour. This means that creating 20% Hydro Extent would require 0.5 atm of water vapour (this will be much faster on smaller worlds because the speed at which water vapour atm is added is linked to surface area). With this in mind, existing water becomes an important factor in the speed at which terraforming can be accomplished, especially on larger worlds.
-
Water will also evaporate into the atmosphere. The evaporation cycle follows condensation and will stabilise water vapour in the atmosphere of a planet with liquid water at a level of: Atmospheric Pressure * (Hydro Extent / 100) * 0.01 atm. The resulting atm * 20 is the % of the planet’s surface that loses water. As the water vapour is removed from the atmosphere, it will replenish from the surface water. This is to allow the removal of water from ocean worlds to create more living space.
These new rules should add more variety to terraforming and, in conjunction with the max population rules, should add more interesting decision-making when choosing which worlds to terraform.
Engine Size and Fuel Consumption
In C# Aurora, missile and ship engines follow a single fuel consumption rule. The modifier is equal to SQRT (10 / Engine Size in HS). Thanks to alex_brunius for the formula.
The new rule creates a smooth transition for both engine types, which is more realistic and consistent, provides a bonus to larger ships, makes the fuel portion of missile design more interesting (as fuel is not a major concern at the moment) and allows larger engines to be designed beyond the current 50 HS limit.
This will complement the new sensor changes as they will reduce missile ranges anyway (described in the changes discussion thread but not published here yet)
As a result of these changes, a new Maximum Engine Size tech progression has been added. The starting max engine size is 25 HS. The research progression is 40 HS, 60 HS, 100 HS, 160 HS, 250 HS and 400 HS, with the costs ranging from 2,000 RP to 60,000 RP.
Engine HTK
Due to their size, Engines in VB6 Aurora create a damage shield because their HTK is very high compared to the amount of damage they are likely to receive. This would only become worse in C# Aurora with much larger engines now possible.
Therefore, the Engine HTK will change from 50% of Size to SQRT(Size).
Maximum Engine Power Modifier
The research costs for the Maximum Engine Power Modifier line of technology have all been halved. The Minimum Power Modifier line of technology remains at the VB6 research costs.
Engine Technology Progression
I’ve updated the engine technology progression to include a couple of extra early levels that will smooth out the speed progression. In addition, Ion has been increased from 12 to 12.5 and Plasma Core Anti-matter changed from 60 to 64. See below for old and new engine progressions. Also (not shown), I’ve changed conventional engine power from 0.2 to 1.0 to make the conventional era more interesting.
Power plants have been updated on the same lines, with two new additions and minor changes to power ratings
Plasma Carronades
- The development cost of Plasma Carronade focal size has been halved. For example, a 30cm Carronade is now 4000 RP.
- The building cost of Carronades has also been halved.
These two changes should make Carronades more viable. A powerful and inexpensive weapon but very short-ranged.
Particle Lance
The Particle Lance is a large, potentially devastating weapon that is variant of the Particle Beam.
Once Particle Beam Range 200,000 km and Particle Beam Strength 6 have both been researched, the Particle Lance can be researched for 30,000 RP. The Lance is a modification of the normal Particle Beam and is an extra option in the design window.
The Particle Lance modification affects the Particle Beam in the following ways:
2x Damage
2x Size
2x HTK
2x Crew
2.5x Power Requirement
3x Cost
2x Development Cost
As well as the above modifications, which essentially creates a weapon twice as large, that recharges 2.5x more slowly and costs 3x as much, the damage template of the Particle Lance is a single column of armour, rather than the Particle Beam which has a template between that of missiles and lasers. The Particle Lance retains the constant damage of the Particle Beam, creating a weapon that can penetrate enemy armour at significant range.
Here are examples of similar tech level Particle Beam, Particle Lance and Laser.
Comparison of Damage Templates at 240,000 km
Particle Beam (6): 2, 3, 1
Particle Lance (12): 12
Laser (3): 3
Two Particle Beams or 25cm Lasers can be installed in the same hull space as the Particle Lance. The Lasers are devastating at close range, the Particle Beams inflict more damage at long range (in terms of DPS), while the Particle Lance penetrates much more armour at long range.
The Particle Lance is intended as a powerful anti-ship weapon that requires a large investment in a particular tech line, lacks the flexibility of lasers or railguns and provides a different armour penetrating option to mesons, although mesons are still superior against shields. Mainly though it is to boost the Particle Beam as a serious weapon choice.
Meson Update
Mesons have the following changes for C# Aurora:
- Their cost is based on the same principles as a laser, so mesons will cost the same as an equivalent laser of the same tech level.
- Mesons penetrate shields as before but their ability to penetrate armour is now limited.
- A new tech line exists, Meson Armour Retardation, which is the chance for each layer of armour to stop the meson. This starts at 50%, then 40%, 32%, etc. finishing at 7% for TL 12
- If armour does stop the meson, it scores 1 point of damage on the armour.
- If the meson hits a damaged armour location, it only has to penetrate the remaining armour in that location.
- Mesons will destroy missiles without penalty, as missiles are no longer armoured in C# Aurora.
Gauss Cannon Research Changes
I’ve lowered the research point requirements for Gauss Cannon.
The Rate of Fire tech starts at 2 shots with the following progression in RP from 2 to 6 shots: 1500, 5000, 15,000, 45,000, 135,000. Eight shots is 450,00 RP.
The Launch Velocity still has six levels with the following progression in RP: 500, 1500, 5000, 15,000, 45,000, 135,000
Power Plant Changes
Power plants will no longer have linear power vs size. Additional power will be produced by larger reactors, using a similar formula to the increase in fuel efficiency for larger engines. This change will provide a reason to create larger power plants and will result in a small improvement in energy weapon capabilities. The table below shows power per HS and total power for a given size of reactor. This value is multiplied by the base technology of the power plant (Pressurised Water, Pebble Bed, etc).
The additional boost provided by the “Power Plant Boost” technology line provides double the previous bonus, with lower research costs and slightly higher explosion chances. This is intended for smaller ships that are short on space. The updated tech line provides between 10% and 100% additional boost with research costs between 500 RP and 30,000 RP.
Beam Weapon Recharge
In VB6, if a power plant is damaged, it slows down the recharge rate of all weapons by a proportionate amount.
In C# Aurora, power is allocated weapon by weapon until the available power is exhausted. This means that some weapons may not be recharged, but the others will be recharged at the maximum rate. Weapons are charged in order of ascending power requirement. Once a weapon is recharged, it will require no more power and other weapons can begin the recharge process.
This should allocate power in the most effective way to keep a ship in the fight.
Turret Update
A minor update. The benefits of multiple energy weapons in turrets have been doubled. A twin turret now has a 20% reduction in crew vs two solo weapons and has a 10% reduction in gear size. A quad turret has a 40% reduction in crew vs four solo weapons and has a 20% reduction in gear size.
In addition, I found an error in the VB6 code for turret design that meant a turret needed four times more armour than a ship of equivalent size. This has been corrected for C# Aurora, which means armoured turrets are now much more viable.
Armour Damage Templates
In VB6 Aurora, the damage templates for each weapon are held in a database table, with one row for each combination of weapon type and damage amount. While this is simple, it mean any new weapon or change to damage model has to be laboriously updated in the table.
For C#, the damage templates are generated in code as needed based on a ‘gradient’ system. All the damage starts at a single point and is distributed right and left according to the gradient setting. Any column which has damage greater than the gradient, checks left and right. If an adjacent column has a damage amount that is lower than the current column damage minus the gradient, a single point of damage is moved to that column. The adjacent column with lower damage is used first. The code cycles back and forth through the columns until no more adjustments are necessary
For example, missile damage has a ‘gradient’ of 1. Therefore, there cannot be a gap of 2 damage between adjacent columns. Laser damage has a gradient of 3, so any gap of 4 damage between columns is corrected. Here are some examples for 25 damage:
Gradient 1 (Missile, Carronade, Ramming): 1,2,3,4,5,4,3,2,1
Gradient 2 (Railgun, Particle Torpedo): 1,3,5,7,5,3,1
Gradient 3 (Laser): 3,6,8,5,3
Particle Lances cause damage in a single column, gauss cause only a single point of damage and meson ignore armour.
The template generation takes about a millisecond so there is no performance issue. This means that new weapons with higher gradients can be added very easily.
Weapon Failure
At the point when any weapon (energy-based or missile launcher) fires, there is a 1% chance the weapon will suffer a failure. If sufficient maintenance supplies are available, the weapon will be instantly repaired and will fire normally. If maintenance supplies are not available, the weapon will be damaged and unable to fire.
This is partially to simulate the stress of combat on weapon systems, but also as a balance to other rule changes.
Atmosphere and Energy Weapons
In C# Aurora, there is no penalty for energy weapons firing in or through an atmosphere.
Shock Damage Update
The recent debate on mesons highlighted some issues with Shock damage at higher levels. Therefore Shock Damage in C# Aurora will operate as follows:
- The chance of shock damage is equal to: Damage Caused to armour / Size of Ship in HS. For example a 9 point warhead vs a 6000 ton ship has a 7.5% chance of shock damage. A 16 point energy impact vs 10,000 ton ship has an 8% chance of shock damage.
- Any damage with less than a 5% chance is ignored as too small (i.e. any damage where the strength is less than 5% of the ship HS)
- If shock damage occurs, the shock damage is rolled randomly up to 20% of armour damage
Where the armour damage is easily divisible by 5, for example a 15 point warhead, there is a random roll from 1 to max shock damage (1-3 in this case). Where the armour damage is not divisible by 5, the max shock damage is the amount divisible by 5 (rounded) down plus a percentage chance of an extra 1 max shock damage equal to the percentage of 5 remaining. For example, a 12 point warhead would be assigned 2 max shock damage approximately 60% of the time and 3 max shock damage 40% of the time.
New Active Sensor Model
A new active sensor model has been implemented for C# Aurora. In VB6 Aurora, there is an issue that active sensor ranges become so huge with large size-50 sensors, that the standard tactic is to create a ship with such a sensor so that it can watch the entire inner system, taking away some of the fog of war. In addition, such extreme-range sensors allow ultra-long range missile combat, giving the race that possesses such sensors a major advantage. The following change is intended to create a situation where:
a) Multiple scouts or pickets become a serious alternative to one huge sensor.
b) Missile combat ranges are reduced
c) Fog of war is increased, leading to more interesting exploration and combat.
The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:
Sensor Range = Racial Sensor Strength * HS * Racial EM Sensitivity * SQRT(Resolution) * 10,000 km
The C# model uses similar basics and leaves all the existing technology in place. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors. In addition, the modifier for resolution has been adjusted from square root to the power of (1 / 1.5). Because of this formula, smaller, lower resolution sensors are now more effective than the VB6 equivalents (much more in some cases), making earlier detection of missiles and fighters possible for non-specialised ships. The new formula is:
Sensor Range = SQRT((Racial Sensor Strength * HS * Racial EM Sensitivity * (Resolution ^ (1/1.5)) / PI) * 1,000,000 km
The following screenshots are based on the Commonwealth in my current campaign, which has active sensor strength 21 and EM sensitivity 11.
New Passive Sensor Model
A new passive sensor model has been implemented for C# Aurora, using similar principles to the new active sensor model. In VB6 Aurora, small ship-based passive sensors are not particularly effective compared to active sensors in terms of detection, although their passive nature does allow a ship some sensor capability without giving away its position. Planet-based passive sensors (deep space tracking stations) are very effective as they can be stacked to cover the whole star system,
The C# Aurora passive sensor model substantially improves small passive sensors, particularly against small signatures, while dramatically reducing the benefits of creating large numbers of deep space tracking stations.
The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:
Detection Range = Passive Sensor Strength * Target Signature * 1000 km. For example, a strength-10 thermal sensor would detect a signature-500 target at 5m km (10 * 500 * 1000).
The C# model uses all the existing technology and tech values. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors.
Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km. The same example as above would result in the strength-10 thermal sensor detecting the signature-500 target at 17.7m km.
Because of the great improvement in the performance of small passive sensors, there will no longer be an inherent size-1 passive sensor on all ships. In addition, the smallest functional passive sensor on a missile will be 0.25 MSP.
The screenshot below demonstrates the difference between the two models.
Ship Thermal Signature
In VB6 Aurora, a ship always has its maximum thermal signature even when not moving. The fleet can be set to a lower speed if desired, which reduces the signature, but that isn’t directly related to movement. As it doesn’t seem realistic that a stationary ship and one moving at full speed should have the same thermal signature, C# Aurora will handle thermal signatures in the following way:
If a fleet has movement orders, each ship in that fleet has a thermal signature equal to: (current speed / max speed) * max thermal signature (the same as VB6). This applies regardless of whether the order involves a change in position, so a freighter in transit and one loading cargo are both ‘moving’.
A ship in a fleet without orders has a baseline thermal output equal to 5% of its size in hull spaces (or 0.1% of its size in tons). For example, a 10,000 ton ship without orders would have a thermal signature of 10 (200 HS x 5%). There is no distinction for commercial shipping on the basis that some commercial functions (mining, terraforming, harvesters) would generate heat and even freighters would have less thermal shielding than similar size warships. The minimum thermal signature for a ship with movement orders is also the base thermal output.
This has significant implications for scouting, as passive sensors will now only detect large stationary alien warships from a relatively short range.
Ground Forces Detection
In C#, as in VB6, ground forces are treated as size-1 for the purposes of detection, so are best detected with resolution-1 sensors.
For C#, the ground forces signature is equal to the total signature of all ground formation elements on a planet, divided by 100. The signature of each element is equal to (unit size * unit number) / (fortification level * dominant terrain fortification modifier).
In other words, well-fortified ground forces will have a smaller signature than those out in the open, so you won’t always know if you face a small force, or a well-fortified larger force.
Surface to Orbit Ground Forces Contact
STO elements that have not fired are detected with other ground forces as a ground forces contact.
When an STO element fires, any races that are currently detecting it as part of normal ground forces will flag it as an STO element. Thereafter, those races will detect that element as an ‘STO Ground Forces’ contact, which is a new contact type. All known STO elements on a planet are grouped as a single STO Ground Forces contact. Players can choose to target either the known STO elements or the normal ground forces (which may contain undetected STO elements).
An STO element may be known to some races and detected accordingly, while still being part of the normal ground forces contact for other races.
The active sensors of STO elements are detected by EM sensors in the same way as any other active sensor. However, this is not sufficient to flag the STO element.
Missile Launch Detection
In VB6, missiles are only detected after their first movement sub-pulse. This is due to the sequence of play of Movement → Detection → Combat. Consequently, a missile ship close enough to an opponent for its missile to cover the distance in less than five seconds can avoid point defence entirely, because there is no opportunity to detect the missile before impact.
In C#, an additional detection phase takes place after missile launch, which is restricted to the detection of newly launched missiles at the point of launch. This means that no matter how close the missile ship is to its opponent, the missile will be detected if the opponent has sensors capable of detecting it. The missile will still be in the same location as the launching ship when this detection phase takes place.
Alien Weapon Detection
As part of the tactical intelligence in C# Aurora, it will be possible to determine the weapons of alien ships under the right circumstances.
When a ship fires beam weapons, either in the combat phase or in the missile movement phase, each race which has a current active sensor contact for the firing ship will detect the type of weapon (Railgun, Laser, etc), the power of the weapon, the number of weapons fired and the weapon range (based on target location).
When a ship launches missiles, each race which can detect the new salvo at the point of launch will detect the number and size of the launchers on the firing ship (only those launchers that fire missiles will be detected).
If a ship fires or launches multiple times, the interval between firing for each weapon type will be tracked (this won’t be perfect because the alien ship may be firing different weapons at different times but will provide a reasonable idea). All the weapon intelligence gathered will be displayed for the Alien Class.
Detecting Engine Type
Thermal sensors are able to detect whether a ship moving faster than 1 km/s has military or commercial engines. This information is added to the intelligence for the associated alien class.
The thermal contact strength for a ship will be preceded by “M” or “C” if the engine type for the parent class is known.
NPRs will treat ships without detected military engines that have not demonstrated any weapon capability as 10% of the normal size when assessing their threat level
Transponders
In C# Aurora, transponders have three modes; Off, Friendly and All. A transponder set to Friendly will only be detected by Friendly or Allied Races. A transponder set to All will be visible to all races, even hostile ones.
Civilian Shipping will have transponders set to Friendly.
Ship Class Components View
The components view has been expanded considerably for C# Aurora.
The tab still has the functionality from VB6, showing the component breakdown by Amount, Size, Cost, Crew and HTK. To that has been added ordnance loadout, fuel and maintenance supplies, plus a breakdown of minerals and wealth. The mineral and wealth breakdown takes into account the mineral requirement and/or cost for the full loadout of fuel, maintenance and ordnance, so you can see the full cost of the design
Two new columns have been added which replace the damage allocation chart from VB6. Instead, this is the percentage chance that a component of the specified type will be selected for internal damage. E-DAC is for weapons that only target electronics.
Shield Generators
Shield generators have been overhauled for C# Aurora to make them more interesting.
- Shields no longer require fuel.
- Shield generators can be created from 1 HS to 50 HS in size.
- A new tech line has been added for maximum shield generator size. The starting tech is 10 HS and there are seven further steps from 12 to 50 with RP costs between 2000 RP and 120,000 RP.
- The strength of the generator is modified by its size using the formula SQRT(HS/10). This means a 10 HS generator will have standard strength, a 1 HS generator will have 32% of normal strength and 50 HS generator will have 224% of normal strength
- Recharge rates remain as before so a 10 HS shield will recharge at the same rate as an equivalent tech VB6 shield generator. Larger generators will recharge more slowly. For example, a 40 HS generator has 200% strength so will take twice as long to fully recharge.
- HTK is the square root of the size, so it is easier to take out a single 50 HS generator than five 10 HS generators.
- Cost of shields has been doubled
- The only mineral involved in building shields is Corbomite.
In general, this means that shields become stronger than before and larger ships have an advantage when using shield generators. However, they also cost more, require more investment in research and are easier to destroy.
Commercial Hangars
Commercial hangars are available in C# Aurora. They are 50% larger than military hangar bays (size 32), have the same cost of 100 BP and the same crew requirement (15).
They are intended for transport of other commercial vessels, temporary transport of military vessels, reloading of box launchers and for repairing ships. With this in mind, a military ship still has normal maintenance requirements while in a civilian hangar.
However, as you can maintain ships in deep space in C# Aurora it will be possible to build a large ship that could provide both commercial hangar space and maintenance, or combine ships with commercial hangars and ships with maintenance modules to provide a logistics hub.
Maintenance Storage Bays
In C# Aurora, Maintenance Storage Bays are no longer a military system.
Conventional Armour
The new ground combat rules provide the opportunity to simulate current ground forces, such as tanks, artillery, etc. However, the single conventional armour tech does not provide any granularity to show the different between different generations of armour. Therefore the current Conventional Armour tech is replaced by three new techs. I have also slightly reduced the capability of Duranium Armour and increased the research cost to create a more graduated progression and give conventional forces some chance against the first generation of TN vehicles.
High Density Duranium and above remain the same. Duranium Armour becomes available, regardless of current armour tech, once Trans-Newtonian Technology is researched.
Here are the first six armour techs as they now stand:
Fuel Storage Costs
I’ve realised that fuel storage is very expensive in Aurora compared to other ‘storage’ modules. In terms of cost per HS they are more expensive than hangars or magazines, three times as expensive as cryo, seven times as expensive as troop transport bays and sixty times more expensive than cargo bays. They are also about six times more expensive than most productive modules (Terraform, Salvage, Harvester, Jump Point Stabilisation, etc.). BTW I realised this by wondering why a tanker was taking so long to build. The reason was that because build time is based on cost but modified by size, high ‘cost density’ ships take a long time and that was greatly exacerbated by the fuel storage.
On that basis, I am reducing the cost of fuel storage considerably for C# Aurora, although it is staggered so the cost benefit of larger modules is improved.
Fuel Storage - Tiny: 5,000 litres, 0.5 BP
Fuel Storage - Small: 10,000 litres, 0.8 BP
Fuel Storage - Standard: 50,000 litres, 2 BP
Fuel Storage - Large: 250,000 litres, 5 BP
Fuel Storage - Very Large: 1,000,000 litres, 10 BP
Fuel Storage - Ultra Large: 5,000,000 litres, 25 BP
Maintenance Storage Bays
VB6 has the Maintenance Storage Bay, which is 5 HS and carries 1000 MSP.
In C#, the new 1% weapon failure rate means that the ship design process will have to account for that additional MSP expenditure when considering engineering systems. This includes small craft such as fighters which may mount a single energy weapon or multiple box launchers. The issue for fighters is that adding sufficient engineering to cover that potential MSP cost may give them maintenance lives of many years, which is unnecessary and not very realistic.
Therefore, C# adds several new maintenance storage options. These create a reserve of maintenance supplies that can be used to repair weapons but do not affect failure rates or maintenance life. I’ve also doubled the storage capacity because the MSP capacity of normal engineering was not significantly lower in many cases.
Maintenance Storage Bays in C#
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.
Prototype Components
When designing components in the Create Research Project window or the Turret window, you have the option of the Prototype button instead of the Create button. Prototype components are researched instantly and are available in the class design window, where they will appear with a (P) suffix. There is a display toggle on the class design window for prototype components.
Prototypes can be obsoleted to remove from the display. In this case, they will only appear if both the obsolete and prototype options are checked.
On the turret window, prototype energy weapons will be displayed with a (P) suffix. Any turret containing a prototype energy weapon can only be a prototype. The Create button will be unavailable.
If a class contains a prototype component, it will be displayed with a (P) suffix on the class tree and in the class summary on the Class Design window. A shipyard cannot be retooled for a class that contains prototype components.
Prototypes will allow you to try out different class designs without having to research all the potential components.
Future Tech for Prototypes
The Create Project now has a Show Next Tech checkbox. When this box is checked, you will see the the next tech that can be researched in the design options. For example, if you have researched 12cm and Visible Light for lasers, then checking the box will add 15cm and Near Ultraviolet to the design options.
When using the Next Tech option, only Prototype Components can be created.
Prototype Components created when the Show Next option is active will be classed as Future Prototypes and will have an (FP) suffix.
Researching Prototypes
If you select a prototype component on the Class Design window that can be created with current technology (i.e. not a future prototype), you will see a ‘Research Proto’ button appear. Clicking this turns the prototype into a Research Prototype. Research Prototypes have an (RP) suffix on the class window.
Research Prototypes will appear in the Research tab of the Economics window in their appropriate Research Field. They can now be researched like any other component, except they are still available in class design as a prototype until the research is complete. At that point, the prototype flag will disappear. If that was the last prototype in a class, that class can thereafter be tooled in a shipyard.
The combination of this and previous posts means that any component can in one of four states. A ‘normal’ component (no suffix), a ‘current’ prototype (P), a future prototype (FP) and a research prototype (RP).
The various prototype changes mean you can build a prototype class design using prototype components and then research all those components, making the class available for use.
Missile Launcher Changes
Missile Launchers have undergone significant changes in C# Aurora.
-
Fractional-size launchers can be created. The minimum is still 1 HS but a launcher can now be 1.1 HS, 2.7 HS, etc.
-
The reduced-size launcher techs are all available immediately and do not need to be researched. This means box launchers are available from the start. The progression for reduced size launchers has been altered slightly:
0.75 HS 2x Reload
0.6 HS 5x Reload
0.4 HS 20x Reload
0.3 HS 100x Reload
0.15 HS 100x Reload (Box Launcher) - note that reload for this was x15 in VB6.
If a box launcher containing a missile is damaged, the missile will explode. The chance of this happening can be reduced by a new tech line. The first step reduces the explosion chance to 70% for 1000 RP and the last step reduces to 5% for 120,000 RP. In addition, Box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).
The base reload rate for all missile launchers is now: (SQRT(missile size) * 30 seconds * Reduced Size Modifier) / Reload Rate Tech.
Assuming a race has reload rate tech of 3, a normal size 1 launcher will reload in 10 seconds, a size 4 will reload in 20 seconds and a size 9 will reload in 30 seconds. This change will dramatically reduce reload times for larger launchers.
The change for box launcher reload rate from x15 to x100 is not as dramatic as it seems for larger missiles due to the new reduced reload times for larger missiles. However, it is still an significant increase from VB6. A size 4 missile mounted on a box launcher will now take about 1h 40m to reload in a hangar and about 17 hours for an ordnance transfer point. A size 6 is about 2 hours and 20 hours respectively.
These changes are intended to:
- Reduce the disadvantage of larger missiles,
- Remove the realism issue of not having box launchers available at low tech yet make box launchers a more difficult decision vs standard-type launchers.
Missile Updates
The following changes will be made to missiles in C# Aurora:
-
Missile Armour has been removed.
-
Laser warheads have been removed (I may add these back at some point in the future).
-
ECM is now a fixed 0.25 MSP for missiles. The ‘Missile ECM’ tech line has been removed and if a missile is equipped with ECM it will have the same ECM capability as the current racial ECM technology, The missile design will maintain that ECM capability and will not be upgraded if the racial tech improves. For each level of ECM, the missile will be 10% harder to hit with energy weapons and will reduce the lock of missile fire controls by 10%. This can be negated by linking a similar level of ECCM to the point defence fire controls.
-
Missiles can be equipped with ECCM, which is a fixed 0.25 MSP. The missile ECCM level will be equal to the current racial ECCM tech. In C# Aurora, the ECCM of missile fire controls will only affect the range at which the fire control can lock on. The ECCM of the missile itself will affect the chance of the missile striking its target, if that target has active ECM.
-
Any missile sensor (active, thermal, EM or Geo) has to be a minimum of 0.25 MSP or it will have no effect.
-
Missile series have been removed. Instead, there will be more detailed class loadout options.
These changes will make electronic warfare much more important for missile combat. Missiles with ECM will become harder to shoot down and missiles without ECCM will have a reduced chance to hit targets equipped with ECM. Anti-missile missiles will either be less effective, or larger, vs ECM-protected missiles, while anti-ship missiles are likely to increase in size (and therefore reduce salvo sizes). Large volleys of size-1 missiles will be less effective in a heavy EW environment and no longer have a huge advantage in launching speed (due to the missile launcher changes).
Missile Engines
In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula: SQRT (10 / Engine Size in HS)
The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still consistent with ship engines.
Therefore, the calculation for fuel consumption based on boosting engines will now include an additional multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:
if Boost Used > Max Boost Multiplier Tech then
High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;
So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.
Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.
Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:
Missile Engines Integrated into Missile Design
In VB6, you research missile engines first and then use that engine within a missile design. This can be tedious, especially if you are not sure exactly what engine size you need. Therefore, for C# the missile engine design has been removed from the Create Research Project window and integrated directly into the Missile Design window.
The best engine and fuel efficiency tech will automatically be used, so the player decides on the engine size and power boost. The engine design takes place behind the scenes and is confirmed when you design the missile. This means you can play around with the engine design and missile design at the same time. See first screenshot below.
If no engine is required, just tick the No Engine option. See second screenshot.
Missile Thermal Detection
In VB6 Aurora, the thermal detection of missiles is based on the following formula:
(Missile Size / 20) * (Speed / 1000)
I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed like a good idea at the time For C# Aurora, missiles will use the same formula as ships for thermal signature:
Max Engine Output * (Current Speed / Max Speed) * Thermal Reduction
As missiles (for now anyway), don’t have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora.
Commercial Magazines
I’ve added a non-military magazine to C# Aurora. There are two versions; one with 100 capacity and one with 500 capacity.
In general terms they are cheaper but less efficient in terms of space then military magazines. Also, they have a 100% explosion chance if hit, so don’t apply for a job on a commercial ammunition transport
Commercial Magazine - Capacity 100, Size 12, Cost 25, Crew 5, HTK 1, RP 2000
Commercial Magazine - Capacity 500, Size 50, Cost 100, Crew 20, HTK 1, RP 5000
Even if you armour the ship, one of the magazines could still explode due to shock damage. As the magazines are fairly large, if they are hit then the ship is probably gone, so it would be a Bad Idea to take a commercial ammunition transport along with the battle fleet.
Box Launcher Reloading
In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities. For C# Aurora, box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).
Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers if they could still use those facilities to reload, especially given they are immediately available in C#. The introduction of ordnance-specific facilities for C# provides a good alternative.
The existing changes post for Missile Launchers has been updated to take account of this new rule:
Magazine Design
There are several changes to magazine design for C# Aurora.
-
The ‘ejection’ tech line has been replaced by the Magazine Neutralisation System. It is functionally identical but in technobabble terms this is a system design to render missile warheads permanently inert in the event of damage to the magazine.
-
Magazines have a base HTK number equal to the square root of their size (rounded down). in VB6 Aurora, all magazines have a base HTK of 1, regardless of size. It is still possible to add extra HTK in C# by sacrificing internal space.
-
The explosion chance for a magazine is divided by the square root of its size. For example, if a size 1 magazine has a base explosion chance of 15%, the equivalent tech size 5 has an explosion chance of 6.71%, the size 10 is 4.74% and the size 20 is 3.35%.
-
If the ship has a Chief Engineer, any explosion chance (for magazines or engines) is reduced by his Engineering Bonus. So a 5% explosion chance would be reduced to 3.5% by a Chief Engineer with an Engineering bonus of 30%.
-
When a magazine is hit, a proportion of the remaining ordnance will be destroyed (based on destroyed magazine capacity / total ship magazine capacity). Any destroyed ordnance will explode with its full warhead strength. In VB6, only ordnance beyond the remaining magazine capacity explodes and only at 20% strength.
In summary, magazine explosions in C# Aurora will be much rarer, especially for larger ships, but far more devastating when they do occur.
Ship Ordnance Templates
In VB6, you can set an ordnance template for each class. When a ship loads ordnance it will load ordnance based on that parent class template.
For C#, you can create optional ship ordnance templates. If a template is created at the individual ship level, it will override the parent class template when the ship loads ordnance. If there is no template at the ship level, the parent class template will be used.
A new tab on the Ship section of the Naval Organization window shows the class and ship ordnance templates for each ship, plus the current actual loadout for the ship. This tab can be used to change the ship ordnance template in a similar way to setting the class ordnance template on the Class window. You can copy the existing class ordnance template into the ship template if you only want to make minor changes. You can rename and obsolete missiles from this tab.
The screenshot shows a recon-focused ship ordnance template.
Tracking Time Bonus vs Missiles
Energy weapons and beam fire controls engaging missiles can gain a bonus to their tracking speed based on how long the missile has been on active sensors. Similar functionality was added to VB6 but is not working. The benefit of this has been toned down a little from the planned functionality in VB6 as fuel considerations in C# will reduce the max boost used for anti-ship missiles and avoid the late game missile speed vs tracking speed disparity.
The gain in tracking speed is equal to one percent for every five seconds a missile is continually tracked by active sensors. This is subject to a maximum time based on the associated tracking time tech. The starting tech costs 1000 RP and adds tracking bonus for the first 30 seconds. The tech name format is: Max Tracking Time for Bonus vs Missiles: 30 Seconds (6%)
This time increases with subsequent tech to 45, 60, 80, 120, 160, 200, 250, 320 and 400. Each tech is approximately double the cost of the previous one.
Note this is a bonus to tracking speed, not the base to-hit chance. If the tracking speed is already higher than the missile speed, this bonus will not improve the chance to hit.
I considered adding this to all energy-weapon fire for consistency, but decided it was reasonable to keep it to missiles only, given their more predictable courses.
Launch Ready Ordnance
You can use the Launch Ready Ordnance order at any movement destination, including a waypoint. Any ordnance assigned to a missile launcher that is assigned to a fire control will be launched at that point. The fire control does not need to be set to ‘fire’. The missile will be launched without an assigned target.
This is useful for deploying buoys or mines or just launching missiles without a known target.
Deployment, Overcrowding, Under-manning and Life Support Failures
In VB6 Aurora, this is a very complex area (see link below), particularly with regard to fighters and other parasite warships.
http://aurora2.pentarch.org/index.php?topic=4835.msg49116#msg49116
For C# I am trying to keep all the flavour of this area while simplifying the mechanics in general and adding a couple of additional mechanics that never made it into VB6. Each construction phase, every ship is checked according to the following rules:
Deployment Clock
-
Any military ship, or one equipped with geological survey sensors, has a deployment clock, similar to their maintenance clock, which is displayed on the fleet window in months
-
For ships outside hangar bays, the clock normally advances at a rate equal to the passage of time when the ship is anywhere except at a recreational location
-
A recreational location is any ship with a recreational module or any population of at least 50,000 people.
-
When any ship (including those in hangars) is at a recreational location, the deployment clock reduces at a rate equal to ten times the passage of time.
-
If a parasite is in a hangar bay but the mothership is not at a recreational location, the deployment clock of the parasite reduces at a rate equal to the following formula:
Time Passed * 10 * (1 - Mothership Deployment Modifier)); -
The Mothership Deployment Modifier is equal to the Mothership Deployment Clock / Mothership Class Intended Deployment Time. In effect, the more time on the mothership deployment clock, the slower any docked parasites reduce their own clocks
-
If the Mothership Deployment Modifier is equal to or greater than 1, any parasite in the hangar cannot reduce its own deployment clock, although the time on the parasite clock will not grow either. This means that every time the parasite is deployed, its clock will continue to increase without the chance to reduce between missions.
-
A ship’s morale is always 100% unless the ship’s deployment clock exceeds the intended deployment time of its class (or for other reasons in subsequent sections). In that case, morale is equal to the intended deployment time / deployment clock. For example, a ship with a deployment clock for 15 months and an intended deployment time of 12 months would have a morale of 80%.
-
If the crew on the ship is less than half the required crew complement, morale is multiplied by (Current Crew / Class Crew) x 2;
-
Morale can never fall below 25% as a result of the above rules.
Overcrowding
-
Each construction phase, the total personnel on each ship is compared to the available accommodation (after accounting for damage). Personnel in this case equals the crew, any rescued survivors beyond the capacity of any cryogenic modules and the capacity of the flight crew berths (I may add a rule tracking whether the hangar is in use when checking the flight crew berths).
-
If the required accommodation is greater than the available accommodation, the ship is overcrowded.
-
In this case, an Overcrowding Modifier is calculated equal to: (Required Accommodation / Actual Accommodation) ^ 2.
-
The ship’s deployment clock will increase at a rate equal to the time passed multiplying by the Overcrowding Modifier. For example, if the ship is 25% overcrowded, the deployment clock will increase at 1.5625x the normal rate (1.25 x 1.25).
-
If the overcrowding modifier is greater than 1.5, life support may begin to suffer damage.
-
The percentage chance of failure in any construction phase is equal to Overcrowding Modifier * 100 * (Increment Length / Year Length). That translates to a 3.1% chance per construction phase if the ship is 50% overcrowded, an 8.6% chance at 150% overcrowded and a 34.2% chance at 400%.
-
If failure occurs, a crew quarters system will potentially be damaged. This can be prevented in the normal way by maintenance supplies. If no maintenance supplies are available, the crew quarters will be destroyed.
-
Destruction of crew quarters will reduce available accommodation and increase the overcrowding problem. Eventually, if all crew quarters are destroyed, this will lead to complete life support failure.
-
Overcrowding is not checked on parasites in hangars, as it is assumed the flight crew berths and life support on the mothership will help with this situation. To avoid potential exploits of this simplification, any survivors on a parasite that docks with a mothership will be transferred to the mothership, unless they can be held in cryogenic modules on the parasite.
Life Support Failure
If a ship has no life support systems (due to combat damage or maintenance failures), it suffers the following penalties:
-
For any military ship or one equipped with geological survey sensors, the deployment clock increases at 12x the normal rate and morale is immediately reduced to 10%.
-
The crew takes casualties from 4% to 80% (4D20) of the remaining crew in each construction phase
-
Any survivors on board take casualties of up to 80% of the remaining survivors in each construction phase
-
Each commander on board the ship has a chance of dying equal to half the crew casualty percentage in step 2.
Life support failure is not checked for parasites in hangars, as it is assumed the flight crew berths and life support on the mothership will help with this situation.
If help is not close by, it may be better for the crew in these circumstances to abandon the ship and hope for rescue. This rule may also be a reason for a more common use of lifeboats.
Summary
This is still a long rule section but I hope it is more straightforward than in VB6 and will provide the background for building the support network required for distant deployments, plus the capacity to handle rescued crew members or prisoners of war.
Planetary Terrain
As part of the ground combat changes, each planet will have a dominant terrain type. In many cases, for most asteroids, comets or small moons, that type will simply be Barren. Within certain environmental tolerances, other terrain types are possible.
Any system body with temperature lower than -100C or higher than 200C or with no atmosphere or atmosphere greater than 10 atm will be Barren, unless it has platelet or extreme tectonics, in which case it will be Mountain.
All other system bodies will check the following table to determine which terrain types are eligible based on the environmental conditions. One of the eligible terrain types will be selected randomly. Barren, Mountain and Rift Valley (which are base types available without any atmospheric, temperature or water requirements) will only be selected if no other terrain types are eligible. The tectonic numbers are internal to Aurora and have the following values: Dead = 1, Hot Spot = 2, Plastic = 3, Plate Tectonics = 4, Platelet Tectonic = 5, Extreme = 6.
Terraforming will change the terrain under two circumstances:
- A planet with a base type (Barren, Mountain and Rift Valley) becomes eligible for another terrain of a similar type. Mountain can move to any other Mountain type, Rift Valley to any other Rift Valley Type and Barren to any non-Mountain, non-Rift Valley type.
- The terrain type is no longer possible with the current environmental conditions. A new terrain type is generated with the same base type.
I am happy to add additional types or modify the environmental parameters if there is general consensus on any changes.
The fortification modifier is a modifier for the max fortification level, rather than an automatic defence increase. It means you can dig in much deeper (given sufficient time) in Mountains than you can in Steppe or Swamp. The to hit modifier is a reduction in the chance to hit in that terrain (for other ground units and any supporting ships in orbit). In effect, fortification is a benefit to the defender, while to hit is a penalty to both sides. Within the new ground combat rules, you can assign ground units ‘capabilities’, such as Jungle Warfare, Mountain Warfare, etc. which will double their chance to hit in those types of terrain. Ground units of species with certain types of home world may gain capabilities for free (if you are from a desert planet, you would gain Desert Warfare for free, for example). There are additional capability options to avoid penalties for ground units fighting on worlds that are outside their species tolerance for gravity, temperature and pressure.
An important factor to bear in mind is that when ships are engaging ground units with surface-to-orbit capability, the main defence of the ground unit will be its fortification level. The ship-based weapons are assumed to hit 100% of the time divided by the fortification level. On a planet with Steppe as the dominant terrain type, the maximum fortification of a static ground unit will be 6 with no penalty for the ship to hit. On a Jungle Mountain world, the maximum fortification level will be 18 for that same ground unit and any shots against it by the ships will be modified by 0.125, giving the ground unit an effective fortification level of 144. In other words, the ship in orbit is going to hit once every 144 shots. So trying to use orbital bombardment against surface to orbit units buried in jungle-covered mountains is going to be a Bad Idea. It would be far more effective to send in ground forces (which can’t be hit by STO units) to dig them out. That is an extreme example, but there should be many more situations where there are some serious decisions for the attacker.
Sol System Changes
- Salacia and 2007 OR10 upgraded to dwarf planet status. They are large enough and I am sure this will be confirmed at some point.
- Added 2017 MB7. Asteroid/Comet with furthest known orbit.
- C/2017 K2: Non-periodic comet
- Oumuamua: Interstellar object but treated as extreme distance comet heading outwards
- 2017 UV43: Centaur.
- 2015 RR245: 700 km diameter Trans-Neptunian object (TNO)
- 2015 KH162: 700 km diameter TNO
- Added Ultima Thule. 30 km diameter TNO
Known Stars Changes
Added the following stars:
Renamed several stars:
Player Race Banned Bodies
Player Races can ban bodies in the same way as an NPR. Unlike an NPR, the player can select which bodies are banned. This is done via a toggle on the system view. There is an option to ban / un-ban all moons of a planet at once.
Civilians will not create mining colonies on banned bodies and survey ships with standing orders will not attempt to conduct geological surveys on those bodies. It is still possible that player ship will approach due to other considerations, such as moving between two points unrelated to banned bodies. Note this is different to a military restriction, which applies only to the interaction of civilian shipping lines with existing populations.
This player banned bodies function is mainly for role-playing purposes as NPRs react to a player presence in a system, rather than in proximity to a specific body, although it could also be used to prevent the creation of civilian mining colonies.
Ground Forces: Part 1 - Unit Design
Ground Forces and Ground Combat are undergoing a huge expansion in C#. The VB6 Ground Unit becomes the Formation and the VB6 Ground Unit Type becomes the Formation Template. However, there are no longer any fixed unit types or unit values. Instead, there is endless scope for Formations and Formation Templates, based on a detailed design process at the Formation level and below. This will allow the simulation of ground forces from many science fiction genres. As this is a long topic, I am going to break it into several posts each covering a different topic.
The most granular level is the Ground Unit Class, which is an individual soldier or vehicle. One or more of the same Ground Unit Class are grouped into Formation Elements, which in turn are grouped into Formations. Formations remain intact for movement purposes, but combat involves each individual unit (each soldier or vehicle). As individual units are now tracked for casualty purposes, readiness no longer exists. Morale is tracked at the Formation Element level (which is a group of the same unit class), so the infantry in a Formation may have a different morale than the anti-tank guns or artillery.
The process of design starts with the Ground Unit Class. Two important factors in this design process are the Racial Armour Strength and Racial Weapon Strength, shown at the top of the Ground Forces window.
Racial Armour Strength is based on the strength of the highest racial armour technology. Conventional Armour is 3, Duranium Armour is 5, et cetera. For this screenshot, the Commonwealth has researched Ceramic Composite, which has a strength of 10.
Racial Weapon Strength is based on the highest tech level (TL) among Laser Focal Size, Railgun Type, Meson Focal Size, Particle Beam Strength and Carronade Calibre. For example, 15cm Laser Focal Size is TL3 as it is the third tech of that type. Racial Weapon Strength is the value of armour at the same tech level. In this case, the Commonwealth has researched 20cm Laser Focal Size, which is TL4. The fourth Armour Tech is Ceramic Composite, which has a strength of 10, so the Racial Weapon Strength is 10. The reason for using Armour as the basis of Weapon Strength is partly because that means Ground Armour and Ground Weaponry are aligned, and partly because it is straightforward way to assign value based on very different weapons.
The Ground Unit Design tab of the new ground Forces window is shown below. First, a ‘base type’ is chosen, which is infantry, several sizes of vehicle, or static. Static in this sense is a weapon that is not self-mobile, such as a towed anti-tank gun, towed artillery, et cetera. Static weapons remain in place when firing so they are easier to hit than infantry or vehicles. Each base type has six main characteristics:
- Size (in tons): Size is the basis for transport requirements and cost, although there are other modifiers to cost (discussed below)
- Hit Points: Unit hit points are compared to weapon damage during combat to determine the chance of destruction (the Damage Check). The chance of a weapon destroying a unit is (Weapon Damage / Hit Points) ^ 2.
- Slots: The number of component slots available for the base type
- To-Hit Modifier: Used to modify the chance of the unit being hit during combat (based on the mobility of the unit). This only applies if the unit is not fortified.
- Maximum Fortification: The maximum strength to which the unit can be fortified by construction factories or construction units. The Chance to Hit for a firing unit is divided by the Fortification Level of the target unit.
- Maximum Self-Fortification: The maximum strength to which the unit can be fortified without construction factories or construction units.
The next section is Armour Type. The Armour of a unit is compared to the Armour-Penetration (AP) value of a weapon. The chance to penetrate is equal to (AP / Armour) ^2. For example, a weapon with AP 4 attacking a unit with Armour 6 has a 45% chance to penetrate. The overall process for checking if a shot destroys a target is Chance To-Hit, followed by Armour Penetration Check, followed by Damage Check. All three must be successful to destroy the target. Each type of Armour has two values.
- Base AR: The Base Armour Rating is multiplied by Unit Size (including components below) to determine cost. So a unit with 6 armour would be 50% more expensive than the same unit with 4 armour.
- Racial AR: Racial Armour Rating is the Base Armour Rating multiplied by the Racial Armour Strength (shown at top of window).
Below the base type and armour is a large section showing Components. Infantry, static and light vehicles all have one ‘component slot’, vehicles and heavy vehicles have two slots, while super-heavy and ultra-heavy vehicles have three and four slots respectively. Each slot can hold one component from the list and the same component can be put into multiple slots. Certain components are only available with certain base types. For example, the Super-Heavy Anti-Vehicle component can only be used by super-heavy and ultra-heavy vehicles. The primary component is selected from the main table, while any additional components are selected from the dropdown(s) below the main table. Each component has a name and an abbreviation and is rated in nine different areas:
- Size: The size in tons is added to the size of the base unit type.
- Armour-Penetration (AP): If the component is a weapon, the chance to penetrate a target’s armour is (AP / Armour) ^2. The AP Rating is the underlying AP of the component (not shown), multiplied by the Racial Weapon Strength.
- Damage: If the component is a weapon, the chance to destroy a target after the armour has been penetrated is (Weapon Damage / Hit Points) ^2. The damage value is the underlying damage rating of the component (not shown), multiplied by the Racial Weapon Strength.
- Shots: The number of times a weapon will fire during each ground combat phase
- CIWS: ‘Y’ indicates this component is a Close-in-Weapon-System, capable of defending the planet (on which the unit is based) from missile attack. This CIWS will use the values in the CIWS section, which will become visible when a CIWS component is selected. More on this in a later rules post.
- STO: ‘Y’ indicates this component is a Surface-To-Orbit energy weapon, capable of engaging ships in space within weapon range of the planet on which the unit is based. The weapon type used for the STO component can be selected in the section to the centre right, which will become visible when an STO component is selected. More on this in a later rules post, although see the second screenshot.
- HQ: The headquarters capacity of the component in tons. This is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. To assign a commander to a formation, one of the units within that formation requires a headquarters component. More details on command hierarchies will be provided in a future rules post.
- FFD: ‘Y’ indicates this component is a Forward Fire Direction (FFD) component. Forward Fire Direction allows a front-line unit (more on that later) to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit. A later rules post will explain this function.
- Const. The construction value of the component in Construction Factory Equivalents (CFEs).
At the top-right of the window is the Capability section. One or more Capabilities can be selected for the Unit Class. The Boarding Combat capability is required for a Unit to be able to board another ship. For all other capabilities, the Chance to Hit is doubled in the environment specified. If a unit has multiple capabilities, such as Mountain Warfare and Jungle Warfare on a world with a dominant terrain of ‘Jungle Mountain’, the bonus is cumulative (i.e. 4x to-hit in this case). Each capability selected for a Unit will increase the cost by the multiple specified. Some capabilities are only available for infantry units.
In the bottom right section, a summary of the unit is shown in a similar style to the Class Summary for naval designs. When the sizes of all the units in a formation are aggregated, that is the transport requirement for that formation in tons. Cost is in BP. When the costs of all the units in a formation are aggregated, that is the build point requirement to construct the formation. Armour and Hit Points have been described previously. Below that is a list of components, followed by the materials required for construction and the research cost to develop the unit once designed.
This screenshot shows a static unit with an STO component selected. The chosen weapon (which is any non-turreted weapon developed for shipboard use) is selected on the right. Spinal Weapons can be selected for ground use without penalty. The STO mount includes the weapon, a reactor of the exact size needed for the recharge rate, an active sensor with range greater than the weapon range and a built-in beam fire control with a 4x range modifier. The cost is equal to the static platform, the weapon, the reactor, the active sensor and half the fire control. STO weapons have a 25% bonus to fire control range. The damage shows two numbers, which is the damage at minimum and maximum range.
Ground Forces: Part 2 - Formation Templates
The screenshot below shows the Formation Templates tab of the Ground Forces window. Formation Templates are the equivalent of VB6 Ground Unit Types, although it might be easier to think of them as serving the same function as Ship Classes. They are a detailed design that serves as a template for building Formations based on that same design, which is the same relationship as Ship Classes to Ships.
This tab is split into two halves. On the left is a list of available Ground Unit Classes created using the Unit Class Design tab (as explained in the previous rules post). All of these were created using TL4 technology, with three exceptions. For comparison purposes, the Challenger 2 Main Battle Tank and the Warrior AFV were created using Conventional, rather than Trans-Newtonian, technology, while the Challenger – Base TN Upgrade was the Challenger design with TL1 technology. It should be possible to simulate most modern army units with the new C# Aurora ground combat, so you could theoretically be landing on an alien world with Abrams and Bradleys or T-14 and T-15 Armatas. The ten columns for the Unit Class List are as follows:
- Type: An abbreviation for the Base Type (infantry, Vehicle, Heavy Vehicle, etc.)
- Name: The name assigned during Unit Class Design. This can be changed using the Rename Unit button.
- Size: Transport size in tons.
- Cost: Cost in Build Points.
- Arm: The Armour Strength of the Unit. This is based on the armour available at the time of design and is not upgraded when newer technology becomes available (as with ship designs).
- HP: The Hit Points of the Unit. This is set at design time and does not change.
- Components A to D: Abbreviations for each of the components included in the Unit Class. These are the same abbreviations as used on the Components table in the Unit Class Design tab. As with armour and hit points, any components use the technology available at the time of unit design. To see the detailed view of the components, click on the Unit. The Unit Summary will be shown in the bottom section on the left hand side.
As an example, the Leman Russ Battle Tank is a Heavy Vehicle of 104 tons, with 60 Armour and 60 Hit points, costing 12.48 BP. The components are Heavy Anti-Vehicle (HAV) and Heavy Crew-Served Anti-Personnel (HCAP). Looking at the summary, the HAV has 1 shot per combat phase with Penetration 60 and Damage 60, while the HCAP has 6 shots with Penetration 20 and Damage 10.
The right-hand half of the tab shows Formation Templates. A new Formation Template is created by clicking the New button. In this case, four have already been created. Each Template comprises one or more Template Elements, shown in the bottom right section Each Template Element has a specific number of specific Ground Unit Class. For example, the Guard Armoured Regiment is currently selected, which has four template elements: 60x Leman Russ Battle Tank, 1x Macharius Command Tank, 12x Hydra Flak Tank and 24x Hellhound Anti-Infantry Tank.
Each template element has the following attributes:
- Name: The Unit Class for this element.
- Units: The number of units of that Unit Class in this element
- Size: The total size on tons of this element. For example, 60 Leman Russ Battle Tanks at 104 tons each is 6,240 tons.
- Cost: The total cost in Build Points for this element.
- HP: The total aggregate hit points for the element.
- HQ: The headquarters capacity of the element’s Unit Class in tons. If there are multiple units in a template element, only one is considered for the headquarters capacity. Any additional units are for redundancy. The headquarters capacity is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. In the case of the Macharius Command Tank, it has an HQ capacity of 10,000 tons.
- FFD: The total number of Forward Fire Direction (FFD) components in the template element. Forward Fire Direction allows a front-line unit to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit.
- Const. The construction value of the element in Construction Factory Equivalents (CFEs).
- CIWS: The number of Close-in-Weapon-System components in the template element, capable of defending the planet (on which the unit is based) from missile attack.
- STO: The number of Surface-To-Orbit energy weapon components in the template element. STOs are capable of engaging ships in space within weapon range of the planet on which the unit is based.
The totals for each Template Element are added together to create the total for the Formation Template as a whole, shown in the top right section. In the example shown, the Guard Armoured Regiment has a total size of 8,942 tons, which is the combination of all four template elements. The Formation Template list has an additional column for Rank. A default rank will be suggested by the program, although this can be overridden by the player. This rank will be used by Automated Assignment process for any Formations built using this Formation Template.
To add new Template Elements to a Formation Template, use the Add Units button in conjunction with the adjacent text field to specify the number of units in the new element. This number can be subsequently edited by selecting the element and clicking the Edit Amount button. Both Formation Templates and Element Templates can be deleted using the appropriate buttons.
This screenshot shows the Macharius Command Tank on the left and the Brigade Headquarters formation template on the right. The Macharius is a super-heavy vehicle, with two super-heavy anti-vehicle weapons and an HQ4 component, which provides a headquarters capacity of 10,000 tons. This is a large and expensive vehicle at 518 tons and 93.24 BP, but is well-protected as the loss of the HQ in a formation will result in the loss of any commander bonuses (and maybe the commander himself).
The Brigade Headquarters formation template includes two Guard Brigade Headquarters units, in case one is destroyed, plus thirty-six large artillery pieces, twelve flak tanks and a company of Guardsman. Combat involves three locations. Front-Line, Support or Rear-Echelon. Units in a Support position can only attack using bombardment weapons, or defend themselves against air attack. This formation is intended to serve in the Support location and is organising accordingly. However, it is possible for a Support Formation to temporarily find itself moved into a Front-Line position, so the Guardsman Element will provide additional protection in that case.
Ground Force Logistics
Ground Units have two separate logistics requirements. The first is Maintenance, which applies to all units at all times and has a wealth cost equal to 12.5% of Ground Unit cost per annum. The second is Ground Supply Points (GSP), which applies only to combat units during ground combat.
The GSP requirement for a weapon component is equal to Penetration Value * Damage Value * Shots. For example, Personal Weapons is (1 x 1 x 1) = 1. Crew Served Anti-personnel is (1 x 1 x 6) = 6. Medium Anti-Vehicle is (4 x 6 x 1) = 24. Heavy Bombardment is (2 x 6 x 3) = 36.
The GSP requirement for a Ground Unit Class is the sum of its weapon components. For example, a tank with a Medium Anti-Vehicle component and a Crew Served Anti-personnel component would have a GSP requirement of 30. The GSP requirement for a Formation Element is the GSP for the Ground Unit Class in the element multiplied by the number of units. The GSP requirement for a Formation is the sum of the GSP for its constituent Formation Elements. In all these cases, that is the GSP cost to provide sufficient supply for ten combat rounds.
Two new ground unit components have been added; the Logistics Module, which is Size 50 and provides 500 GSP, and the Logistics Module - Small, which is Size 10 and provides 100 GSP. The standard module is available for light vehicle and infantry base types, while the small module is only available to infantry. Here is an example of a light vehicle with the Logistics Module.
Ground units with either logistics module can be added to any level of the ground force hierarchy, either embedded with the front line combat formations or held at a superior formation, such as a headquarters.
Each Ground Unit has sufficient inherent supply points to fight ten rounds of combat (currently one round takes place every eight hours). After that point, only one quarter of units in a formation element that is out of supply will fire in each round. In addition, a formation with out of supply elements cannot use a field position of ‘Front Line Attack’ (more on this when I publish the full ground combat rules). However, if units with logistics modules are available, ground units can draw supply to both fight the current combat round and replenish supplies used in previous combat rounds.
Ground Units will attempt to draw supply from the formation that sits highest in their hierarchy and is at the same population. If no supply is available, they will move down the hierarchy to their own parent formation, checking at each stage. However, when drawing supply from outside their own formation, units can only draw on logistic modules mounted on light vehicles. Logistics modules with an infantry base type can only supply their own formation.
For example, a formation element of 10 tanks engaged in combat is part of an armoured formation with a brigade HQ formation above it and a division HQ formation above that. The tanks will check for a vehicle-based logistics element within the division formation first, then a vehicle-based logistics element within the brigade formation and finally either type of logistic element within their own parent formation. If no logistic elements are available, the tanks will use their inherent supply, although they can only use that inherent supply for ten combat rounds, unless resupplied. If a unit does not require a full resupply (for example, it still has sufficient inherent supply for eight combat rounds), it will only draw an appropriate fraction of its normal GSP requirement (in this case 20%).
When a formation element of logistics units provides supply, a number of units will be consumed based on the supply required. For example, assume the 10 tanks above each have a GSP requirement of 100, which is 1000 for the whole element. If they draw on a logistics element using light vehicles with normal logistics modules (which have 500 GSP each), two of those logistics vehicles would be consumed. When the GSP requirement does not neatly fit into the 500 point granularity, there is a chance of an additional logistics vehicle being consumed. This chance is dependent on the fraction of supplies required. For example, if there were 12 tanks with a requirement of 1200, then two logistic vehicles would be consumed and there is 40% chance (200 / 500) than a third vehicle will be consumed. This adds an element of uncertainty, as supplies may be consumed faster or slower than normal (although it will average out over time), plus it avoids any tracking of partial supplies per vehicle.
Below is an example of a Formation Template for a Brigade Headquarters that includes 50 Supply Vehicles.
Below is an order of battle for a divisional formation. At the divisional level are 240 Supply Vehicles, indicated by LOG 120k (120,000 supply points) in the Formation Attributes column, with smaller numbers within each brigade headquarters formation. The GSP column shows the resupply requirement for each formation or formation element. The total divisional organisation requires 40,338 GSP for a complete resupply and there are sufficient supply vehicles (410) in that organisation to resupply five times. With the inherent supply as well, the entire division can stay in combat for sixty rounds before additional supply vehicles are required.
Finally here is a view of a single population, with the order of battle tab in Location mode.
Setting Ground Formation Support
Here is a screenshot of the UI for setting support relationships between superior and subordinate formations. You drag the superior formation on to the subordinate formation. If the Support checkbox is checked, the supporting formation is shown in blue-grey with the name of the supported formation. Any supported formation in shown in orange. Support can only be provided when the supporting formation is a superior formation in the hierarchy of the supported formation, or is directly subordinate to a superior formation in the hierarchy of the supported formation and does not itself have any subordinate formations (an independent artillery formation for example). Supporting formations must be on the same system body as the supported formation. In combat, the support relationship will only function if the supporting unit has suitable bombardment units and is in a support or rear echelon position and the supported unit is in a front line position.
The drag-drop is intelligent and can distinguish between setting support relationships, reassigning formations to a new headquarters, removing headquarters assignments, moving formations from one population to another (on the same system body) and moving elements between formations (more on that last option in the next post).
Ground Formation Element Transfer UI
Below is the same screenshot as the previous post but with the Elements option selected. Now the formation elements for each Ground Formation are shown in the hierarchy. For formations with no subordinate formations, the formation elements are shown directly under the parent formation. For formations with subordinate formations, the formation elements are shown under their own node, to avoid cluttering the tree view.
To move elements between formations, you can drag and drop elements from one formation to another, although they must be on the same system body. Normally, the whole element is transferred. However, if the Amount checkbox is checked, a popup box will appear after the drag-drop, allowing you to transfer only a portion of the element. If the receiving formation already has an element with the same ground unit class, the additional units will be added to the existing element.
Ground-based Geological Survey
Geological Survey Teams do not exist in C# Aurora.
Instead, a new ground unit component (100 tons) provides 0.1 survey points per day. Ground units with this component may be added to ground formations to provide a geological survey capability. All formations at the same population with a geological survey capability will combine their survey points to conduct a ground-based survey. This can only take place after the orbital survey is complete.
Once the orbital survey of a system body is completed, the potential for a further ground survey will be revealed (None, Minimal, Low, Good, High, Excellent). The ground survey requires the same survey points as the orbital survey, except they are generated by ground forces. Only system bodies with a diameter of at least 4000 km will be eligible for a ground-based survey (in Sol that is Mercury, Venus, Earth, Mars, Ganymede, Callisto and Titan).
Normal mineral generation (at system body creation) has three phases:
- An overall roll for the potential for minerals to be present, based on radius, density and system abundance. If this roll fails, the body has no minerals.
- A roll for each type of mineral to be present, based on density and abundance. Duranium has twice the chance of any other mineral.
- A roll for the accessibility of each mineral generated in step 2). This is based on radius.
Once the ground survey is completed (assuming potential is Minimal or higher), a new mineral generation roll will take place. For this roll:
Step 1 is the same regardless of the potential.
Step 2 is modified by the potential. Minimal is 25% normal, Low is 33% normal (same as teams in VB6), Good is 50% normal, High is 100% normal and Excellent is 200% normal.
Step 3 is modified by High (+ 0.1) and Excellent (+ 0.2). All others are same as normal.
If a deposit of a mineral that didn’t previously exist is generated by the ground survey, that deposit is added to the system body.
If a mineral deposit is generated by the ground survey and a deposit of that mineral already exists on the system body, the existing deposit is changed to match the amount or accessibility (or both) of the ground survey deposit if the latter is greater.
The chances that an eligible body (4000 km diameter) will have ground survey potential is equal to: None 60%, Minimal 20%, Low 10%, Good 6%, High 3%, Excellent 1%.
For reference, in the Colonial Wars campaign, there are 2145 eligible bodies in 495 systems, so in general about 1.7 worlds per system will have potential of at least Minimal. About 1 system in 23 would have an Excellent potential world.
Here is an example survey ground unit:
Geosurvey Vehicle
Transport Size (tons) 218 Cost 8.72 Armour 20 Hit Points 40
Geosurvey Equipment:
Geosurvey Equipment:
Vendarite 8.72
Development Cost 436
Ground-based Xenoarchaeology
Xenology Teams do not exist in C# Aurora.
Instead, a new ground unit component (100 tons) provides 0.5 xenoarchaeology points. Ground units with this component may be added to ground formations to provide a xenoarchaeology capability. All formations at the same population with a xenoarchaeology capability will combine their xenoarchaeology points.
The annual chance for a race to successfully translate the alien language and symbology is equal to the xenoarchaeology points on the planet. For example, a Xenoarchaeology Vehicle is created with 2 components, giving it 1 xenoarchaeology point (cost about 9 BP). If a formation has forty such vehicles, the annual chance would be 40%. The chance in any given construction phase is equal to the annual chance * (construction phase length / year).
Ground Force Fortification
Fortification happens at the element level. Formation elements can fortify to different levels, depending on the base type of the unit class. That level is also affected by whether the element is restricted to fortifying itself or if it has assistance from construction vehicles. The level of self-fortification and maximum fortification is as follows:
Infantry, Static: Self 3, Max 6.
Light vehicle, Medium Vehicle, Heavy Vehicle: Self 2, Max 3.
Super-Heavy Vehicle: Self 1.5, Max 2
Ultra-Heavy Vehicle: Self 1.25, Max 1.5
All elements move from non-fortified to their maximum self-fortification level in 30 days without outside assistance. This progress is linear and happens automatically for all formation elements when their parent formation is not set to front line attack.
Construction elements will work on any element in their own formation or that formation’s subordinate hierarchy that has already reached its max self-fortification level. If the construction element’s formation has no subordinate, the Construction elements will work on any element in their own formation’s parent formation or in that parent formation’s subordinate hierarchy that has already reached its max self-fortification level. This means you can attach a construction-based formation directly to a formation you need fortified, or you can attach to a HQ and it will fortify every formation descending from that HQ. Construction elements can only assist elements that are on the same system body (they can be in different populations on the same body).
Given sufficient capacity (see below), a construction element can fortify any other element from its maximum self-fortification level to the maximum fortification level in 90 days.
The capacity of a construction element is equal to the construction rating of the elements unit class * number of units * race construction rating * commander production bonus * 100 tons. For example, a formation of 50 construction vehicles, each with 0.1 construction rating (2 const components at 0.05) for a race with 16 construction which is part of a formation with commander with 10% production bonus would be: 0.1 * 50 * 16 * 1.1 * 100 = 8800 tons. BTW a construction battalion of this type would cost 636 BP to build.
All construction elements are ordered by descending order of construction capacity. Each one determines the list of elements that they can assist (using the above criteria), excluding any that have been assisted by a previous construction element. The list of target element is ordered by Construction Rating (so construction units fortify themselves last), then descending tracking speed (so point defence STO and then normal STO), then by field position (so front line defence, then support, then rear echelon), then by descending max fortification (so infantry, static first), then by descending cost (elements with more expensive units first), then by descending morale.
The construction element cycles through the list of target elements using the following process.
-
The total size of the target element is determined (element unit size * number of units)
-
This is compared to the remaining construction capacity of the construction element. If its is greater, then the remaining construction capacity of the construction element is reduced by the size of the target element. If it is less, remaining construction capacity is reduced the zero and a Size Vs Capacity Modifier equal to (remaining construction capacity / target element size) is applied below
-
The amount of fortification that could be accomplished in ninety days is determined by deducting the target element self-fortification level from the target element max fortification level
-
The amount of fortification that could be accomplished within the current period is determined by 90 Day Fortification Amount * (Current Period / 90 Days) * Size Vs Capacity Modifier
-
The fortification for the current period is applied. If this would surpass the target element maximum fortification, then that value is set instead
-
If the construction element has capacity remaining, it moves on to the next target element in its list
Note that because of the way this is applied, it will take the same amount of time to move infantry from fortification level 3 to level 6 as it does for armour from 2 to 3.
This process will allow the player to either directly manage construction elements by attaching their formation to the desired target formation, or to attach the formation to a high level HQ and have the process happen automatically. If a construction element is used to fortify other elements, it will not contribute its construction capacity to its parent population during the next construction phase.
In combat, if the fortification level of a formation element is greater than 1, it is multiplied by the fortification bonus of the dominant terrain.
Genetically Enhanced Soldiers
Infantry units can be given capabilities, known as Genetic Enhancement, which increase their hit points and make them more resistant to damage. So far there are three options:
Basic Genetic Enhancement: RP 5,000, HP x 1.25, Cost x 1.5
Improved Genetic Enhancement: RP 10,000, HP x 1.6, Cost x 2.0
Advanced Genetic Enhancement: RP 20,000, HP x 2, Cost x 2.5
Once researched, the new capabilities can by chosen from the available capabilities list during ground combat design. These are all Biology/Genetics techs and the first in the sequence can be researched following Genome Sequence Research
Chance of Ruins
I’ve added the chance of alien ruins to the game window, so it can be adjusted.
It is normally 20% for any terrestrial world, terrestrial moon or small terrestrial moon with gravity > 0.4G and temperature between 200K and 360K (about -73C to +87C).
Recovering Technology and Ship Components from Ruins
In order to prevent unbalancing tech advancements occurring while excavating very large ruins, the maximum tech advancement you can achieve from recovering abandoned installations will be based on the tech level of the ruin race. The max development cost of any associated tech will be:
(2 ^ (Ruin Race Level + 1)) * 1000;
This means a level 1 ruin race will have tech up to 4000 RP, a level 2 race up to 8000 RP, etc. with the maximum being a level 5 race with tech up to 64,000 RP.
When standard components are selected for recovery (such as gravitational survey sensors), they will be the best available component within the above limit. If no component of the specified type is available within the limit (for example when the random selection is a 5000 RP Asteroid Mining Module for a level 1 race), nothing will be recovered.
Ruins in Sol
There is a very small chance that one of the larger bodies in Sol may have alien ruins. This can happen on Mars, Mercury, the Galilean Moons, Titan, Triton, Pluto or Eris. This is only about 5% for Mars, 3% for Mercury, 1% for Titan or Ganymede and fractions of a percent for the others.