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

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

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.

In VB6 Aurora, the thermal detection of missiles is based on the following formula:

(Missile Size / 20) * (Speed / 1000)

I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed like a good idea at the time . For C# Aurora, missiles will use the same formula as ships for thermal signature:

Max Engine Output * (Current Speed / Max Speed) * Thermal Reduction

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

Commercial hangars are available in C# Aurora. They are 50% larger than military hangar bays (size 32), have the same cost of 100 BP and the same crew requirement (15).

They are intended for transport of other commercial vessels, temporary transport of military vessels, reloading of box launchers and for repairing ships. With this in mind, a military ship still has normal maintenance requirements while in a civilian hangar.

However, as you can maintain ships in deep space in C# Aurora it will be possible to build a large ship that could provide both commercial hangar space and maintenance, or combine ships with commercial hangars and ships with maintenance modules to provide a logistics hub.

In VB6, if a power plant is damaged, it slows down the recharge rate of all weapons by a proportionate amount.

In C# Aurora, power is allocated weapon by weapon until the available power is exhausted. This means that some weapons may not be recharged, but the others will be recharged at the maximum rate. Weapons are charged in order of ascending power requirement. Once a weapon is recharged, it will require no more power and other weapons can begin the recharge process.

This should allocate power in the most effective way to keep a ship in the fight.

I've added a non-military magazine to C# Aurora. There are two versions; one with 100 capacity and one with 500 capacity.

In general terms they are cheaper but less efficient in terms of space then military magazines. Also, they have a 100% explosion chance if hit, so don't apply for a job on a commercial ammunition transport

Even if you armour the ship, one of the magazines could still explode due to shock damage. As the magazines are fairly large, if they are hit then the ship is probably gone, so it would be a Bad Idea to take a commercial ammunition transport along with the battle fleet.

In VB6 Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to the commander's crew training rating. The maximum number of points is 2000.

In C# Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to 50% of the commander's crew training rating, plus 100% of the executive officer's crew training rating. This training will only happen if the ship has at least one command & control system undamaged. The maximum number of points is 1000.

A ship's crew grade bonus is equal to SQRT(Grade Points) - 10. So for VB6 Aurora the maximum is 34% and for C# Aurora it is 21%.

The net effect is that the grade bonus will be received more quickly but has a lower maximum value. The gap will be made up by the bonuses of other officers, such as the Tactical Officer or Chief Engineer.

