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 - Steve Walmsley

Pages: [1] 2 3 ... 19
1
C# Aurora / Re: C# Aurora Changes List
« on: Yesterday at 05:29:39 AM »
Logistics and Ground Combat Research

Due to the increase in Logistics techs for C# Aurora and the planned revamp of ground combat design, the Logistics / Ground Combat research field will be split into two separate fields. There are now nine research fields in total.
The following users thanked this post: DIT_grue, Tristitan

2
C# Aurora / Replacing PDCs
« on: September 18, 2017, 06:05:06 PM »
I posted a comment in the changes discussion thread about removing PDC and enhancing ground forces to compensate. Having given this some thought, it solves a lot of issues in the game that add complexity without really adding a lot in the way of additional game play. PDCs create exceptions for a number of rules, add complexity (in the sense of awkwardness rather than variety) to ground combat and their maintenance-free status can be an exploit. They create a lot of orders and rules around prefabrication and assembly and can't be effectively upgraded.

I've decided to replace them with some additional types of ground forces to improve defences planetary defences and keep all 'ships' in space. This thread is to look at the options for the ground combat enhancements. At the moment I am thinking along the following lines (but I am open to suggestions):

1) A unit with air defence capability that functions as a CIWS for the planet.

2) A unit with similar capability to ship-based energy weapons, designed to fire ground to orbit, rather than ground to ground.

3) Probably adding some basic form of ground unit design rather than having specific unit types. This would include (for example) 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. 'Garrison' rating separated from defence. 'Movement' tech could be personal armour, tracked vehicles, combat walkers, etc.. A combination of these techs would determine unit cost, size, capability, etc.

4) 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.

5) The type of planet could affect which units are most effective - specialist units for extreme temperature, or mountainous terrain (based on tectonic rating), or mostly water planets, etc. Terrain would also determine the effectiveness of different movement types.

6) An 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. Energy-armed spacecraft in orbit could be assigned for fire-support missions when assigned to direct support of a HQ unit.

7) Units would not increase in capability with tech and would use the tech at the time of creation. However, units could be converted into a cadre unit (and retain their experience) so they can be used as the basis for a new unit with improved capability.

8) These changes 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).

Comments and suggestions welcome.
The following users thanked this post: Bremen, DIT_grue

3
C# Aurora / Re: C# Aurora Changes Discussion
« on: September 18, 2017, 03:29:49 PM »
i dunno if this has been asked.  What engine is this being made on

C# and Windows Forms - not that popular as a gaming platform :)
The following users thanked this post: infernobirdkrpt

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: DIT_grue, Detros, Frank Jager

5
C# Aurora / Re: C# Aurora Changes List
« on: September 17, 2017, 12:12:11 PM »
Ordnance Transfer Orders

With the new ordnance transfer rules, I am changing how some of the ordnance transfer orders work.

The first major change is that a collier within a fleet can be set to automatically transfer ordnance to or from other ships in the fleet. You can flag a collier as being at one of seven ordnance transfer statuses; None, Load Fleet, Replace Fleet, Remove Fleet, Load Sub-Fleet, Replace Sub-Fleet, Remove Sub-Fleet.

When this flag is set to Load Fleet or Load Sub-Fleet, each collier will load ordnance into the magazines of non-colliers within its own fleet (or sub-fleet) as that fleet continues with its normal orders (the transfer itself is not an order). Essentially, the collier will keep the fleet's magazines topped up. The rate of ordnance transfer will be based on the ordnance transfer system of the collier multiplied by the parent race’s underway replenishment tech (unless the fleet is stationary). The missiles being loaded will be based on what is missing from the ship's magazine when compared to the class loadout, starting with the largest missiles first (although smaller missiles will be loaded if there is insufficient time in the sub-pulse to load a larger one). However, missiles will only be added using this order and missiles that do not match the current class loadout will not be removed.

When this flag is set to Replace Fleet or Replace Sub-Fleet, each collier will remove any missiles that do not match the current class loadout and replace them with those from the class loadout (assuming the collier has a sufficient stockpile) for any non-colliers within its own fleet (or sub-fleet) . The collier will remove non-loadout missiles from the target ship while it has magazine space remaining, then add class loadout missiles to create space. Essentially, the collier will alternate loading and unloading as necessary to create the correct loadout.

When this flag is set to Remove Fleet or Remove Sub-Fleet, the collier will unload all missiles from non-colliers within its own fleet (or sub-fleet), as long as it has space to store them.

The current ‘Provide Ordnance to Fleet’ order has been replaced with several new orders to facilitate the above. These include:

Join and Add Ordnance to Fleet
Join and Add Ordnance to Sub-Fleet
Join and Replace Ordnance in Fleet
Join and Replace Ordnance in Sub-Fleet
Join and Remove Ordnance from Fleet
Join and Remove Ordnance from Sub-Fleet

