Aurora v1.0.0 Launch Documentation

New Game Settings

  1. Percentage modifier for Research Speed (for all races)
  2. Percentage modifier for Terraforming Speed (for all races)
  3. Percentage modifier for starting minerals on Sol.
  4. Flag for Active Civilian Shipping Lines. When this is disabled, shipping lines will not produce ships.
  5. Flag for Civilian Harvesters. When this is disabled, shipping lines will not build fuel harvesters.
  6. Flag for recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
  7. LY entry to limit Starting NPR Locations to within a specific range of Sol
  8. Option for Planet X in the Sol System

You can specify a number of Earth-based player races on the Game Setup window. You will cycle through a number of Race Creation windows equal to the number of races selected. You will still need to create any non-Earth-based races after the main game creation process.


Starting Build Points

A new player race in Aurora receives a number of Starting Build Points equal to two years wealth. These can be spent on instant build for Ships and Ground Formations.

If the available Instant Build Point total is greater than zero, the Instant Build section will be shown on the Miscellaneous tab of the Class window, including the current Instant Build Point total, plus selection options for destination fleet and number of ships to be built. This section will also appear if SM Mode is active, so additional ships can be instantly built if required by the game setup.

If the available Instant Build Point total is greater than zero, that total, plus the Instant Build button, will be shown on the GU Training tab of the Economics window. When the Instant Build button is clicked, a popup box will allow entry of the number of formations to be built. This button will also appear if SM Mode is active, so additional formations can be instantly built if required by the game setup.

If you choose to have automatically constructed ground formations at game start, their cost will be deducted from the starting build points.

The ship options replace the VB6 Fast OOB window, while the ground options are new for C# Aurora.


Starting NPR Locations

There is a new option on the New Game window that allows you to specify the minimum and maximum distance (in light years) of starting NPRs in Known Stars games. The NPR starting location will be selected from the list of known star systems within that distance range from Sol. This gives you some control over how fast you will run into the starting NPRs.

Once a known system is selected, the system bodies for that system will be generated and checked for a suitable planet or moon to establish the NPR. This potential body needs to be in the acceptable range for gravity, temperate and hydro extent. The atmosphere will be changed to something suitable. If nothing is found, the system is generated again and again until a suitable location appears (this won’t take long).

A check is also made to see if the NPR location is within reasonable range of the primary star; either by orbiting within about 12 billion kilometres or orbiting within 12b km of a star that allows travel by Lagrange point to the primary (with the LPs also within 12b of each star). I’ve even checked for the planet/moon orbiting a star with no Lagrange points but that star is within 12b km of the primary, or orbiting a star with no Lagrange points but that star is within 12b km of another star that does have LPs to the primary :) This is to ensure no NPRs created that are unlikely to interact with the player.


Planet X in the Sol System

In recent years, several theories have been published regarding a potential planet affecting some Kuiper Belt objects, possibly a distant but undetected gas giant. Therefore, a new game option is to “Add Planet X to the Sol System”.

The planet will be located at a distance between 125% and 225% of the orbit of the most distant dwarf planet. 10% of the time it will be a terrestrial body, 60% a gas giant and 30% a superjovian. Moons, Trojan asteroids and a Lagrange point may also be generated depending on the type of planet generated. If Planet X has a Lagrange point, a Lagrange point will also be generated for Jupiter. While very distant from the inner system, this could add an interesting variation to the Sol system.

Currently Planet X is named Minerva, although I haven’t created any moon or Trojan asteroid names. Suggestions welcome.

Here is one version of Minerva - a superjovian with eight moons, orbiting at 145 AU.


Conventional Start

There are no longer any missile bases or ICBMs for a conventional start. The player now receives:

1,000 ton Naval Shipyard
10,000 ton Commercial Shipyard
Spaceport
Military Academy
Naval Headquarters
Deep Space Tracking Station
5x Maintenance Facility
Conventional Industry equal to eight times the Manufacturing population in millions.
Research Facilities equal to one twelfth of the Manufacturing population in millions. This is more research facilities than in VB6.

For example, a starting population of one billion will have 1600 conventional factories and 16 research facilities


Starting Financial Centres

New Trans-Newtonian Races will start with a number of financial centres equal to one quarter of the number of construction factories.

Fleet Movement Auto Route

The Fleet Movement Orders section of the Naval Organization window has an option called Auto Route by System. When this option is selected, the normal movement destinations list will be replaced by a list of systems that the Fleet is capable of reaching. Clicking on a system and clicking Add Move will generate all the movement orders from the current system to the destination system. The System Locations option will be automatically selected and the destination list for the new system will be displayed, so the player can complete any specific orders.

The determination of which systems can be reached is based on three check boxes to the right hand side of the same tab.

  1. Assume Fleet is Jump Capable: If checked, the algorithm will assume the fleet will be able to transit any jump point. If not checked, the fleet will have to be jump capable to reach any system beyond a jump point without a gate.

  2. Check Danger Rating: If checked, the fleet will not be able to travel through any system where the danger rating is higher than the protection value of the friendly warships in that system

  3. Exclude Alien-Controlled: If checked, the fleet will not be able to travel through any system that the player has flagged as alien controlled (assigned a flag)

Fleets have two stored values, Avoid Danger and Avoid Alien Systems. These are set on by clicking the second and third check boxes above and will affect the algorithm used for Standing and Conditional Orders for that fleet in addition to the Auto Route.

A system can also be flagged on the Galactic Map as excluded from auto-route. For example, there may be a shorter route in terms of kilometres but longer in terms of transits. You can block one of the systems on the original route so the algorithm will always choose your preferred path.

The list of systems will highlight any populated systems in light green and any other colony systems in dark green. The total population will be shown (if greater than zero) or the number of the most important installation type. In order of priority these are automated mines (including asteroid miners), then terraformers (including orbital), then tracking stations. This is similar to the population tree view on the Economics window functions.

These four screenshots below show an example journey. In the first, a US fleet in the Eta Cassiopeiae system (highlighted at the bottom) wants to return to Sol. In the second, the potential system list is displayed. As the Exclude Alien-Controlled option is checked, the fleet cannot travel through the Commonwealth systems starting with EV Lacertae so none of those systems are an option. The third screenshot shows the results as the path finding algorithm takes the fleet on a longer route via Oregon then displays the destination list for Sol. The fourth screenshot shows the journey of a French survey ship. In this case, the algorithm has determined that using Lagrange points in two of the systems will make the journey shorter.


Standing Orders

Standing Orders are the C# equivalent of Default Orders in VB6 and function in exactly the same way. If your ship has no active movement orders, it will act on the Primary Standing Order. If that is not possible, it will act on the Secondary Standing Order.

Standing orders will only be checked if the increment length is greater than one hour. In addition, acting on the Standing Orders for “Move to Gas Giant with Sorium” and “Move to Asteroid Mineral Source” will unset the standing order (to prevent continuous issuing of the same order). Civilians and NPRs will monitor ships in this situation and reactivate the standing order if required.

Conditional Orders are Standing Orders linked to a Condition. When the condition is met, the associated conditional order will be executed where possible. Secondary conditional orders will not be executed if the fleet is already acting on the primary conditional order.

Each potential order is accompanied by an S or an A. This indicates whether the order will look at potential destinations in the same system (S) or all systems (A). When the order involves moving to a different system, the algorithm calculating the best path will take into account whether the fleet will try to Avoid Danger and try to Avoid Alien Systems. These two values are set by the Check Danger Rating and Exclude Alien-Controlled check boxes respectively, which are located on the Movement Orders tab (see Auto Route rules post for more details).

There will be some new standing orders for C#, which I will list here as I add them:

  1. Land on Assigned Mothership: Can be used for Standing or Conditional orders and will only be executed if there is a common mothership for the fleet. An example of use would be survey carrier ops, where the parasites would return to the mothership if they were low on fuel or had surveyed all potential destinations.

  2. Move to System Requiring GeoSurvey: Can be used for Standing Orders. The fleet will move a system where the ‘Standing Order Geo Survey Complete’ flag is not set . This flag is set when a survey ship with an order of “Survey Nearest Body” or “Survey Next Five System Bodies” cannot find a system body within ten billion kilometres. It doesn’t mean the system is completely surveyed, but that it is surveyed in practical terms. If you need to you can send a survey ship to a distant planet or star (more than 10b km) and it will still automatically survey everything within ten billion kilometres of the last surveyed body, but the earlier setting of the flag means that other survey ships will not arrive automatically to survey the very distant bodies.

  3. Move to System Requiring Gravsurvey: Same as above but for survey locations.

  4. Refuel at Hub. This is part of several different orders. A Refuelling Hub is a large module intended for space stations (although it can be used on ships) which can simultaneously refuel an unlimited number of ships (while the fuel supply lasts) if it is stationary.

  5. Move to Closest Rendezvous Point: A new type of waypoint (see changes post following this one) is the Rendezvous Point. This can be assigned as a destination for a Standing Order or a Conditional Order

  6. Investigate Closest Point of Interest: A new type of waypoint (see changes post following this one) is the Point of Interest, which is a temporary waypoint that remain in place until a fleet arrives at the location or for six months, whichever happens first. The function of this order and the new waypoint is for the player to designate areas in a system which he wishes a fleet to visit automatically. Different fleets operating with the “Investigate Closest Point of Interest” order will take account of each other’s activity to avoid duplication of destination. Points of Interest can be designated as Urgent and these will take priority over other POIs.


Waypoints

Waypoints will be much more useful in C# Aurora. It will be possible to add the following five types to the system map:

  • Normal: The standard waypoint from VB6 Aurora. This will appear on the map as Waypoint #1, Waypoint #2, etc. with the number unique to the system. A normal waypoint will remain until manually removed and can be assigned as a destination in movement orders.

  • Named: Functions as a normal waypoint with the exception that during placement you can assign a name to the waypoint, that will be displayed instead of the normal text.

  • Rendezvous: Functions as a normal waypoint and will also be used as a target for the new Standing / Conditional Order “Move to closest Rendezvous Point”.

  • Point of Interest (POI): A temporary waypoint that remain in place until a fleet arrives at the location or for six months, whichever happens first. The POI will be used as the destination for the new Standing Order “Investigate Point of Interest”. The function of this waypoint is for the player to designate areas in a system which he wishes a fleet to visit automatically. Different fleets operating with the “Investigate Point of Interest” order will take account of each other’s activity to avoid duplication of destination.

  • Urgent Point of Interest: Similar in function to a POI waypoint. The differences are that this waypoint type will remain in place until a fleet arrives at the location or for one year, whichever happens first, and that any fleet with the Standing Order “Investigate Point of Interest” will visit Urgent POIs before normal POIs.

Clicking on a system body icon when placing a waypoint of any kind will link the waypoint to the system body and it will move with that system body.

Example screenshots below:


Reaction Bonus

A commander’s initiative bonus has been replaced by a new Reaction Bonus. This serves two functions:

  1. Fleets (both player and NPR) will move in ascending order of the average reaction bonus of the ship commanders in the fleet.
  2. Response time for orders (when hostiles are present), which is based on fleet training, will be further reduced by the average reaction bonus of the ship commanders in the fleet.
  3. Any ship without a designated commander will be treated as if it has a commander with a 0% bonus.

Standing Order for Unload Colonists

I’ve completely rewritten the standing order (VB6 default order) for unloading colonists (used by shipping lines, NPRs and your own ships if desired). The process is as follows:

  1. Colony fleet looks for a suitable population that is set as a destination with no other colony fleets inbound, checking its current system first and then using the path finding algorithm to search everywhere else in the empire.
  2. Same as 1) but without the check for inbound colony ships.

When determining if a population is a suitable destination, the fleet checks the following:

  1. How many colonists it is carrying.
  2. If the species is the same as the colonists.
  3. The available capacity of the system body on which the population is situated, taking into account other populations.
  4. The available capacity of the infrastructure (normal or LG depending on the gravity), taking into account the current population size.
  5. The lesser of 2) and 3) is used as the base capacity of the population to accept new colonists.
  6. Any available space in orbital habitats is added to that capacity.
  7. The total number of colonists on ships already inbound to the colony is deducted from that capacity.
  8. if the capacity exceeds the number of colonists in the checking fleet and the species match, the colony is suitable.

This should prevent the current problem of many colony ships delivering to a colony without the capacity to support them all. As soon as a fleet determines a colony is suitable, the orders are issued, which means other fleets checking in the same increment will be aware of the extra inbound colonists.

Because of these changes, Passenger Liners will no longer search their current system for a potential destination (otherwise they could load and unload at the same population).


Standard transits by Fleets with Commercial and Military Ships

In VB6 Aurora, fleets that included at least one ship with military engines could only use military jump drives for standard transits, which meant you had to split out commercial-engined ships into a separate fleet and escort them with a commercial jump drive ship.

In C# Aurora, commercial-engined and military-engined ships are treated separately. So if you have a fleet with mixed engine types that also includes ships with commercial and military jump drives, it will still carry out a standard transit if the respective jump drives are large enough for the ships with the matching respective engine types. However, if any ship with either engine type can’t jump, the whole fleet will fail to transit.

Squadron jumps are handled differently so I will cover that in a separate post.


Jump Point Stabilisation

For C# Aurora, Jump Gates have been replaced by Stabilised Jump Points. This is purely a technobabble change and there is no change in function.

Anything associated with VB6 Jump Gates will be changed accordingly. For example, Jump Gate Construction Modules have been replaced with Jump Point Stabilisation Modules and the Build Jump Gate order is now Stabilise Jump Point.


Fleet Maximum Speed

Fleets have a checkbox on the Naval Organization window entitled ‘Use Maximum Speed’.

If this is checked, Fleets will automatically recheck their speed at the start of each movement sub-pulse and use the maximum available


Jump Drive Size Requirements

When using a jump drive to open a jump point for other ships, the only requirement is that the jump drive capacity is large enough for the transiting ship. There is no requirement in C# Aurora for ship mounting the jump drive to be as large as the transiting ship.

Relatively small jump tenders or bases will now be able to open a jump point for much larger ships.


Jump Point Transit Shock

When a ship transits a jump point, it will suffer jump shock. This temporarily disables active sensors, fire control systems and jump drives.

A ship making a standard transit will suffer a delay equal to: (120 seconds + Random 1 to 60 seconds) * Ship Bonus.
A ship making a squadron transit will suffer a delay equal to: (20 seconds + Random 1 to 10 seconds) * Ship Bonus.

