Author Topic: C# Aurora Changes List v1.00  (Read 573314 times)

0 Members and 10 Guests are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #75 on: March 14, 2018, 08:22:52 AM »
Combat Reports

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

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





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





The ship is finally destroyed by the next volley.

« Last Edit: March 14, 2018, 08:59:56 AM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #76 on: March 17, 2018, 02:35:07 PM »
Point Defence

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

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

A target population will use any ground units assigned to point defence to shoot at incoming missiles. If that is insufficient, the same process as for ships will take place, checking same race or allied ships within point defence range of the planet.
« Last Edit: December 12, 2018, 10:37:46 AM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #77 on: March 22, 2018, 01:50:46 PM »
Known Stars Changes

This is a placeholder for Known Stars changes as I make them

Added the following stars:



Renamed several stars:

 
The following users thanked this post: Laurence, waresky, Garfunkel, Britich, SpikeTheHobbitMage, Tristitan, TMaekler, serger, Rye123, Detros

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #78 on: March 24, 2018, 02:58:59 PM »
Magazine Design

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.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #79 on: March 25, 2018, 10:33:54 AM »
Automated Weapon Assignment

C# has a more intelligent auto-assignment for weapons and fire controls. You can set up a ship with a single click and then adjust as necessary. The code assumes that
  • Any missile fire control with a resolution of 1 is an anti-missile fire control
  • Any missile fire control with a resolution greater than 1 is a 'normal' missile fire control
  • Any beam fire control with a tracking speed at least 2x racial speed is a point defence fire control (some leeway here for older ships)
  • Other beam fire controls are for offensive weapons
  • Weapons within the given category (missile PD, missile offensive, beam PD, beam offensive) are split equally between fire controls of the same category
  • More powerful beam weapons are assigned first
  • ECCM is assigned as available with the priority order of offensive launcher, PD launcher, offensive beam, PD beam
The assignment code will take account of damage to the ship and adjust accordingly. In most cases, the above will be sufficient (and will be used for NPR designs). For more bespoke and unusual player ships, some tweaking may be necessary.

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





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





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





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





An extreme example!




Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #80 on: March 25, 2018, 01:11:59 PM »
Communication Attempts

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

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

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

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

This should add more realism and a little more tension to first contact.
« Last Edit: June 25, 2019, 03:07:59 PM by Steve Walmsley »
 
The following users thanked this post: davidr, Garfunkel, Britich, SpikeTheHobbitMage, Tristitan, TMaekler, serger, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #81 on: April 07, 2018, 09:09:34 AM »
Weapon Failure

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 changes.
« Last Edit: January 17, 2020, 05:06:22 AM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #82 on: April 07, 2018, 09:11:09 AM »
Atmosphere and Energy Weapons

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

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #83 on: April 07, 2018, 09:56:38 AM »
Planetary Bombardment

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

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

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

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

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

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

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


Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #84 on: April 07, 2018, 12:56:10 PM »
Ground-based Geological Survey

Geological Survey Teams do not exist in C# Aurora.

Instead, a new ground unit component (100 tons) provides 0.1 survey points per day. Ground units with this component may be added to ground formations to provide a geological survey capability. All formations at the same population with a geological survey capability will combine their survey points to conduct a ground-based survey. This can only take place after the orbital survey is complete.

Once the orbital survey of a system body is completed, the potential for a further ground survey will be revealed (None, Minimal, Low, Good, High, Excellent). The ground survey requires the same survey points as the orbital survey, except they are generated by ground forces. Only system bodies with a diameter of at least 4000 km will be eligible for a ground-based survey (in Sol that is Mercury, Venus, Earth, Mars, Ganymede, Callisto and Titan).

Normal mineral generation (at system body creation) has three phases:
1) An overall roll for the potential for minerals to be present, based on radius, density and system abundance. If this roll fails, the body has no minerals.
2) A roll for each type of mineral to be present, based on density and abundance. Duranium has twice the chance of any other mineral.
3) A roll for the accessibility of each mineral generated in step 2). This is based on radius.

Once the ground survey is completed (assuming potential is Minimal or higher), a new mineral generation roll will take place. For this roll:
Step 1 is the same regardless of the potential.
Step 2 is modified by the potential. Minimal is 25% normal, Low is 33% normal (same as teams in VB6), Good is 50% normal, High is 100% normal and Excellent is 200% normal.
Step 3 is modified by High (+ 0.1) and Excellent (+ 0.2). All others are same as normal.