The fleet containing the collier will become part of the target fleet and switch to an appropriate ordnance transfer status depending on the order. You can also use an 'Absorb' order to collect a collier with an existing status set. I may look at adding ship-level conditional orders (rather than fleet) so that colliers/tankers can detach when empty and return home without player supervision.

A new 'Load from Ordnance Transfer Hub' order has been added. This order requires a second fleet containing at least one ordnance transfer hub as the destination. On arrival, any ships in the fleet with magazines will receive ordnance according to their class loadouts until all magazines are full, or the ordnance transfer hub runs out of ordnance. No ordnance will be removed by the hubs. All ships in the fleet will receive ordnance, including colliers. Once completed, the fleet will move on to its next order. If the fleet containing the ordnance transfer hub has any movement orders, the ordnance transfer will not take place and the ordnance transfer order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of ordnance transfer but they can all contribute ordnance.

A new 'Replace at Ordnance Transfer Hub' order has been added. This order functions in a similar way to above except that any ordnance not in the class loadout will be removed by the hubs. The mechanics of this process are the same as the ordnance transfer within fleets above.

A new 'Unload to Ordnance Transfer Hub' order allows colliers to deliver ordnance to the hubs.

The existing ‘Load Ordnance from Colony’ order will remain but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station. On arrival, the fleet will receive ordnance until all its magazines are full, or the colony runs out of appropriate ordnance. All ships in the fleet will be receive ordnance, including colliers. Once completed, the fleet will move on to its next order. Multiple spaceports or ordnance transfer stations at the colony will not increase the rate of ordnance transfer.

The 'Unload Ordnance to Colony' order also remains but can only be used at colonies that have either a Spaceport or an Ordnance Transfer Station.

Any order involving the transfer of ordnance to or from a colony or ordnance transfer hub will use the current racial ordnance transfer tech to determine the rate of transfer.

Note this means that significantly more planning will be required in this version of Aurora to ensure missile-armed ships can be reloaded at the frontier. It will no longer be possible to dump ordnance on the nearest available rock. Colonies will require a spaceport or an ordnance transfer station before they can support missile-armed fleets. Alternatively, colliers can accompany fleets, or a deep space base with an ordnance transfer hub can be established.
The following users thanked this post: MarcAFK, Alfapiomega, Tristitan, Rye123

6
C# Aurora / Re: C# Aurora Changes List
« on: September 17, 2017, 09:30:13 AM »
Ordnance Transfer Mechanics

In C# Aurora, transferring ordnance is no longer instant and ships without specialised equipment cannot exchange ordnance in space. A ship can only receive ordnance at a Spaceport, an Ordnance Transfer Station, a ship with a Ordnance Transfer System, a base with a Ordnance Transfer Hub or in a military hangar bay.

A new technology line - Ordnance Transfer Systems - provides the basis of the rate of ordnance transfer and allows ships to mount systems to transfer ordnance to or from other ships. The baseline system (Ordnance Transfer System: 40 MSP per Hour) sets the racial ordnance transfer rate at 40 MSP per hour and allows the use of the first ship-mounted Ordnance Transfer System. There are ten further steps in the tech progression with the highest tech system allowing ordnance transfer at 400 MSP per hour.

Spaceports, Ordnance Transfer Stations or Ordnance Transfer Hubs will always use the highest tech ordnance transfer rate and can transfer ordnance to or from an unlimited number of ships simultaneously. However, the ships involved must be stationary. Hangar Bays also use the highest tech ordnance transfer rate (mainly to avoid multiple hangar bay types).

Spaceports have increased in cost to 3600 BP but can now be moved by freighters. They are equal to four research facilities for transport purposes (or 80 factories). They retain their existing bonuses to loading and unloading cargo.

Ordnance Transfer Stations are a new installation with a cost of 1200 BP. They do not require workers and can be moved by freighters. They have a transport size equal to 10 factories. Essentially, they are a cut-down version of a spaceport intended to facilitate ordnance transfer in forward areas, transferring ordnance between the surface of a planet and ships in orbit. They have no bonuses for loading or unloading cargo.

An Ordnance Transfer Hub can be mounted on a ship. It is a commercial system with a research cost of 10,000 RP, build cost of 2400 BP and a size of 100,000 tons. In practical terms, this is likely to form part of a large, deep-space station, due to the size and cost, rather than being deployed on ammunition colliers that will accompany fleets.

