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

0 Members and 6 Guests are viewing this topic.

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #45 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.

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #46 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.

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #47 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.
« Last Edit: July 15, 2018, 06:12:43 PM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #48 on: September 23, 2017, 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.
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #49 on: November 05, 2017, 12:14:00 PM »
Planetary Terrain

As part of the ground combat changes, each planet will have a dominant terrain type. In many cases, for most asteroids, comets or small moons, that type will simply be Barren. Within certain environmental tolerances, other terrain types are possible.

Any system body with temperature lower than -100C or higher than 200C or with no atmosphere or atmosphere greater than 10 atm will be Barren, unless it has platelet or extreme tectonics, in which case it will be Mountain.

All other system bodies will check the following table to determine which terrain types are eligible based on the environmental conditions. One of the eligible terrain types will be selected randomly. Barren, Mountain and Rift Valley (which are base types available without any atmospheric, temperature or water requirements) will only be selected if no other terrain types are eligible. The tectonic numbers are internal to Aurora and have the following values: Dead = 1, Hot Spot = 2, Plastic = 3, Plate Tectonics = 4, Platelet Tectonic = 5, Extreme = 6.

Terraforming will change the terrain under two circumstances:
1) A planet with a base type (Barren, Mountain and Rift Valley) becomes eligible for another terrain of a similar type. Mountain can move to any other Mountain type, Rift Valley to any other Rift Valley Type and Barren to any non-Mountain, non-Rift Valley type.
2) The terrain type is no longer possible with the current environmental conditions. A new terrain type is generated with the same base type.

I am happy to add additional types or modify the environmental parameters if there is general consensus on any changes.

The fortification modifier is a modifier for the max fortification level, rather than an automatic defence increase. It means you can dig in much deeper (given sufficient time) in Mountains than you can in Steppe or Swamp. The to hit modifier is a reduction in the chance to hit in that terrain (for other ground units and any supporting ships in orbit). In effect, fortification is a benefit to the defender, while to hit is a penalty to both sides. Within the new ground combat rules, you can assign ground units 'capabilities', such as Jungle Warfare, Mountain Warfare, etc. which will double their chance to hit in those types of terrain. Ground units of species with certain types of home world may gain capabilities for free (if you are from a desert planet, you would gain Desert Warfare for free, for example). There are additional capability options to avoid penalties for ground units fighting on worlds that are outside their species tolerance for gravity, temperature and pressure.

An important factor to bear in mind is that when ships are engaging ground units with surface-to-orbit capability, the main defence of the ground unit will be its fortification level. The ship-based weapons are assumed to hit 100% of the time divided by the fortification level. On a planet with Steppe as the dominant terrain type, the maximum fortification of a static ground unit will be 6 with no penalty for the ship to hit. On a Jungle Mountain world, the maximum fortification level will be 18 for that same ground unit and any shots against it by the ships will be modified by 0.125, giving the ground unit an effective fortification level of 144. In other words, the ship in orbit is going to hit once every 144 shots. So trying to use orbital bombardment against surface to orbit units buried in jungle-covered mountains is going to be a Bad Idea. It would be far more effective to send in ground forces (which can't be hit by STO units) to dig them out. That is an extreme example, but there should be many more situations where there are some serious decisions for the attacker.

« Last Edit: September 16, 2018, 12:07:34 PM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #50 on: December 10, 2017, 01:32:33 PM »
Cargo Shuttle Bays

Part of the background in C# Aurora will be that large TN ships function only in space and cannot move any closer to planetary bodies than low orbit. Small craft below a limit of 500 tons, such as fighters and shuttles, are capable of landing on planets. Ship are built in orbit and habitats are assembled in orbit. Only fighters can be built on the ground.

As part of this change, Cargo Handling Systems have been replaced by Cargo Shuttle Bays. They function in a similar way, although they are larger (10 HS) and more expensive.

Because large ships cannot land on planets, a freighter or colony ship cannot load / unload unless it has at least one Cargo Shuttle Bay, or the target population has either a Spaceport or a Cargo Shuttle Station (new installation, 1200 BP). Spaceports and Cargo Shuttle Stations can service any number of ships simultaneously but they do not stack. In effect they count as a single Cargo Shuttle Bay for any ship at the population.

All races start with conventional shuttles available for their cargo shuttle bays and stations. Conventional shuttles do not reduce loading time but do enable cargo deliveries to planets without Spaceports or Cargo Shuttle Stations. Three levels of advancement in shuttle technology are available:

1) TN Shuttles (5000 RP): This reduces loading time by 2 per bay (so two bays means speed reduced by 4, three bays means speed reduced by 6).
2) Improved Shuttles (15,000 RP): Reduces loading time by 3 per bay.
3) Advanced Shuttles (40,000 RP): Reduces loading time by 5 per bay.

