C# Aurora Changes List v1.00

[Steve Walmsley (OP)]

New Species Attributes

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

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

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

[Steve Walmsley (OP)]

Command & Control Rules

I am introducing new command and control rules for C# Aurora. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill). However, additional officers can be assigned to the ship with each officer applying his full bonus for his chosen speciality (more on that later). The commander of the ship is now a jack-of-all-trades, applying a portion of his bonus while the specialists provide the larger bonuses. Larger ships gain an advantage as they can afford the space to accommodate the specialists, while smaller ships have to make do with the commander handling everything (at half efficiency). Any bonuses not mentioned here (such as Reaction or Production) will still be at full value for the commander.

Five new command and control modules have been added, the cost of the bridge has been doubled and the role of the flag bridge has been changed. Each module adds one to the Control Rating of the ship.

1) Bridge is 1 HS and costs 20 BP. The required rank for the ship commander is the racial minimum.

2) Auxiliary control is 1 HS and 15 BP. Allows the assignment of an Executive Officer to the ship who will apply his full Crew Training Bonus. The required rank for the ship commander is one above the racial minimum.

3) Science Department is 2 HS and 50 BP. Allows the assignment of a Science Officer to the ship who will apply his full Survey Bonus. The required rank for the ship commander is one above the racial minimum.

4) Main Engineering is 3 HS and 75 BP. Allows the assignment of a Chief Engineer to the ship who will apply his Engineering Bonus to affect maintenance and damage control. The required rank for the ship commander is two above the racial minimum.

5) Combat Information Centre (CIC) is 3 HS and 75 BP. Allows the assignment of a Tactical Officer to the ship who will apply his Tactical Bonus to various combat-related function (TBD). The required rank for the ship commander is two above racial minimum.

6) Primary Flight Control is 4 HS and 100 BP. Allows the assignment of a Commander Air Group to the ship who will apply his full Fighter Operations Bonus. The required rank for the ship commander is one above the racial minimum.

7) Flag Bridge is 5 HS and 125 BP. A fleet that includes a ship with a flag bridge can assign a 'fleet commander' senior to the commander of the ship. If a fleet has multiple flag bridges, the most senior officer assigned to any of them will be the fleet commander. The fleet commander will improve the fleet's overall reaction rating by his Reaction Bonus. If there are no flag bridges in a fleet, the senior ship commander will be the de facto fleet commander, but his reaction bonus will not affect other ships. The required rank for the ship commander of the ship with the flag bridge is two above the racial minimum. There are no longer any task forces or staff officers. Any commander assigned to a flag bridge who is not the most senior in the fleet will be referred to as a 'Flag Officer'.

In cases where different control stations have different required ranks for the ship commander, the highest rank takes precedence.

An officer can be killed if his station is damaged. I may also add 'temporary promotions' if the commander is killed, with the most senior surviving officer taking over as commander until relieved or promoted.

Except for the ship commander and the executive officer, the bonus from each specialist will only apply if their associated module is undamaged. Bonuses from the commander and XO will only apply if the ship has a control rating greater than zero (they can command the ship from any of the surviving control spaces). Ships smaller than 1000 tons automatically have a control rating of 1, even without a bridge. This is to simulate that small ships do not require a dedicated centralised command function.

I don't plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won't be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.

For auto-assignment purposes, each ship class now has a specific rank requirement for its commander, based on its command and control modules. The rank requirement for the XO, CAG and Science Officer is one lower than for the ship commander. The rank requirement for the Chief Engineer and Tactical Office is two lower than the ship commander. The rank requirement for a fleet commander is one higher than for the ship commander. You can manually assign higher-ranked ship commanders and fleet commanders if desired but other officers can only be assigned at the specified rank. The commander priority setting for each class of ship remains as before and is still set manually. It also applies to the other officer types as well. Auto-assignment will work in the following sort order:

1)   Class Priority
2)   Survey Ships by descending size
3)   Warships by descending PPV
4)   Unarmed Military Ships by descending size
5)   Construction Ships by descending construction speed
6)   Terraformers by descending terraforming capacity
7)   Sorium Harvesters by descending harvesting capacity
8)   Asteroid Miners by descending mining capacity
9)   Salvage Ships by descending salvage capacity
10)   All other ships (primarily freighters and colony ships) by descending size

