DOKK Library

Aurora C# unofficial manual v0.1.3

Authors Steve Walmsley

License CC-BY-NC-4.0

               Aurora C# unofficial manual
Written by Steve Walmsley and organized by Aurora C# forum community
                         September 15, 2020


I     Introduction                                                                                                                                                                                         4
1 What is Aurora C#                                                                                                                                                                                         4

2 About this document                                                                                                                                                                                       4

II    Diplomacy                                                                                                                                                                                            5
3 Basic Framework                                                                                                                                                                                           5

4 Intrusion into NPR territory                                                                                                                                                                              6

5 Claiming systems from NPRs                                                                                                                                                                                7

6 NPR vs. NPR claims                                                                                                                                                                                        9

7 Restrictions on NPR claims                                                                                                                                                                               10

8 Independence                                                                                                                                                                                             10

9 Banned bodies                                                                                                                                                                                            11

10 Diplomatic ships                                                                                                                                                                                        11

III    Star System Design                                                                                                                                                                                  13
11 Modifying stars                                                                                                                                                                                         13

12 Adding stars                                                                                                                                                                                            15

13 Modifying system bodies                                                                                                                                                                                 16

14 Deleting stars and system bodies                                                                                                                                                                        17

15 Adding planets, comets and asteroid belts                                                                                                                                                               18

16 Adding moons and Lagrange points                                                                                                                                                                        19

17 Deleting asteroids and Lagrange points                                                                                                                                                                  20

IV     Weapons                                                                                                                                                                                             21
18 Missiles                                                                                                                                                                                                21
   18.1 Missile updates . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   21
   18.2 Missile engines . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   21
   18.3 Missile launcher changes .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
   18.4 Box launcher reloading . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
   18.5 Missile thermal detection          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
   18.6 Magazine design . . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24

19 Guns                                                                                                                                                                                                    24
   19.1 Meson update . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   24
   19.2 Turret update . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
   19.3 Beam weapon recharge       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
   19.4 Weapon failure . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
   19.5 Plasma carronades . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
   19.6 Particle lance . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25

20 Other                                                                                                                                                                                      26
   20.1 Point defence . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
   20.2 Ordnance transfer mechanics . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
   20.3 Ordnance transfer orders . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
   20.4 Automated weapon assignment .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   29
   20.5 Atmoshpere and energy weapons         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   31
   20.6 Planetary bombardment . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   31

V    Ground Forces                                                                                                                                                                            33
21 Unit design                                                                                                                                                                                33

22 Formation templates                                                                                                                                                                        36

VI    YouTube content creators                                                                                                                                                                39

Part I
1      What is Aurora C#
    Aurora C# is turn based 4X1 computer game made solely by one man: Steve Walmsley as a hobby project
in spare time. It’s modern version of it’s predecessor „Aurora 4X” called sometimes „Aurora VB6” from Visual
Basic 6 - language it was written in. Aurora C# is writen in... C# more modern programming language which
resulted in dramatic increse of performance.
    Aurora C# is free game distributed thru forum under address where you can
find more information about game and ask qestions about mechanics to more experienced players and the
developer himself.

2      About this document
    This document wasn’t be possible without Steve Walmsley who wrote devlogs during game developement
and forum community, especially user named Demonides who gave idea and started consolidation of information
scattered around forum and Father Tim for helping.
    This document is based on his and others work. Thank you! You can find original topic here: C# Aurora
Changes List v1.12 / Table of Contents
    This document and it’s source in LATEXis distributed under Creative Commons Attribution-NonCommercial
4.0 International Public License. You can help improve it on GitHub or Aurora official forum. Newest versions of
this document in PDF format are availble on

    1 4X   - eXplore, eXpand, eXploit, eXterminate

Part II
3    Basic Framework
    Original post can be found here.

    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.
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 Diplo-
macy 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:
                                                                             T argetRacialXenophobia
           DiplomacyP oints = (DiplomacyBonus ∗ 4 + 1) ∗ 100 ∗ (1 −                                    )
    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
    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 − RacialXenophobia
                                                                                    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
    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.

4      Intrusion into NPR territory
    Original post can be found here.

In each construction phase, each NPR will determine a value for each known system. In order of ascend-
ing 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 section 5).
    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:
                       T hreatLevel = BaseT hreatLevel ∗ StatusM odif ier ∗
                                                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:
    DP P 2 = T otalDetectedShipT onnage + T otalDetectedP opulationEM Signature ∗ 10 ∗ T hreatLevel

    Each construction phase, the diplomatic penalty applied is equal to the annual penalty multiplied by
ConstructionP haseLength
          Y ear
    2 DPP   - Diplomatic Point Penalty

    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 section 10) 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, as-
suming an NPR Xenophobia of 50. For populations, use EM Signature * 10 for ‘Tonnage’.

              √                    Annual Diplomacy Penalty                         Construction Phase Penalty
 Tonnage          Tonnage    Secondary Primary Core Capital                    Secondary Primary Core Capital
    1000           31.6         39.5       79.1    158.1   316.2                  0.5         1.1     2.2      4.3
    3000           54.8         68.5      136.9    273.9   547.7                  0.9         1.9     3.8      7.5
   10000           100.0        125.0     250.0    500.0   1000.0                 1.7         3.4     6.8     13.7
   30000           173.2        216.5     433.0    866.0   1732.1                 3.0         5.9    11.9     23.7
   100000          316.2        395.3     790.6   1581.1   3162.3                 5.4        10.8    21.7     43.3
   300000          547.7        684.7     1369.3  2738.6   5477.2                 9.4        18.8    37.5     75.0
  1000000         1000.0       1250.0     2500.0  5000.0 10000.0                  17.1       34.2    68.5    137.0
    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.