All bays and stations use the new shuttles once they are available.

Base cargo load times have been reduced by about 45% for all situations (36s per cargo point to 20s per cargo point and 18s to 10s per colonist), which means a ship with a standard cargo bay and a single Cargo Shuttle Bay with TN Shuttle tech will take slightly longer than the same ship with a cargo handling system in VB6.

This will affect troop transport in a different way and that will be covered in a separate post.

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #51 on: December 19, 2017, 01:34:50 PM »
Forced Labour Camps
 
As part of the ground combat overhaul, Forced Labour ground units will be removed. They will be replaced by two new installations; the Forced Labour Construction Camp and the Forced Labour Mining Camp. These each cost 40 BP to build and have the same output as a construction factory and a mine respectively. Transport size is 100,000 cargo points, or 4x that of a construction factory.
 
Forced Labour Camps can be built at any population, not just occupied ones. However, they consume 100,000 population and instantly cause 5 points of unrest. Once built they only require 5000 population to man them (serving as overseers), as the bulk of the workers, plus associated basic survival-level infrastructure, is provided during construction.
 
This installation has a few different uses. Making an conquered population productive is one, as you can build three of these for a single construction factory or mine cost, offsetting much of the production modifier penalty for occupation status. You can achieve more overall production in one of your own colonies for lower cost, if you are prepared to accept the unrest penalty, or you can build these in occupied populations and ship them to your own colonies.

Finally, because they have a minimal requirement for a supporting population, you can move them to a hostile world using only a small amount of infrastructure for the overseers. In effect, you can create the Dilithium mines of Rura Penthe if you wish. There are role-playing consequences, as you may not want to play the type of empire that convert its citizens into slaves and sends them to mine asteroids.

Labour Camps are affected by all the production modifiers that affect construction factories and mines (such as radiation, unrest, economic and political modifiers, etc.), although their cheap build cost allows you to offsets these modifiers with triple production. The transport requirement take into account the number of integral workers and supporting infrastructure. However, you could ship the potential workers as colonists (in a quarter of the tonnage) and create the Forced Labour Camp at the desired location.

While Labour Camps might seem low cost and tempting, they do have drawbacks. The large transport size means you could use the same freighter lift for 4x as many mines or construction factories. In addition, the 100,000 population cost is actually much higher in reality as you lose all the potential future growth & wealth provided by that population. They will be suitable in certain situations though; where you need to ramp up production and have excess population to support it, if you don't want to wait for a conquered population to improve its political status or you need a fast way of producing an equivalent to automated mines.
 
The unrest penalty for creation might be a little low so I will see how that works in play-test.

NOTE: Edited to include the 5000 pop requirement after a suggestion in the comments thread.
« Last Edit: December 19, 2017, 06:23:21 PM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #52 on: December 26, 2017, 01:11:29 PM »
Removal of Planetary Defence Centres

Planetary Defence Centres (essentially a ground-based ship) will not exist in C# Aurora. They will be replaced by a much more detailed ground-combat system, including ground units capable of engaging ships within energy range of the planet.