Ship commanders will be assigned first (checking every category above), followed by executive officers, science officers, air group commanders, chief engineers and tactical officers. The ships will cycle through in priority order and commanders will be assigned if they meet the criteria for the ship type (correct rank and suitable bonus).

These changes should make ship design more interesting, create better histories for commanders (as they progress through different roles) and provide lots of potential roles for the junior commanders.

[Steve Walmsley (OP)]

New Maintenance Rules

In VB6 Aurora, the maintenance facilities of a population, aided by ships in orbit with maintenance modules, have a maximum maintenance capacity measured in tons. Any ship of that size or less can be maintained. Fighters cannot be maintained in this way and have to be stored in hangars.

In C# Aurora, maintenance facilities and modules are handled differently:

1)   Each maintenance facility or maintenance module has a basic capacity of 1000 tons. A new tech line exists that can raise this capacity in increments, starting with 1250 capacity for 2000 RP. The 2000 ton capacity is at 8,000 RP and the max is currently 6250 tons at 250,000 RP.

2)   Any location that contains a population with maintenance facilities or a ship with maintenance modules is known as a 'Maintenance Location'. This does not need to be in the same location as a population. A Maintenance Location consisting only of ships with maintenance modules could be in deep space.

3)   The maintenance capacities of all populations and maintenance ships of the same race in the same Maintenance Location are added together to create a 'Total Maintenance Capacity'.

4)   A Maintenance Location can fully maintain ships in its location if the total tonnage of those ships is equal to or less than the Total Maintenance Capacity. In other words, maintenance is now based on summing the tonnage of ships to be maintained, rather than supporting all ships under a set tonnage.

5)   If the total tonnage of the ships to be maintained is greater than the Total Maintenance Capacity, each ship will be partially maintained. This is known as the 'Effective Maintenance Rate (EMR)' For example, if the Total Maintenance Capacity is 80,000 tons and the total tonnage of the ships requiring maintenance is 100,000 tons, the EMR is 80%. Each ship will use 80% of the normal amount of MSP required for maintenance. Each's ship maintenance clock will advance at 20% of normal and their chance of system failure will be 20% of normal.

6)   The maintenance capacity of maintenance facilities on a population is modified by the population's Manufacturing Efficiency (available worker / required workers), Radiation Production Modifier, Political Stability Modifier (based on unrest) and Political Status Production Modifier (Conquered / Subjugated, etc.). The capacity of both maintenance facilities and maintenance modules is modified by the racial Economic Production Modifier (amount of debt vs annual income).

7)   Ships can enter overhaul in the same way as they do now, except they can also do this at a deep space Maintenance Location as well as at a population. Overhauls will proceed at a slower rate (and use fewer MSP) if the total tonnage of the ships being maintained exceeds the Total Maintenance Capacity. However, ships undergoing overhaul will not suffer maintenance failures in this situation.

8)   Fighters can be maintained by Maintenance Locations and do not need to be stored in hangars (because now they use capacity whereas the VB6 rule was implemented to prevent unlimited fighters being maintained).

Use of Maintenance Supply Points (MSP):

1)   MSP are used in a very similar way to VB6 Aurora. While a ship is being maintained, it requires total MSP per year equal to Class Cost / 4. A ship undergoing overhaul requires total MSP per year equal to Class Cost.

2)   If the ship is being maintained in a situation where the total tonnage of the ships being maintained is greater than the Total Maintenance Capacity (EMR less than 100%), the MSP requirement will be reduced accordingly (see above).

3)   The ship being maintained will use up MSP from any racial populations in the same location, in descending order of MSP stockpile. If no populations are available, or have no MSP, the maintained ship will use MSP from any Supply Ships in the same location, in descending order of available MSP. Finally, if no other option is available, the maintained ship will consume its own MSP. A ship can use a combination of the above to locate sufficient MSP.

4)   If the ship cannot locate sufficient MSP to meet the requirements for maintenance, this also has an impact on the Effective Maintenance Rate (EMR) for that specific ship. For example, assume a Maintenance Location with a capacity of 80,000 tons is maintaining 100,000 tons of shipping. The EMR for that Maintenance Location is 80%. A ship with a class cost of 1500 BP is being normally maintained and will require annual MSP equal to (Class Cost / 4) * EMR or (1500 / 4) * 80% = 300 MSP. If the ship can only locate 240 MSP, the EMR will be reduced by the proportion of available MSP to required MSP: (240 / 300) * 80% = 64%. The ship will now consume 240 MSP, the maintenance clock will be advanced at 36% of normal and the chance of system failure will be 36% of normal. (in reality the MSP numbers will be much smaller as during a single increment the ship is being maintained for only a small fraction of a year).

