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

0 Members and 2 Guests are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #105 on: October 08, 2018, 06:07:03 PM »
Non-Support Fighter Missions

In addition to the option to directly support ground forces, fighters can be assigned additional missions over the battlefield. To be eligible, a fleet composed only of fighters is given one of the following orders with a system body as the destination. A friendly population is not required. These orders function in a similar way to a 'Follow' order, with the order remaining in place until removed by the player. Fleets with these orders that are at their target system body cannot be targeted in normal naval combat or by STO weapons.

Search & Destroy

Search and Destroy involves sending fighters to a planet with enemy ground forces (with or without friendly forces present) to attack targets of opportunity. This is similar to a ground support mission with the following differences:
  • The fighters do not need to be assigned to a friendly ground formation and do not require fire direction
  • The fighters will select any hostile formation, regardless of field position
  • The chance to hit is 33% of normal
  • Hostile AA will fire as if this is a ground support mission directed against the selected formation

Flak Suppression

Flak Suppression involves sending fighters to a planet with enemy ground forces (with or without friendly forces present) to specifically attack hostile AA units. Because the fighters are seeking out nearby AA units that are engaging them, the chance to hit is higher than for Search & Destroy, but the target selection is more difficult (finding the AA). This is similar to a ground support mission with the following differences:
  • The fighters do not need to be assigned to a friendly ground formation and do not require fire direction
  • The fighters will select any hostile formation, regardless of field position
  • The chance to hit is 50% of normal
  • Only hostile AA elements will be attacked. If none are present in the selected formation, no air-to-ground attack will take place
  • Hostile AA will fire as if this is a ground support mission directed against the selected formation, even if the fighters did not open fire

This post is also a placeholder for additional missions - one of which will be Combat Air Patrol (when I code it).
 
The following users thanked this post: Garfunkel, Britich, SpikeTheHobbitMage, bro918, TMaekler, Rye123, dag0net

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #106 on: October 09, 2018, 06:05:16 PM »
Ground Support Bonus

This is a new bonus in C# for naval officers commanding fighters on ground support, search & destroy and flak suppression missions. The to hit chance is modified by the bonus.

The bonus is also used for orbital bombardment support (explained in a future rules post), with the Tactical Officer contributing 100% of his bonus and the Ship Commander contributing 50% of his bonus.
 
The following users thanked this post: Garfunkel, Britich, SpikeTheHobbitMage, bro918, TMaekler, Rye123, dag0net

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #107 on: October 10, 2018, 05:52:49 PM »
Orbital Bombardment Support

Ships equipped with energy weapons can provide support to ground unit formations during ground combat.

To be eligible, a fleet with energy weapons is given an order to "Provide Orbital Bombardment Support" with a friendly population as the destination. This order functions in a similar way to a 'Follow' order, with the order remaining in place until removed by the player. On the Ground Combat Window, eligible fleets (those in orbit and with this order) appear under their own section of the tree view for each population, with a parent node of "Orbital Bombardment Support". The ships in those fleets can be dragged and dropped on to formations in the same way as ground support fighters. Fleets with this order can still be targeted in normal naval combat or by STO weapons (they do not have the same protection as fighters on ground support missions).

In combat, the orbital bombardment ships attack at the same time as bombardment elements and have the same target selection options as heavy bombardment. Orbital bombardment ships have the same chance to hit as ground units, although they are not affected by any negative environmental modifiers (such as high gravity or extreme temperatures). Each ship fires its weapons once per ground combat phase. Each ship's to hit chance is affected by its crew grade and morale, plus 100% of the ground support bonus of the tactical officer and 50% of the ground support bonus of the ships commander.

The damage in ground combat for an energy weapon is equal to 20x the square root of its point blank damage in ship-to-ship combat. Armour penetration is equal to half the damage. Fractions are retained. For example, the AP/Damage ratings would be 10/20 for a 10cm railgun round or gauss cannon, 17.3/34.6 for a 10cm laser, 40/80 for a 25cm laser. Weapons roll for failure in the same way as in naval combat.

Ships cannot perform orbital bombardment in the ground combat phase if they fired in the preceding naval combat phase of the same increment.