This post provides more details. Every race starts with a single top level Admin Command (which can't be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy. Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command.

An Admin Command can be created at a population with a Naval Headquarters (a new installation). Each level of a Naval Headquarters costs 1200 BP and can be moved with the same cargo requirement as a research facility. Naval Headquarters function in a similar way to Sector Commands, with each doubling of the level adding +1 to the command radius. For example, level 1 has a Radius of 1, level 2 has a radius of 2, level 4 has a radius of 3, level 8 has a radius of 4, etc.. The command radius of the Admin Command is based on the Naval Headquarters in which it is based (with modifications for certain types of Admin Command). A single Naval Headquarters can support multiple Admin Commands.

If a fleet is within the command radius of its parent Admin Command, each ship within the fleet gains benefits based on the type of command and the bonus of the commander assigned to the Admin Command. There are seven different types of Admin Command, with the following capabilities.

Naval: Provides 25% of the Admin Command commander bonus for Crew Training, Reaction, Engineering and Tactical. (For example, if the commander has a 20% Reaction Bonus, a 5% bonus would be provided).

Patrol: Provides 25% of the Admin Command commander bonus for Reaction and Engineering. This command type operates at twice the command radius of the parent naval headquarters.

Survey: Provides 25% of the Admin Command commander bonus for Survey and Engineering. This command type operates at twice the command radius of the parent naval headquarters.

Logistics: Provides 25% of the Admin Command commander bonus for Logistics (cargo load/unload speed) and 10% of the bonus for Mining (including Harvesting) and Terraforming.

Industrial: Provides 25% of the Admin Command commander bonus for Mining and Terraforming, plus 10% of the bonus for Logistics.

Training: Functions differently to the others. Fleet Training can only take place within the command radius of a Training Admin Command (see later rules post for details). The crew training rating of the Admin Command commander is used as the basis for the speed of training.

Each Admin Command also gains additional bonuses if it is within the command radius of its own parent command. For example, if a survey fleet is within the command radius of a Survey Admin Command it will provide 25% of the bonus of the commander of that Survey Admin Command. If that Survey Admin Command is within the command radius of a parent Survey Admin Command, that bonus would be multiplied by 25% of the parent admin command commander bonus. So if both Admin Commands each had a commander with a 30% survey bonus, the total provided bonus to ships in the command radius of the lower Admin Command would be 15.56% (1.075 * 1.075). If a third layer existed above those two and that also had a commander with a 30% bonus, the overall bonus would rise to 24.23%.

This isn't as easy to achieve as it might seem as each of these Admin Commands will need an assigned commander or the chain will be broken. Also each superior Admin Command requires a commander of higher rank than the inferior Admin Command and any Admin Command with fleets directly attached requires a higher rank than the highest-ranked ship captain in those fleets. If an Admin Command does not have a commander of sufficient rank, it will not provide bonuses. Therefore, large hierarchies are difficult to achieve. However, this does give meaningful commands for those higher ranked commanders that currently are used as the captains of major warships. It also means that if you establish the necessary command infrastructure required to support your fleets across your territory, it can have substantial benefits.

The required rank for each admin command is updated when the commander or naval organisation windows are loaded and during each construction phase. The check for the required level of commander is performed during each construction phase. If this check fails, the player will be notified and the admin command will be ineffective until the next construction phase.

Each increment, the command radius of all admin commands is checked so that all activity within that increment will use up-to-date information. This is dynamic during the turn, so the position of a ship or fleet at the moment it checks a bonus is used to determine the effect of the command network. The command hierarchy is checked each increment and whenever you modify that hierarchy so that you will always have up to date information on what rank is required for each Admin Command.

This command network is created using the new Admin Command tab on the Naval Organization window (see below). The Admin Commands are in green on the main structure chart. Each one is prefixed by the type abbreviation and suffixed by the required rank and current location. Selecting an Admin Command shows the systems within range and any Naval Headquarters in those systems. There is also a list of all Naval Headquarters within your Empire and a breakdown of the different Admin Command types. New commands can be created by selecting a parent Admin Command, a host population and an Admin Command Type. Fleets can be dragged and dropped between Admin Commands as desired. I will also add a movement order specifying a change in Admin Command.

None of this functionality has to be used as all new fleets will be assigned to the single, starting Admin Command. However, for those players who wish to set up their own command structures, I hope this will add an interesting extra dimension to the game. As with all these changes, I may modify things a little as a result of play testing but the essential principles should remain the same.

In order to prevent unbalancing tech advancements occurring while excavating very large ruins, the maximum tech advancement you can achieve from recovering abandoned installations will be based on the tech level of the ruin race. The max development cost of any associated tech will be:

(2 ^ (Ruin Race Level + 1)) * 1000;

This means a level 1 ruin race will have tech up to 4000 RP, a level 2 race up to 8000 RP, etc. with the maximum being a level 5 race with tech up to 64,000 RP.

When standard components are selected for recovery (such as gravitational survey sensors), they will be the best available component within the above limit. If no component of the specified type is available within the limit (for example when the random selection is a 5000 RP Asteroid Mining Module for a level 1 race), nothing will be recovered.

In C# Aurora, the rules for accidental death and commander health remain as they are in VB6 Aurora.

Retirements are handled differently. An naval officer will be checked for the potential for retirement from service once the length of his career exceeds the minimum retirement time for his rank. The minimum retirement point is 10 years for the lowest rank. For other ranks it is equal to 10, plus 5 years for every level of rank above the minimum. So assuming lieutenant commander was the lowest rank, minimum retirement would be 10 years after career start for a lieutenant commander, 15 years for a commander, 20 years for a captain, etc..

For ground forces commanders the minimum retirement is 20 years for the minimum rank. For other ranks it is equal to 20, plus 5 years for every level of rank above the minimum.

For scientists and administrators the minimum retirement is 40 years.

The chance of the retirement occurring is 20% for each year beyond the minimum retirement date. This is doubled if the commander has no assignment. Each increment the chance is checked using: (Increment Length / One Year) * Retirement Chance.

The VB6 concept of 'tour length' does not exist in C# Aurora, so there will no longer be mass-reassignments every couple of years. In addition, the removal of officers after six years with no command will no longer happen. Instead, C# should have a more realistic progression because of the different mechanics. Firstly, inactive or low ranked commanders will tend to retire relatively early, which will keep overall officer numbers down and open up their commands (if one exists) for new assignments. Secondly, ships can potentially have multiple officers, which creates many more assignments. Thirdly, each ship (or other officer position) can only be assigned to an officer of a specific rank. As soon as that officer is promoted, he has to leave that position, which opens it up for another officer. Finally, naval officers in non-command positions (XO, Tactical Officer, CAG, Chief Engineer, Science Officer), will be automatically assigned to any ship command position that becomes available, assuming they have suitable bonuses, opening up their previous role.

Ship commander ranks are based on the following rules:

1) Assume lowest rank if none of the following conditions exist. Otherwise use the highest applicable rank for any condition.2) Lowest rank + 1 for any ship class equipped with any of the following: Geological or Gravitational Sensors, Auxiliary Control, Science Department, Jump Drive3) Lowest rank + 2 for any ship equipped with any of the following: Weapons, Military Hangar Bay, Main Engineering, CIC, Flag Bridge4) Regardless of the above, any ship of 1000 tons or less will be the lowest rank, unless it has one of the control stations (Auxiliary Control, Science Department, Main Engineering, CIC)