The ship bonus is equal to: 2 - ((1 + Crew Grade) * Morale * Overhaul Factor).

For example, if a ship has 100% morale, an overhaul factor of 1 (which is normal) and crew grade of 10%, the ship bonus would be (2 - (1.1 * 1 * 1) = 0.9. So any delay would be multipled by 90%.

The length of jump shock for NPRs is halved. This is to compensate for the fact that humans can make much better decisions in this situation, in particular with regard to ensuring the right mix of jump ships and warships is available in the right place at the right time to take advantage of squadron transits. If I get around to coding more detailed strategic decision-making in this situation for NPRs (not a priority for V1), I’ll make them the same as player races.


Fleet Order Templates

When a fleet is given a set of orders on the Naval Organization window, those orders can be saved as an ‘Order Template’. This is as simple as clicking the Save Template button and typing a name into a popup box.

When the Order Templates option is chosen in the top left of the Movement Orders tab, all Order templates that start in the same system as the currently selected fleet are displayed (see first screenshot). To use a template, select it from the list and click Add Move. All the orders are created accordingly (see second screenshot). This is similar to the same functionality in VB6 but the UI allows a lot more templates to be easily accessible.

Templates can be deleted with the Delete Template button.


Fleet Distance and Time

When a fleet is given orders, the Naval Org window will show both the distance and time required for those orders, so you now know (for example) when vital Gallicite shipments will reach your home world. See at the top of the screenshot below.

There are a few other enhancement, such as military tonnage in the fleet (which helps with checking maintenance requirements) and total fleet cost.


Create New Lagrange Points

Ships designed for jump point stabilisation (creating jump gates in VB6) can also stabilise new Lagrange points.

Any planet with a mass of at least 150 will already have a stable Lagrange point that allows any numbers of ships to jump to other stable Lagrange points. Planets less than 150 mass also have Lagrange points but they are not stable and therefore not visible on the map. A ship with a stabilisation module can stabilise these Lagrange points so that all ships can use them. It is much easier to stabilise high mass planets, so gas giants are commonly used for this purpose, but it is possible even for larger terrestrial worlds given sufficient time. It is not possible to stabilise the Lagrange point of a planet with less than 0.25 mass.

The time in months required to stabilise a Lagrange point for a given planet is equal to: 60 / SQRT (Planet Mass). The production bonus of the ship commander will reduce this time.

For the solar system:
Jupiter has a mass of 317 so it already has a stable Lagrange point.
Saturn has a mass of 95 and would require six months.
Uranus has a mass of 14 and would require 1.3 years.
Neptune has a mass of 17 and would require 1.2 years.
Earth has a mass of 1 and would require 5 years.
Venus has a mass of 0.82 and would require 5.5 years.

Mars has a mass of 0.11 and Mercury has a mass of 0.055 so they are too small.

A new ‘Stabilise Lagrange Point’ order is available for planets where stabilisation is possible. The stabilisation ship remains at the associated planet while the task is carried out. Apart from the location and different required time, this is very similar to a jump point stabilisation task.

The time required for any given planet can be found on the System View in the very last column (you will need to scroll right).


Lagrange Points for Moons

In C#, it will be possible to have Lagrange Points for moons. These will not occur naturally, but there are two situations where it is possible. Firstly, you can use a ship equipped with a Stabilisation Module on any moon with a mass of at least 0.25 Earth masses. The time required will depend on the mass of the moon but it is likely to be several years. Secondly, you can place the Lagrange Point manually using the new System Design functionality. The latter option does not have any mass restriction.

This will provide a way to have ships jump very close to the parent planet of the moon, which is very useful in logistics terms but very dangerous if you are at war.


Salvage in Orbit

When a wreck is salvaged in VB6, the recovered minerals and components so to freighters in the same fleet as the salvage ship.

In C#, the same is true. However, if the wreck is in orbit of a population from the same race as the salvage ship, there are no freighters available and either a ship in the salvage fleet or the population has cargo shuttles, the recovered minerals and components are added to the population stockpile.


Tractor Any Ship

I’ve added a new order to “Tractor Any Ship in Fleet”. A tug with this order will tractor the largest ship in the target fleet, without you having to specify the ship.

This allows you to create an order cycle to move a group of space stations (terraformers, fuel harvesters, orbital miners, etc.) from one location to another without having to specify each ship individually. With the new space station rules in C# Aurora, this will happen a lot, so this new order is designed to protect my sanity :slight_smile:


Survey Speed

The game details window has an option to change survey speed in the game. 100 is the normal rate. For example, if survey speed is changed to 50, all surveys will take twice as long, whereas if survey speed is changed to 125, surveys will happen 20% faster.

The survey speed modifier is applied to the survey points produced by survey ships. Everything else remains the same.


Structural Shells

A ‘No Armour’ check box has been added to the class window. Clicking this removes the normal armour from the class.

Designs with no armour instead have a new type of armour called ‘structural shell’. This costs 1 per unit and has a strength of 20, essentially making it 5% of the cost of normal armour in terms of strength.

There are severe limitation on ships with no armour:

  1. They cannot have engines
  2. They cannot have military systems
  3. The structural shell does not prevent damage. In effect, weapon fire passes straight through the ‘armour’

This type of ship is ideally suited for orbital habitats or space stations of some type, such as fuel harvesting platforms, mining stations, etc., that require towing to move.


Space Stations

The rules on construction factories building spacecraft are changing in C# Aurora. Any class with a Structural Shell instead of armour is classed as a Space Station. Space Stations can be built by construction factories at any population that includes a Spaceport. Note this means you no longer need an orbital habitat in order to use construction factories, which means you can create huge deep space logistical bases, terraforming stations or small observation platforms, or anything in between, using construction factories.

The downside to this flexibility is no armour, no engines and no military systems, so space stations will require protection from defensive bases (which can be maintained by the space station if it has sufficient maintenance facilities). As an example, if you were channeling Starship Troopers (movie, not book) you could build the following station and deploy in deep space, near the Arachnid Quarantine Zone:


Orbital Habitats

This is a copy of a post in the VB6 7.2 Changes List. I didn’t release the updated VB6 version so this is still a change from the released VB6 Aurora.

The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new ‘No Armour’ option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper, although it is probably practical at lower colony costs because the ground-based infrastructure would require a larger proportion of population for environment. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.

Combat Reports

In VB6, understanding the combat events can be difficult given the sheer amount of information. Therefore, C# Aurora uses a condensed system where you no longer see each individual weapon firing, or the damage from individual hits. Instead weapon fire and any resulting damage are shown in a summary format. The side being attacked will also receive some information about the firing ship, using the Alien Ship Name if available.

Here is the summary when a Japanese destroyer opens fire on a Martian Patrol Ship. The different in hull designation in the two reports is because Mars classes the Monoceros as a patrol ship, while Japanese Intelligence classes it as a destroyer.

image

image

Subsequent damage reports in the next two five-second increments as the Japanese ship continues firing with 10cm railguns. The 15cm railguns are recharging.

image

image

The ship is finally destroyed by the next volley.

image


Point Defence

In C# Aurora, fire controls set to ‘Final Defensive Fire’ or ‘Final Defensive Fire (Self Only)’ will fire on hostile missiles, regardless of whether the fire control is set to ‘Open Fire’. Fire controls set to Area Mode or for AMMs will only fire defensively when that fire control is set to ‘Open Fire’.

When a missile reaches its target, a target ship will use its CIWS first. If that is insufficient, it will use any weapons linked to fire controls set to ‘Final Defensive Fire’ or ‘Final Defensive Fire (Self Only)’. If that is still insufficient, ships or the same race or an allied race with fire controls set to ‘Final Defensive Fire’ will be checked in increasing order of distance from the target ship.

A target population will use any ground units assigned to point defence to shoot at incoming missiles. If that is insufficient, the same process as for ships will take place, checking same race or allied ships within point defence range of the planet.


Final Defensive Fire Changes

In VB6 Aurora, a fire control can only fire at a single target in any increment. For C# Aurora, an exception is made for fire controls firing in automatic final defensive fire mode.

A fire control in this mode will continue to fire on incoming salvos as long as it has unfired weapons remaining. Each individual weapon or turret will only be able to engage a single salvo. This means point defence ships no longer need a large number of fire control systems, although there is still a design choice in terms of redundancy.

In VB6 Aurora, missiles moved in descending order of speed. I’ve updated that for C# Aurora to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first (and be engaged first by final defensive fire).


Automated Weapon Assignment

C# has a more intelligent auto-assignment for weapons and fire controls. You can set up a ship with a single click and then adjust as necessary. The code assumes that

  • Any missile fire control with a resolution of 1 is an anti-missile fire control

  • Any missile fire control with a resolution greater than 1 is a ‘normal’ missile fire control

  • Any beam fire control with a tracking speed at least 2x racial speed is a point defence fire control (some leeway here for older ships)

  • Other beam fire controls are for offensive weapons

  • Weapons within the given category (missile PD, missile offensive, beam PD, beam offensive) are split equally between fire controls of the same category

  • More powerful beam weapons are assigned first

  • ECCM is assigned as available with the priority order of offensive launcher, PD launcher, offensive beam, PD beam

The assignment code will take account of damage to the ship and adjust accordingly. In most cases, the above will be sufficient (and will be used for NPR designs). For more bespoke and unusual player ships, some tweaking may be necessary.

As a simple example, the escort cruiser below has six twin turrets and three fire controls. Clicking the button assigns two turrets to each fire control and sets the point defence to final fire.

This ship has a mixture of point defence and offensive lasers, plus fire controls for each. The auto-assign determines which weapons should be assigned to which fire control. All beam fire control are set as final fire so the ship will use all available weapons to defend against missile attack.

This ship has a mixture of missiles and offensive lasers. Note that missiles are automatically assigned to launchers.

This ship has a point defence turret and multiple types of offensive beam weapons, plus an ECCM system.

An extreme example!


Fire Delay

The Fire Delay mechanic for inexperienced ships has changed for C#. The delay is about half that in VB6 and is on a bell curve. I decided to reduce the delay because it was never a major issue for long-range missile combat but it could be a very long time in energy range combat. The new mechanic reduces the delay overall and makes the maximum delay far less likely. Note that this is not the same as a jump delay, which remains the same.

A fire delay happens when a ship with less than 100% Fleet Training either opens fire or changes target. The formula is as follows:

Round ((1 - (Fleet Training Points / 500)) * (1 - Reaction Bonus) * Random(10) * Random(10) * 0.5)

For example, a ship with 20% fleet training (100 points) and a 10% reaction bonus would be: Round (0.8 * 0.9 * Random(10) * Random(10) * 0.5), which is anything from no delay to 36 seconds, with the likely outcomes in the middle of that range. 15-20 seconds for a relatively inexperienced ship is long enough to disrupt coordination in a close-range battle, but not so long it is crippling or difficult to accept in terms of reality. A ship with 100% fleet training will suffer no delay and ships with high percentages are more likely to have no delay.


Interrupts for Active Weapons

In VB6, the game interrupts if you have weapons set to fire and no valid targets. It also interrupts when recharging is complete for weapons set to fire, even if nothing is in range.

For C#, the game checks to see if the target exists and is in range for each individual fire control. If not, there is no interrupt. Instead, you get a single event message per ship stating that ship is trying to fire on a target that is out of range or doesn’t exist but the increment otherwise happens normally. This means you can set all your weapons up and assign targets while well out of range. Increments will proceed normally until you are within range, at which point the weapons will start firing.

Once in range, the recharge interrupts will happen (so if your weapons have a 40 second cycle time you can just hit 2 minutes and time will advance 40 seconds).


Point Defence Fire Control

VB6 has a restriction that each fire control can only engage a single target during point blank fire. I’ve removed that restriction for C#. Each weapon can still only engage a single salvo.

In VB6, missiles moved in descending order of speed. In C# that has changed to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first. Consequently, your point defence will engage the largest salvos first.

Base Ground Combat Rules

Ground combat is conducted after the naval combat phase of each increment. One combat round will be performed for every eight hours that passed in the increment. Combat potentially takes place on any system body where populations exist from two or more hostile powers. If only one side has ground forces present, there may be a conquest (rules and code TBD). If ground forces are present from two or more hostile powers, ground combat will take place.

Ground forces can be assigned one of four field positions; front line attack, front line defence, support and rear echelon. Units in support and rear echelon positions cannot directly attack hostile forces but if they possess elements with bombardment weapons they may be assigned to support a front line formation. Support and rear echelon formations can also potentially provide anti-air cover (more in a rules post on ground-space interaction) and supply to front line units. Only formations with all elements supplied can be placed in front line attack mode. Formations placed in front line attack mode lose any fortification bonus.

Each race involved in a combat on a system body creates a list of its own formations on that system body (even if in multiple populations), plus a list of hostile alien formations, even if they are from multiple alien races in multiple populations. Hostile formations are checked for their weighted size. This is based on actual size for front line size, 25% for support and 5% for rear-echelon. Each hostile formation is given a range for potential selection, based on its weighted size.

Each front line friendly formation randomly targets a hostile formation. Friendly units with front line defence can target hostile front line formations. Friendly units with front line attack can target any hostile formation, although support and rear echelon are less likely given their smaller weighted size. In fact, the more formations that are pushed into front line positions, the less likely it is that rear areas will be attacked.

Support and Rear Echelon formations that contain formation elements with bombardment weapons can be assigned to support front line formations that are part of the same organisation. Formations in a support position with light bombardment weapons will fire with the front line formations (see next paragraph). Formations in a support position with medium/heavy bombardment weapons or formations in a rear echelon position with heavy bombardment weapons will fire in a subsequent phase - see below.

Once a front line formation (or a light bombardment element in the Support position) has been matched against a hostile formation, each friendly individual unit (a soldier or vehicle) in that formation engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements. The targeting on an individual unit level represents that the different elements in a front line formation will generally be attacking in conjunction (infantry supporting tanks, etc.).

Once all front line attacks have been concluded, each unit in each element providing supporting bombardment will engage either the hostile formation being targeted by the friendly formation they are supporting, or one of the hostile formation’s own supporting elements (counter-battery fire). If the hostile formation is targeted, each unit in the supporting artillery element engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements (the same as front-line vs front-line). If a hostile supporting element is targeted, all fire is directed against that element. This represents the difference between providing supporting fire in a combined arms front-line battle and targeting specific hostile artillery for counter-battery fire. The decision to target the hostile front-line formation vs hostile support elements is based on the relative sizes.

Supporting medium artillery will choose between hostile forces in Front-Line or Support field positions (and will ignore any elements in Rear Echelon field position for purposes of relative size), while heavy artillery can select targets in any field position. In other words, if the enemy has supporting heavy artillery in a rear echelon position, you will only be able to target those elements with your own heavy artillery (or ground support fighters, or orbital bombardment support).

Once all the initial combat is complete, there is a chance for a breakthrough. Each defending formation is checked according to the following procedure:

  1. A Cohesion Damage value is determined for each formation element using the following formula: Element Class Size * Units Destroyed in Combat Phase * (100 / Element Morale)

  2. The total Cohesion Damage is summed for all elements in the formation and compared to the formation size. This value, from 0 to 100%, is the Formation Cohesion Rating

  3. For each front line formation that attacked the defending formation, a Breakthrough Value is determined for each formation element

  4. Static elements have zero Breakthrough Value. Vehicle elements use the following formula: Element Class Size * Element Units * (Element Morale / 100). Infantry elements use the same formula as vehicles with a further modifier of 0.5.

  5. The total Breakthrough Value is summed for all elements in the attacking formation and compared to the formation size. The value is multiplied by 2 if the formation has a field position of Front Line Attack. This value, from 0 to 200%, is the Formation Breakthrough Rating

  6. A Breakthrough Potential value is determined for the attacking formation by multiplying the defending Formation Cohesion Rating by the attacking Formation Breakthrough Rating. If this value is equal to or greater than 30%, a breakthrough has occurred for that attacking formation.

  7. Each formation that creates a breakthrough mounts a second attack. This attack does not benefit from supporting artillery or fighter support. However, it functions as if the attacking formation has a field position of Front Line Attack, which means all hostile formations are potential targets, not just those on the front line.

The breakthrough rules mean that defending formations that suffer casualties may allow attacking formations to penetrate their lines and conduct a second attack. This is more likely under the following circumstances: A single defending formation is attacked by multiple attacking formations, the defender suffers a high casualty percentage in a single ground combat round (potentially because the formation is small in size), the defender suffers disproportionate casualties to elements with larger unit classes, the defender is low morale, the attacker is primarily vehicle-based, the attacker is on front-line attack, the attacker is high morale.

When a formation element is engaged in combat against a hostile formation element, supply is checked. If supply is not available, the number of units firing will be 25% of normal. Each attacking unit uses the following process:

  1. The To Hit Chance is determined. The base chance is 20% multiplied by the ‘Dominant Terrain To Hit Modifier’, the firing element morale / 100 and, if the target is not fortified, the base to hit chance for the target element unit class.

  2. The Fortification Modifier for the target element is determined, which is the current fortification level of the target multiplied by the ‘Dominant Terrain Fortification Modifier’. If the target is not fortified, the Fortification Modifier is 1.

  3. The Environment Modifier is calculated, taking into account gravity, pressure and temperature and whether the firing element has capabilities in those environments. Each environment for which the element is not trained has a x2 modifier.

  4. The Terrain Capability Modifier is calculated. If the element is trained to fight in the dominant terrain, the modifier is 0.5.

  5. The Final Chance to Hit is calculated as To Hit Chance / (Fortification Modifier * Environment Modifier * Terrain Capability Modifier)

  6. The unit fires each weapon it has (except for non-bombardment weapons on units bombarding from support and rear-echelon field positions). If the to-hit roll is equal or less than the final chance to hit, the weapon has struck the target.

  7. If a hit is scored, the armour-piercing (AP) value of the weapon is checked against the armour of the target. If AP is equal or greater than armour, the shot has penetrated. If AP is less than armour, the percentage chance to penetrate armour is (AP / Armour)^2.

  8. If the shot penetrates armour, the percentage chance of destroying the target is equal to (Weapon Damage / Target Hit Points)^2.

  9. If a target is destroyed, the firing element gains morale and the target element suffers a loss of morale. This morale gain/loss is doubled if the firing unit is in front-line attack mode.

All combat is conducted simultaneously and losses are applied once all firing is completed. Because of the way the above is structured, multi-way conflicts with multiple races on each side are possible.


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.


Orbital Bombardment Support

Ships equipped with energy weapons can provide support to ground unit formations during ground combat.

To be eligible, a fleet with energy weapons is given an order to “Provide Orbital Bombardment Support” with a friendly population as the destination. This order functions in a similar way to a ‘Follow’ order, with the order remaining in place until removed by the player. On the Ground Combat Window, eligible fleets (those in orbit and with this order) appear under their own section of the tree view for each population, with a parent node of “Orbital Bombardment Support”. The ships in those fleets can be dragged and dropped on to formations in the same way as ground support fighters. Fleets with this order can still be targeted in normal naval combat or by STO weapons (they do not have the same protection as fighters on ground support missions).

In combat, the orbital bombardment ships attack at the same time as bombardment elements and have the same target selection options as heavy bombardment. Orbital bombardment ships have the same chance to hit as ground units, although they are not affected by any negative environmental modifiers (such as high gravity or extreme temperatures). Each ship fires its weapons once per ground combat phase. Each ship’s to hit chance is affected by its crew grade and morale, plus 100% of the ground support bonus of the tactical officer and 50% of the ground support bonus of the ships commander.

The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat. Armour penetration is equal to half the damage. Fractions are retained. For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17.3/34.6 for a 10cm laser, 40/80 for a 25cm laser. Weapons roll for failure in the same way as in naval combat.

Ships cannot perform orbital bombardment in the ground combat phase if they fired in the preceding naval combat phase of the same increment.

Each Forward Fire Direction (FFD) component in a formation allows support from a single ship in orbit or up to six ground support fighters. If a ship is providing orbital bombardment support and the formation loses its FFD capability, the ship will try to find another formation at the same population with available FFD.

Orbital bombardment is a powerful aid to any ground combat, although the ships will be vulnerable to hostile STO weapons and require fire direction from the surface. Ships conducting Orbital Bombardment Support will be firing far less than often than a ship conducting general planetary bombardment, but will do so with more accuracy. This is because the ship will be firing on specific targets as directed by ground-based controllers when the right opportunity arises.


Collateral Damage

When ground combat takes place, it may cause collateral damage to the populations involved. This is based on attacks, rather than hits. For example, if you use heavy bombardment weapons, it will have an impact on the population regardless of whether you hit any hostile units. Collateral damage is caused by any weapon that affects ground combat, including close air support and orbital bombardment support.

Collateral damage is not linear with ground combat damage. The effect on the population increases exponentially for ground combat weapons with higher damage. The ‘base component damage value’ (before modification for weapon technology) of each weapon that fires is cubed, then the total damage is divided by 10,000. For example:

An infantryman with personal weapons would generate 0.0001 collateral damage per combat round (damage 1, shots 1)
Light anti-vehicle (damage 2, shots 1) is 0.008
Light bombardment (damage 2, shots 3) is 0.0024
Medium anti-vehicle (damage 4, shots 1) is 0.0 64
Medium bombardment (damage 4, shots 3) is 0.0192
Heavy anti-vehicle (damage 6, shots 1) is 0.0216
Heavy bombardment (damage 6, shots 3) is 0.0648

Putting that in terms of regiments, 1000 infantrymen would generate 0.1 collateral damage per combat round while 50 heavy tanks (about the same size but 2x cost) would generate 1.2 collateral damage, assuming HAV and HCAP. Over ten combat rounds, that will become 1 and 11.2 respectively. To put that in perspective, vs energy weapon fire a construction factory has 20 HP and a research facility has 400 HP.

Once the total damage to a population is calculated, it is allocated as a series of 2-point energy weapon attacks. This is because infrastructure has 2 hit points. A construction factory (20 HP) would have a 10% chance of being destroyed, etc.. In addition to the installation damage, the collateral (energy) damage increases the dust level by 5% of the damage amount and inflicts civilian casualties at the rate of 2,000 per point of damage.

As populations suffer collateral damage, a track is kept of the total size of destroyed installations. Future collateral damage is reduced by (Total Size of Intact Installations / Total Size of Intact and Destroyed Installations). This is to simulate that fighting in the rubble does not cause further collateral damage.

As ground support fighters are involved in close combat, Fighter Pods have a ‘base damage’, equal to their normal damage divided by the weapon tech at the time of creation, which is used for ‘base component damage value’ in the above collateral damage calculation. This brings them in line with ground forces.

Orbital bombardment support is less discriminatory and the base values do not change over time. For example, a higher tech tank will inflict more damage but a 10cm laser is always a 10cm laser. Therefore orbital bombardment support uses 20% of the normal damage vs ground forces as the ‘base component damage value’. Consequently, orbital bombardment will generally cause more much more collateral damage than an equivalent amount of damage from ground-based weapons or ground support fighters.

If attacking forces wish to minimise collateral damage, they will need to restrict the use of heavy weapons and orbital bombardment support. Note that the base component damage value is used on the assumption that higher tech ground units are more destructive but also more precise in their targeting.


Ground Combat Events

Ground combat in C# is very detailed with many things happening in each combat round. There are a number of new events at varying levels of detail to serve as combat reports. Note that a formation (such as an Imperial Guard Regiment) consists of several formation elements, each containing one or more units of a single ground unit class.

  1. Element vs GUC: This is the most granular and reports the results of attacks from one formation element against one type of hostile ground unit class, providing number of shots, hits, armour penetrations and kills. If a formation element engages in combat against five types of enemies, that element will have five Element vs GUC reports

  2. Ship vs GUC. This is similar to the above and reports the results of attacks from a single ship against one type of hostile ground unit class, providing number of shots, hits, armour penetrations and kills. If a ship attacks five types of enemies, that ship will have five Ship vs GUC reports

  3. GUC vs GUC Summary: A summary of the results of attacks from one type friendly ground unit class against one type of hostile ground unit class, providing number of shots, hits, armour penetrations and kills. For example, if there are five friendly types of ground unit class, each of which attack five types of hostile ground unit class, there will be twenty-five reports of this type. This is useful if you want to see how well certain types match-up - are your AT Guns able to knock out hostile tanks for example.

  4. Attack vs GUC Summary: A summary of the results of attacks from all friendly ground forces against one type of hostile ground unit class, providing number of shots, hits, armour penetrations and kills. For example, if six types of hostile types of ground unit class have been attacked by ground forces there will be six reports of this type.

  5. Orbital vs GUC Summary: A summary of the results of attacks from all friendly ships against one type of hostile ground unit class, providing number of shots, hits, armour penetrations and kills. For example, if six types of hostile types of ground unit class have been attacked by ships there will be six reports of this type.

  6. Formation Attack Summary: A list of the type and number of hostile units destroyed by a specific friendly formation

  7. Ground Attack Summary: A list of the type and number of hostile units destroyed by all friendly surface and orbit forces

  8. Element Loss Summary: Reports the results of enemy attacks against a single friendly formation element, providing number of shots, hits, armour penetrations and kills.[

  9. Formation Loss Summary: A list of the type and number of friendly units lost in a specific formation

  10. Ground Defence Summary: A list of the type and number of friendly units in all formations destroyed by all hostile forces

  11. Breakthrough Achieved: Reports that a specific formation achieved a breakthrough

There may be other events as a result of more play-testing. The above may be too granular for some players so you can filter out the events you don’t want to see, or you can see very granular detail for role-playing and AAR purposes.


Fighter Pods and Fighter Pod Bays

In C# Aurora, fighter-sized ships can be equipped with a new component, the Fighter Pod Bay, which is similar in function to a small Box Launcher, except it will only hold Fighter Pods (see below).

Fighter Pods are created on the Missile Design window. The various pod options, such as bombardment pod, autocannon pod and air-to air pod, will appear when the requisite technology has been researched. When one of those options is selected, the warhead strength field is replaced by a pod size field. The player can choose the pod size, with larger pods being more effective. The pod capabilities will be similar to the capabilities of equivalent-sized ground unit components, although the fighter pods have more flexibility in design. For example, a bombardment pod will have three shots, armour penetration equal to Racial Weapon Modifier * ((Tons / 20) ^ 0.6) and damage equal to Racial Weapon Modifier * ((Tons / 20) ^ 1.6).

Fighter pods are ordnance, in exactly the same way as missiles. They are built by ordnance factories, transported in magazines and loaded onto fighters. Unlike missiles, they are not expended when fired and will function during ground combat phases.

A fighter can be designed with fighter pod bays. Different pods can be assigned to those bays while the fighter is in a hangar, providing flexibility of loadout. The same fighter could be used for bombardment or autocannon pods, as long as the pods bays are large enough and the parent carrier has both types of pods available. The pods can be assigned to the fighter using the normal ordnance loadout. The pods require a missile fire control to operate, although this can be minimal size (0.1 HS) as there are no range or resolution restrictions.

Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods. Because of this efficiency, the minimal-size fire control and no requirement for active sensors in ground combat missions, dedicated ground support fighters can be much smaller than their space combat equivalents. It is also possible to have hybrid designs mounting both pods and box launchers. Due to the requirement for smaller engines for dedicated ground support aircraft, ship engines can now be designed from 0.1 HS in size.


Ground Support Fighters

Fighters equipped with fighter pods can provide support to ground unit formations during ground combat.

To be eligible, a fleet with fighters is given an order to “Provide Ground Support” with a friendly population as the destination. This order functions in a similar way to a ‘Follow’ order, with the order remaining in place until removed by the player. On the Ground Combat Window, eligible fleets appear in their own section for each population. These fleets can be dragged and dropped on to formations in the same way as superior and subordinate formations. Fleets with this order that are at their target population cannot be targeted in normal naval combat or by STO weapons.

In combat, the ground support fighters attack at the same time as bombardment elements and have the same target selection options as heavy bombardment.

Ground support fighters have the same chance to hit as ground units, although they are not affected by any negative environmental modifiers (such as high gravity or extreme temperatures). Each fighter’s to hit chance is affected by its own crew grade and morale.

Each Forward Fire Direction component in a formation allows support from up to six ground support fighters. If more fighters are assigned to a formation than can be supported, the chance to hit is modified by (Number of FFD * 6) / Number of Fighters.


Ground-based AA Fire

AA units take part in ground combat normally, using their ground combat values. If an AA unit takes part in both ground-ground and ground-air combat, it will draw supply twice.

Once all direct combat, bombardment support and ground support fire has been resolved, but before damage is allocated, all AA units will be checked to see if they can fire on hostile aircraft, using the following rules:

  1. All AA units in a formation that was directly attacked by aircraft will each select a random aircraft from those that attacked that formation.
  2. Medium or Heavy AA units in a formation that was not directly attacked by aircraft but is the direct parent of a formation that was attacked will each select a random aircraft from those that are attacking the subordinate formations.
  3. Heavy AA units that are not included in the two categories above will fire on a random hostile aircraft, including those on CAP that are not directly engaged in attacking ground units.

An Environment Modifier is calculated, taking into account gravity, pressure and temperature and whether the firing AA unit has capabilities in those environments. Each environment for which the element is not trained has a x2 modifier. There are no terrain modifiers.

The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier.

If a hit is scored, the damage vs the fighter is (Ground Damage Value / 20)^2 rounded down. For example, an AA unit with a ground damage value of 40 would have AA Damage of (40 / 20) ^ 2 = 4.

All AA damage is applied after all attacks have been resolved.


Non-Support Fighter Missions

In addition to the option to directly support ground forces, fighters can be assigned additional missions over the battlefield. To be eligible, a fleet composed only of fighters is given one of the following orders with a system body as the destination. A friendly population is not required. These orders function in a similar way to a ‘Follow’ order, with the order remaining in place until removed by the player. Fleets with these orders that are at their target system body cannot be targeted in normal naval combat or by STO weapons.

Search & Destroy

Search and Destroy involves sending fighters to a planet with enemy ground forces (with or without friendly forces present) to attack targets of opportunity. This is similar to a ground support mission with the following differences:

  1. The fighters do not need to be assigned to a friendly ground formation and do not require fire direction

  2. The fighters will select any hostile formation, regardless of field position

  3. The chance to hit is 33% of normal

  4. Hostile AA will fire as if this is a ground support mission directed against the selected formation

Flak Suppression

Flak Suppression involves sending fighters to a planet with enemy ground forces (with or without friendly forces present) to specifically attack hostile AA units. Because the fighters are seeking out nearby AA units that are engaging them, the chance to hit is higher than for Search & Destroy, but the target selection is more difficult (finding the AA). This is similar to a ground support mission with the following differences:

  1. The fighters do not need to be assigned to a friendly ground formation and do not require fire direction

  2. The fighters will select any hostile formation, regardless of field position

  3. The chance to hit is 50% of normal

  4. Only hostile AA elements will be attacked. If none are present in the selected formation, no air-to-ground attack will take place

  5. Hostile AA will fire as if this is a ground support mission directed against the selected formation, even if the fighters did not open fire


Ground Support Bonus

This is a new bonus in C# for naval officers commanding fighters on ground support, search & destroy and flak suppression missions. The to hit chance is modified by the bonus.

The bonus is also used for orbital bombardment support (explained in a future rules post), with the Tactical Officer contributing 100% of his bonus and the Ship Commander contributing 50% of his bonus.

Damage Control

Damage Control functions in a similar way to VB6 with a few exceptions.

  1. There is no longer any separation between the current damage control assignment and the queue. In C# there is just a damage control queue and the highest priority item will be worked on first.

  2. The ship damage control rating is equal to the total value of engineering, damage control and commercial damage control systems, boosted by five times the Engineering bonus of the Chief Engineer (if one is assigned). So a Chief Engineer with a 20% bonus would double the damage control rating

  3. If the ship being repaired is in a hangar, the damage control rating of the mothership will be added to the damage control rating of the ship and the mothership maintenance supplies will be used first (although they will not be used past the specified minimum level). While this allows the mothership DC rating to be potentially used on multiple ships simultaneously, I decided that was preferable to having repair priorities per ship. The micromanagement isn’t really worth the extra realism.

  4. If the top item in the damage control queue is too expensive to repair (due to lack of maintenance supplies), other items will be checked in order to see if they can be repaired instead.

  5. The percentage chance of repair is equal to ((Increment Length in Seconds / Repair Cost) * Damage Control Rating) / 1000. For example, Geological Survey Sensors cost 100 BP so have a repair cost of 200 MSP. If a ship has a damage control rating of 5 and the increment is one hour, the repair chance for the sensor would be ((3600 / 200) * 5) / 1000 = 9%

  6. All ships have the option to engage Automated Damage Control, in which case the ship will assign its own damage control queue based on the same repair priorities as NPRs

Below is the new damage control tab for the Ship section of the Naval Organization window. The Repair Chance on the rightmost column is the chance for the ship to repair the component in the time specified at the bottom of the screen in the Repair Chance Time text box. SM Repair All is only visible in SM mode and will repair everything, including armour. Auto Queue will queue everything using the automated damage control rules. Clicking the Automated Damage Control checkbox means the ship will automatically queue and repair damage (the queuing is done just prior to damage control in the sequence of play).

Surface-to-Orbit Weapons

A ground unit class has an option to mount a surface-to-orbit component. If this option is selected, the class must also select a weapon type. The weapon can be of any type researched by the owning race, including turrets and spinal weapons. Additional systems will be automatically added based on the weapon chosen, creating an integrated component (similar in concept to CIWS). These systems include:

Beam Fire Control: For normal weapons, this will be created using options for 4x Racial Fire Control Range and 1x Racial Tracking Speed. If the Point Defence Weapon checkbox is clicked, the fire control will be created using options for 1x Racial Fire Control Range and 4x Racial Tracking Speed. In all cases, the beam fire control will have a 25% range bonus vs a ship-mounted equivalent. The cost and size of the fire control will be 50% of the ship version due to its dedication to a single weapon.

Active Sensor: This sensor will be resolution 1 and have range at least equal to the maximum range of the weapon. The minimum size will be 5 tons. The sensor is fully functional and will detect targets in general, not just for the weapon. Size and cost are normal.

Reactor: This component will be designed to generate sufficient power for the weapons capacitor. Size and cost are normal.

ECCM: This is optional and can be added by checking Include ECCM checkbox. Size is 50 tons and cost is half normal to reflect the dedication to a single weapon.

Those ground elements containing units with STO capability can set a number of different targeting options. For the moment, targeting and firing is handled automatically although I may add a manual targeting option as well. For those targeting options directed at ships, the player may also select the number of weapons per target, with zero being all weapons. When a number other than zero is chosen, the targets are cycled until all weapons are fired. Targets must be detected, hostile and in range to be eligible.

The target settings are as follows:

  • Do Not Fire

  • Target Random Ship: Eligible Ships are given a random order and the targeting cycles though them (or targets the first if number of weapons is zero). The targets will be cycled through multiple times if required for all weapons to fire.

  • Target Largest Ship: Eligible Ships are arranged in descending order of size

  • Target Smallest Ship: Eligible Ships are arranged in ascending order of size

  • Target Fastest Ship: Eligible Ships are arranged in descending order of speed

  • Target Slowest Ship: Eligible Ships are arranged in ascending order of speed

  • Target Easiest Ship: Eligible Ships are arranged in descending order of chance to hit

  • Target Shipyards: The largest eligible shipyard contact is targeted

  • Target Populations: The largest eligible population contact is targeted. Populations on the same system body as the STO element cannot be targeted.

  • Target Ground Forces: The largest eligible ground forces contact is targeted. Ground forces on the same system body as the STO element cannot be targeted.

  • Target STO Ground Forces: The largest eligible STO ground forces contact is targeted. STO ground forces on the same system body as the STO element cannot be targeted.

  • Final Defensive Fire: When a salvo is about to hit a target within range of the STO weapon, the element will be eligible for point defence fire in the same way as a ship. This allows the STO element to protect itself and other ground forces, any populations on the surface, orbital shipyards and any nearby ships.

  • Final Defensive Fire (Surface Only): Same as Final Defensive Fire except that only salvos attacking surface targets will be intercepted

  • Area Point Defence: The STO units will shoot at any hostile missiles currently in range.

When an STO element targets missiles, it will only fire until the missiles are destroyed. For the purposes of tracking weapon fire and recharging, each STO unit within the element is tracked separately.


Naval Bombardment of Ground Forces in Naval Combat Phase

Ground forces can be bombarded by naval forces as part of normal naval combat. Note this is not the same as Orbital Bombardment Support, which involves ships in orbit working in conjunction with ground forces to deliver precision energy weapon strikes:

Instead, Naval Bombardment of Ground Forces (NBG) is a mass bombardment of ground-based sensor contacts using either missile weapons or energy weapons, which does not require friendly ground forces on the target body or fire direction support and is an adjunct to Planetary Bombardment:

For the purposes of bombarding ground forces, each weapon type on each ship is treated separately for targeting purposes. For example, a ship with both 10cm and 15cm railguns would make two separate rolls to select a target formation, one for each weapon type, and therefore target all weapons of the same type on the same formation. Target formations are selected based on a weighted random roll, with the weighting based on formation size. Once a formation is selected as a target, each shot against that formation selects a random element within the formation, again using a weighted random roll.

Ship using energy weapons for NBG have one third of the chance to hit compared to using Orbital Bombardment Support (as in the latter case they are being directed by FFD units) and do not benefit from any ground support bonus from the ship commander or tactical officer. Their to-hit chance is the base ground combat to hit chance (20%), reduced by two thirds, multiplied by the to-hit modifier of the planet’s dominant terrain and divided by both the fortification of the target formation elements the and fortification modifiers of the planet’s dominant terrain. In summary, blind-firing energy weapons at general concentrations of enemy forces is not a very effective way of destroying them, especially in difficult terrain, although it can be done given sufficient patience and maintenance supplies. When firing at Detected STO units, the two-third reduction in to-hit chance is not applied, as the STO units have given away their general location.

Ships using missiles for NBG have a 100% base chance to strike their targets, as nuclear warheads require considerably less precision than energy weapons, and may hit multiple targets. This is modified by the to-hit modifier of the planet’s dominant terrain and divided by both the fortification of the target formation elements and the fortification modifier of the planet’s dominant terrain. One attack is made with the missile’s full warhead damage. Two attacks are made with one half damage, four attacks with one quarter damage etc. This division continues while the damage is higher than 1 point of warhead strength. Each of these attacks can also hit multiple smaller targets, such as infantry. The number of sub-attacks is equal to 50 / target size.

This means that a single 8 point missile warhead targeted on infantry will make 15 attacks (1 + 2 + 4 + 8) and each attack will be directed against 10 units, for a total of 150 infantry attacked. However, bear in mind that if the infantry are fortified normally that will reduce the normal 100% chance to hit by a third. If they have help from construction units and are in difficult terrain such as mountains, the chance to hit could be much lower so many of them could survive the attack. Missiles also cause environmental damage so if you plan to use the planet afterwards, this may not be the best approach.

The ground combat damage for an naval weapon is equal to 20x the square root of the damage at the same range in ship-to-ship combat. Armour penetration is equal to half the that damage. Fractions are retained. For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17.3/34.6 for a 10cm laser, 30/60 for a 9-point missile warhead, 40/80 for a 25cm laser. Weapons roll for failure in the same way as in naval combat.

Any weapon used for NBG has the same environmental impact as it would for planetary bombardment. Missile warheads cause radiation and dust levels to increase by an amount equal to their warhead size. Energy weapons increase the dust level by 5% of their damage amount and have no effect on radiation.

Each NBG shot has a one third chance to also strike the population itself, inflicting installation damage and population losses accordingly (see Planetary Bombardment link above for details). Conversely, each energy weapon or missile used for general Planetary Bombardment attack has a one third chance to also attack any ground forces on the planet (using the above rules), regardless of whether those ground forces have been detected. Note that all the to hit modifiers vs ground still apply so the chance of accidentally hitting any ground unit with an energy weapon for example is still very low.


Planetary Bombardment

In C# Aurora, populations can be attacked by missiles and energy weapons. However, because missile warheads are area-effect weapons, they are much more effective at destroying the civilian population and any installations.

Each installation type has a Target Size. The chance of each attack (either a missile or a single energy weapon) destroying an installation is equal to: Weapon Damage / Target Size. For example, a construction factory has a Target Size of 20, so a 10cm laser fired from orbit would have a 15% chance to destroy the target (3 / 20). For the purposes of this check, missile warheads are treated as equal to 20x warhead strength. Therefore, a single 1 point warhead has a 100% chance to destroy a construction factory.

A single energy weapon can destroy only one target per hit. A missile warhead is applied until all damage is used. For example, a 5-point missile warhead is counted as 100. If the first installation hit is a construction factory, that factory is destroyed and the remaining damage reduced to 80. That damage is then applied the next installation hit and so on.

Missile warheads cause radiation and dust levels to increase by an amount equal to their warhead size. Energy weapons increase the dust level by 5% of their damage amount.

Missile warheads inflict civilian casualties at the rate of 100,000 per point of damage. Energy weapons inflict civilian casualties at the rate of 2,000 per point of damage.

Populations will no longer surrender purely due to orbital bombardment. You have to land ground formations to force a surrender.

Energy weapons now provide a way to destroy the industry and infrastructure of a target population, without causing radiation or using up ordnance. However, this will require considerable effort for a large population and consume maintenance supplies due to weapon failures. It will also bring you within range of any ground-based energy weapons. Of course, it will usually be more beneficial to conquer the planet and gain the installations instead of destroying them.

Automated Medal Awards

In terms of basic concept, Medals in C# have a similar function to VB6. You can create a medal with a name and description, associate a medal image and assign a promotion score boost (or penalty). You can assign that medal as desired to different officers for role-playing reasons. A minor addition for C# is that you can flag a medal as allowing only a single award, or allowing multiple awards.

The major change for C# is that medals can now be assigned automatically. A lengthy default list of conditions for medal awards will be available and, within the constraints of the available measurement types, additional conditions can be added. Medals can be associated with one or more conditions and the medal will be awarded if a commander meets one of those conditions (unless it is a single-award only and the commander already has it).

This first screenshot shows the Medal Window, with the first medal on the list selected. At the bottom of the window are options for changing text or image, setting promotion score and the multiple award flag and adding/removing conditions for the medal.

The second screenshot shows a list of available conditions. This is only an initial list to show examples of what is possible. All these conditions are already working. I will also add to this window the ability to create new conditions. They will have to use one of the existing measurement types, but you can choose different measurement amounts. This thread is open for suggestions of different measurement.


Manual Medal Awards

The previous post on medals covered automated medal assignment. This covers manual awards, for which there are two options:

  1. An award to an individual commander on the Commanders window using the Award Medal button (as per VB6).
  2. Mass Awards to large numbers of commanders at once, primarily for the purposes of ‘Campaign Medals’.

On the Fleet window, you can select a Ship, a Sub-Fleet, a Fleet or a Naval Admin Command and click Award Medal. The following window pops up:

You choose the medal and the type of command positions to which the medal will be awarded. Every commander with a command included in the selected types that is on a ship included in the selected organisation will be awarded the selected medal. This would include commanders of any ground formations present on the ships if that command type is selected. If a fleet is selected, all ships in the fleet are included, including any in sub-fleets. If an Admin Command is selected, every ship in the complete hierarchy of that Admin Command will be selected. Mass Awards use a confirmation popup after you close the Medal Award window, as a mistaken mass award would require some sorting out :)

On the Naval Forces window of the Galactic Map there is an Award Medal button. This will pop up the same Award Medal window. The selected medal will be awarded to every commander with one of the selected command types in the system currently selected on the Galactic map, including commanders of ground formations at populations in the system if that command type is selected.

On the Ground Forces window in the Order of Battle tab are two new buttons; Formation Medal and Hierarchy Medal. Formation Medal functions in a similar way to the Award Medal on the Commander window. The medal is awarded to the single commander of the currently selected formation. Hierarchy Medal is a Mass Award option with two functions, depending on whether a formation or a population is selected. When a formation is selected, the mass award is to all commanders in the downward hierarchy of the currently selected formation, included the commander of the selected formation. When a population is selected the mass award is to the commanders of all formations at that population.

When awarded medals manually, a popup box will appear after the medal is chosen, allowing you to enter an optional medal citation. This citation will appear if you mouse-over the medal in the commander view.

This new Mass Award option should result in a much more visual history of different commanders with the display of their various campaign medals.


Ship Achievements

All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded. Currently the recorded ship achievements include the following:

Hostile Ships Destroyed
Military Shipping Tonnage Destroyed
Commercial Shipping Tonnage Destroyed
Hostile Missiles Destroyed
Ground Forces Tonnage Destroyed
Armour Damage Taken
Internal Damage Taken
Star Systems Discovered
Ruins Discovered
Bodies With Minerals Discovered
Jump Points Discovered
Habitable World Discovered
Combat Drop - Transport
Tons Salvaged
Stablisations Completed

The ship total for each of the above is displayed on the Ship Design Display tab, under the Ship Overview tab on the Naval Organization window.

EDIT: If a ship has an assigned mothership, the parasite still gets the credit, but the assigned mothership receives a separate credit flagged with (SG) for strike group. Separate achievement entries are shown for the carrier itself and the strike group, even if they are the same achievement. So if a Battlestar has destroyed 10,000 tons of shipping directly and its Vipers have destroyed 20,000 tons, the achievement list for the Battlestar will show:

Military Shipping Tonnage Destroyed: 10,000 tons
Military Shipping Tonnage Destroyed (SG): 20,000 tons.

Electronic Intelligence Gathering

A new concept in C# Aurora is ELINT, or Electronic Intelligence Gathering. This is performed by a new line of ship components, the Electronic Intelligence and Analysis Modules. These start at strength 5 and follow a similar strength progression to EM Sensors. One of the prerequisites for each module is the corresponding EM Sensor strength technology.

The ELINT Modules are 10 HS, require 15 crew and cost 20x their strength (this is subject to change as a result of play test). They have a secondary function as an EM Sensor, although a dedicated EM sensor of the same size would be far more effective. Their primary function is to gather electronic and signals intelligence on alien populations and active sensors (and I will add ground forces at some point). Increased strength, through research or multiple modules, can increase the range at which intelligence is gathered but the base rate is fixed. Multiple ships cannot increase the intelligence gathered from a single source, although a single ELINT module can gather intelligence from multiple sources.

If the target can be detected by the ELINT modules’ built-in EM Sensors, intelligence can be gathered. The rate is 1 intelligence point per day, boosted by the Intelligence bonus of the ELINT ship commander. For populations, the intelligence is also multiplied by (100 - Population Species Xenophobia) / 100. In other words, it is much harder to gain intelligence when a population has high xenophobia. If the alien language is not translated, all intelligence is reduced by 80%.

Intelligence is gathered per population and per active sensor design (if multiple sensors of the same type are monitored, you only gain intelligence at the same rate as one sensor). Specific alien sensors will now be associated with specific alien classes.

Alien active sensors will initially be displayed with just a strength and not a range or resolution. Once 100 intelligence points have been gathered for a particular design of active sensor, its range and resolution will be displayed. Note that in VB6 you only have an approximation of the alien sensor range. I plan to add active jammers and passive stealth capability, both of which will become more effective against alien sensors based on the intelligence gathered on those sensors (no limit to intel points). I’ll provide the detail for this when I post the jammer and stealth rules.

Alien populations will be initially be displayed as they are now, with EM and thermal signatures. Once 100 intelligence points have been gathered, the population size in millions and the number of installations will be displayed. Additional information becomes available at higher intelligence levels:

200 Points:
Number of factories and mines and whether a spaceport and/or a cargo shuttle station are present.

300 Points
Number of refineries and maintenance facilities and whether a refuelling station and/or an ordnance transfer station are present.

500 Points
Number of research facilities and ground force training facilities and whether a naval headquarters and/or a sector command are present.

The intelligence points for a specific population will reduce at approximately 25% per year if ELINT monitoring ends. The information that was gained while intelligence points were at their highest point will remain and is shown in red when viewing the alien population on the Diplomacy window. Current information is shown in green.

Any intelligence gained on a population is also used at the racial level for the purposes of espionage. Each Alien Population Intelligence Point adds one Alien Race Intelligence Point. If the population is less than 100m, the translation of Population Intelligence to Race Intelligence is modified by Population in millions / 100. When 100 Alien Race Intelligence Points have accumulated, a check is made for any intelligence gained. This is the same check as in VB6 for espionage teams and can result in new technology, survey data, new system knowledge or details of an enemy ship class. I will probably add information on alien sensors, ground units and populations to that list.

As a result of these changes, espionage teams have been removed from C# Aurora.

A couple of design examples for the ELINT Module


Interrogation of Survivors

In VB6 Aurora, you can gain espionage points from interrogating the survivors picked up from life pods. In C# Aurora, the same principle applies, although they are now Race Intelligence Points and are added to those gained via ELINT.

The rate at which Race Intelligence points are gained from survivors is Crew / 10 + the cube of the rank number of any captured officer (so R3 would provide 27 points). This is more important than the same algorithm in VB6, because there are now potentially multiple officers per ship.

However, unlike VB6, this point gain is reduced if the survivors are from a non-hostile power. The intelligence points gained from neutrals is halved, friendly reduced by 80% and allied by 90%. This is to simulate that aggressive interrogation is unlikely to be used against survivors from a friendly power.

As with other intelligence gains, there is a further 80% reduction if the alien language has not been translated.


Alien Ground Unit Intelligence

As you fight alien ground forces, you will gain intelligence on the alien ground unit classes. This intelligence is displayed on the Diplomacy and Intelligence window alongside intelligence on alien ships, classes, sensors and populations.

For each different type of ground unit class you engage, you may gain intelligence if you have your own ground forces on the same ship or system body. New intelligence is gained under the following circumstances.

  • If the alien unit fires on you, you will gain intelligence on its weapons

  • If you score twenty hits on that type of unit, you will identify its base type (infantry, light vehicle, etc.)

  • If you penetrate the armour of that type of unit twenty times, you will learn its armour strength

  • if you destroy twenty of that type, you will learn its hit points


Ground Combat Hostile Force Intelligence

This post covers intelligence regarding the size and composition of the hostile force in a given ground combat zone. After each combat round, an update is provided on the estimated hostile force. The estimate becomes more accurate as time passes. For each type of hostile ground unit om the combat zone, the following process is used:

The Intel Error Range is 200 / Number of Combat Rounds.
Intel Error is 1 + (Random (Intel Error Range) / 100);
50% of the time, the actual number of alien units is multipled by the Intel Error and 50% of the time the actual number of alien units is divided by the Intel Error.

For example, if there are 1000 units of a particular alien class, the intelligence following the second combat round could indicate between 500 and 2000 units. After 10 combat rounds, the intelligence reporting range will be 833 to 1200 units.


Group Contacts
Similar contacts can be grouped in C# Aurora. This is done via a checkbox on the Tactical Map sidebar entitled ‘Group Contacts’. This is similar in concept to the ‘Hide Active IDs’ in VB6 Aurora but implemented a little differently.

When Group Contacts is active, any contacts with the same alien ship type, the same current coordinates, the same coordinates from the previous increment, the same active sensor emissions and the same contact status will be grouped together. The 001, 002, etc. suffix of the normal contact string will be replaced with a prefix showing how many contacts in the group. If there is only one contact in a location, the grouping is ignored and the normal contact information is displayed. The difference is shown below:


Lost Contacts

The ‘Lost Contacts 1 Month’ checkbox will update the tactical map to display any ship contacts less than one month old, rather than the default of current contacts only. This is more sophisticated than the VB6 equivalent and will also provide more information on current contacts where available. For example, you may be currently tracking an alien ship by its thermal emissions only, but you had an active contact a week ago. When Lost Contacts is active, you will see both the current thermal contact combined with the older active contact.

Any ship contact that is only visible because of the lost contact option will display [LOST] after the contact information. A ship contact with a combination of current and older information will display [PARTIAL] after the contact information.

There is also a ‘Lost Contacts 1 Year’ checkbox, which functions exactly as above except for the period of time. If both boxes are checked, one year takes priority.

Here is a section of my current system map with and without the Lost Contacts option active. The Hegemony of Titan ships near the bottom only appear when Lost Contacts is active. The Venusian freighters at the top left are present in both screenshots, but have more information available when Lost Contacts is active

Lost Contacts can be combined with Group Contacts. Here are two screenshots of Martian ships in orbit of Mars with Group Contacts active. Lost Contacts is active in the second screenshot.

Boarding Combat

Boarding combat in C# Aurora is similar in principle to VB6 Aurora with some adjustments for the new ground combat mechanics. The boarding attempt process is as follows:

  1. Only a ship with a boarding-equipped troop transport bay can be ordered to make a boarding attempt

  2. Only formations that consist entirely of infantry can take part in a boarding attempt

  3. Boarding attempts cannot be made against ships that are faster than the ship making the boarding attempt

  4. A fleet given the ‘Attempt Boarding Action’ (for a specified formation) or ‘Attempt Boarding Action All Formations’ will attempt to end its movement in the same location as the target ship. If that happens, a boarding attempt will be made.

  5. The percentage chance of each individual unit (soldier) conducting a successful boarding attempt is equal to 10% x (Boarding Ship Speed / Target Ship Speed). So if the boarding ship is 10x faster than the target ship, success is automatic.

  6. Any unit with a ‘Boarding Combat’ capability has double the normal chance of success. In this case, if the boarding ship is 5x faster than the target ship, success is automatic.

  7. Any units that do not make the successful attempt are killed. If an HQ unit is lost, there is a chance the formation commander is killed based on (1/Number of HQ units), which is an automatic kill result if only one HQ exists

Once on the target ships, the surviving attackers will move inside if there is a hole in the armour. If there is no hole, the boarders will use a breaching charge to destroy one armour at the weakest point every thirty seconds until they gain access.

Once inside the target ship, a boarding combat round is conducted every sixty seconds. This is very similar in principle to ground combat, albeit without support artillery, aircraft, etc. and with no concept of front-live vs rear. There is no ‘fortification’ in the ground combat sense, but the defenders are given a fortification level of 2 to simulate the advantages of defence within the ship. Also, because this is a confined space and there are likely to be fragments of formations, each individual unit on each side randomly selects a target formation element on the opposing side, using a weighted random selection based on size, and conducts an attack using the normal ground combat procedure:

The commanders of each formation provide a bonus to hit with their Ground Combat Offence bonus and provide a bonus to fortification (base fortification is 1 on attack and 2 on defence) with their Ground Combat Defence bonus. Any units on either side with ‘Boarding Combat’ capability have double the normal chance to hit.

For the purposes of boarding combat, the crew is a temporary formation with a single element composed of ‘crew’ ground units and a morale equal to the current crew morale. A crew member is equipped with light personal weapons and has ‘armour’ equal to half the lowest racial armour for infantry. Casualties in this temporary formation translate into crew losses and morale losses translate into the same impact on crew morale. Given that the crew is not well equipped for a fight of this type, it would advisable for ships to carry a small marine detachment if there is a chance they may face boarding attacks. If the target ship is a carrier, formations based on parasite ships will fight to protect the mothership.

If all the defending units are killed, the ship is transferred to the new owners (I may also add some surrender rules so you don’t need to kill all the crew). To simulate the difficulties in making use of a captured ship, especially as the defenders have no doubt locked out the controls and sabotaged whatever they can, the captured ship is treated as if it just abandoned an overhaul and is given an overhaul factor of 0.01.

If a ship is captured, the associated Alien Class is updated with complete information.

Collateral damage can occur during boarding combat using the same rules as for ground-based collateral damage. All the damage is applied to the ship as a single internal hit. Because of the relatively small-scale of shipboard combat, any fractional points of collateral damage have a percentage chance of becoming full points equal to (fractional damage / 1). Damage to transport bays due to collateral damage will not kill defending troops (as they are fighting on the ship and not located in the bay).

If a ship is struck by external damage during boarding combat and one or more components are destroyed, there may be casualties among the boarding combatants on both sides. The damage to each engaged element is equal to:
(destroyed component size / ship size) * (0.25 + (Random(10) * 0.05))

The random roll is made for each element separately.

New Spoiler Race

C# introduces a new optional spoiler race - the Rakhas.

The Rakhas are the remnants of an ancient civilisation that once had colonies across the galaxy. Their populations were virtually wiped out and the tiny number of survivors have regressed to a primitive, tribal lifestyle, although they retain some elements of Trans-Newtonian technology. The Rakhas have no ships and are confined to planetary surfaces, with each remnant colony effectively a different race with potentially different levels of technology. These populations consist only of ground forces with no ‘civilian’ population and due to the ancient history of alien invasion the Rakhas will resist any invader. The Rakhas are large, heavily-muscled humanoids with skin colouration ranging from green to grey.

Their surviving technology is sufficient for Trans-Newtonian infantry and mechanised forces. Some Rakhas tribes will also retain STO weapons. The ancient Rakhas experimented with genetic modification during their final wars, so some tribes will retain genetic advantages for combat and all tribes will be familiar with warfare in the dominant terrain of their home world (desert fighting, jungle fighting, etc).

The Rakhas have wider environmental tolerances than humans and their colonies were generally created on worlds with large quantities of accessible TN mineral deposits. Therefore, the remnant tribes will usually be encountered on worlds with oxygen atmospheres that posses multiple accessible mineral deposits. There is a small chance that a tribe may have survived on a hostile world.

Orbital bombardment is an option to wipe out the Rakhas, although as the planets that Rakhas tribes inhabit will generally be valuable in terms of habitability and resources, any attacker may wish to avoid catastrophic damage to the environment.


Human NPRs

C# has a new option for NPR generation called Human NPRs. If this option is selected, when a NPR is generated (except for Starting NPRs) there is a one-third chance that a check is made to see if the NPR is ‘human’. ‘Human’ in this context is the species of the oldest population of the oldest player race. This is because you may want to play as a non-human race, or modified human race, and still retain the option of your species appearing as an NPR.

If the check is made and the system body is capable of supporting humans, then the species of the new NPR will be human. Human NPRs will generally be smaller (on average about half the size) of normal NPRs. You also gain +20 to communication checks when two races have the same primary species.

This option is to allow a campaign taking place in the aftermath of the collapse of a large human Empire. As the Empire, or one of its major populations, expands once again, human remnant populations may still be found in distant systems.


Surrender

An AI fleet may surrender to the enemy in certain circumstances. Generally, the fleet will have to be unarmed, badly damaged or not capable of fulfilling its mission and also be under attack from energy weapons.

In that situation, the fleet may try to evade, it may surrender or it may attempt to ram. The chances of each will depend on the Determination and Xenophobia of the crews. Certain spoiler races will not surrender.

When a ship surrenders the Overhaul Factor is set to 0.01, the same as a ship captured by boarding.


New Species Attributes

Each Species now has four new attributes, all of which default to 1.0 but have a low chance to be higher or lower:

  1. Population Growth Rate Modifier
  2. Population Density Modifier. This affect max population capacity, infrastructure

capacity and orbital habitat capacity. Some species prefer more open environments while some can accept higher population densities than normal.
3) Research Rate Modifier (increases or decreases research rate)
4) Production Rate Modifier (affects factories, refineries and shipbuilding)