If a deposit of a mineral that didn't previously exist is generated by the ground survey, that deposit is added to the system body.
If a mineral deposit is generated by the ground survey and a deposit of that mineral already exists on the system body, the existing deposit is changed to match the amount or accessibility (or both) of the ground survey deposit if the latter is greater.

The chances that an eligible body (4000 km diameter) will have ground survey potential is equal to:
None 60%, Minimal 20%, Low 10%, Good 6%, High 3%, Excellent 1%.

For reference, in the Colonial Wars campaign, there are 2145 eligible bodies in 495 systems, so in general about 1.7 worlds per system will have potential of at least Minimal. About 1 system in 23 would have an Excellent potential world.

Here is an example survey ground unit:

Code: [Select]
[b]Geosurvey Vehicle[/b]
Transport Size (tons)  218     Cost  8.72     Armour  20     Hit Points  40
Geosurvey Equipment:
Geosurvey Equipment:

Vendarite  8.72   
Development Cost  436
« Last Edit: January 27, 2019, 03:06:01 PM by Steve Walmsley »
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #85 on: June 23, 2018, 09:42:51 AM »
Jump Point Stabilisation

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

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


Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #86 on: July 04, 2018, 04:03:16 PM »
Starting NPR Locations

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

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

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

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #87 on: July 28, 2018, 04:36:30 AM »
Conventional Armour

The new ground combat rules provide the opportunity to simulate current ground forces, such as tanks, artillery, etc. However, the single conventional armour tech does not provide any granularity to show the different between different generations of armour. Therefore the current Conventional Armour tech is replaced by three new techs. I have also slightly reduced the capability of Duranium Armour and increased the research cost to create a more graduated progression and give conventional forces some chance against the first generation of TN vehicles.

High Density Duranium and above remain the same. Duranium Armour becomes available, regardless of current armour tech, once Trans-Newtonian Technology is researched.

Here are the first six armour techs as they now stand:



 
The following users thanked this post: Arwyn, Laurence, Deutschbag, Happerry, Garfunkel, Doren, JacenHan, Kytuzian, TMaekler, Alucard, Rye123, tywudtke

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #88 on: July 28, 2018, 01:02:39 PM »
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.

The existing changes post for Missile Launchers has been updated to take account of this new rule:

http://aurora2.pentarch.org/index.php?topic=8495.msg102815#msg102815
 
The following users thanked this post: Arwyn, Laurence, Garfunkel, JacenHan, SpikeTheHobbitMage, DIT_grue, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #89 on: July 31, 2018, 04:43:54 PM »
Fleet Training

Fleet Training in C# Aurora provides the same benefits as VB6 Aurora. The mechanics by which it takes place are quite different.

Any fleet assigned to an Admin Command with a 'Training' specialisation will automatically take part in Fleet Training. Attaching a fleet to a Training Admin Command will start Fleet Training, while removing it will end Fleet Training. For details on Admin Commands, see the following post.

http://aurora2.pentarch.org/index.php?topic=8495.msg103849#msg103849

Each construction phase, each ship in a fleet assigned to a Training Admin Command  will gain Fleet Training Points based on the following formula:
Crew Training bonus of the Admin Command Commander * Ship Crew Grade * Ship Morale * (Construction Phase Length / One Year)

Unlike VB6, a fleet undergoing Fleet Training can perform normal duties and can be given orders if desired (although this is not required). There are no fixed movement or locations for training. However, only military ships can benefit from Fleet Training. While in training, a ship is under the following restrictions:

1) The parent fleet must remain in a system that is within range of its parent Training Admin Command
2) The ship cannot use maintenance facilities
3) The ship does not benefit from a Recreational Location
4) Maintenance Failure Chance is 2x normal
5) The ship's Maintenance Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
6) The ship's Shore Leave Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
7) Fuel is used as if the ship was running its engine at 10% power for the period of training (this is on top of any fuel used in normal movement). The fuel is consumed during each movement phase. A 'ship' without engines does not require fuel for this purpose
8) Training will not take place if the ship is out of fuel or the Training Admin Command does not have a sufficiently senior commander.

These mechanics are intended to simulate that ships assigned to 'Fleet Training' are carrying out intensive training (drills, etc,) during the course of their normal activities. This places a strain on the ship systems and the crew, resulting in increased maintenance and fuel use and a lower overall deployment time. The ship also sacrifices the benefits that would come from a different type of Admin Command.
« Last Edit: September 02, 2018, 03:16:28 PM by Steve Walmsley »
 
The following users thanked this post: Deutschbag, Garfunkel, Britich, DIT_grue, TMaekler, serger, Rye123, lordcirth, Rook, Bails_64