There is a lengthy discussion of this change and the new ground combat system in the following thread. I will begin posting the new ground combat rules in the next week or two.

http://aurora2.pentarch.org/index.php?topic=9679.0

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #53 on: January 02, 2018, 10:11:41 AM »
Ground Forces: Part 1 - Unit Design

Ground Forces and Ground Combat are undergoing a huge expansion in C#. The VB6 Ground Unit becomes the Formation and the VB6 Ground Unit Type becomes the Formation Template. However, there are no longer any fixed unit types or unit values. Instead, there is endless scope for Formations and Formation Templates, based on a detailed design process at the Formation level and below. This will allow the simulation of ground forces from many science fiction genres. As this is a long topic, I am going to break it into several posts each covering a different topic.

The most granular level is the Ground Unit Class, which is an individual soldier or vehicle. One or more of the same Ground Unit Class are grouped into Formation Elements, which in turn are grouped into Formations. Formations remain intact for movement purposes, but combat involves each individual unit (each soldier or vehicle). As individual units are now tracked for casualty purposes, readiness no longer exists. Morale is tracked at the Formation Element level (which is a group of the same unit class), so the infantry in a Formation may have a different morale than the anti-tank guns or artillery.

The process of design starts with the Ground Unit Class. Two important factors in this design process are the Racial Armour Strength and Racial Weapon Strength, shown at the top of the Ground Forces window.

Racial Armour Strength is based on the strength of the highest racial armour technology. Conventional Armour is 3, Duranium Armour is 5, et cetera. For this screenshot, the Commonwealth has researched Ceramic Composite, which has a strength of 10.

Racial Weapon Strength is based on the highest tech level (TL) among Laser Focal Size, Railgun Type, Meson Focal Size, Particle Beam Strength and Carronade Calibre. For example, 15cm Laser Focal Size is TL3 as it is the third tech of that type. Racial Weapon Strength is the value of armour at the same tech level. In this case, the Commonwealth has researched 20cm Laser Focal Size, which is TL4. The fourth Armour Tech is Ceramic Composite, which has a strength of 10, so the Racial Weapon Strength is 10. The reason for using Armour as the basis of Weapon Strength is partly because that means Ground Armour and Ground Weaponry are aligned, and partly because it is straightforward way to assign value based on very different weapons.

The Ground Unit Design tab of the new ground Forces window is shown below. First, a 'base type' is chosen, which is infantry, several sizes of vehicle, or static. Static in this sense is a weapon that is not self-mobile, such as a towed anti-tank gun, towed artillery, et cetera. Static weapons remain in place when firing so they are easier to hit than infantry or vehicles. Each base type has six main characteristics:

1) Size (in tons): Size is the basis for transport requirements and cost, although there are other modifiers to cost (discussed below)
2) Hit Points: Unit hit points are compared to weapon damage during combat to determine the chance of destruction (the Damage Check). The chance of a weapon destroying a unit is (Weapon Damage / Hit Points) ^ 2.
3) Slots: The number of component slots available for the base type
3) To-Hit Modifier: Used to modify the chance of the unit being hit during combat (based on the mobility of the unit). This only applies if the unit is not fortified.
4) Maximum Fortification: The maximum strength to which the unit can be fortified by construction factories or construction units. The Chance to Hit for a firing unit is divided by the Fortification Level of the target unit.
5) Maximum Self-Fortification: The maximum strength to which the unit can be fortified without construction factories or construction units.

The next section is Armour Type. The Armour of a unit is compared to the Armour-Penetration (AP) value of a weapon. The chance to penetrate is equal to (AP / Armour) ^2. For example, a weapon with AP 4 attacking a unit with Armour 6 has a 45% chance to penetrate. The overall process for checking if a shot destroys a target is Chance To-Hit, followed by Armour Penetration Check, followed by Damage Check. All three must be successful to destroy the target. Each type of Armour has two values.