5)   The order in which ships are checked for available MSP is based on Class Maintenance Priority, then by Overhaul vs. Normal Maintenance, then by highest maintenance clock.

6)   The chance of system failure, whether away from a Maintenance Location or while being partially maintained, is reduced by the crew grade bonus (or increased for crews with a negative bonus) and the ship's Engineering bonus (50% of commander bonus and 100% of Chief Engineer bonus).

These new rules remove many of the maintenance restrictions on larger ships and make maintenance of FACs and fighters more realistic. They introduce the same economic factors to maintenance that exist for production. In addition, I believe this creates a more realistic environment where the required maintenance facilities / modules are tied to the absolute amount of ships to be maintained, rather than just their maximum size. Finally, maintenance can now be carried out away from population centres, making deep space bases a possibility.

[Steve Walmsley (OP)]

Colony Cost

The colony cost algorithm has been updated for C# Aurora to include hydrosphere extent, low gravity and tide-locked worlds and to change the rules for dangerous gases and max pressure. The new calculation is as follows:

Gas Giants, Super Jovians and worlds with a gravity higher than species tolerance cannot be colonised and therefore have no colony cost. Every other body has a colony cost that is equal to the highest colony cost factor from the following list:

Temperature: If the temperature is outside of the species tolerance, the colony cost factor for temperature is equal to the number of degrees above or below the species tolerance divided by half the total species range. For example, if the species range is from 0C to 30C and the temperature is 75C, the colony cost factor would be 45 / 15 = 3.00. The colony cost factor for tide-locked planets is 20% of normal, so in the example given the colony cost factor would be reduced to 0.60.

Atmospheric Pressure: If the atmospheric pressure is above species tolerance, the colony cost factor for pressure is equal to pressure / species max pressure; with a minimum of 2.00. For example, if a species has a pressure tolerance of 4 atm and the pressure is 10 atm, the colony cost factor would be 2.50. If the pressure was 6 atm, the colony cost factor would be 2.00, as that is the minimum.

Breathable Gas: If the atmosphere does not have a sufficient amount of breathable gas, the colony cost factor for breathable gas is 2.00. If the gas is available in sufficient quantities but exceeds 30% of atmospheric pressure, the colony cost factor is also 2.00.

Dangerous Gas: If a dangerous gas is present in the atmosphere and the concentration is above the danger level, the colony cost factor for dangerous gases will either be 2.00 or 3.00, depending on the gas. Different gases require different concentrations before becoming 'dangerous'. Halogens such as Chlorine, Bromine or Flourine are the most dangerous at 1 ppm, followed by Nitrogen Dioxide and Sulphur Dioxide at 5 ppm. Hydrogen Sulphide is 20 ppm, Carbon Monoxide and Ammonia are 50 ppm, Hydrogen, Methane (if an oxygen breather) and Oxygen (if a Methane breather) are at 500 ppm and Carbon Dioxide is at 5000 ppm (0.5% of atmosphere). Note that Carbon Dioxide was not classed as a dangerous gas in VB6 Aurora. These gases are not lethal at those concentrations but are dangerous enough that infrastructure would be required to avoid sustained exposure.

Hydrosphere Extent: If less than twenty percent of a body is covered with water (less than 20% Hydro Extent), the colony cost factor for hydro extent is (20 - Hydro Extent) / 10, which is a range from zero to 2.00.

Low Gravity: If the gravity of the body is lower than the species tolerance, the colony cost factor for gravity is 1.00. In addition, the overall colony cost for the body will be suffixed by 'LG', for example 2.00 LG, which indicates that low gravity infrastructure is required for any population on that body. Normal infrastructure will not count toward the supported population.

[Steve Walmsley (OP)]

Terraforming Update

In terms of the general mechanics, terraforming works as it does in VB6 Aurora. Atmosphere measured in atm (atmospheric pressure) is added by terraforming ships or installations. However, there are several significant changes for C# Aurora.

1)   The base terraforming technologies have their atm rates reduced by 75% at the lower tech levels. The rate of tech increase has improved so the higher tech levels are reduced by around 60%. The starting racial tech rate per module/installation is 0.00025 atm per year.