Each Forward Fire Direction (FFD) component in a formation allows support from a single ship in orbit or up to six ground support fighters. If a ship is providing orbital bombardment support and the formation loses its FFD capability, the ship will try to find another formation at the same population with available FFD.

Orbital bombardment is a powerful aid to any ground combat, although the ships will be vulnerable to hostile STO weapons and require fire direction from the surface. Ships conducting Orbital Bombardment Support will be firing far less than often than a ship conducting general planetary bombardment, but will do so with more accuracy. This is because the ship will be firing on specific targets as directed by ground-based controllers when the right opportunity arises.
« Last Edit: August 31, 2019, 09:31:21 AM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Britich, SpikeTheHobbitMage, bro918, TMaekler, dukea42, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #108 on: October 12, 2018, 10:45:56 AM »
Civilian Mining Colonies

VB6 Civilian Mining Check

In VB6, a check is made each construction phase to see if new civilian mines are checked. The chance of this check is based on a random number of one million with a successful check equal to annual wealth or less. There must also be two populations for that race.
If a check takes place, the code orders all systems that contain a population of 10m or more (on a single body) and then steps through them in descending order of population. In each step, there is a 50% chance the system will be checked. Once a system is checked, no more will be checked in that phase.

The code then searches that system for bodies without a current population, less than 80 AU from their star, that have at least 15,000 tons of Duranium or Sorium and accessibility 0.7 or higher. The one with the highest combined amount of minerals of any type where accessibility is at least 0.5 accessibility is chosen.

The above can lead to a situations where good mining sites can be 'blocked' by higher population systems with no good mining sites and there are also some issues with potential locations. Therefore, C# uses a different method.

C# Civilian Mining Check

Each construction phase, if a race has at least two colonies with population or infrastructure, that race rolls a random number from 1 to 50,000. If that random number is less than Annual Wealth * (Construction Phase Seconds / Year Seconds), a check is made for a potential new civilian mining complex. For example, for a race with 20,000 annual wealth checking during a construction cycle that is exactly five days, the number needed to pass would be 274 (20,000 * 432,000 / 31,536,000), which is 0.55%. This is a lower chance for a check than in VB6 to account for the following changes.

If that check is passed, a list is made of all suitable locations for a civilian mining complex. A suitable location is a system body with at least 10,000 tons of Duranium that has an accessibility of at least 0.7. That system body must be in a system with at least one population of ten million and must be less than 80 AU from its parent star. If orbiting a non-primary star, that star must be within 80 AU of the primary or have an Lagrange Point within 80 AU that can link to a Lagrange Point within 80 AU of the primary.

Once all suitable locations are determined, each location is given a score based on the total amount of minerals with accessibility of 0.5 or higher. Duranium scores double. The new mining complex is created at the location with the highest score. Population is not a factor beyond the ten million limit required for consideration of the parent system.

For each existing civilian mining colony, a similar check is made in the construction phase to determine if an additional complex is added. For this check, the roll is 1-100,000.
 
The following users thanked this post: Garfunkel, Britich, SpikeTheHobbitMage, DIT_grue, bro918, TMaekler, serger, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #109 on: October 12, 2018, 11:18:28 AM »
Non-Player Race Fuel

In C# Aurora, NPR ships consume fuel and therefore require refuelling. They also need to use the same refuelling infrastructure as players (fuel transfer stations, refuelling systems, etc.) and require the same time to refuel (allowing for technology differences). NPR Tankers will move fuel from harvesters and populations with excess fuel to populations with logistical infrastructure that require fuel. As NPR ships become low on fuel, they will return to the nearest population or tanker that has fuel.

NPR ships and fleets have a concept of Mission Capable Status, which is affected by a number of factors such as fuel status, damage status and ordnance status. When an NPR fleet is very low on fuel, it will be unable to do anything except search for refuelling options. However, to avoid the NPR getting into any logic issues, NPR ships will still be able to move with zero fuel while they move to a refuelling point.

