Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Detros

Pages: [1] 2 3 4
C# Aurora / Re: C# Aurora Changes Discussion
« on: September 18, 2017, 03:48:40 AM »
My intention wouldn't be to remove ground defences entirely, just replace PDCs with ground units that have non-ground capabilities and move to more detailed ground combat. For example, some form of air defence unit that functions as a CIWS for the planet. Perhaps a 'ground to orbit meson battery' unit, etc..

In this case, ground units should probably be more directly affected by racial tech. it may mean I have to move to some form of simple ground unit design where you create your own unit types. This would include CIWS techs, ground to orbit techs based on ship-weapons, ground-based attack/defence split into armour and infantry-based techs (based on weapon & armour techs), maybe the bombardment ability of Titans so as an alternative to Titans you could develop different forms of artillery. Concealment tech to make units harder to strike from orbit. 'Movement' tech could be personal armour, tracked vehicles, combat walkers, etc.

Troop transport bays and combat drop modules would be for infantry (personal armour) types - a different module would be needed for heavy armour or ground to orbit capable units.

Perhaps the type of planet could affect which units are most effective - specialist units for extreme temperature, or mountainous terrain, or mostly water planets, etc. Terrain would also determine the effectiveness of different movement types.

Another option to be considered is removing the restriction on energy weapons in atmosphere. Ground units armed with ship-type weapons would become a serious deterrent, especially given they are more dispersed than ships and harder to eliminate. I would need to add rules on destroying installations from orbit, but not sure how much of a problem that is given that most powers want to capture installations rather than destroy them.

In fact, this could lead to a paradigm where it is very hard to bombard a well-defended planet from orbit so you (still) have to nuke from a distance and risk environmental and industrial damage, or develop very fast drop pods to get troops to the surface (through defensive fire) to take out the ground-based defences (Hoth).

Anyway, just thinking out loud at the moment.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: September 05, 2017, 06:58:38 PM »
Academy Commandants

Commanders can be assigned as an Academy Commandant on any population with at least one military academy. Any type of commander can be assigned with the following restrictions:

1) A civilian administrator must have an Admin Rating equal or greater than the number of military academies at the population
2) A scientist must have a Research Administration rating (new bonus for C# which is the max number of labs) at least five times the number of military academies at the population
3) A naval or ground forces officer must have a rank (with 1 being the lowest rank) at least equal to the number of military academies

The normal distribution of new commander types from the academy is 60% Naval, 25% ground, 8% Admin, 7% Scientist. While a Commandant is assigned, a check is made to see if an commander of the same type as the Commandant is generated. If the check fails, the normal distribution is followed. The chance is 14% for a Scientist Commandant to generate a Scientist, 16% for an Administrator Commandant to generate an Administrator, 40% for a Ground Forces Commandant to generate a ground forces officer and 80% for a Naval Commandant to generate a naval officer.

When a new commander is generated, a check is made to see which bonuses he receives. If the Commandant has at least 20% in any percentage-based bonus or 150 for crew training / ground unit training, all commanders graduating from the academy at that population will take two rolls for each qualifying bonus, and use the higher of the two results. If the Commandant is a scientist, there is a 25% chance any scientist from that academy will have the same research specialisation. If that check fails, the research specialisation will be chosen randomly (as normal).

This new rule should allow specialisation of academies on different worlds. Don't forget that you can set up a military academy on any colony, not just those with a population.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes Discussion
« on: September 05, 2017, 12:56:45 PM »
I was about to suggest something similar. Like a dropdown selection of focus for Academies which after X years make Y % more of one skill an Z % less of everything else. Or maybe you could put a Commander in charge of the Education and have their skill influence what comes out the other end.

In the past I have considered specialised military academies, but I think I prefer the idea of assigning a 'Commandant' and then giving his skills an extra chance of being added when creating new officers (and maybe more chance of his type of commander - scientists, naval officer, etc.). That way, you could build military academies on different planets that can specialise in different areas.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: September 02, 2017, 05:00:51 PM »
Deployment, Overcrowding, Under-manning and Life Support Failures

In VB6 Aurora, this is a very complex area (see link below), particularly with regard to fighters and other parasite warships.

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.
  • 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.
  • In this case, an Overcrowding Modifier is calculated equal to: (Required Accommodation / Actual Accommodation) ^ 2.
  • 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.


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.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: September 02, 2017, 07:27:31 AM »
Crew Morale

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.
The following users thanked this post: Detros