5    Claiming systems from NPRs
    Original post can be found here.

In the same way that NPRs can warn players to leave a system, a player can warn an NPR. On the Intel-
ligence 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

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

   This relationship impact is equal to
                         Impact = DemandN umber2 ∗ SystemV alue2 ∗
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 ∗ Xenophobia50   .
    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 SystemV
                                 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
    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:                  s
                                      T otalEM Signatureof P layerP opulationsinSystem
                        F actor =
                                       T otalEM Signatureof N P RP opulationsinSystem

However, this factor can never be higher than the fourth root of T otalEM Signatureof P layerP
For example, if the player had 1000 EM Signature and the p NPR has 200 EM Signature, the factor would be
1.78 (because the fourth root of (1000/100) is lower than 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.

                                          (Xenophobia + M ilitancy + Determination)
                          Resistance =
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.

      M ilitaryAdvantage ∗ DemandV alue ∗ P opulationF actor > AccessibleSystemV alue ∗ 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 42 ∗ 32 ∗ (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.

6     NPR vs. NPR claims
    Original post can be found here.

    NPR vs NPR Diplomacy works as a combination of NPR vs Players and Player vs NPR.
    As described in section 4, 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 section 4. When
the target is another NPR, the first NPR sets a protection status (in the same way as a player does in section
5 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.

7     Restrictions on NPR claims
    Original post can be found here.

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.

8     Independence
    Original post can be found here.

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 ∗
      (IndependentP opSize/T otalOriginal) 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.

9     Banned bodies
    Original post can be found here.

   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.

10      Diplomatic ships
    Original post can be found here.

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

    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). See section 3 for more details.
    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 commu-
nicated 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).

Part III
Star System Design
11     Modifying stars
   Original post can be found here.

    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

                                             Figure 1: Star Setup

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.

                                       Figure 2: Star Setup Example 1

                                   Figure 3: Star Setup Example 2

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

                                  Figure 4: Engineering Example 1

                                      Figure 5: Engineering Example 2

12     Adding stars
   Original post can be found here.

    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.

                                           Figure 6: Adding 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.

                                         Figure 7: Adding Star Result

13     Modifying system bodies
   Original post can be found here.

    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.

                                      Figure 8: System Body Modification

   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.

                                 Figure 9: System Body Modification Result

14     Deleting stars and system bodies
   Original post can be found here.

    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

                             Figure 10: Deleting Stars And System Bodies

                            Figure 11: Deleting Stars And System Bodies 2

15   Adding planets, comets and asteroid belts
 Original post can be found here.

   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, hydro-
sphere, 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

                                         Figure 12: Add Planet Example

16     Adding moons and Lagrange points
   Original post can be found here.

    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.

                                        Figure 13: Add Moons Example

17     Deleting asteroids and Lagrange points
   Original post can be found here.

   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.

                                      Figure 14: Deleting Lagrange Points

Part IV
18     Missiles
18.1    Missile updates
   Original post can be found here.

   The following changes will be made to missiles in C# Aurora:
  1. Missile Armour has been removed.
  2. Laser warheads have been removed (I may add these back at some point in the future).

  3. ECM is now a fixed 0.25 MSP for missiles. The ’Missile ECM’ tech line has been removed and if a missile
     is equipped with ECM it will have the same ECM capability as the current racial ECM technology, The
     missile design will maintain that ECM capability and will not be upgraded if the racial tech improves. For
     each level of ECM, the missile will be 10% harder to hit with energy weapons and will reduce the lock of
     missile fire controls by 10%. This can be negated by linking a similar level of ECCM to the point defence
     fire controls.

  4. Missiles can be equipped with ECCM, which is a fixed 0.25 MSP. The missile ECCM level will be equal
     to the current racial ECCM tech. In C# Aurora, the ECCM of missile fire controls will only affect the
     range at which the fire control can lock on. The ECCM of the missile itself will affect the chance of the
     missile striking its target, if that target has active ECM.

  5. Any missile sensor (active, thermal, EM or Geo) has to be a minimum of 0.25 MSP or it will have no
  6. Missile series have been removed. Instead, there will be more detailed class loadout options.
    These changes will make electronic warfare much more important for missile combat. Missiles with ECM will
become harder to shoot down and missiles without ECCM will have a reduced chance to hit targets equipped
with ECM. Anti-missile missiles will either be less effective, or larger, vs ECM-protected missiles, while anti-ship
missiles are likely to increase in size (and therefore reduce salvo sizes). Large volleys of size-1 missiles will be
less effective in a heavy EW environment and no longer have a huge advantage in launching speed (due to the
missile launcher changes).

18.2    Missile engines
   Original post can be found here.

   In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula:
                                  F uelConsumption =
    The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a
flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine
type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier
cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption
increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives
of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still
consistent with ship engines.
    Therefore, the calculation for fuel consumption based on boosting engines will now include an additional
multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have
the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and
missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for
ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier

from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:

   if BoostU sed > M axBoostM ultiplierT ech then
                                          BoostU sed − M axBoostM ultiplierT ech
                  HighBoostM odif ier =                                          ∗4+1
                                                M axBoostM ultiplierT ech
    So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard
boost fuel modifier calculation of BoostLevel2.5 .
    Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x
fuel consumption at 4x Boost Level.
    Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max
Boost Tech for this race is 2x:

VB6 Missile Engine with 2x Boost
Engine Power: 1.6 Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost Engine Power 1.60 Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP (2.5 tons) Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite 0.80

VB6 Missile Engine with 4x Boost
Engine Power: 3.2 Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20 Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP (2.5 tons) Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite 1.60

18.3    Missile launcher changes
   Original post can be found here.

   Missile Launchers have undergone significant changes in C# Aurora.
  1. Fractional-size launchers can be created. The minimum is still 1 HS but a launcher can now be 1.1 HS,
     2.7 HS, etc.

  2. The reduced-size launcher techs are all available immediately and do not need to be researched. This
     means box launchers are available from the start. The progression for reduced size launchers has been
     altered slightly:

                                             0.75   HS   2x Reload
                                              0.6   HS   5x Reload
                                              0.4   HS   20x Reload
                                              0.3   HS   100x Reload
                                             0.15   HS   100x Reload (Box Launcher)3

    If a box launcher containing a missile is damaged, the missile will explode. The chance of this happening
can be reduced by a new tech line. The first step reduces the explosion chance to 70% for 1000 RP and the
last step reduces to 5% for 120,000 RP. In addition, Box launchers can only be reloaded in a hangar, or at an
Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at
an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in
VB6 Aurora).
    The base reload rate for all missile launchers is now:
                                             M issileSize ∗ 30seconds ∗ ReducedSizeM odif ier
                  M issileReloadRate =
                                                             ReloadRateT ech
    Assuming a race has reload rate tech of 3, a normal size 1 launcher will reload in 10 seconds, a size 4 will