1) Base AR: The Base Armour Rating is multiplied by Unit Size (including components below) to determine cost. So a unit with 6 armour would be 50% more expensive than the same unit with 4 armour.
2) Racial AR: Racial Armour Rating is the Base Armour Rating multiplied by the Racial Armour Strength (shown at top of window).

Below the base type and armour is a large section showing Components. Infantry, static and light vehicles all have one 'component slot', vehicles and heavy vehicles have two slots, while super-heavy and ultra-heavy vehicles have three and four slots respectively. Each slot can hold one component from the list and the same component can be put into multiple slots. Certain components are only available with certain base types. For example, the Super-Heavy Anti-Vehicle component can only be used by super-heavy and ultra-heavy vehicles. The primary component is selected from the main table, while any additional components are selected from the dropdown(s) below the main table. Each component has a name and an abbreviation and is rated in nine different areas:

1) Size: The size in tons is added to the size of the base unit type.
2) Armour-Penetration (AP): If the component is a weapon, the chance to penetrate a target's armour is (AP / Armour) ^2. The AP Rating is the underlying AP of the component (not shown), multiplied by the Racial Weapon Strength.
3) Damage:  If the component is a weapon, the chance to destroy a target after the armour has been penetrated is (Weapon Damage / Hit Points) ^2. The damage value is the underlying damage rating of the component (not shown), multiplied by the Racial Weapon Strength.
4) Shots: The number of times a weapon will fire during each ground combat phase
5) CIWS: 'Y' indicates this component is a Close-in-Weapon-System, capable of defending the planet (on which the unit is based) from missile attack. This CIWS will use the values in the CIWS section, which will become visible when a CIWS component is selected. More on this in a later rules post.
6) STO: 'Y' indicates this component is a Surface-To-Orbit energy weapon, capable of engaging ships in space within weapon range of the planet on which the unit is based. The weapon type used for the STO component can be selected in the section to the centre right, which will become visible when an STO component is selected. More on this in a later rules post, although see the second screenshot.
7) HQ: The headquarters capacity of the component in tons. This is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. To assign a commander to a formation, one of the units within that formation requires a headquarters component. More details on command hierarchies will be provided in a future rules post.
8) FFD: 'Y' indicates this component is a Forward Fire Direction (FFD) component. Forward Fire Direction allows a front-line unit (more on that later) to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit. A later rules post will explain this function.
9) Const. The construction value of the component in Construction Factory Equivalents (CFEs).

At the top-right of the window is the Capability section. One or more Capabilities can be selected for the Unit Class. The Boarding Combat capability is required for a Unit to be able to board another ship. For all other capabilities, the Chance to Hit is doubled in the environment specified. If a unit has multiple capabilities, such as Mountain Warfare and Jungle Warfare on a world with a dominant terrain of ‘Jungle Mountain’, the bonus is cumulative (i.e. 4x to-hit in this case). Each capability selected for a Unit will increase the cost by the multiple specified. Some capabilities are only available for infantry units.

In the bottom right section, a summary of the unit is shown in a similar style to the Class Summary for naval designs. When the sizes of all the units in a formation are aggregated, that is the transport requirement for that formation in tons. Cost is in BP. When the costs of all the units in a formation are aggregated, that is the build point requirement to construct the formation. Armour and Hit Points have been described previously. Below that is a list of components, followed by the materials required for construction and the research cost to develop the unit once designed.

I'll cover Formation Templates in the next rules post.



This screenshot shows a static unit with an STO component selected. The chosen weapon (which is any non-turreted weapon developed for shipboard use) is selected on the right. Spinal Weapons can be selected for ground use without penalty. The STO mount includes the weapon, a reactor of the exact size needed for the recharge rate, an active sensor with range greater than the weapon range and a built-in beam fire control with a 4x range modifier. The cost is equal to the static platform, the weapon, the reactor, the active sensor and half the fire control. STO weapons have a 25% bonus to fire control range. The damage shows two numbers, which is the damage at minimum and maximum range.