2)   Smaller planets are much faster to terraform. The terraforming rate in atm is modified by Earth Surface Area / Planet Surface Area. For example, the rate at which atm is added to Mars is 3.5x faster than on Earth (90% of VB6 Aurora speed), Ganymede is 6x faster and Luna is almost 14x faster (3.4x faster than VB6)

3)   System Bodies with gravity of less than 0.1G cannot retain atmosphere and therefore cannot be terraformed

4)   Carbon Dioxide is now a dangerous gas.

5)   Water is now a significant factor in terraforming planets. Any planet with less than 20% water has a colony cost factor for water equal to (20 - Hydro Extent) / 10 (see colony cost rules).

6)   Water vapour can be added to the atmosphere just like any other gas.

7)   Water vapour will condense out of the atmosphere at a rate of 0.1 atm per year and increase the planet's Hydro Extent

8)   Each 1% of Hydro Extent requires 0.025 atm of water vapour. This means that creating 20% Hydro Extent would require 0.5 atm of water vapour (this will be much faster on smaller worlds because the speed at which water vapour atm is added is linked to surface area). With this in mind, existing water becomes an important factor in the speed at which terraforming can be accomplished, especially on larger worlds.

9)   Water will also evaporate into the atmosphere. The evaporation cycle follows condensation and will stabilise water vapour in the atmosphere of a planet with liquid water at a level of: Atmospheric Pressure * (Hydro Extent / 100) * 0.01 atm. The resulting atm * 20 is the % of the planet's surface that loses water. As the water vapour is removed from the atmosphere, it will replenish from the surface water. This is to allow the removal of water from ocean worlds to create more living space.

These new rules should add more variety to terraforming and, in conjunction with the max population rules, should add more interesting decision-making when choosing which worlds to terraform.

[Steve Walmsley (OP)]

Engine Size and Fuel Consumption

In C# Aurora, missile and ship engines follow a single fuel consumption rule. The modifier is equal to SQRT (10 / Engine Size in HS). Thanks to alex_brunius for the formula.

The new rule creates a smooth transition for both engine types, which is more realistic and consistent, provides a bonus to larger ships, makes the fuel portion of missile design more interesting (as fuel is not a major concern at the moment) and allows larger engines to be designed beyond the current 50 HS limit.

This will complement the new sensor changes as they will reduce missile ranges anyway (described in the changes discussion thread but not published here yet)



As a result of these changes, a new Maximum Engine Size tech progression has been added. The starting max engine size is 25 HS. The research progression is 40 HS, 60 HS, 100 HS, 160 HS, 250 HS and 400 HS, with the costs ranging from 2,000 RP to 60,000 RP.

[Steve Walmsley (OP)]

Plasma Carronades

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

[Steve Walmsley (OP)]

Particle Lance

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

[Steve Walmsley (OP)]

New Active Sensor Model

A new active sensor model has been implemented for C# Aurora. In VB6 Aurora, there is an issue that active sensor ranges become so huge with large size-50 sensors, that the standard tactic is to create a ship with such a sensor so that it can watch the entire inner system, taking away some of the fog of war. In addition, such extreme-range sensors allow ultra-long range missile combat, giving the race that possesses such sensors a major advantage. The following change is intended to create a situation where:

a) Multiple scouts or pickets become a serious alternative to one huge sensor.
b) Missile combat ranges are reduced
c) Fog of war is increased, leading to more interesting exploration and combat.

The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:

Sensor Range = Racial Sensor Strength * HS * Racial EM Sensitivity * SQRT(Resolution) * 10,000 km

The C# model uses similar basics and leaves all the existing technology in place. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors. In addition, the modifier for resolution has been adjusted from square root to the power of (1 / 1.5). Because of this formula, smaller, lower resolution sensors are now more effective than the VB6 equivalents (much more in some cases), making earlier detection of missiles and fighters possible for non-specialised ships. The new formula is:

Sensor Range = SQRT((Racial Sensor Strength * HS * Racial EM Sensitivity * (Resolution ^ (1/1.5)) / PI) * 1,000,000 km

The following screenshots are based on the Commonwealth in my current campaign, which has active sensor strength 21 and EM sensitivity 11.

[Steve Walmsley (OP)]

Power Plant Changes

Power plants will no longer have linear power vs size. Additional power will be produced by larger reactors, using a similar formula to the increase in fuel efficiency for larger engines. This change will provide a reason to create larger power plants and will result in a small improvement in energy weapon capabilities. The table below shows power per HS and total power for a given size of reactor. This value is multiplied by the base technology of the power plant (Pressurised Water, Pebble Bed, etc).



The additional boost provided by the "Power Plant Boost" technology line provides double the previous bonus, with lower research costs and slightly higher explosion chances. This is intended for smaller ships that are short on space. The updated tech line provides between 10% and 100% additional boost with research costs between 500 RP and 30,000 RP.

[Steve Walmsley (OP)]

Engine HTK

Due to their size, Engines in VB6 Aurora create a damage shield because their HTK is very high compared to the amount of damage they are likely to receive. This would only become worse in C# Aurora with much larger engines now possible.

Therefore, the Engine HTK will change from 50% of Size to SQRT(Size).

[Steve Walmsley (OP)]

Shield Generators

Shield generators have been overhauled for C# Aurora to make them more interesting.

1) Shields no longer require fuel.
2) Shield generators can be created from 1 HS to 50 HS in size.
3) A new tech line has been added for maximum shield generator size. The starting tech is 10 HS and there are seven further steps from 12 to 50 with RP costs between 2000 RP and 120,000 RP.
3) The strength of the generator is modified by its size using the formula SQRT(HS/10). This means a 10 HS generator will have standard strength, a 1 HS generator will have 32% of normal strength and 50 HS generator will have 224% of normal strength
4) Recharge rates remain as before so a 10 HS shield will recharge at the same rate as an equivalent tech VB6 shield generator. Larger generators will recharge more slowly. For example, a 40 HS generator has 200% strength so will take twice as long to fully recharge.
5) HTK is the square root of the size, so it is easier to take out a single 50 HS generator than five 10 HS generators.
6) Cost of shields has been doubled
7) The only mineral involved in building shields is Corbomite.

In general, this means that shields become stronger than before and larger ships have an advantage when using shield generators. However, they also cost more, require more investment in research and are easier to destroy.

[Steve Walmsley (OP)]

Missile Engines

In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula: SQRT (10 / Engine Size in HS)

The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still consistent with ship engines.

Therefore, the calculation for fuel consumption based on boosting engines will now include an additional multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


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

[Steve Walmsley (OP)]

Missile Launcher Changes

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) - note that reload for this was x15 in VB6.

If a box launcher containing a missile is damaged, the missile will explode. The chance of this happening can be reduced by a new tech line. The first step reduces the explosion chance to 70% for 1000 RP and the last step reduces to 5% for 120,000 RP. In addition, Box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).

The base reload rate for all missile launchers is now: (SQRT(missile size) * 30 seconds * Reduced Size Modifier)  / Reload Rate Tech.

Assuming a race has reload rate tech of 3, a normal size 1 launcher will reload in 10 seconds, a size 4 will reload in 20 seconds and a size 9 will reload in 30 seconds. This change will dramatically reduce reload times for larger launchers.

The change for box launcher reload rate from x15 to x100 is not as dramatic as it seems for larger missiles due to the new reduced reload times for larger missiles. However, it is still an significant increase from VB6. A size 4 missile mounted on a box launcher will now take about 1h 40m to reload in a hangar and about 17 hours for an ordnance transfer point. A size 6 is about 2 hours and 20 hours respectively.

These changes are intended to:
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.

[Steve Walmsley (OP)]

New Passive Sensor Model

A new passive sensor model has been implemented for C# Aurora, using similar principles to the new active sensor model. In VB6 Aurora, small ship-based passive sensors are not particularly effective compared to active sensors in terms of detection, although their passive nature does allow a ship some sensor capability without giving away its position. Planet-based passive sensors (deep space tracking stations) are very effective as they can be stacked to cover the whole star system,

The C# Aurora passive sensor model substantially improves small passive sensors, particularly against small signatures, while dramatically reducing the benefits of creating large numbers of deep space tracking stations.

The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:
Detection Range = Passive Sensor Strength * Target Signature * 1000 km.  For example, a strength-10 thermal sensor would detect a signature-500 target at 5m km (10 * 500 * 1000).

The C# model uses all the existing technology and tech values. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors.
Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km. The same example as above would result in the strength-10 thermal sensor detecting the signature-500 target at 17.7m km.

Because of the great improvement in the performance of small passive sensors, there will no longer be an inherent size-1 passive sensor on all ships. In addition, the smallest functional passive sensor on a missile will be 0.25 MSP.

The screenshot below demonstrates the difference between the two models.