reload in 20 seconds and a size 9 will reload in 30 seconds. This change will dramatically reduce reload times
for larger launchers.
    The change for box launcher reload rate from x15 to x100 is not as dramatic as it seems for larger missiles
due to the new reduced reload times for larger missiles. However, it is still an significant increase from VB6. A
size 4 missile mounted on a box launcher will now take about 1h 40m to reload in a hangar and about 17 hours
for an ordnance transfer point. A size 6 is about 2 hours and 20 hours respectively.
    These changes are intended to:
  1. Reduce the disadvantage of larger missiles
  2. Remove the realism issue of not having box launchers available at low tech yet make box launchers a more
     difficult decision vs standard-type launchers

18.4       Box launcher reloading
   Original post can be found here.

    In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities. For C# Aurora, box
launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer
Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar
(similar to the penalty for maintenance facilities in VB6 Aurora).
    Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy
facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers
if they could still use those facilities to reload, especially given they are immediately available in C#. The
introduction of ordnance-specific facilities for C# provides a good alternative.
    The existing changes post for Missile Launchers section 18.3 has been updated to take account of this new

18.5       Missile thermal detection
   Original post can be found here.

   In VB6 Aurora, the thermal detection of missiles is based on the following formula:
                                                                   M issileSize Speed
                                     T hermalSignatureV B6 =                   ∗
                                                                        20       1000
    I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed
like a good idea at the time :). For C# Aurora, missiles will use the same formula as ships for thermal signature:

                T hermalSignatureC# = M axEngineOutput ∗                          ∗ T hermalReduction
                                                                      M axSpeed
  3 Note   that reload for this was x15 in VB6

    As missiles (for now anyway), don’t have thermal reduction or an option to travel below maximum speed,
their thermal signature is equal to the power of their engines. Combined with the changes to passive detection,
this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances
than in VB6 Aurora.

18.6    Magazine design
   Original post can be found here.

   There are several changes to magazine design for C# Aurora.
   • The ’ejection’ tech line has been replaced by the Magazine Neutralisation System. It is functionally
     identical but in technobabble terms this is a system design to render missile warheads permanently inert
     in the event of damage to the magazine.

   • Magazines have a base HTK number equal to the square root of their size (rounded down). in VB6
     Aurora, all magazines have a base HTK of 1, regardless of size. It is still possible to add extra HTK in
     C# by sacrificing internal space.
   • The explosion chance for a magazine is divided by the square root of its size. For example, if a size 1
     magazine has a base explosion chance of 15%, the equivalent tech size 5 has an explosion chance of 6.71%,
     the size 10 is 4.74% and the size 20 is 3.35%.
   • If the ship has a Chief Engineer, any explosion chance (for magazines or engines) is reduced by his
     Engineering Bonus. So a 5% explosion chance would be reduced to 3.5% by a Chief Engineer with an
     Engineering bonus of 30%.
   • When a magazine is hit, a proportion of the remaining ordnance will be destroyed (based on destroyed
     magazine capacity / total ship magazine capacity). Any destroyed ordnance will explode with its full
     warhead strength. In VB6, only ordnance beyond the remaining magazine capacity explodes and only at
     20% strength.
In summary, magazine explosions in C# Aurora will be much rarer, especially for larger ships, but far more
devastating when they do occur.

19     Guns
19.1    Meson update
   Original post can be found here.

   Mesons have the following changes for C# Aurora:
  1. Their cost is based on the same principles as a laser, so mesons will cost the same as an equivalent laser
     of the same tech level.
  2. Mesons penetrate shields as before but their ability to penetrate armour is now limited.
  3. A new tech line exists, Meson Armour Retardation, which is the chance for each layer of armour to stop
     the meson. This starts at 50%, then 40%, 32%, etc. finishing at 7% for TL 12

  4. If armour does stop the meson, it scores 1 point of damage on the armour.
  5. If the meson hits a damaged armour location, it only has to penetrate the remaining armour in that
  6. Mesons will destroy missiles without penalty, as missiles are no longer armoured in C# Aurora.

As with everything else, these changes are subject to play test.

19.2    Turret update
   Original post can be found here.

   A minor update. The benefits of multiple energy weapons in turrets have been doubled. A twin turret now