This should add more constraints to NPR deployment, add an interesting layer to NPR operations and provide the player with a new way to attack NPRs (attacking their fuel supplies instead of their ships). While it isn't completely the same as players due to the 'search for fuel while empty' concept, I think that is the best trade-off between realism and avoiding any unforeseen logic issues.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #110 on: October 13, 2018, 10:41:51 AM »
Ground Forces Detection

In C#, as in VB6, ground forces are treated as size-1 for the purposes of detection, so are best detected with resolution-1 sensors.

For C#, the ground forces signature is equal to the total signature of all ground formation elements on a planet, divided by 100. The signature of each element is equal to (unit size * unit number) / (fortification level * dominant terrain fortification modifier).

In other words, well-fortified ground forces will have a smaller signature than those out in the open, so you won't always know if you face a small force, or a well-fortified larger force.
 
The following users thanked this post: Bremen, Garfunkel, Britich, SpikeTheHobbitMage, DIT_grue, bro918, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #111 on: October 19, 2018, 12:38:45 PM »
Surface-to-Orbit Weapons

A ground unit class has an option to mount a surface-to-orbit component. If this option is selected, the class must also select a weapon type. The weapon can be of any type researched by the owning race, including turrets and spinal weapons. Additional systems will be automatically added based on the weapon chosen, creating an integrated component (similar in concept to CIWS). These systems include:

Beam Fire Control: For normal weapons, this will be created using options for 4x Racial Fire Control Range and 1x Racial Tracking Speed. If the Point Defence Weapon checkbox is clicked, the fire control will be created using options for 1x Racial Fire Control Range and 4x Racial Tracking Speed. In all cases, the beam fire control will have a 25% range bonus vs a ship-mounted equivalent. The cost and size of the fire control will be 50% of the ship version due to its dedication to a single weapon.

Active Sensor: This sensor will be resolution 1 and have range at least equal to the maximum range of the weapon. The minimum size will be 5 tons. The sensor is fully functional and will detect targets in general, not just for the weapon. Size and cost are normal.

Reactor: This component will be designed to generate sufficient power for the weapons capacitor. Size and cost are normal.

ECCM: This is optional and can be added by checking Include ECCM checkbox. Size is 50 tons and cost is half normal to reflect the dedication to a single weapon.

Those ground elements containing units with STO capability can set a number of different targeting options. For the moment, targeting and firing is handled automatically although I may add a manual targeting option as well. For those targeting options directed at ships, the player may also select the number of weapons per target, with zero being all weapons. When a number other than zero is chosen, the targets are cycled until all weapons are fired. Targets must be detected, hostile and in range to be eligible.

The target settings are as follows:
  • Do Not Fire
  • Target Random Ship:  Eligible Ships are given a random order and the targeting cycles though them (or targets the first if number of weapons is zero). The targets will be cycled through multiple times if required for all weapons to fire.
  • Target Largest Ship:  Eligible Ships are arranged in descending order of size
  • Target Smallest Ship:  Eligible Ships are arranged in ascending order of size
  • Target Fastest Ship:  Eligible Ships are arranged in descending order of speed
  • Target Slowest Ship:  Eligible Ships are arranged in ascending order of speed
  • Target Easiest Ship:  Eligible Ships are arranged in descending order of chance to hit
  • Target Shipyards:  The largest eligible shipyard contact is targeted
  • Target Populations:  The largest eligible population contact is targeted. Populations on the same system body as the STO element cannot be targeted.
  • Target Ground Forces:  The largest eligible ground forces contact is targeted. Ground forces on the same system body as the STO element cannot be targeted.
  • Target STO Ground Forces:  The largest eligible STO ground forces contact is targeted. STO ground forces on the same system body as the STO element cannot be targeted.
  • Final Defensive Fire:  When a salvo is about to hit a target within range of the STO weapon, the element will be eligible for point defence fire in the same way as a ship. This allows the STO element to protect itself and other ground forces, any populations on the surface, orbital shipyards and any nearby ships.
  • Final Defensive Fire (Surface Only):  Same as Final Defensive Fire except that only salvos attacking surface targets will be intercepted
  • Area Point Defence:  The STO units will shoot at any hostile missiles currently in range.