« Last Edit: December 10, 2018, 08:49:36 AM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #54 on: January 02, 2018, 01:55:51 PM »
Ground Forces: Part 2 - Formation Templates

The screenshot below shows the Formation Templates tab of the Ground Forces window. Formation Templates are the equivalent of VB6 Ground Unit Types, although it might be easier to think of them as serving the same function as Ship Classes. They are a detailed design that serves as a template for building Formations based on that same design, which is the same relationship as Ship Classes to Ships.

This tab is split into two halves. On the left is a list of available Ground Unit Classes created using the Unit Class Design tab (as explained in the previous rules post). All of these were created using TL4 technology, with three exceptions. For comparison purposes, the Challenger 2 Main Battle Tank and the Warrior AFV were created using Conventional, rather than Trans-Newtonian, technology, while the Challenger – Base TN Upgrade was the Challenger design with TL1 technology. It should be possible to simulate most modern army units with the new C# Aurora ground combat, so you could theoretically be landing on an alien world with Abrams and Bradleys or T-14 and T-15 Armatas. The ten columns for the Unit Class List are as follows:

1)   Type: An abbreviation for the Base Type (infantry, Vehicle, Heavy Vehicle, etc.)
2)   Name: The name assigned during Unit Class Design. This can be changed using the Rename Unit button.
3)   Size: Transport size in tons.
4)   Cost: Cost in Build Points.
5)   Arm: The Armour Strength of the Unit. This is based on the armour available at the time of design and is not upgraded when newer technology becomes available (as with ship designs).
6)   HP: The Hit Points of the Unit. This is set at design time and does not change.
7)   Components A to D: Abbreviations for each of the components included in the Unit Class. These are the same abbreviations as used on the Components table in the Unit Class Design tab. As with armour and hit points, any components use the technology available at the time of unit design. To see the detailed view of the components, click on the Unit. The Unit Summary will be shown in the bottom section on the left hand side.

As an example, the Leman Russ Battle Tank is a Heavy Vehicle of 104 tons, with 60 Armour and 60 Hit points, costing 12.48 BP. The components are Heavy Anti-Vehicle (HAV) and Heavy Crew-Served Anti-Personnel (HCAP). Looking at the summary, the HAV has 1 shot per combat phase with Penetration 60 and Damage 60, while the HCAP has 6 shots with Penetration 20 and Damage 10.

The right-hand half of the tab shows Formation Templates. A new Formation Template is created by clicking the New button. In this case, four have already been created. Each Template comprises one or more Template Elements, shown in the bottom right section Each Template Element has a specific number of specific Ground Unit Class. For example, the Guard Armoured Regiment is currently selected, which has four template elements: 60x Leman Russ Battle Tank, 1x Macharius Command Tank, 12x Hydra Flak Tank and 24x Hellhound Anti-Infantry Tank.

Each template element has the following attributes:
1)   Name: The Unit Class for this element.
2)   Units: The number of units of that Unit Class in this element
3)   Size: The total size on tons of this element. For example, 60 Leman Russ Battle Tanks at 104 tons each is 6,240 tons.
4)   Cost: The total cost in Build Points for this element.
5)   HP: The total aggregate hit points for the element.
6)   HQ: The headquarters capacity of the element’s Unit Class in tons. If there are multiple units in a template element, only one is considered for the headquarters capacity. Any additional units are for redundancy. The headquarters capacity is the total size of the formation (or formation hierarchy) that can be effectively controlled by a commander based in a unit with this component. In the case of the Macharius Command Tank, it has an HQ capacity of 10,000 tons.
7)   FFD: The total number of Forward Fire Direction (FFD) components in the template element. Forward Fire Direction allows a front-line unit to direct the fire of bombardment units from a formation in a support position, fighters on close air support missions, or ships in orbit.
8)   Const. The construction value of the element in Construction Factory Equivalents (CFEs).
9)   CIWS: The number of Close-in-Weapon-System components in the template element, capable of defending the planet (on which the unit is based) from missile attack.
10)   STO: The number of Surface-To-Orbit energy weapon components in the template element. STOs are capable of engaging ships in space within weapon range of the planet on which the unit is based.