A Ordnance Transfer System is 500 tons and has a cost ranging from 20 BP to 200 BP, depending on the tech level. A ship with an Ordnance Transfer System can transfer ordnance to or from a single ship at once, so it will take some time to replenish a whole fleet, although this will improve with higher technology. At the early tech levels, the Ordnance Transfer System can only be used if both ships (collier and target ship) are both stationary. Underway Replenishment allows the transfer to take place while both ships are in the same fleet and underway. Priorities can be set for the ordnance transfer order when multiple ships are involved. The first Underway Replenishment tech allows ordnance transfer at 20% of the normal rate (2500 RP), rising to 100% with the highest tech (40,000 RP).

Ordnance transfer order types will be adjusted to deal with the new requirements (which I will list in a separate post). Ordnance will be transferred during each movement increment as time passes until the target ship has full magazines.
The following users thanked this post: Bremen, sublight, Tristitan, serger, xhunterx, Rye123

7
C# Aurora / Re: Progress
« on: September 12, 2017, 01:15:46 PM »
is there a way to track progress? am still checking every other month but apart from changeset posts the closeness to release is not even fuzzy but just impossible to desume

I can't really give a release date. It depends a lot on the availability of my free time and how well I maintain enthusiasm. I can say I am a long way past half way in terms of the functionality but I still haven't touched combat or AI and have about a third of the different movement orders still to do, plus several of the smaller windows. Once I finish working on move orders, I will probably work on new game creation so I can start a test game. I have been working on this since March 2016, so already 18 months in. I would be disappointed if I didn't start posting test campaign reports this year but don't believe there will be a release version before 2018.
The following users thanked this post: Laurence, Ayeshteni, Ynglaur, snapto, Alfapiomega, briang, Shiwanabe

8
C# Aurora / Re: C# Aurora Changes Discussion
« on: September 06, 2017, 01:14:47 PM »
I like the addition of commandants, but I am a bit concerned about the minimal requirements.  I like to have all my academies on my capital planet (give it a reason to be capital).  The requirements could get very high :(

Though I guess I will see how it pans out when the game is out.

You don't have to assign a commandant. You have the option of continuing as you do now, with no downside compared to VB6, or you can spread out your academies and gain some additional benefit.
The following users thanked this post: xhunterx

9
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: Ayeshteni, DIT_grue, Tristitan, serger, Steven Wargames, Rye123, Detros

10
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: chrislocke2000, El Pip, serger, Detros

11
C# Aurora / Re: C# Aurora Changes List
« on: September 03, 2017, 11:24:12 AM »
Logistics Bonus

I'm not sure if I have mentioned this anywhere else, so making sure here  :)

The cargo handling speed of any ship is modified by the ship commander's logistics bonus and by any bonus from the parent admin command of the ship's fleet (assuming the fleet is within he command radius). Setting up a network of Logistic-focused Admin Commands has the potential to boost cargo handling considerably.
The following users thanked this post: MagusXIX, Shuul, Tristitan, serger, Steven Wargames

12
C# Aurora / Re: C# Aurora Changes Discussion
« on: September 03, 2017, 05:09:24 AM »
Wouldn't this prioritise the oldest (slowest) ships, rather than the newest?

It looks like you've calculated these percentages from the given figures as amount of overcrowding, not the Overcrowding Modifier (i.e. they've been squared when I don't think they should be). Also, isn't that last one 34.7%, not 34.2%?

Good spot on the construction ships. One of the benefits of posting the rules is getting this type of review. I'll change it to class cost, as the more modern construction ships are likely to be more expensive.

Also correct on the overcrowding modifiers. I've changed the text.

I still get 34.2% though. If Overcrowding is 5x, then modifier is 25x. I have ROI modifier of 0.01369863, assuming 432,000 seconds for the 5-day increment and 31,536,000 for year length. I am using 365 day calendar years, rather than 365.25 astronomical years, although I suppose I could use the latter as Aurora now handles leap years.
The following users thanked this post: swarm_sadist, DIT_grue

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

http://aurora2.pentarch.org/index.php?topic=4835.msg49116#msg49116

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.
Overcrowding
  • 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.

Summary

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: MagusXIX, DIT_grue, Tristitan, serger, Steven Wargames, Rye123, Detros

14
C# Aurora / Re: C# Aurora Changes List
« on: September 02, 2017, 02:16:23 PM »
Flight Crew Berths

In VB6 Aurora, the player has to remember to add additional accommodation for the crews of parasite warships when designing a carrier, even without knowing the potential future parasites. These are known as Flight Crew Berths.

In C# Aurora, due to changes in the way crew morale and overcrowding are handled, the design process will automatically add 20 flight crew berths for each hangar bay. These berths are assumed to be sufficient for whatever parasite warships are present.
The following users thanked this post: Demonides, Ayeshteni, DIT_grue, Steven Wargames, Silvarelion, Rye123

15
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: Ynglaur, DIT_grue, ChildServices, Tristitan, Rye123, Detros

Pages: [1] 2 3 ... 19