When an STO element targets missiles, it will only fire until the missiles are destroyed. For the purposes of tracking weapon fire and recharging, each STO unit within the element is tracked separately.



« Last Edit: October 19, 2018, 05:10:04 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, DIT_grue, bro918, TMaekler, jonw, Rye123, dag0net

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #112 on: October 19, 2018, 05:28:13 PM »
Surface to Orbit Ground Forces Contact

STO elements that have not fired are detected with other ground forces as a ground forces contact.

When an STO element fires, any races that are currently detecting it as part of normal ground forces will flag it as an STO element. Thereafter, those races will detect that element as an 'STO Ground Forces' contact, which is a new contact type. All known STO elements on a planet are grouped as a single STO Ground Forces contact. Players can choose to target either the known STO elements or the normal ground forces (which may contain undetected STO elements).

An STO element may be known to some races and detected accordingly, while still being part of the normal ground forces contact for other races.

The active sensors of STO elements are detected by EM sensors in the same way as any other active sensor. However, this is not sufficient to flag the STO element.
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, DIT_grue, TMaekler, Rye123, lordcirth

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #113 on: October 19, 2018, 06:46:57 PM »
Collateral Damage

When ground combat takes place, it may cause collateral damage to the populations involved. This is based on attacks, rather than hits. For example, if you use heavy bombardment weapons, it will have an impact on the population regardless of whether you hit any hostile units. Collateral damage is caused by any weapon that affects ground combat, including close air support and orbital bombardment support.

Collateral damage is not linear with ground combat damage. The effect on the population increases exponentially for ground combat weapons with higher damage. The 'base component damage value' (before modification for weapon technology) of each weapon that fires is cubed, then the total damage is divided by 10,000. For example:

An infantryman with personal weapons would generate 0.0001 collateral damage per combat round (damage 1, shots 1)
Light anti-vehicle (damage 2, shots 1) is 0.008
Light bombardment (damage 2, shots 3) is 0.0024
Medium anti-vehicle (damage 4, shots 1) is 0.0 64
Medium bombardment (damage 4, shots 3) is 0.0192
Heavy anti-vehicle (damage 6, shots 1) is 0.0216
Heavy bombardment (damage 6, shots 3) is 0.0648

Putting that in terms of regiments, 1000 infantrymen would generate 0.1 collateral damage per combat round while 50 heavy tanks (about the same size but 2x cost) would generate 1.2 collateral damage, assuming HAV and HCAP. Over ten combat rounds, that will become 1 and 11.2 respectively. To put that in perspective, vs energy weapon fire a construction factory has 20 HP and a research facility has 400 HP.

Once the total damage to a population is calculated, it is allocated as a series of 2-point energy weapon attacks. This is because infrastructure has 2 hit points. A construction factory (20 HP) would have a 10% chance of being destroyed, etc.. In addition to the installation damage, the collateral (energy) damage increases the dust level by 5% of the damage amount and inflicts civilian casualties at the rate of 2,000 per point of damage.

As populations suffer collateral damage, a track is kept of the total size of destroyed installations. Future collateral damage is reduced by (Total Size of Intact Installations / Total Size of Intact and Destroyed Installations). This is to simulate that fighting in the rubble does not cause further collateral damage.

As ground support fighters are involved in close combat, Fighter Pods have a 'base damage', equal to their normal damage divided by the weapon tech at the time of creation, which is used for 'base component damage value' in the above collateral damage calculation. This brings them in line with ground forces.

Orbital bombardment support is less discriminatory and the base values do not change over time. For example, a higher tech tank will inflict more damage but a 10cm laser is always a 10cm laser. Therefore orbital bombardment support uses 20% of the normal damage vs ground forces as the 'base component damage value'. Consequently, orbital bombardment will generally cause more much more collateral damage than an equivalent amount of damage from ground-based weapons or ground support fighters.

If attacking forces wish to minimise collateral damage, they will need to restrict the use of heavy weapons and orbital bombardment support.  Note that the base component damage value is used on the assumption that higher tech ground units are more destructive but also more precise in their targeting.
« Last Edit: December 27, 2019, 07:12:26 AM by Steve Walmsley »
 