For example, the executive officer on a warship would be lowest rank + 1 (one lower than commander requirement) while the executive officer on an unarmed geological survey ship would be the lowest rank.

Overall, the variety of positions available at different ranks, combined with the positions opening up due to retirements, promotions and assignment of junior officers to ship command, should provide a more interesting career progression.

Auto-Assignment of naval commanders is similar to VB6, although the process is now more detailed.

Every class of ship has a Commander Priority, a Primary Assignment Priority and a Secondary Assignment Priority. The Commander Priority is set by the player, while the others are set by Aurora. Each class also has a Primary Bonus Type. When the list of ships without commanders is created every construction phase (during the auto-assignment phase) it is ordered by Commander Priority then by Primary Assignment Priority and then by Secondary Assignment Priority.

The ships are cycled through in that order, searching the available commanders (which is any unassigned commander or any commander assigned to a non-command position on a ship) for a suitable match for each ship. A suitable commander must have the primary bonus for the ship or they will not be assigned. In C# Aurora, unassigned commanders still have a small chance of gaining experience, including new bonuses, so they may be assigned in the future even if they currently do not have a suitable bonus.

Primary and Secondary Assignment Priorities and the Primary Bonus are set based on the following rules. Secondary Assignment Priorities are based on descending order for the ship class and the Primary Bonus is based on descending order for the commander.

SalvagerPrimary: 8Secondary: Number of Salvage ModulesBonus: Production

All OthersPrimary: 9Secondary: SizeBonus: Logistics

Bear in mind that all of the above is secondary to the priority given to each class by the player, so if you want a particular type of ship to get the best commanders assigned, give it a high priority.

After ship commanders are assigned, the non-command positions are assigned. Ships must have the appropriate command module for each non-command position in order for a commander to be assigned and the commander must have the required bonus. For each of the non-command positions (in the order below), the ships with an available position are ordered using the same rules as above, including the player priority. The positions and requirements are as follows:

An issue in VB6 is that crew morale is checked for all ships, yet for many ships (anything that is not a military ship or doesn't mount survey sensors), the morale is effectively irrelevant.

Therefore in C# Aurora, only ships for which morale is a potential issue will be checked for exceeding deployment time. This check is indicated by the addition of 'MCR' to the end of the Intended Deployment Time row of the class summary.

The requirement for a ship to have at least a 3 month deployment time in order to be classed as a non-military vessel still remains.

In VB6 Aurora, the player has to remember to add additional accommodation for the crews of parasite warships when designing a carrier, even without knowing the potential future parasites. These are known as Flight Crew Berths.

In C# Aurora, due to changes in the way crew morale and overcrowding are handled, the design process will automatically add 20 flight crew berths for each hangar bay. These berths are assumed to be sufficient for whatever parasite warships are present.

For C# I am trying to keep all the flavour of this area while simplifying the mechanics in general and adding a couple of additional mechanics that never made it into VB6. Each construction phase, every ship is checked according to the following rules:

Deployment Clock

Any military ship, or one equipped with geological survey sensors, has a deployment clock, similar to their maintenance clock, which is displayed on the fleet window in months

For ships outside hangar bays, the clock normally advances at a rate equal to the passage of time when the ship is anywhere except at a recreational location

A recreational location is any ship with a recreational module or any population of at least 50,000 people.

When any ship (including those in hangars) is at a recreational location, the deployment clock reduces at a rate equal to ten times the passage of time.

If a parasite is in a hangar bay but the mothership is not at a recreational location, the deployment clock of the parasite reduces at a rate equal to the following formula: Time Passed * 10 * (1 - Mothership Deployment Modifier));