The totals for each Template Element are added together to create the total for the Formation Template as a whole, shown in the top right section. In the example shown, the Guard Armoured Regiment has a total size of 8,942 tons, which is the combination of all four template elements. The Formation Template list has an additional column for Rank. A default rank will be suggested by the program, although this can be overridden by the player. This rank will be used by Automated Assignment process for any Formations built using this Formation Template.

To add new Template Elements to a Formation Template, use the Add Units button in conjunction with the adjacent text field to specify the number of units in the new element. This number can be subsequently edited by selecting the element and clicking the Edit Amount button. Both Formation Templates and Element Templates can be deleted using the appropriate buttons.



This screenshot shows the Macharius Command Tank on the left and the Brigade Headquarters formation template on the right. The Macharius is a super-heavy vehicle, with two super-heavy anti-vehicle weapons and an HQ4 component, which provides a headquarters capacity of 10,000 tons. This is a large and expensive vehicle at 518 tons and 93.24 BP, but is well-protected as the loss of the HQ in a formation will result in the loss of any commander bonuses (and maybe the commander himself).

The Brigade Headquarters formation template includes two Guard Brigade Headquarters units, in case one is destroyed, plus thirty-six large artillery pieces, twelve flak tanks and a company of Guardsman. Combat involves three locations. Front-Line, Support or Rear-Echelon. Units in a Support position can only attack using bombardment weapons, or defend themselves against air attack. This formation is intended to serve in the Support location and is organising accordingly. However, it is possible for a Support Formation to temporarily find itself moved into a Front-Line position, so the Guardsman Element will provide additional protection in that case.

« Last Edit: February 21, 2018, 01:45:22 PM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #55 on: January 23, 2018, 04:50:21 PM »
Sol System Changes

This is a placeholder for Sol System changes as I make them

1) Salacia and 2007 OR10 upgraded to dwarf planet status. They are large enough and I am sure this will be confirmed at some point.
2) Added 2017 MB7. Asteroid/Comet with furthest known orbit.
3) C/2017 K2: Non-periodic comet
4) Oumuamua: Interstellar object but treated as extreme distance comet heading outwards
5) 2017 UV43: Centaur.
6) 2015 RR245: 700 km diameter Trans-Neptunian object (TNO)
7) 2015 KH162: 700 km diameter TNO
8) Added Ultima Thule. 30 km diameter TNO
« Last Edit: January 04, 2019, 11:44:42 AM by Steve Walmsley »
 
The following users thanked this post: Laurence, waresky, Garfunkel, SpikeTheHobbitMage, Prapor, Tristitan, madgabz, serger, Rye123, bugkill

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #56 on: January 28, 2018, 04:33:32 AM »
New Game Settings

This is a placeholder for Game-level modifiers

1) Percentage modifier for Research Speed (for all races)
2) Percentage modifier for Terraforming Speed (for all races)
3) Percentage modifier for starting minerals on Sol.
4) Flag for Active Civilian Shipping Lines. When this is disabled, shipping lines will not produce ships.
5) Flag for Civilian Harvesters. When this is disabled, shipping lines will not build fuel harvesters.
6) Flag for recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
7) LY entry to limit Starting NPR Locations to within a specific range of Sol: http://aurora2.pentarch.org/index.php?topic=8495.msg108824#msg108824
8) Option for Planet X in the Sol System: http://aurora2.pentarch.org/index.php?topic=8495.msg109206#msg109206