Player-created Species can have custom values set. Also note this is at the species level, not the empire level. Empire modifiers to Research or Production are based on technology rather than innate ability.

Wealth Generation

In VB6 wealth generation is based on total population. Therefore some real-world nations with large populations (which I use in multi-race starts), generate a lot of excess wealth, even though in reality their wealth output is more in line with their industrial output. India is a good example of this situation. VB6 tries to solve this by having an option to set lower starting wealth per capita for a nation. However, that penalises the race throughout the whole game. In addition, conventional starts generate huge wealth excess as the population is initially producing wealth with minimal industry to consume it.

For C# Aurora, wealth is produced only by workers in TN installations, simulating that wealth is more closely tied to industrial potential than total population. Each 1 million workers produces a baseline 100 wealth per annum, although this can be improved by a new Wealth Generation tech line that replaces the VB6 Civilian Economy tech. This wealth is generated regardless of whether the installation to which the workers are assigned is currently building or producing anything. Wealth Generation tech starts with 120 wealth per million workers for 3000 RP, then 140 for 5000 RP, etc.. Workers in Conventional Factories and Forced Labour Camps do not produce wealth.

Financial Centres generate additional wealth equal to the tax from 250,000 workers (I may adjust this based on play test). Financial Centres can be transported to other colonies (unlike VB6). In addition to their other output, Conventional Factories function as 1/10th of a Financial Centre. Conventional Factories can be converted to Financial Centres at a cost of 20 BP, using 10 Corbomite and 10 Uridium. It is also worth noting here that tax generation from shipping lines has been doubled for C# Aurora.