has a 20% reduction in crew vs two solo weapons and has a 10% reduction in gear size. A quad turret has a
40% reduction in crew vs four solo weapons and has a 20% reduction in gear size.
   In addition, I found an error in the VB6 code for turret design that meant a turret needed four times more
armour than a ship of equivalent size. This has been corrected for C# Aurora, which means armoured turrets
are now much more viable.

19.3    Beam weapon recharge
   Original post can be found here.

   In VB6, if a power plant is damaged, it slows down the recharge rate of all weapons by a proportionate
   In C# Aurora, power is allocated weapon by weapon until the available power is exhausted. This means
that some weapons may not be recharged, but the others will be recharged at the maximum rate. Weapons are
charged in order of ascending power requirement. Once a weapon is recharged, it will require no more power
and other weapons can begin the recharge process.
   This should allocate power in the most effective way to keep a ship in the fight.

19.4    Weapon failure
   Original post can be found here.

    At the point when any weapon (energy-based or missile launcher) fires, there is a 1% chance the weapon
will suffer a failure. If sufficient maintenance supplies are available, the weapon will be instantly repaired and
will fire normally. If maintenance supplies are not available, the weapon will be damaged and unable to fire.
    This is partially to simulate the stress of combat on weapon systems, but also as a balance to other rule

19.5    Plasma carronades
   Original post can be found here.

  1. The development cost of Plasma Carronade focal size has been halved. For example, a 30cm Carronade
     is now 4000 RP.
  2. The building cost of Carronades has also been halved.

These two changes should make Carronades more viable. A powerful and inexpensive weapon but very short-

19.6    Particle lance
   Original post can be found here.

     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 Particle Lance is a large, potentially devastating weapon that is variant of the Particle Beam.
     Once Particle Beam Range 200,000 km and Particle Beam Strength 6 have both been researched, the Particle
Lance can be researched for 30,000 RP. The Lance is a modification of the normal Particle Beam and is an
extra option in the design window.
     The Particle Lance modification affects the Particle Beam in the following ways:
2x Damage

2x Size
2x HTK
2x Crew
2.5x Power Requirement
3x Cost
2x Development Cost
    As well as the above modifications, which essentially creates a weapon twice as large, that recharges 2.5x
more slowly and costs 3x as much, the damage template of the Particle Lance is a single column of armour,
rather than the Particle Beam which has a template between that of missiles and lasers. The Particle Lance
retains the constant damage of the Particle Beam, creating a weapon that can penetrate enemy armour at
significant range.
    Here are examples of similar tech level Particle Beam, Particle Lance and Laser.

Particle Beam
Beam Strength 6 Rate of Fire: 15 seconds Maximum Range: 240,000 km
Particle Beam Size: 8 HS Particle Beam HTK: 4
Power Requirement: 15 Power Recharge per 5 Secs: 5
Cost: 94 Crew: 24
Materials Required: 18.8x Duranium 18.8x Boronide 56.4x Corundium
Development Cost for Project: 2250RP

Particle Lance
Beam Strength 12 Rate of Fire: 38 seconds Maximum Range: 240,000 km
Particle Beam Size: 16 HS Particle Beam HTK: 8
Power Requirement: 38 Power Recharge per 5 Secs: 5
Cost: 282 Crew: 48
Lance Weapon
Materials Required: 56.4x Duranium 56.4x Boronide 169.2x Corundium
Development Cost for Project: 4500RP

25cm Far Ultraviolet Laser
Damage Output 16 Rate of Fire: 20 seconds Range Modifier: 5
Max Range 800,000 km Laser Size: 8 HS Laser HTK: 4
Power Requirement: 16 Power Recharge per 5 Secs: 5
Cost: 100 Crew: 24
Materials Required: 20x Duranium 20x Boronide 60x Corundium
Development Cost for Project: 1000RP
(laser will have 320,000 km range with equivalent tech level fire control)

                            Comparison of Damage Templates at 240,000 km
                            Particle Beam (6)                       2, 3, 1
                            Particle Lance (12)                         12
                            Laser (3)                                     3

    Two Particle Beams or 25cm Lasers can be installed in the same hull space as the Particle Lance. The Lasers
are devastating at close range, the Particle Beams inflict more damage at long range (in terms of DPS), while
the Particle Lance penetrates much more armour at long range.
    The Particle Lance is intended as a powerful anti-ship weapon that requires a large investment in a particular
tech line, lacks the flexibility of lasers or railguns and provides a different armour penetrating option to mesons,
although mesons are still superior against shields. Mainly though it is to boost the Particle Beam as a serious
weapon choice.
    The Particle Lance is not tested under normal battle conditions yet so I may change it a little after play-

20     Other
20.1    Point defence
   Original post can be found here.

     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.

20.2     Ordnance transfer mechanics
   Original post can be found here.

    In C# Aurora, transferring ordnance is no longer instant and ships without specialised equipment cannot
exchange ordnance in space. A ship can only receive ordnance at a Spaceport, an Ordnance Transfer Station,
a ship with a Ordnance Transfer System, a base with a Ordnance Transfer Hub or in a military hangar bay.
    A new technology line - Ordnance Transfer Systems - provides the basis of the rate of ordnance transfer
and allows ships to mount systems to transfer ordnance to or from other ships. The baseline system (Ordnance
Transfer System: 40 MSP per Hour) sets the racial ordnance transfer rate at 40 MSP per hour and allows the
use of the first ship-mounted Ordnance Transfer System. There are ten further steps in the tech progression
with the highest tech system allowing ordnance transfer at 400 MSP per hour.
    Spaceports, Ordnance Transfer Stations or Ordnance Transfer Hubs will always use the highest tech ordnance