The following users thanked this post: ExChairman, Garfunkel, SpikeTheHobbitMage, DIT_grue, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #114 on: October 20, 2018, 08:20:51 AM »
Ground Forces Construction Complex

For C# Aurora, the Ground Force Training Facility becomes the Ground Force Construction Complex. They remain the same size as a research facility and now require one million population to operate.

The build rate for the complex starts at 250 BP per year and can be increased through research. For example, 500 BP per year is 8000 Research Points and 1000 BP per year is 60,000 Research points.

These changes reflects the amount of effort that will be required to construct, train and support the new ground forces.



« Last Edit: January 27, 2019, 03:15:12 PM by Steve Walmsley »
 
The following users thanked this post: ExChairman, Garfunkel, SpikeTheHobbitMage, TMaekler, Rye123, dag0net

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #115 on: October 20, 2018, 08:51:32 AM »
Genetic Modification Centre

Genetic Modification Centres now produce one million conversions per year (250k in VB6). They also require 250,000 workers (zero in VB6).

 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #116 on: October 20, 2018, 09:11:57 AM »
Worker Requirements

Workers are required to man a variety of facilities in C# Aurora. This is only required in game terms where there are sufficient workers to potentially require additional infrastructure in hostile conditions. For example, an 'Automated Mine' does not have a worker requirement even though in reality it may have a small workforce for maintenance. In these cases, it is assumed the installation itself provides sufficient accommodation for the small workforce. A secondary consideration here is micromanagement, in that it would not add to game play if every refuelling station or mass driver required the transportation and housing of a few hundred workers, but it would add additional micromanagement.

With that in mind, the following installations require workers.

5,000 workers. Forced Labour Construction Camp, Forced Labour Mining Camp.
50,000 workers: Construction Factory, Ordnance Factory, Fighter Factory, Fuel Refinery, Mine, Conventional Industry, Maintenance Facility, Financial Centre.
250,000 workers: Terraforming Installation, Ground Force Construction Facility, Genetic Modification Centre
1,000,000 workers: Research Facility, Spaceport.

The following installations do not require workers
Infrastructure, Deep Space Tracking Station, Automated Mine, Military Academy, Sector Command, Mass Driver, Civilian Mining Complex, Refuelling Station, Naval Headquarters, Ordnance Transfer Station, Cargo Shuttle Station.

The calculation for Shipyard workers has been changed for C# Aurora and is covered in the following post:
http://aurora2.pentarch.org/index.php?topic=8495.msg112323#msg112323
« Last Edit: February 04, 2019, 06:52:21 AM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, TMaekler, Rye123, King-Salomon, DEEPenergy

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #117 on: October 21, 2018, 08:11:47 AM »
Ground Force Fortification

Fortification happens at the element level. Formation elements can fortify to different levels, depending on the base type of the unit class. That level is also affected by whether the element is restricted to fortifying itself or if it has assistance from construction vehicles. The level of self-fortification and maximum fortification is as follows:

Infantry, Static: Self 3, Max 6.
Light vehicle, Medium Vehicle, Heavy Vehicle: Self 2, Max 3.
Super-Heavy Vehicle: Self 1.5, Max 2
Ultra-Heavy Vehicle: Self 1.25, Max 1.5

All elements move from non-fortified to their maximum self-fortification level in 30 days without outside assistance. This progress is linear and happens automatically for all formation elements when their parent formation is not set to front line attack.

Construction elements will work on any element in their own formation or that formation's subordinate hierarchy that has already reached its max self-fortification level. If the construction element's formation has no subordinate, the Construction elements will work on any element in their own formation's parent formation or in that parent formation's subordinate hierarchy that has already reached its max self-fortification level. This means you can attach a construction-based formation directly to a formation you need fortified, or you can attach to a HQ and it will fortify every formation descending from that HQ. Construction elements can only assist elements that are on the same system body (they can be in different populations on the same body).

Given sufficient capacity (see below), a construction element can fortify any other element from its maximum self-fortification level to the maximum fortification level in 90 days.