The C# method has a few advantages over the VB6 method:

  1. High population, low industry nations are now easy to handle as most of the population does not generate wealth (it is assumed that the wealth from agriculture and service is used to cover welfare, health, education, etc. with a net wealth of zero).
  2. Conventional starts do not generate huge excess wealth
  3. As a nation industrialises, its wealth generation capability grows naturally, which reflects historical trends.
  4. The planned wealth reserve cap can be removed.
  5. Financial centres grow in importance and have more of a wealth impact (in relative terms) compared to VB6.

>br>

Maximum Wealth Balance

In Conventional Start games, races often build up a huge wealth reserve due to a lack of costs. This removes wealth as a consideration for many years and takes away meaningful decisions.

Therefore, in C# Aurora, a race’s wealth balance can never exceed double the annual wealth. Any excess beyond that is assumed to be spent on improving the lives of its citizens.


Manufacturing Sector

The maximum service sector size has been reduced from 75% to 70%. The effect of this is an increase in the manufacturing population by 5% of total population. For a population on a colony cost zero world with max service sector (a home world for example), the manufacturing sector will be 25% of population, rather than 20%.

This change is because of the increased worker requirements for shipyards, plus the increased need for financial centres and maintenance facilities. I considered lowering the starting numbers of factories, but decided to maintain the existing balance and free up more population instead. Otherwise, the standard start will generally have a manufacturing efficiency problem.