transfer rate and can transfer ordnance to or from an unlimited number of ships simultaneously. However, the
ships involved must be stationary. Hangar Bays also use the highest tech ordnance transfer rate (mainly to
avoid multiple hangar bay types).
    Spaceports have increased in cost to 3600 BP but can now be moved by freighters. They are equal to four
research facilities for transport purposes (or 80 factories). They retain their existing bonuses to loading and
unloading cargo.
    Ordnance Transfer Stations are a new installation with a cost of 1200 BP. They do not require workers and
can be moved by freighters. They have a transport size equal to 10 factories. Essentially, they are a cut-down
version of a spaceport intended to facilitate ordnance transfer in forward areas, transferring ordnance between
the surface of a planet and ships in orbit. They have no bonuses for loading or unloading cargo.
    An Ordnance Transfer Hub can be mounted on a ship. It is a commercial system with a research cost of
10,000 RP, build cost of 2400 BP and a size of 100,000 tons. In practical terms, this is likely to form part of a
large, deep-space station, due to the size and cost, rather than being deployed on ammunition colliers that will
accompany fleets.
    A Ordnance Transfer System is 500 tons and has a cost ranging from 20 BP to 200 BP, depending on the
tech level. A ship with an Ordnance Transfer System can transfer ordnance to or from a single ship at once,
so it will take some time to replenish a whole fleet, although this will improve with higher technology. At the
early tech levels, the Ordnance Transfer System can only be used if both ships (collier and target ship) are both
stationary. Underway Replenishment allows the transfer to take place while both ships are in the same fleet
and underway. Priorities can be set for the ordnance transfer order when multiple ships are involved. The first
Underway Replenishment tech allows ordnance transfer at 20% of the normal rate (2500 RP), rising to 100%
with the highest tech (40,000 RP).
    Ordnance transfer order types will be adjusted to deal with the new requirements (which I will list in a
separate post). Ordnance will be transferred during each movement increment as time passes until the target
ship has full magazines.

20.3     Ordnance transfer orders
   Original post can be found here.

   With the new ordnance transfer rules, I am changing how some of the ordnance transfer orders work.
   The first major change is that a collier within a fleet can be set to automatically transfer ordnance to or
from other ships in the fleet. You can flag a collier as being at one of seven ordnance transfer statuses; None,
Load Fleet, Replace Fleet, Remove Fleet, Load Sub-Fleet, Replace Sub-Fleet, Remove Sub-Fleet.

    When this flag is set to Load Fleet or Load Sub-Fleet, each collier will load ordnance into the magazines
of non-colliers within its own fleet (or sub-fleet) as that fleet continues with its normal orders (the transfer
itself is not an order). Essentially, the collier will keep the fleet’s magazines topped up. The rate of ordnance
transfer will be based on the ordnance transfer system of the collier multiplied by the parent race’s underway
replenishment tech (unless the fleet is stationary). The missiles being loaded will be based on what is missing
from the ship’s magazine when compared to the class loadout, starting with the largest missiles first (although
smaller missiles will be loaded if there is insufficient time in the sub-pulse to load a larger one). However,
missiles will only be added using this order and missiles that do not match the current class loadout will not
be removed.
    When this flag is set to Replace Fleet or Replace Sub-Fleet, each collier will remove any missiles that do not
match the current class loadout and replace them with those from the class loadout (assuming the collier has a
sufficient stockpile) for any non-colliers within its own fleet (or sub-fleet). The collier will remove non-loadout
missiles from the target ship while it has magazine space remaining, then add class loadout missiles to create
space. Essentially, the collier will alternate loading and unloading as necessary to create the correct loadout.
    When this flag is set to Remove Fleet or Remove Sub-Fleet, the collier will unload all missiles from non-
colliers within its own fleet (or sub-fleet), as long as it has space to store them.
    The current ’Provide Ordnance to Fleet’ order has been replaced with several new orders to facilitate the
above. These include:
   • Join and Add Ordnance to Fleet
   • Join and Add Ordnance to Sub-Fleet

   • Join and Replace Ordnance in Fleet
   • Join and Replace Ordnance in Sub-Fleet
   • Join and Remove Ordnance from Fleet
   • Join and Remove Ordnance from Sub-Fleet

    The fleet containing the collier will become part of the target fleet and switch to an appropriate ordnance
transfer status depending on the order. You can also use an ’Absorb’ order to collect a collier with an existing
status set. I may look at adding ship-level conditional orders (rather than fleet) so that colliers/tankers can
detach when empty and return home without player supervision.
    A new ’Load from Ordnance Transfer Hub’ order has been added. This order requires a second fleet
containing at least one ordnance transfer hub as the destination. On arrival, any ships in the fleet with
magazines will receive ordnance according to their class loadouts until all magazines are full, or the ordnance
transfer hub runs out of ordnance. No ordnance will be removed by the hubs. All ships in the fleet will receive
ordnance, including colliers. Once completed, the fleet will move on to its next order. If the fleet containing the
ordnance transfer hub has any movement orders, the ordnance transfer will not take place and the ordnance
transfer order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of
ordnance transfer but they can all contribute ordnance.
    A new ’Replace at Ordnance Transfer Hub’ order has been added. This order functions in a similar way to
above except that any ordnance not in the class loadout will be removed by the hubs. The mechanics of this
process are the same as the ordnance transfer within fleets above.
    A new ’Unload to Ordnance Transfer Hub’ order allows colliers to deliver ordnance to the hubs.
    The existing ’Load Ordnance from Colony’ order will remain but can only be used at colonies that have either