The Mothership Deployment Modifier is equal to the Mothership Deployment Clock / Mothership Class Intended Deployment Time. In effect, the more time on the mothership deployment clock, the slower any docked parasites reduce their own clocks

If the Mothership Deployment Modifier is equal to or greater than 1, any parasite in the hangar cannot reduce its own deployment clock, although the time on the parasite clock will not grow either. This means that every time the parasite is deployed, its clock will continue to increase without the chance to reduce between missions.

A ship's morale is always 100% unless the ship's deployment clock exceeds the intended deployment time of its class (or for other reasons in subsequent sections). In that case, morale is equal to the intended deployment time / deployment clock. For example, a ship with a deployment clock for 15 months and an intended deployment time of 12 months would have a morale of 80%.

If the crew on the ship is less than half the required crew complement, morale is multiplied by (Current Crew / Class Crew) x 2;

Morale can never fall below 25% as a result of the above rules.

Overcrowding

Each construction phase, the total personnel on each ship is compared to the available accommodation (after accounting for damage). Personnel in this case equals the crew, any rescued survivors beyond the capacity of any cryogenic modules and the capacity of the flight crew berths (I may add a rule tracking whether the hangar is in use when checking the flight crew berths).

If the required accommodation is greater than the available accommodation, the ship is overcrowded.

The ship's deployment clock will increase at a rate equal to the time passed multiplying by the Overcrowding Modifier. For example, if the ship is 25% overcrowded, the deployment clock will increase at 1.5625x the normal rate (1.25 x 1.25).

If the overcrowding modifier is greater than 1.5, life support may begin to suffer damage.

The percentage chance of failure in any construction phase is equal to Overcrowding Modifier * 100 * (Increment Length / Year Length). That translates to a 3.1% chance per construction phase if the ship is 50% overcrowded, an 8.6% chance at 150% overcrowded and a 34.2% chance at 400%.

If failure occurs, a crew quarters system will potentially be damaged. This can be prevented in the normal way by maintenance supplies. If no maintenance supplies are available, the crew quarters will be destroyed.

Destruction of crew quarters will reduce available accommodation and increase the overcrowding problem. Eventually, if all crew quarters are destroyed, this will lead to complete life support failure.

Overcrowding is not checked on parasites in hangars, as it is assumed the flight crew berths and life support on the mothership will help with this situation. To avoid potential exploits of this simplification, any survivors on a parasite that docks with a mothership will be transferred to the mothership, unless they can be held in cryogenic modules on the parasite.

Life Support Failure

If a ship has no life support systems (due to combat damage or maintenance failures), it suffers the following penalties:

For any military ship or one equipped with geological survey sensors, the deployment clock increases at 12x the normal rate and morale is immediately reduced to 10%.

The crew takes casualties from 4% to 80% (4D20) of the remaining crew in each construction phase

Any survivors on board take casualties of up to 80% of the remaining survivors in each construction phase

Each commander on board the ship has a chance of dying equal to half the crew casualty percentage in step 2.

Life support failure is not checked for parasites in hangars, as it is assumed the flight crew berths and life support on the mothership will help with this situation.

If help is not close by, it may be better for the crew in these circumstances to abandon the ship and hope for rescue. This rule may also be a reason for a more common use of lifeboats.

Summary

This is still a long rule section but I hope it is more straightforward than in VB6 and will provide the background for building the support network required for distant deployments, plus the capacity to handle rescued crew members or prisoners of war.

I'm not sure if I have mentioned this anywhere else, so making sure here

The cargo handling speed of any ship is modified by the ship commander's logistics bonus and by any bonus from the parent admin command of the ship's fleet (assuming the fleet is within he command radius). Setting up a network of Logistic-focused Admin Commands has the potential to boost cargo handling considerably.