Orbital Mining Modules

Asteroid Mining Modules in VB6 are replaced with Orbital Mining Modules in C#.

Each race has a new tech line called Maximum Orbital Mining Diameter. The starting tech is 100 km and each additional tech increases the size of the body that can be mined (125 km, 160 km, etc.). The tech line finishes at 500 km. Any system body, including asteroids, comets, moons and small dwarf planets, that falls within this diameter can be mined using Orbital Mining Modules. This does mean that some asteroids will be too large for orbital mining.

The population summary shows parent body diameter and eligibility for orbital mining. On the system view, you can flag those bodies that are eligible for orbital mining. On the Mineral Search window you can choose to filter on eligible bodies.


Mineral Search Window

The new version of the Mineral Search window. This should be more flexible than the VB6 version as you can specify minimum amounts and accessibilities for every mineral, plus the amounts are now nicely lined up so it is easier to compare different bodies. The window will order by the mineral with the highest minimum amount. The filter apply in left to right order, so if you specify gas giants only, it doesn’t matter what you specify for asteroids.

For example, here are all bodies with at least 1000 tons of Duranium with 0.3 accessibility or higher.

Here is the same but with the added requirement of at least 1 ton of Sorium.


Mineral Search Flag

A new option on the galactic map allows you to mark individual systems with a “Mineral Search Flag”. There is a display option to show which systems have been flagged.