a Spaceport or an Ordnance Transfer Station. On arrival, the fleet will receive ordnance until all its magazines
are full, or the colony runs out of appropriate ordnance. All ships in the fleet will be receive ordnance, including
colliers. Once completed, the fleet will move on to its next order. Multiple spaceports or ordnance transfer
stations at the colony will not increase the rate of ordnance transfer.
    The ’Unload Ordnance to Colony’ order also remains but can only be used at colonies that have either a
Spaceport or an Ordnance Transfer Station.
    Any order involving the transfer of ordnance to or from a colony or ordnance transfer hub will use the current
racial ordnance transfer tech to determine the rate of transfer.
    Note this means that significantly more planning will be required in this version of Aurora to ensure missile-
armed ships can be reloaded at the frontier. It will no longer be possible to dump ordnance on the nearest
available rock. Colonies will require a spaceport or an ordnance transfer station before they can support missile-
armed fleets. Alternatively, colliers can accompany fleets, or a deep space base with an ordnance transfer hub
can be established.

20.4    Automated weapon assignment
   Original post can be found here.

    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.

                                 Figure 15: Automated Assignment Example 1

                                Figure 16: Automated Assignment Example 2

   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.

         (a) Automated Assignment Example 3
                                                                  (b) Automated Assignment Example 4

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

                                                                  (b) Automated Assignment Example 6
         (a) Automated Assignment Example 5

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

                                                             (b) Automated Assignment Example 8
        (a) Automated Assignment Example 7

  An extreme example!

                                                             (b) Automated Assignment Example 10

        (a) Automated Assignment Example 9

20.5   Atmoshpere and energy weapons
  Original post can be found here.

  In C# Aurora, there is no penalty for energy weapons firing in or through an atmosphere.

20.6   Planetary bombardment
  Original post can be found here.

    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
    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.

                               Name                                   Target size
                               Automated Mine                                  20
                               Cargo Shuttle Station                          200
                               Civilian Mining Complex                        200
                               Construction Factory                            20
                               Conventional Industry                           20
                               Deep Space Tracking Station                     40
                               Fighter Factory                                 20
                               Financial Centre                                20
                               Forced Labour Construction Camp                 80
                               Forced Labour Mining Camp                       80
                               Fuel Refinery                                   20
                               Genetic Modification Centre                    400
                               Ground Force Training Facility                 400
                               Infrastructure                                   2
                               Low Gravity Infrastructure                       2
                               Maintenance Facility                            20
                               Mass Driver                                     20
                               Military Academy                               400
                               Mine                                            20
                               Naval Headqarters                              400
                               Ordnance Factory                                20
                               Ordnance Transfer Station                      200
                               Refuelling Station                             200
                               Research Lab                                   400
                               Sector Command                                 400
                               Spaceport                                     1000
                               Terraforming Installation                      100

Part V
Ground Forces
21     Unit design
   Original post can be found here.

    Ground Forces and Ground Combat are undergoing a huge expansion in C#. The VB6 Ground Unit becomes
the Formation and the VB6 Ground Unit Type becomes the Formation Template. However, there are no longer
any fixed unit types or unit values. Instead, there is endless scope for Formations and Formation Templates,
based on a detailed design process at the Formation level and below. This will allow the simulation of ground
forces from many science fiction genres. As this is a long topic, I am going to break it into several posts each
covering a different topic.
    The most granular level is the Ground Unit Class, which is an individual soldier or vehicle. One or more of
the same Ground Unit Class are grouped into Formation Elements, which in turn are grouped into Formations.
Formations remain intact for movement purposes, but combat involves each individual unit (each soldier or
vehicle). As individual units are now tracked for casualty purposes, readiness no longer exists. Morale is
tracked at the Formation Element level (which is a group of the same unit class), so the infantry in a Formation
may have a different morale than the anti-tank guns or artillery.
    The process of design starts with the Ground Unit Class. Two important factors in this design process are
the Racial Armour Strength and Racial Weapon Strength, shown at the top of the Ground Forces window.
    Racial Armour Strength is based on the strength of the highest racial armour technology. Conventional
Armour is 3, Duranium Armour is 5, et cetera. For this screenshot, the Commonwealth has researched Ceramic
Composite, which has a strength of 10.
    Racial Weapon Strength is based on the highest tech level (TL) among Laser Focal Size, Railgun Type,
Meson Focal Size, Particle Beam Strength and Carronade Calibre. For example, 15cm Laser Focal Size is TL3
as it is the third tech of that type. Racial Weapon Strength is the value of armour at the same tech level. In
this case, the Commonwealth has researched 20cm Laser Focal Size, which is TL4. The fourth Armour Tech
is Ceramic Composite, which has a strength of 10, so the Racial Weapon Strength is 10. The reason for using
Armour as the basis of Weapon Strength is partly because that means Ground Armour and Ground Weaponry
are aligned, and partly because it is straightforward way to assign value based on very different weapons.
    The Ground Unit Design tab of the new ground Forces window is shown below. First, a ’base type’ is chosen,
which is infantry, several sizes of vehicle, or static. Static in this sense is a weapon that is not self-mobile, such
as a towed anti-tank gun, towed artillery, et cetera. Static weapons remain in place when firing so they are
easier to hit than infantry or vehicles. Each base type has six main characteristics:
  1. Size (in tons): Size is the basis for transport requirements and cost, although there are other modifiers to
     cost (discussed below).
  2. Hit Points: Unit hit points are compared to weapon damage during combat to determine the chance of de-
     struction (the Damage Check). The chance of a weapon destroying a unit is (W eaponDamage/HitP oints)2 .
  3. Slots: The number of component slots available for the base type.
  4. To-Hit Modifier: Used to modify the chance of the unit being hit during combat (based on the mobility
     of the unit). This only applies if the unit is not fortified.
  5. Maximum Fortification: The maximum strength to which the unit can be fortified by construction factories
     or construction units. The Chance to Hit for a firing unit is divided by the Fortification Level of the target
  6. Maximum Self-Fortification: The maximum strength to which the unit can be fortified without construc-
     tion factories or construction units.
    The next section is Armour Type. The Armour of a unit is compared to the Armour-Penetration (AP) value