The capacity of a construction element is equal to the construction rating of the elements unit class * number of units * race construction rating * commander production bonus * 100 tons. For example, a formation of 50 construction vehicles, each with 0.1 construction rating (2 const components at 0.05) for a race with 16 construction which is part of a formation with commander with 10% production bonus would be: 0.1 * 50 * 16 * 1.1 * 100 = 8800 tons. BTW a construction battalion of this type would cost 636 BP to build.

All construction elements are ordered by descending order of construction capacity. Each one determines the list of elements that they can assist (using the above criteria), excluding any that have been assisted by a previous construction element. The list of target element is ordered by Construction Rating (so construction units fortify themselves last), then descending tracking speed (so point defence STO and then normal STO), then by field position (so front line defence, then support, then rear echelon), then by descending max fortification (so infantry, static first), then by descending cost (elements with more expensive units first), then by descending morale.

The construction element cycles through the list of target elements using the following process.
  • The total size of the target element is determined (element unit size * number of units)
  • This is compared to the remaining construction capacity of the construction element. If its is greater, then the remaining construction capacity of the construction element is reduced by the size of the target element. If it is less, remaining construction capacity is reduced the zero and a Size Vs Capacity Modifier equal to (remaining construction capacity / target element size) is applied below
  • The amount of fortification that could be accomplished in ninety days is determined by deducting the target element self-fortification level from the target element max fortification level
  • The amount of fortification that could be accomplished within the current period is determined by 90 Day Fortification Amount * (Current Period / 90 Days) * Size Vs Capacity Modifier
  • The fortification for the current period is applied. If this would surpass the target element maximum fortification, then that value is set instead
  • If the construction element has capacity remaining, it moves on to the next target element in its list
Note that because of the way this is applied, it will take the same amount of time to move infantry from fortification level 3 to level 6 as it does for armour from 2 to 3.

This process will allow the player to either directly manage construction elements by attaching their formation to the desired target formation, or to attach the formation to a high level HQ and have the process happen automatically. If a construction element is used to fortify other elements, it will not contribute its construction capacity to its parent population during the next construction phase.

In combat, if the fortification level of a formation element is greater than 1, it is multiplied by the fortification bonus of the dominant terrain.
« Last Edit: October 21, 2018, 08:15:56 AM by Steve Walmsley »
 
The following users thanked this post: ExChairman, Garfunkel, SpikeTheHobbitMage, DIT_grue, TMaekler, Rye123

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #118 on: October 25, 2018, 10:30:16 AM »
Conventional Start

There are no longer any missile bases or ICBMs for a conventional start. The player now receives:

1,000 ton Naval Shipyard
10,000 ton Commercial Shipyard
Spaceport
Military Academy
Naval Headquarters
Deep Space Tracking Station
5x Maintenance Facility
Conventional Industry equal to eight times the Manufacturing population in millions.
Research Facilities equal to one twelfth of the Manufacturing population in millions. This is more research facilities than in VB6.

For example, a starting population of one billion will have 1600 conventional factories and 16 research facilities
« Last Edit: October 26, 2018, 09:26:16 AM by Steve Walmsley »
 
The following users thanked this post: ExChairman, Garfunkel, Doren, SpikeTheHobbitMage, dj756, bro918, TMaekler, Rye123, DEEPenergy, dag0net

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11644
  • Thanked: 20338 times
Re: C# Aurora Changes List
« Reply #119 on: October 26, 2018, 06:08:48 AM »
Installations without Required Tech

Given the player starts with certain installations in a conventional start, it does not make sense to make additional construction of those installations dependent on Trans-Newtonian Theory. The full list of the installations that can be constructed before Trans-Newtonian Theory is researched is as follows:

Naval Shipyard Complex
Commercial Shipyard Complex
Research Facility
Spaceport
Ground Force Construction Complex
Military Academy
Naval Headquarters
Refuelling Station
Ordnance Transfer Station
Cargo Shuttle Station
Maintenance Facility
Financial Centre
Deep Space Tracking Station
Infrastructure
 
The following users thanked this post: Brian Neumann, Garfunkel, Doren, SpikeTheHobbitMage, bro918, TMaekler, Alucard, Rye123, dag0net