On the Mineral Search window, you can restrict the search to systems with the flag set, in conjunction with the existing filters.

This will allow you to search for mineral deposits within a subset of systems, in addition to the current options of a specific system or all systems.

Communication Attempts

There are two additional constraints on attempting communication with alien races in C# Aurora.

  1. Translation checks will only take place if both sides have a status of “Attempting Communication”. In other words, you can’t translate their language if they refuse to talk to you.

  2. For translation checks to happen, both sides must have ships and/or populations in the same system and both sides must be able to detect the other. Detection in this context is Thermal or EM for populations and Active for ships. So you must effectively announce your presence and stay there if you wish to attempt communication (or show the aliens the way to another system for communication attempts).

The highest Communication bonus of any commander of a ship with a Diplomacy module in one or more of the contact systems will boost any positive results achieved through the communication process. If no Diplomacy module is present in any of the contact system, any positive gains are halved.

This should add more realism and a little more tension to first contact.


Diplomacy Part 1: Basic Framework

This post replaces the previous post on the Diplomacy module and covers the basic framework for Diplomacy in C#. Future posts will provide more detail, such as territorial claims.

Diplomacy Module
The Diplomacy Module is new for C# Aurora and replaces Diplomatic Teams. It also affects communication attempts. The module is 30 HS, costs 300 BP and requires 50 crew. The minerals required are Corbomite, Mercassium and Vendarite. It is a starting technology in both TN and conventional starts.

Communication
For communication checks to take place both sides must have ships and/or populations in the same system and both sides must be able to detect the other. Communication checks will only take place if both sides have a status of “Attempting Communication”. In other words, you can’t translate their language if they refuse to talk to you. Diplomacy cannot take place until full communication is established. Alien races may take exception to your presence in this situation, based on a number of factors will be covered in a future post.

For communication attempts, the highest Communication bonus of any commander of a ship with a Diplomacy module in one or more of the contact systems will boost any positive results achieved through the communication process (which is otherwise the same as VB6). If no Diplomacy module is present in any of the contact systems or the commander has no communication bonus, any positive gains toward full communication are halved.

Basic Diplomacy
Basic diplomacy follows similar principles to VB6 Aurora. Actions by each side generate positive or negative diplomatic points. As the total of diplomatic points goes above or below certain thresholds, high level treaties (trade, sharing of data, etc.) are put in place and the general level of cooperation changes (hostile, neutral, friendly, allied).

The primary method of generating diplomatic points is via the Diplomacy module. The module must be located in a system where the target alien race has ships and/or populations and both sides must be able to detect the other. Diplomacy can only take place when full communication has been established. The highest Diplomacy bonus of any commander of a qualifying ship is used. The number of points generated per year is as follows:

Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * 100 * (1 – (Target Racial Xenophobia / 100))

For example, an officer with 20% Diplomacy trying to influence an alien race with Xenophobia of 40 would have the following calculation: (((0.2) * 4) + 1) * 100 * (0.6) = 108 Points.

If there is contact but no Diplomacy module in a contact system or the commander has no Diplomacy bonus, then no points are generated from this process (although other factors may generate points - covered in a future post).

If there is no contact at all, even via civilian ships, then Diplomacy Points will move toward zero, from either direction. The annual rate of change is the Xenophobia of the viewing race when the starting point is positive and 100 – Xenophobia when the starting point is negative. For example, the view of a race with 25 Xenophobia will only fall 25 points when the starting point is positive but will rise by 75 points when the starting point is negative. Low Xenophobia races are quicker to forgive transgressions and vice versa.

Existing treaties or diplomatic statuses will improve relationships over time. Different treaties have a base influence that is measured in diplomatic points per year multiplied by (1 – (Racial Xenophobia / 100)). For example, a trade treaty has a base influence of 100 diplomatic points per year. If two races have respective Racial Xenophobia of 30 and 60, then while a treaty is in place the view of the first race will improve by 70 diplomatic points per year while the view of the second ace will improve by 40. It takes longer to build trust with higher Xenophobia races.

Trade, Geological and Gravitational treaties all have a base influence of 100. A research treaty has a base influence of 200. A diplomatic status of friendly has a base influence of 100, while a diplomatic status of allied has a base influence of 200.

Positive and Negative diplomatic points will be gained through other events, many of which will be defined in future posts. An example of a negative impact is combat. Negative diplomatic points are suffered due to damage inflicted by an alien race using the following rules:

Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01

If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point. However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral. For example, if communications are established you may ask a survey ship to leave your system (mechanics in a future post). If that didn’t work or you did not have communication, you can slightly damage that ship. An unarmed ship would retreat from hostile aliens and the immediate impact would be the alien race treating you as hostile. However, with no further combat in the short term, the status would soon return to a wary neutrality. Future communication and diplomacy would still be an option. Larger wars are harder to resolve but peace treaties will be covered in a future post.

I know that “future posts” are mentioned several times, but I wanted to lay out the basic framework so I can build upon it.


Diplomacy Part 2: Intrusion into NPR Territory

In each construction phase, each NPR will determine a value for each known system. In order of ascending importance, the values are: Alien Controlled, Neutral, Claimed, Secondary, Primary, Core, Capital. The value is calculated on a number of different factors, including existing population and installations, whether it is a logistics node, mining potential, terraforming potential and proximity to other important systems. Neutral is the default state for a system in which the NPR has no current interest, while Alien Controlled is a system which the NPR acknowledges is in the territory of another race as a result of accepting a claim from that race (see Part 3).

If you have forces or a population in a system that has at least Secondary value to an NPR, you are detected and you are currently viewed as neutral or friendly, the NPR will issue a warning which will appear as an event. This will still happen even if you haven’t detected any NPR forces. You will be notified which fleet or population received the message. If communication has not been established, you will receive notification of an “unintelligible communication of unknown origin”. If you have established communication, the text will reflect the severity of the situation.

This communication can be as mild as a suggestion that your forces leave in the near future and as strong as demanding you depart immediately or be fired upon. There are five levels of severity for messages and the one chosen by the NPR primarily depends on the ‘Threat Level’ (see below), although it may also issue a stronger warning at lower threat levels if the NPR believes that war will soon follow without a player withdrawal.

The threat level is based on three factors; the NPR’s estimate of the value of the system, any status modifiers due to the existing diplomatic relations and the Xenophobia of the NPR. This is calculated as follows:

Threat Level = Base Threat Level * Status Modifier * (Racial Xenophobia / 100)

Base Threat Level
Secondary = 2.5
Primary = 5
Core = 10
Capital = 20

Status Modifiers
Friendly Status = 0.5
Neutral with Diplomatic Points >= 1
Neutral with Diplomatic Points < 0 = 2

In addition to the messages, the threat levels generate a negative impact on diplomatic relations. The penalty in diplomatic points for intrusion into NPR territory is based on the Threat Level above plus the ships and population that the NPR can detect. The calculation for the annual point penalty is as follows:

Diplomatic Point Penalty = SQRT(Total Detected Ship Tonnage + (Total Detected Population EM Signature * 10)) * Threat Level

Each construction phase, the diplomatic penalty applied is equal to the annual penalty multiplied by (Construction Phase Length / Year)

Shipping Line vessels will be ignored for this purpose if a trade treaty is in force. NPRs will treat ships without military engines that have not demonstrated any weapon capability as 10% of their normal tonnage. If at least one ship is detected, the minimum rating for Detected Ship Tonnage will be 1000 tons. If at least one population is detected, the minimum rating for Population EM Signature will be 100. NPRs deduct 10,000 tons from the tonnage of one Diplomatic Ship (see Part 8) per system for threat purposes if that class type has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it is not treated as core for this purpose.

This table shows the diplomatic point penalties for different ship tonnages in different value systems, assuming an NPR Xenophobia of 50. For populations, use EM Signature * 10 for ‘Tonnage’.

The warning message is issued during the first construction phase after detection and repeated during each subsequent construction phase where the violation still exists. Allied Races do not receive warnings as they can freely enter the NPR territory. Hostile races do not receive warnings as they are attacked instead. Trading will allow some exceptions to the rules above and I’ll cover that in a future post. I will also cover situations where the NPR considers claiming a system with a large existing player population in the ‘Alien Controlled’ update.