You can specify a number of Earth-based player races on the Game Setup window. You will cycle through a number of Race Creation windows equal to the number of races selected. You will still need to create any non-Earth-based races after the main game creation process.
« Last Edit: January 29, 2019, 12:48:20 PM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #57 on: February 12, 2018, 02:58:27 PM »
Starting Build Points

A new player race in Aurora receives a number of Starting Build Points equal to two years wealth. These can be spent on instant build for Ships and Ground Formations.

If the available Instant Build Point total is greater than zero, the Instant Build section will be shown on the Miscellaneous tab of the Class window, including the current Instant Build Point total, plus selection options for destination fleet and number of ships to be built. This section will also appear if SM Mode is active, so additional ships can be instantly built if required by the game setup.

If the available Instant Build Point total is greater than zero, that total, plus the Instant Build button, will be shown on the GU Training tab of the Economics window. When the Instant Build button is clicked, a popup box will allow entry of the number of formations to be built. This button will also appear if SM Mode is active, so additional formations can be instantly built if required by the game setup.

If you choose to have automatically constructed ground formations at game start, their cost will be deducted from the starting build points.

The ship options replace the VB6 Fast OOB window, while the ground options are new for C# Aurora.
« Last Edit: February 12, 2018, 03:07:52 PM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, SpikeTheHobbitMage, Viridia, Tristitan, TMaekler, Rye123, lordcirth

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #58 on: February 21, 2018, 07:40:50 AM »
Standing Order for Unload Colonists

I've completely rewritten the standing order (VB6 default order) for unloading colonists (used by shipping lines, NPRs and your own ships if desired). The process is as follows:

1) Colony fleet looks for a suitable population that is set as a destination with no other colony fleets inbound, checking its current system first and then using the path finding algorithm to search everywhere else in the empire.
2) Same as 1) but without the check for inbound colony ships.

When determining if a population is a suitable destination, the fleet checks the following:

1) How many colonists it is carrying.
2) If the species is the same as the colonists.
3) The available capacity of the system body on which the population is situated, taking into account other populations.
4) The available capacity of the infrastructure (normal or LG depending on the gravity), taking into account the current population size.
5) The lesser of 2) and 3) is used as the base capacity of the population to accept new colonists.
6) Any available space in orbital habitats is added to that capacity.
7) The total number of colonists on ships already inbound to the colony is deducted from that capacity.
8) if the capacity exceeds the number of colonists in the checking fleet and the species match, the colony is suitable.

This should prevent the current problem of many colony ships delivering to a colony without the capacity to support them all. As soon as a fleet determines a colony is suitable, the orders are issued, which means other fleets checking in the same increment will be aware of the extra inbound colonists.

Because of these changes, Passenger Liners will no longer search their current system for a potential destination (otherwise they could load and unload at the same population).
« Last Edit: December 21, 2019, 10:03:59 AM by Steve Walmsley »
 

Online Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 12036
  • Thanked: 22710 times
Re: C# Aurora Changes List
« Reply #59 on: February 21, 2018, 08:23:46 AM »
Shipping Lines

A Shipping Line will start building freighters and colony ships when the parent race has two colonies (including the capital) with populations greater than zero.

A Shipping Line will start building passengers liners when the parent race has two colonies (including the capital) with populations greater than zero in two different systems.

A Shipping Line will start building harvesters when the parent race has two colonies with populations greater than zero and there is Sorium present at any gas giant or superjovian in a system with a parent race population of at least ten million (including the capital).

The number of civilian freighters and colony ships will be kept relatively even.

Creation of new shipping lines will only be possible once the starting shipping line has created its first ship.
« Last Edit: February 04, 2019, 11:55:17 AM by Steve Walmsley »
 
The following users thanked this post: Garfunkel, Doren, SpikeTheHobbitMage, Viridia, Kytuzian, Tristitan, TMaekler, serger, Rye123