Aurora is on version 2.5.0 C#, available at the Aurora Forums.
Contact Erik on the forum for a wiki account.
C-Missiles
Missiles
Missile Detection
A new active sensor model has been implemented for C# Aurora. It is intended to create a situation where:
b) Missile combat ranges are reduced Date 20.05.2017
Missile Thermal Detection
In VB6 Aurora, the thermal detection of missiles is based on the following formula:
(Missile Size / 20) * (Speed / 1000)
I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed like a good idea at the time :). For C# Aurora, missiles will use the same formula as ships for thermal signature:
Max Engine Output * (Current Speed / Max Speed) * Thermal Reduction
As missiles (for now anyway), don't have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora. Date 09.07.2017
Missile Electronic Warfare and Sensors
Missile ECM
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.
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). Date 11.06.2017
Missile ECCM
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.
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). Date 11.06.2017
Missile Sensors
Any missile sensor (active, thermal, EM or Geo) has to be a minimum of 0.25 MSP or it will have no effect. Date 11.06.2017
Missile Engines
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)
http://www.pentarch.org/steve/Screenshots/FuelModelV2.PNG Date 14.05.2017
Engine Boost
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
|
C# Missile Engine with 2x Boost
|
VB6 Missile Engine with 4x Boost
|
C# Missile Engine with 4x Boost
|
Missile Launcher
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. Date 28.07.2018
Fighter Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods.
Date 22.09.2018]
Missile Magazines
please refer to C-Ship Modules
Reloading
Basics
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. Date 28.07.2018
Box Launcher Reloading
In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities.
For C# Aurora, box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).
Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers if they could still use those facilities to reload, especially given they are immediately available in C#. The introduction of ordnance-specific facilities for C# provides a good alternative.
General Changes
Armour Damage Templates
In VB6 Aurora, the damage templates for each weapon are held in a database table, with one row for each combination of weapon type and damage amount. While this is simple, it mean any new weapon or change to damage model has to be laboriously updated in the table.
For C#, the damage templates are generated in code as needed based on a 'gradient' system. All the damage starts at a single point and is distributed right and left according to the gradient setting. Any column which has damage greater than the gradient, checks left and right. If an adjacent column has a damage amount that is lower than the current column damage minus the gradient, a single point of damage is moved to that column. The adjacent column with lower damage is used first. The code cycles back and forth through the columns until no more adjustments are necessary
For example, missile damage has a 'gradient' of 1. Therefore, there cannot be a gap of 2 damage between adjacent columns. Laser damage has a gradient of 3, so any gap of 4 damage between columns is corrected. Here are some examples for 25 damage:
- Gradient 1 (Missile, Carronade, Ramming): 1,2,3,4,5,4,3,2,1
- Gradient 2 (Railgun, Particle Torpedo): 1,3,5,7,5,3,1
- Gradient 3 (Laser): 3,6,8,5,3
Particle Lances cause damage in a single column, gauss cause only a single point of damage and meson ignore armour.
The template generation takes about a millisecond so there is no performance issue. This means that new weapons with higher gradients can be added very easily.
Missile Launch Detection
In VB6, missiles are only detected after their first movement sub-pulse. This is due to the sequence of play of Movement -> Detection -> Combat. Consequently, a missile ship close enough to an opponent for its missile to cover the distance in less than five seconds can avoid point defence entirely, because there is no opportunity to detect the missile before impact.
In C#, an additional detection phase takes place after missile launch, which is restricted to the detection of newly launched missiles at the point of launch. This means that no matter how close the missile ship is to its opponent, the missile will be detected if the opponent has sensors capable of detecting it. The missile will still be in the same location as the launching ship when this detection phase takes place.
Planetary Bombardment
Shock Damage Update
Shock Damage in C# Aurora will operate as follows:
- 1) The chance of shock damage is equal to: Damage Caused to armour / Size of Ship in HS. For example a 9 point warhead vs a 6000 ton ship has a 7.5% chance of shock damage. A 16 point energy impact vs 10,000 ton ship has * an 8% chance of shock damage.
- 2) Any damage with less than a 5% chance is ignored as too small (i.e. any damage where the strength is less than 5% of the ship HS)
- 3) If shock damage occurs, the shock damage is rolled randomly up to 20% of armour damage
Where the armour damage is easily divisible by 5, for example a 15 point warhead, there is a random roll from 1 to max shock damage (1-3 in this case). Where the armour damage is not divisible by 5, the max shock damage is the amount divisible by 5 (rounded) down plus a percentage chance of an extra 1 max shock damage equal to the percentage of 5 remaining. For example, a 12 point warhead would be assigned 2 max shock damage approximately 60% of the time and 3 max shock damage 40% of the time.
Weapon Failure
At the point when any weapon (energy-based or missile launcher) fires, there is a 2% chance the weapon will suffer a failure. If sufficient maintenance supplies are available, the weapon will be instantly repaired and will fire normally. If maintenance supplies are not available, the weapon will be damaged and unable to fire.
This is partially to simulate the stress of combat on weapon systems, but also as a balance to other rule changes.
Removed Components
- Laser Warheads have been removed Date 11.06.2017
- Missile Armour has been removed. Date 11.06.2017
- Missile series have been removed. Instead, there will be more detailed class loadout options. Date 11.06.2017
Fighter Pods for Ground Combat
In C# Aurora, fighter-sized ships can be equipped with a new component, the Fighter Pod Bay, which is similar in function to a small Box Launcher, except it will only hold Fighter Pods (see below).
http://www.pentarch.org/steve/Screenshots/GroundSupport004.PNG
Fighter Pods
Fighter Pods are created on the Missile Design window.
The various pod options, such as bombardment pod, autocannon pod and air-to air pod, will appear when the requisite technology has been researched.
When one of those options is selected, the warhead strength field is replaced by a pod size field. The player can choose the pod size, with larger pods being more effective.
The pod capabilities will be similar to the capabilities of equivalent-sized ground unit components, although the fighter pods have more flexibility in design.
| For example, a bombardment pod will have three shots, armour penetration equal to Racial Weapon Modifier * ((Tons / 20) ^ 0.6) and damage equal to Racial Weapon Modifier * ((Tons / 20) ^ 1.6). |
Fighter pods are ordnance, in exactly the same way as missiles. They are built by ordnance factories, transported in magazines and loaded onto fighters.
Unlike missiles, they are not expended when fired and will function during ground combat phases.
http://www.pentarch.org/steve/Screenshots/GroundSupport002.PNG
http://www.pentarch.org/steve/Screenshots/GroundSupport003.PNG
Fighter Pod Bays
A fighter can be designed with fighter pod bays. Different pods can be assigned to those bays while the fighter is in a hangar, providing flexibility of loadout. The same fighter could be used for bombardment or autocannon pods, as long as the pods bays are large enough and the parent carrier has both types of pods available. The pods can be assigned to the fighter using the normal ordnance loadout. The pods require a missile fire control to operate, although this can be minimal size (0.1 HS) as there are no range or resolution restrictions.
Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods.
Because of this efficiency, the minimal-size fire control and no requirement for active sensors in ground combat missions, dedicated ground support fighters can be much smaller than their space combat equivalents. It is also possible to have hybrid designs mounting both pods and box launchers. Due to the requirement for smaller engines for dedicated ground support aircraft, ship engines can now be designed from 0.1 HS in size.
http://www.pentarch.org/steve/Screenshots/GroundSupport005.PNG