Diplomacy Part 3: Claiming Systems from NPRs

In the same way that NPRs can warn players to leave a system, a player can warn an NPR. On the Intelligence and Foreign Relations window, there is a tab for Known Systems for each NPR. You can select a system and then set a ‘Protection Status’ for the selected system in connection with the selected NPR. Alternatively, you can set a protection status for the system on the galactic map and that status will be set for any alien race when they are first detected in the system. The six statuses are shown below with their ‘Demand Number’ (0-5) and their ‘Demand Strength’.

Protection Status
0. No Protection 0

  1. Suggest Leave: 1
  2. Request Leave: 1.41
  3. Request Leave Urgently: 1.73
  4. Demand Leave: 2
  5. Demand Leave with Threat: 2.24

If you set a status for a specific combination of system and NPR, then if that NPR is detected by you in that system during a construction phase it will be informed of your demand unless it is already allied or hostile.

The impact of the message on the NPR decision to accept or reject your demand is shown by the ‘Demand Strength’ in the list above, which is the square root of the ‘Demand Number’. A Request is 41% more likely to work than a Suggestion, while a Demand with Threat is 2.24x more effective than a Suggestion. The Demand Value represents the idea that, from the perspective of the NPR, the forcefulness of your language may represent a willingness to use force.

While the strength of your demand plays a part in the NPR decision, it also has a significant effect on relations with that NPR. So a higher demand might increase the chance the NPR will leave, but it also increases the chance of starting a war. If you demand the NPR leaves a system it doesn’t care about you will cause fairly minor damage, but you could have made a polite request and it may have left with hardly any impact on relations. If you demand an NPR abandons what it regards as a primary system, that might work if you have a significant military advantage and the NPR is aware of it, but it might also cause the NPR to open fire immediately.

System Values
1 Neutral
2 Claimed
3 Secondary
4 Primary
5 Core
6 Capital

This relationship impact is equal to (Demand Number ^2) * (System Value ^2) * (Xenophobia / 50). So a demand to leave a primary system would have the impact of 256 * (Xenophobia / 50), while a request to leave a claimed system would have an impact of only 16 * (Xenophobia / 50).

The demand will be rejected if the NPR has not detected populations of your race with a total EM signature of (10 * Xenophobia) or more. The NPR will base this on actual populations, not currently detected populations, as it is assumed you will provide the necessary evidence to back up your demand.

Otherwise, the demand will be accepted based on Demand Value plus the following additional factors:

Accessible System Value
For each system that would no longer be accessible if the claim was accepted, including the target system, a value is assigned equal to (System Value ^2)/4. For example, a Claimed system is worth 1, a Secondary system is worth 2.25, a Primary system is worth 4, etc. Each individual system value is calculated first and then the results are summed.

Military Advantage
This assessment depends on the total size of your military forces that have been detected by the NPR during the last five years in comparison to its own (with an assumption of some as-yet-unseen forces) and its assessment of relative technology based on its observation of your ships. I don’t want to go into too much detail on the Player Military Advantage, but if the NPR believes the racial balance of forces is equal, Player Military Advantage will be equal to 1. For the NPR to believe you have an advantage, it will need to see some firepower. This is based on total known forces, not local known forces, so generating a high Military Advantage number is difficult unless you show off a large portion of your forces. You won’t be able to simply send in a survey ship and ask the NPR to move out

Population Factor
This is equal to SQRT(Total EM Signature of Player Populations in System / Total EM Signature of NPR Populations in System). However, this factor can never be higher than the fourth root of (Total EM Signature of Player Populations in System / 100). For example, if the player had 1000 EM Signature and the NPR has 200 EM Signature, the factor would be 1.78 (because the fourth root of (1000/100) is lower than SQRT(1000 / 200). This is to limit the advantage when the populations are relatively small or the NPR has no populations. Population Factor is the best ’peaceful option’ as demonstrating a large population is much more likely to achieve a decision in your favour.

Resistance
(Xenophobia + Militancy + Determination) / 150. If the NPR has low militancy, low determination and low xenophobia, it will be much easier to push around, and vice versa. This is difficult to assess because it is an unknown factor.

If Military Advantage * Demand Value * Population Factor) > (Accessible System Value * Resistance), the NPR will accept the claim.

For example, if the NPR has militancy, determination and xenophobia all at 50, then the value to overcome for a Secondary system is 2.25. If there are no populations and you use ‘Demand Leave’ which is worth 2x, you will need a Military Advantage greater than 1.125. Making this demand will cause a negative relationship impact of (4^2) * (3^2) * (50/50) = 144. If you have a significant advantage in population in the system, then you require a smaller military advantage or can use a lesser demand.

If the NPR rejects your demand to withdraw, the protection status for that system for that NPR is reset to No Protection, so that further diplomatic penalties are not incurred. If you want to re-instate the demand (at whatever level), it will generate a new penalty.

If the NPR decides it must withdraw based on its assessment of the situation, it will evacuate its ships and transfer any colonies to your control. These will start at a status of Occupied. The system will be set to ‘Alien Controlled’ (Player controlled) from the perspective of the NPR and it will ignore the system when deploying forces. This will change if conflict breaks out.

Note that the player vs NPR and NPR vs player functionality for claiming systems are a little different. Both sides can send messages to each other and the types of messages are effectively the same. The difference is the method of delivery and the potential reaction. This is because I wanted to give the player maximum flexibility in Diplomacy, while still proving a structured approach for the NPR. For example, the player view of the NPR in terms of diplomatic points does not drop if the NPR ignores demands to leave. The player can decide whether it is necessary to go to war.

This is a complex set of interactions, so I may modify after play test (or if someone spots any errors in the algorithms).


Diplomacy Part 4: NPR vs NPR Claims

NPR vs NPR Diplomacy works as a combination of NPR vs Players and Player vs NPR.

As described in Part 2, when an NPR detects alien forces in a system that is claimed by the NPR, the NPR will issue a warning. When the target is a player this appears as an event message as per Part 2. When the target is another NPR, the first NPR sets a protection status (in the same way as a player does in Part 3) that corresponds to the same demand level as it would send to a player.

For example: An NPR detects an alien force in a system that it claims and decides this represent a threat level of 12. If the alien is a player, the NPR will send a message to the player that will appear as an event. The message will be on the lines of “We demand you leave” and that message will continue to be sent each construction phase. If the target is another NPR (let’s call this NPR-B), then NPR-A will set a protection status of ‘Demand Leave’ instead.

Next phase (or in some cases later in the same phase), NPR-B will see the withdrawal demand from NPR-A, just as it would see a similar demand from a player. It will react to that demand in exactly the same way except for one crucial difference; NPR-B will not reduce the diplomatic points for NPR-A.

So why all the messing about with slightly different methods for Player vs NPR, NPR vs Player and NPR vs NPR? Because NPRs, even though they are much smarter in C#, will still not have the human capability to make intuitive estimates weighing the strategic benefit of claiming a system claim vs the potential downsides of reduced diplomatic relations. This strategic deficit in AI vs human ability is handled by the different reactions to claims.

  • Player vs NPR: The NPR will generally react negatively to being asked to leave a system, as that is a relatively easy to understand situation, and it can make a reasonable estimate of whether to abandon that system. The player does not react negatively to the NPR refusing to leave in game mechanics terms because the human player can make decisions himself about whether to treat the NPR differently. This also means that continual messages can be sent to remind the player without diplomatic penalties in-game.

  • NPR vs Player: The NPR will react negatively to player forces being in one of its systems, as that is also a relatively easy to understand situation. The negative impact is based on the importance of the system and the size of the player force. The player does not react negatively to the NPR asking him to leave in game mechanics terms because the human player can make decisions himself about whether to leave or treat the NPR differently.

  • NPR vs NPR: NPR-A will react negatively to NPR-B forces being in one of its systems, as that is also a relatively easy to understand situation. The negative impact is based on the importance of the system and the size of the NPR-B force. NPR-B will decide whether to leave the system but will not react negatively to being asked to do so. This allows the protection level to be reset each time without negative impact (so the NPR doesn’t have to consider the huge variety of factors on when to make a new demand). Also, NPR-B may well regard the system as one of its own and will be making its own demand of NPR-A, in which case it will react negatively to a refusal from NPR-A.

The difference is that the NPR is always faced with an immediate decision and does not have to consider wider implications. The player has the ability to take those wider implications into consideration and is free to make his own decisions on relationships. When NPRs do confront each other, either one will leave because the system is not important or they will start making demands of each other, which takes care of the dual negativity. I know it sounds complex, but I think it the best option to handle the different situations.


Diplomacy Part 5: Restrictions on NPR Claims

There are several situations where NPRs will not make territorial claims:

  • If the NPR and the alien race share a capital system, no claims will be made in the capital system or in any adjacent system

  • The NPR will not make claims against an alien race with whom it shares a Fixed Relationship due to a Truce Countdown

  • The NPR will ignore claims from an alien race with whom it shares a Fixed Relationship due to a Truce Countdown and there will be no diplomatic penalty

  • The NPR will not claim a system if there are alien populations with a total EM signature greater than 10% * (Xenophobia / 100) of its own capital’s EM signature and also greater than the total EM signatures of any AI populations in that system. The existence of populations will be based on intelligence data rather than current contacts.

The above is based on the concept that an AI is unlikely to claim a system where it knows there is a good chance that claim will cause a war. Note that from the NPR perspective an ‘alien race’ includes player races.


Diplomacy Part 6: Independence

In C#, you can declare a colony independent using a button on the Economics window. Colonies may also become independent in other situations, such as a rebellion following high unrest. Independence is far more complex than it first sounds, because the population will be under the control of a new race that is essentially a copy of the original race. The process is as follows:

  • The title of the new race will be based on the name of the newly-independent population.

  • A new flag will be auto-selected and random naming themes chosen for classes, systems, etc.. Commander name themes will remain the same as the original race.

  • The ranks of the new race will copy the ranks of the original race.

  • Any ground forces at the population will be transferred to the new race.

  • It is possible that an NPR population can become independent, in which cases it will retain the same tech but create a new design philosophy.

  • The new race will start with an amount of wealth equal to total original race wealth * (independent pop size / total original race pop size before independence), which will be transferred from the original race.

  • The new race will start with a number of commanders equal to original race number of commanders * (independent pop size / total original race pop size before independence). These are new commanders and not transferred from the original race.

  • A top-level admin command will be created at the population.

The new race will gain the following knowledge from the original race.

  • The same galactic map, including map labels.

  • All geological and gravitational survey data.

  • All tech systems.

  • How to build all ship components and missiles.

  • All class designs.

  • All ground unit class designs.

  • All ground formation templates.

  • All intelligence data, including alien races, classes, ships, sensors, weapons, populations and ground forces.

  • A complete set of intelligence information on the original race which will be set up as a new alien race, with known systems, ships, etc.

  • Control Race flags on galactic map.

  • Protection Status settings for different combination of alien races and systems.

  • Locations of ruins, anomalies, wrecks, etc..

  • Event colours.

For manual independence, any naval forces will have to be transferred using the Transfer Fleet option. In the case of a rebellion, some ships may be transferred automatically.


Diplomacy Part 7: Banned Bodies

If a non-spoiler NPR has a relationship of neutral or higher with another race, it will generally avoid approaching ‘banned bodies’.

An NPR will decide for itself which bodies are banned, but in general these will include:

  1. Bodies that have an alien race population of approximately ten million or more

  2. Bodies that are moons of any bodies in (1)

  3. Bodies that are moons and share the same parent body as any body in (1)

  4. Bodies on which the NPR already has a population will be exempt from the above rules

NPRs will not create populations on banned bodies and will not attempt to conduct geological surveys on those bodies. The NPR will not generate points of interest within a few million kilometres of banned bodies. It is still possible that NPR ships will approach due to other considerations, such as moving between two points unrelated to banned bodies, but in general this should prevent the VB6 situation of NPR battle fleets making port visits to your home world.

The banned bodies list is updated at game launch and during each construction phase. Banned bodies do not exist for populations of races with which the NPR has a hostile relationship. If there are two populations on a planet, one of which is hostile to the NPR and one neutral, the body will not be banned.

For example, in the Space 1889 campaign, the Martians will generally avoid Venus, Earth, Luna, all the moons of Jupiter and all the moons of Saturn. They will still survey the Trojan asteroids and they still may pass close to the banned bodies when on an unrelated mission.

NOTE: I looked at various ways of applying this in reverse. The NPR would generate a list of important planets and check for player race ships within a certain range, perhaps ten million kilometres. If they were detected, that would trigger a response, even if the NPR would otherwise not object to the player being in the system. The problem is that the player would have to be checking each ship path to ensure that didn’t happen. I even added code to avoid this problem by only flagging player ships that remained within ten million in two consecutive construction phases, but even that is not foolproof. Essentially, the player knows the NPRs is trying to avoid his populations and will react to NPR movements accordingly, but understanding that is much more difficult for the AI. In the end the game play benefit is outweighed by the considerable micro-management required on the part of the player, or by the amount of code that would be needed to avoid accidentally passing through restricted zones. In most situations, the player would want to avoid being detected anyway so this situation would usually only be relevant where a truce countdown is in effect and the player and the NPR share the same home system. The player can RP that situation if needed.


Diplomacy Part 8: Diplomatic Ships

A Diplomatic ship is any ship equipped with a Diplomacy Module. These can be built by the player or by NPRs.

Diplomacy Modules and therefore Diplomatic Ships are important for communication attempts and essential for basic diplomacy (influencing an alien race to view your race more positively).

When a Diplomatic Ship is involved in diplomacy or communication attempts, the opposing race will know the origin of those messages. If the Diplomatic Ship is on opposing sensors, the identity of that ship will be noted in an event for the opposing race and its parent class will be flagged as a diplomatic vessel. If diplomacy is underway, the name of the Ambassador will also be passed to the opposing race.

If the Diplomatic Ship is not on opposing sensors, the location of the signal from that ship will be communicated to the opposing race. This may be a system body, a jump point or simply a point in space.

Any damage to NPR Diplomatic ships, regardless of whether the opposing race knows that status, will be treated as triple damage for the purposes for affecting diplomatic relations. If a diplomatic ship is attacked without an existing hostile relationship, the relationship will fall to -300 from the perspective of the owner of the ship (rather than the normal -100 for attacking when not hostile).

Screen Resolution