C# Aurora / Re: Screenshots published so far
« on: August 05, 2017, 11:59:10 AM »
Although this is not a view of a new screen, it is a development milestone.

Racial Design Philosophy (used by NPRs) and Automated Design (used by NPRs and Shipping Lines) are both complete. Below is a computer-created design for a missile cruiser, using a random design philosophy. This uses all the new rules for sensors, shields, missiles, command & control, etc.. The automated design process includes designing missiles and allocating them to the class. The second screenshot is for a beam-armed destroyer, created using the same tech but a different design philosophy.

Note there is a small display bug in the missile range which I fixed after creating the screenshot.
The following users thanked this post: Detros

C# Aurora / Re: Box Launcher Reloads
« on: July 19, 2017, 04:09:49 AM »
Bear in mind there is a difference between launcher cycle time and missile reload time. For a 'normal' missile ship, as soon as the launcher recycles, it can load another missile from the magazine. However, missiles are loaded into the magazine in a different operation. For box launchers in VB6, the launchers can be loaded with missiles quickly. It is the recycle of the launcher that takes a long time. This can seen as preparing the launcher for firing.

In C# Aurora, loading ordnance will take time rather than be done instantly (a similar change to refuelling). This will be true for both box launchers and magazines. As 'normal' missile ships will have increased magazine reload times, it makes sense to further limit box launchers to maintain balance. In fact, maybe rather than simply recycling launchers in a hangar, box launchers should reload there as well. This wouldn't be a problem for fighters or FACs. For larger warships, a dedicated facility would be required, probably using commercial hangars and commercial magazines (Space Dock!). Below is an excerpt from the U.S. Naval Institute Blog regarding the replenishment of current VLS.

"Unfortunately, reloading VLS at-sea isn’t incorporated into the Navy’s logistical DNA in the same way refueling is. Reloading VLS cells in today’s status quo demands an industrially robust port facility with heavy equipment, trained rigging crews, and a large munitions storage facility. It is not uncommon to damage equipment, and people have been seriously injured during VLS loading and unloading evolutions. Experts at the Naval Weapons Stations and some Naval Support Facilities use cranes to unload spent canisters, move gas management system equipment, and place loaded canisters in cells. "
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: July 18, 2017, 05:43:23 PM »
Beam Weapon Recharge

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.
The following users thanked this post: Detros

The Academy / Re: Newbie question
« on: July 05, 2017, 04:25:25 PM »
Just a little clarification; we're still getting all the mechanics changes scheduled for 7.2, its just we're not getting them until the C# update is done.
The following users thanked this post: Detros

C# Aurora / Re: Screenshots published so far
« on: July 02, 2017, 04:51:40 AM »
The new Turret Design window. Very similar in function to the VB6 version but with the addition of the company name option and instant research option. Both this window and the missile design window can be accessed via the Create Project Window (as in VB6) and via the main toolbar on the tactical map window.

Note that the changes to turret design, especially with regard to correcting the armour bug, result in this turret being significantly smaller than the VB6 equivalent. For comparison, the same twin turret with armour strength 2 in VB6 is 24.27 HS and 194 BP.

The following users thanked this post: Detros

Bureau of Ship Design / Re: Ships
« on: June 29, 2017, 08:37:33 AM »
Home rule 1: Size 1 passive sensors are needed for navigational reasons.
All ships already sport a hidden strength 1 thermal and EM passive, though. Probably for navigational reasons too.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: June 27, 2017, 02:01:50 PM »
Turret Update

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.
The following users thanked this post: Detros

The Academy / Re: Maintenance Clock going up during overhaul
« on: May 30, 2017, 04:16:58 PM »
475t courier Pelican is located at Earth with 2000 Maintenance Supplies, some ores and 5 Maintenance Facilities. AFAIK, that should make sure it gets maintained as it is smaller than 1000t. Pelican is overhauling and its Maintenance Clock is still slowly going up.

What else, other than not enough Maintenance Facilities, can cause such behaviour?

Anything under 500 tons is classed as a fighter and can't be maintained by maintenance facilities - only by hangars.

This rule was to prevent a couple of maintenance facilities supporting a lot of fighters. In C# Aurora, fighters can be maintained by maintenance facilities as the tonnage supported is based on the total ship tonnage, not max hull size.
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: May 28, 2017, 07:16:09 AM »
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
The following users thanked this post: Detros

C# Aurora / Re: C# Aurora Changes List
« on: May 21, 2017, 03:53:43 AM »
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).
The following users thanked this post: Detros

Pages: [1] 2 3 4