of a weapon. The chance to penetrate is equal to (AP/Armour)2 . For example, a weapon with AP 4 attacking
a unit with Armour 6 has a 45% chance to penetrate. The overall process for checking if a shot destroys a
target is Chance To-Hit, followed by Armour Penetration Check, followed by Damage Check. All three must
be successful to destroy the target. Each type of Armour has two values.
  1. Base AR: The Base Armour Rating is multiplied by Unit Size (including components below) to determine
     cost. So a unit with 6 armour would be 50% more expensive than the same unit with 4 armour.

  2. Racial AR: Racial Armour Rating is the Base Armour Rating multiplied by the Racial Armour Strength
     (shown at top of window).
    Below the base type and armour is a large section showing Components. Infantry, static and light vehicles
all have one ’component slot’, vehicles and heavy vehicles have two slots, while super-heavy and ultra-heavy
vehicles have three and four slots respectively. Each slot can hold one component from the list and the same
component can be put into multiple slots. Certain components are only available with certain base types. For
example, the Super-Heavy Anti-Vehicle component can only be used by super-heavy and ultra-heavy vehicles.
The primary component is selected from the main table, while any additional components are selected from
the dropdown(s) below the main table. Each component has a name and an abbreviation and is rated in nine
different areas:

  1. Size: The size in tons is added to the size of the base unit type.
  2. Armour-Penetration (AP): If the component is a weapon, the chance to penetrate a target’s armour is
     (AP/Armour)2 . The AP Rating is the underlying AP of the component (not shown), multiplied by the
     Racial Weapon Strength.

  3. Damage: If the component is a weapon, the chance to destroy a target after the armour has been penetrated
     is (W eaponDamage/HitP oints)2 . The damage value is the underlying damage rating of the component
     (not shown), multiplied by the Racial Weapon Strength.
  4. Shots: The number of times a weapon will fire during each ground combat phase.

  5. CIWS: ’Y’ indicates this component is a Close-in-Weapon-System, capable of defending the planet (on
     which the unit is based) from missile attack. This CIWS will use the values in the CIWS section, which
     will become visible when a CIWS component is selected. More on this in a later rules post.
  6. STO: ’Y’ indicates this component is a Surface-To-Orbit energy weapon, capable of engaging ships in
     space within weapon range of the planet on which the unit is based. The weapon type used for the STO
     component can be selected in the section to the centre right, which will become visible when an STO
     component is selected. More on this in a later rules post, although see the second screenshot.
  7. HQ: The headquarters capacity of the component in tons. This is the total size of the formation (or for-
     mation hierarchy) that can be effectively controlled by a commander based in a unit with this component.
     To assign a commander to a formation, one of the units within that formation requires a headquarters
     component. More details on command hierarchies will be provided in a future rules post.
  8. FFD: ’Y’ indicates this component is a Forward Fire Direction (FFD) component. Forward Fire Direction
     allows a front-line unit (more on that later) to direct the fire of bombardment units from a formation in
     a support position, fighters on close air support missions, or ships in orbit. A later rules post will explain
     this function.

  9. Const. The construction value of the component in Construction Factory Equivalents (CFEs).
    At the top-right of the window is the Capability section. One or more Capabilities can be selected for the
Unit Class. The Boarding Combat capability is required for a Unit to be able to board another ship. For all
other capabilities, the Chance to Hit is doubled in the environment specified. If a unit has multiple capabilities,
such as Mountain Warfare and Jungle Warfare on a world with a dominant terrain of Jungle Mountain, the
bonus is cumulative (i.e. 4x to-hit in this case). Each capability selected for a Unit will increase the cost by the
multiple specified. Some capabilities are only available for infantry units.
    In the bottom right section, a summary of the unit is shown in a similar style to the Class Summary for
naval designs. When the sizes of all the units in a formation are aggregated, that is the transport requirement
for that formation in tons. Cost is in BP. When the costs of all the units in a formation are aggregated, that is
the build point requirement to construct the formation. Armour and Hit Points have been described previously.
Below that is a list of components, followed by the materials required for construction and the research cost to
develop the unit once designed.

                                    Figure 21: Ground Forces Example 1

    This screenshot shows a static unit with an STO component selected. The chosen weapon (which is any
non-turreted weapon developed for shipboard use) is selected on the right. Spinal Weapons can be selected for
ground use without penalty. The STO mount includes the weapon, a reactor of the exact size needed for the
recharge rate, an active sensor with range greater than the weapon range and a built-in beam fire control with
a 4x range modifier. The cost is equal to the static platform, the weapon, the reactor, the active sensor and
half the fire control. STO weapons have a 25% bonus to fire control range. The damage shows two numbers,
which is the damage at minimum and maximum range.

                                    Figure 22: Ground Forces Example 2

22     Formation templates
   Original post can be found here.

   The screenshot below shows the Formation Templates tab of the Ground Forces window. Formation Tem-
