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: Replacing PDCs
« on: November 10, 2017, 06:50:44 PM »
Nope it wont.
I want PDC's to stay - period.

The problem is PDCs (as currently implemented) require about a thousand lines of code to handle all their exceptions, as they are ships (but not really) that don't move, don't get built in shipyards, can't have certain systems, don't need other systems, don't work properly for what they are supposed to do, and sometimes count as ground units (but not really).

Steve has been quite clear that because of the nightmare PDCs are to code, evaluate, and debug, the one thing you can't have in C# Aurora is PDCs the same as they are now.  He's implied that the new "PDCs" must be ground units that follow the ground unit rules, or ships that follow the ship rules, or buildings (installations) that follow the building rules, or orbital habitats/shipyards/complexes that follow the orbital structures rules, or some version of the above that "follows the rules" as they exist, not requires a(nother) thousand exceptions in the code.

So what is it about current PDCs that you want to keep?  Is it surface-based anti-ship weaponry that is invisible until it fires?  Is is an armoured redoubt to shelter your ground forces?  Is it a giant chunk of PPV that you can build and forget?  Is it several milion tons of hangar space in which to pseudo-mothball a fleet?

Any, perhaps all, of those things may end up in C# Aurora, but I'm 99% certain they won't be called "PDCs" if they do.
The following users thanked this post: Detros

Aurora Suggestions / Re: Semi-Official 7.x Suggestion Thread
« on: October 28, 2017, 07:06:59 PM »
Suggestion: Inverse the effect of the "Show Surveyed Bodies" checkbox on the Minerals-tab.

Whenever the checkbox is checked it adds a white ring to every body that has been surveyed, which makes the screen very noisy.
That's why I only check it whenever I want to know which bodies still need to be surveyed.
If the effect is inversed you could simply leave it ticked and have your survey ships remove the noise from your populated systems.

+ one option less you have to fumble around with every now and then
+ as an added bonus you have less redundant information on the screen, since the checkbox "Show Mineral Concentrations" already implies what has been surveyed.

- people will have to get used to the inversed effect

... feel free to add more to the pros and cons if something comes to mind.
The following users thanked this post: Detros

C# Aurora / Re: Replacing PDCs
« on: October 18, 2017, 02:32:58 AM »
I'm a bit worried about Steve trying to tackle ground combat. It's a very difficult gameplay to design and balance. Something that rts and grand strategy games today still have difficulties to get right. For me the simple but straightforward ground combat aurora has is fine. I sincerely wish Steve delays this aspect of developement until everything else is ready
It'd be nice to get the Aurora port to C# first and keep the reworked ground combat for Aurora C# 2.0.
The following users thanked this post: Detros

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

Pages: [1] 2 3 4