I’ve mentioned the minimum resolution a few times in different places, but I think it is worth including here, especially as it just came up on the Discord.

C# Aurora will launch with a minimum resolution of 1440 x 900. The windows will not be re-sizeable except for the Tactical Map and the Galactic Map and even in that case it is because those windows are intended to fill the whole screen. The Class design window has a ‘Wide’ option that takes it to about 1800 x 900.


Tactical Map in Background

C# does not have a starting menu bar in the same way as VB6. Instead, the Tactical Map is the main game window.

Once the Tactical Map is open however, both VB6 and C# have a similar issue. Assume you have the Tactical Map on maximised and you open the Economics window. That window is now on top of the Tactical Map. Now you click the button on the Tactical Map to open the Fleet Window. While that is on top of the Tactical Map, the existing Economics window is now behind the Tactical Map because clicking on the button gave the tactical map focus and therefore precedence over the existing Economics window. Which means if you want to see both Economics and Fleet at the same time you need to manually bring Fleet to the front (or move Economics to a second monitor before clicking the Fleet button).

Therefore C# now has an option called ‘Keep Tactical in Background’. While this is active, after pressing the toolbar button on the Tactical Map, the new window will open and then the Tactical Map will move to the background, leaving all other windows in front of it and the newly opened one on top.


Linked Windows

C# Aurora has a option to link all the open windows, so that when you change the current Race in one window, all the other windows change to the same race.


Tactical Map Popup Menu

When you right-click on the tactical map, any fleets, population or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.


Save Button

C# Aurora doesn’t continually update to disk in the same way as VB6 Aurora, which is one of the reasons why it is much faster. Instead, there is a Save Button.

When you click Save, the database prior to the save is copied to a new file called AuroraDBSaveBackup.db and then the AuroraDB file is updated with the current game. The previous AuroraDBSaveBackup.db is copied to a file called AuroraDBPreviousSaveBackup.db, so you have automatic backups of your last two saves. To restore a previous save, you need to delete AuroraDB.db rename the backup file to AuroraDB.db.

If you close without saving then your game will revert to the last save. Saving takes about thirty seconds.


Multiple Window Instances

In C# Aurora, you can open multiple instances of each window except for the tactical map. So you can have multiple class windows, galactic map windows, fleet windows, etc.. Each time you click the Fleet window button (for example) another Fleet window opens.

This is useful for comparing classes for example. However, you can also drag and drop between two windows of the same type. For example, you could drag a ship from a fleet on one window and drop it on a fleet on a second window, or drag a ground unit from one Ground Forces windows under the hierarchy of an HQ on the second Ground Forces window.


Assigned Mothership Display

In playing my BSG campaign, I found it difficult to keep track of which mothership was the parent of each survey FAC. Therefore, I have added Assigned Mothership as a field on the ship design display and also added assigned mothership name and fleet to the summary at the top of the Fleet tab of the Naval Organization window.


Race Comparison Window

C# has a comparison window that allows you to see a high level comparison between different Races. It is simple and read-only, but useful for a high-level overview.

The window expands to the number of player races in the game. I may also add some additional comparison information over time.


Race Comparison Window

C# has a comparison window that allows you to see a high level comparison between different Races. It is simple and read-only, but useful for a high-level overview.

The window expands to the number of player races in the game. I may also add some additional comparison information over time.


Survey Site List

Given the number of potential ground survey sites, it could be difficult to keep track. Therefore I have added a new tab to the tactical map that contains a list of current known sites.

Star System Design Part 1: Modifying Stars

C# Aurora allows you to manipulate star systems in SM Mode. While it would be difficult to design a system during the original generation process, due to the complexities involved, you can now add or modify stars and system bodies. This post covers modifying stars.

You click on a star in the System View and then click Change Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.

Here is an example from my current test campaign that changes the B component of Alpha Centauri from a K1-V star to an F0-V, which is much hotter. The star will orbit more quickly due to the increased mass, plus all the planets orbiting the star are affected by the increased mass and luminosity of the different star. Temperatures will change, along with potentially hydrosphere type and atmospheric composition (as gases freeze out or boil). Oceans or ice sheets may convert entirely to water vapour given a significant temperature rise. Planets may change their tide-locked status.

These two screenshots show the effect of moving the star further from the primary.


Star System Design Part 2: Adding Stars

Adding a new star is straightforward. You click Add New Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.

This screenshot shows the result of adding the above star to the Alpha Centauri system. New stars do not have any planets or other system bodies. These are added separately and will be covered in a future post.


Star System Design Part 3: Modifying System Bodies

Modifying system bodies is a more complex process than stars due to the number of factors involved. There are factors that are tied to each other, such as mass, radius, density and gravity, plus certain types of bodies have different rules (planets vs moons, gas giants vs rocky worlds).

Therefore, the following factors can be changed; distance to parent body, diameter, density, hydro extent, albedo, atmospheric composition and dominant terrain. The dominant terrain is restricted to those terrains permitted by the other factors. Factors such as colony cost, gravity, temperature, atmospheric pressure, length of year, maximum population, tidal lock status, atmospheric retention, time required to stabilise a Lagrange point, etc. will all be derived from the factors that can be changed. For example, if you change the diameter or density, the mass and gravity will automatically change. If you change the distance to parent, the temperature and year will change and perhaps the tidal lock status. Finally, factors such as escape velocity, magnetic field, etc. are not shown here because they have no current game play impact, even though escape velocity will change as a result of modifications to density or diameter.

The basic type of system body (terrestrial, dwarf, etc.) cannot be changed, but it will be possible to delete one system body and add a new one of the desired type. This is to ensure all system bodies follow the basic rules of their type, even if they are later modified.

Below is the System Body Modification popup window. You can change the green fields in the top left, the dominant terrain dropdown and can add and remove atmospheric gases by choosing a gas and the desired atm (0 to remove). As you make each change, everything else updates.

For example, here is what happens if the diameter is halved. Gravity, mass and max population all fall, while the terraform rate vs Earth and the time to stablise a Lagrange point both increase.


Star System Design Part 4: Deleting Stars and System Bodies

Deletion of stars or system bodies is straightforward. Click on the target object and then click Delete Body or Delete Star. You will be given two popup warnings and then the object will be deleted. Deleting a star will remove any system bodies in orbit. Deleting a planet will remove any moons of that planet. Any populations on affected system bodies will be deleted. Deleting the primary star is not possible.

When a star is deleted, any remaining stars will be renamed accordingly. For example, if you delete the B component of a primary, the original C component will now become the B component. When a planet or moon is deleted, the orbit numbers of the planets or moons will be adjusted accordingly.

For example, here are the before and after views of the Alpha Centauri-A system when the fourth planet is deleted.


Star System Design Part 5: Adding Planets, Comets and Asteroid Belts

Below is the form for adding all new system bodies except for additional moons. You choose a system body from the drop down, which includes Terrestrial, Dwarf Planet, Gas Giant, Superjovian, Comet and Asteroid. Each body type has a distance parameter plus one or more other additional options.

  • For terrestrial and dwarf planets you have a toggle for automatic moon generation and can choose a specific or random number of moons.

  • For gas giants and superjovians, you have the above moon options plus similar options for Trojan asteroids (on/off, random/specific)

  • For comets, you choose the starting distance and maximum distance

  • For asteroid belts, you can choose a random or specific number of asteroids and the specific or random width of the belt (how far an asteroid can be generated from the centre of the belt)

Once the planet parameters are selected, press OK and the new body or bodies will appear in the System View. You can select them and use Modify Body to customise if desired.

The various zones shown at the top affect how Aurora determines parameters such as atmosphere, hydrosphere, mineral deposits, albedo, density, number of moons, total mass of asteroid belts and a variety of other factors. There is far too much detail to list, but generally bodies in the life zone will have better conditions and mineral deposits, followed in decreasing order by Inner, Outer and Extreme. These zones also exist in VB6. Of course, those factors only affect initial generation so you can override that by directly modifying a body post-creation.


Star System Design Part 6: Adding Moons and Lagrange Points

Below is the form for adding moons to existing planets. During planet creation you can specify appropriate moons to be created at the same time using standard moon generation based on the type of planet and is orbital distance. This form, accessed via the Add Moons button, is for creating additional moons which do not have to obey normal size restrictions. The form allows the addition of up to five moons (the drop-downs all start with no moon) with type and distance specified. If more than five moons are needed, the form can be used multiple times for the same parent planet.

After initial generation you can use Modify Body to specify additional detail if required

The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.


Star System Design Part 7: Deleting Asteroids and Lagrange Points

Deleting individual asteroids can be done by using the Delete Body button. To delete an entire asteroid belt or all the Trojan asteroids for a particular planet, click one of the asteroids in the belt or one of the Trojans and click Delete Asteroids. There will be two warnings before all the affected asteroids are deleted.

Lagrange Points can be removed by selecting the parent system body and clicking Remove Lagrange.

Below is the final version of the System View in SM mode with all system engineering buttons present.

Populations as Text

This change is purely to aid AARs.

The Economics window has two new buttons; ‘Pop as Text’ and ‘All Pop as Text’. Pressing the first pops up a window with a text version of the population. The text lists population amount, shipyard capacity, maintenance capacity and the number of each installation present. This is intended for copying directly into an AAR. The text is already highlighted so you just press ctrl - c to copy it. An example is shown below.

The ‘All Pop as Text’ button does the same, but for all populations instead of just one. This ‘press a button and copy’ was how I did the ‘State of the Imperium’ section in my last campaign post. The populations will appear in the same order as the population tree on the left of the window. If you exclude civilian colonies from the tree, they will be excluded from the text as well.

Terra
Population: 1576.67m
Naval Shipyard Capacity: 489,622 tons
Commercial Shipyard Capacity: 2,520,000 tons
Maintenance Capacity: 666,000 tons
Research Facility: 48
Ground Force Construction Complex: 9
Construction Factory: 562
Ordnance Factory: 246
Fighter Factory: 100
Mine: 104
Automated Mine: 10
Fuel Refinery: 400
Maintenance Facility: 333
Financial Centre: 132
Deep Space Tracking Station: 9
Mass Driver: 1
Military Academy: 5
Naval Headquarters: 1
Spaceport: 1
Infrastructure: 30
Low Gravity Infrastructure: 100


Fleets as Text

This is similar to the earlier ‘Populations as Text’ function. A new button on the Naval Organization window will open a window with a text version of the ships in the fleet. The text lists each ship class in the fleet with the names of each ship of that class alongside. For ships of 1000 tons or less, the number of ships is displayed, rather than the names. This is intended for copying directly into an AAR. The text is already highlighted so you just press ctrl - c to copy it. An example is shown below. I added the italics manually afterwards.

Expeditionary Fleet
Lunar III class Cruiser: Agrippa
Dictator II class Cruiser: Fortitude
Dominator class Cruiser: Ultima Praetor
Endeavour II class Light Cruiser: Endeavour, Sword of Voss
Dauntless IV class Light Cruiser: Divine Crusade, Guardian, Hammer of Truth, Vigilant
Vanguard III class Strike Cruiser: Angelic Blade, Dread Argent
Cobra III class Destroyer: Arbitrator, Omnis Arcanum
Firestorm IV class Frigate: Harrower, Just Persecution, Liberator
Sword III class Frigate: Achilles, Mariatus, Rapier
Falchion III class Jump Frigate: Scimitar
6x Thunderhawk II class Assault Transport
16x Starhawk III class Bomber
5x Aquila class Lander


Ground Forces Text Summary

The ‘Temp as Text’ button on the Formation Templates tab of the Ground Forces window will pop up a window with a text version of the selected template composition, which can be copied using ctrl-C and pasted into an AAR. Format is as follows:

Colonial Marine Battalion
Transport Size: 4,914 tons
Build Cost: 156.4 BP
400x Colonial Marine
96x Colonial Marine - LMG
12x Mortar Section
24x Anti-Tank Section
4x Forward Air Control Party
16x Centaur AFV
8x Supply Section
2x Marine Battalion HQ

The ‘Total Force Text’ button on the Order of Battle tab of the Ground Forces window will pop up a window with a text version of your entire ground force, which can be copied using ctrl-C and pasted into an AAR. Format is as follows:

Total Ground Forces
Total Formations: 116
Total Transport Size: 439,767 tons
Total Cost: 30,210 BP

21,600x Colonial Marine
5,184x Colonial Marine - LMG
1,440x Colonial Marine Raider
1,140x Anti-Tank Section
760x Centaur AFV
570x Mortar Section
448x Supply Vehicle
396x Medium Howitzer
380x Supply Section
360x Colonial Marine Raider - LMG
348x Minotaur Battle Tank
190x Forward Air Control Party
132x Manticore Medium AA
120x Marine Battalion HQ
104x Sphinx Planetary Defence Installation
52x Hydra Planetary Defence Installation
48x Marine Raiding Force HQ
12x Minotaur Command Tank
11x Regimental HQ
4x Marine Company HQ


Alien Classes Text Summary

As with the other text summaries, this is a tool for generating text to paste into after-action reports.

A button on the Intelligence & Foreign Relations window will generate a summary of alien class information for the selected alien race. Here is a summary from the Martian Empire in my current campaign. Weapons will also be shown when known.

Alien Class Intelligence - Martian Empire
5x XX Xining 84,250 tons Thermal 84
1x XX Jiangwei 73,200 tons Thermal 1,600 1,092 km/s
5x XX Changsha 59,850 tons
8x FT Su Small F4 34,650 tons Thermal 640 923 km/s
8x CS Su Small C4 22,000 tons Thermal 640 1,453 km/s
1x XX Houxin 20,100 tons
15x XX Kaifeng 19,300 tons
1x XX Luda 17,700 tons Thermal 800 2,253 km/s
15x XX Houjian 12,850 tons Thermal 282 1,092 km/s AS #61
9x XX Dalian 12,850 tons
3x XX Hegu 12,800 tons AS #61
3x XX Hainan 12,700 tons AS #61
10x XX Jinan 12,500 tons
4x XX Luhu 6,900 tons Thermal 400 2,892 km/s
16x XX Yinchuan 6,400 tons Thermal 140 1,092 km/s AS #61
7x XX Huangwen 6,400 tons
1x XX Chongqing 6,400 tons
1x XX Zunyi 6,400 tons
4x XX Jianghu 5,400 tons Thermal 200 1,836 km/s
8x FH Su H4 Thermal 320 248 km/s
3x XX Xian Thermal 200 1,724 km/s
Total Known Tonnage 2,293,300