plates are the equivalent of VB6 Ground Unit Types, although it might be easier to think of them as serving
the same function as Ship Classes. They are a detailed design that serves as a template for building Formations
based on that same design, which is the same relationship as Ship Classes to Ships.
   This tab is split into two halves. On the left is a list of available Ground Unit Classes created using the
Unit Class Design tab (as explained in the previous rules post). All of these were created using TL4 technology,
with three exceptions. For comparison purposes, the Challenger 2 Main Battle Tank and the Warrior AFV were
created using Conventional, rather than Trans-Newtonian, technology, while the Challenger Base TN Upgrade
was the Challenger design with TL1 technology. It should be possible to simulate most modern army units with
the new C# Aurora ground combat, so you could theoretically be landing on an alien world with Abrams and
Bradleys or T-14 and T-15 Armatas. The ten columns for the Unit Class List are as follows:
  1. Type: An abbreviation for the Base Type (infantry, Vehicle, Heavy Vehicle, etc.)
  2. Name: The name assigned during Unit Class Design. This can be changed using the Rename Unit button.
  3. Size: Transport size in tons.

  4. Cost: Cost in Build Points.
  5. Arm: The Armour Strength of the Unit. This is based on the armour available at the time of design and
     is not upgraded when newer technology becomes available (as with ship designs).
  6. HP: The Hit Points of the Unit. This is set at design time and does not change.

  7. Components A to D: Abbreviations for each of the components included in the Unit Class. These are the
     same abbreviations as used on the Components table in the Unit Class Design tab. As with armour and
     hit points, any components use the technology available at the time of unit design. To see the detailed
     view of the components, click on the Unit. The Unit Summary will be shown in the bottom section on
     the left hand side.

    As an example, the Leman Russ Battle Tank is a Heavy Vehicle of 104 tons, with 60 Armour and 60
Hit points, costing 12.48 BP. The components are Heavy Anti-Vehicle (HAV) and Heavy Crew-Served Anti-
Personnel (HCAP). Looking at the summary, the HAV has 1 shot per combat phase with Penetration 60 and
Damage 60, while the HCAP has 6 shots with Penetration 20 and Damage 10.
    The right-hand half of the tab shows Formation Templates. A new Formation Template is created by
clicking the New button. In this case, four have already been created. Each Template comprises one or more
Template Elements, shown in the bottom right section Each Template Element has a specific number of specific
Ground Unit Class. For example, the Guard Armoured Regiment is currently selected, which has four template
elements: 60x Leman Russ Battle Tank, 1x Macharius Command Tank, 12x Hydra Flak Tank and 24x Hellhound
Anti-Infantry Tank.
    Each template element has the following attributes:

  1. Name: The Unit Class for this element.
  2. Units: The number of units of that Unit Class in this element.
  3. Size: The total size on tons of this element. For example, 60 Leman Russ Battle Tanks at 104 tons each
     is 6,240 tons.

  4. Cost: The total cost in Build Points for this element.
  5. HP: The total aggregate hit points for the element.
  6. HQ: The headquarters capacity of the elements Unit Class in tons. If there are multiple units in a template
     element, only one is considered for the headquarters capacity. Any additional units are for redundancy.
     The headquarters capacity is the total size of the formation (or formation hierarchy) that can be effectively
     controlled by a commander based in a unit with this component. In the case of the Macharius Command
     Tank, it has an HQ capacity of 10,000 tons.

  7. FFD: The total number of Forward Fire Direction (FFD) components in the template element. Forward
     Fire Direction allows a front-line unit to direct the fire of bombardment units from a formation in a
     support position, fighters on close air support missions, or ships in orbit.
  8. Const. The construction value of the element in Construction Factory Equivalents (CFEs).
  9. CIWS: The number of Close-in-Weapon-System components in the template element, capable of defending
     the planet (on which the unit is based) from missile attack.
 10. STO: The number of Surface-To-Orbit energy weapon components in the template element. STOs are
     capable of engaging ships in space within weapon range of the planet on which the unit is based.
    The totals for each Template Element are added together to create the total for the Formation Template
as a whole, shown in the top right section. In the example shown, the Guard Armoured Regiment has a total
size of 8,942 tons, which is the combination of all four template elements. The Formation Template list has an
additional column for Rank. A default rank will be suggested by the program, although this can be overridden
by the player. This rank will be used by Automated Assignment process for any Formations built using this
Formation Template.
    To add new Template Elements to a Formation Template, use the Add Units button in conjunction with
the adjacent text field to specify the number of units in the new element. This number can be subsequently
edited by selecting the element and clicking the Edit Amount button. Both Formation Templates and Element
Templates can be deleted using the appropriate buttons.
    This screenshot shows the Macharius Command Tank on the left and the Brigade Headquarters formation
template on the right. The Macharius is a super-heavy vehicle, with two super-heavy anti-vehicle weapons and
an HQ4 component, which provides a headquarters capacity of 10,000 tons. This is a large and expensive vehicle
at 518 tons and 93.24 BP, but is well-protected as the loss of the HQ in a formation will result in the loss of
any commander bonuses (and maybe the commander himself).

                                 Figure 23: Formation Templates Example 1

    The Brigade Headquarters formation template includes two Guard Brigade Headquarters units, in case one
is destroyed, plus thirty-six large artillery pieces, twelve flak tanks and a company of Guardsman. Combat
involves three locations. Front-Line, Support or Rear-Echelon. Units in a Support position can only attack
using bombardment weapons, or defend themselves against air attack. This formation is intended to serve in the
Support location and is organising accordingly. However, it is possible for a Support Formation to temporarily
find itself moved into a Front-Line position, so the Guardsman Element will provide additional protection in
that case.

Figure 24: Formation Templates Example 2

Part VI
YouTube content creators