Aurora 4x

Aurora => C# Aurora => Topic started by: Steve Walmsley on April 02, 2016, 09:03:29 AM

Title: C# Aurora Changes List
Post by: Steve Walmsley on April 02, 2016, 09:03:29 AM
This thread is for me to note any significant changes in functionality for C# Aurora, beyond minor UI updates.

Low Gravity Infrastructure

Underground Infrastructure is replaced with Low Gravity Infrastructure (or LG-Infrastructure). This will be built and transported in the same way as regular infrastructure, except it will be more expensive - probably 6 BP instead of 2 BP.

Any low gravity bodies (below the minimum gravity of the colonising species) will now have a normal colony cost calculation (based on atmosphere, temperature, pressure, etc.) and an 'LG' suffix will be added. For any bodies with an LG suffix, the maximum supported population will be based on the available LG-Infrastructure.

For example, for a colony cost 2.00 world you need 200 infrastructure per 1m pop. For a colony cost 2.00(LG) world, you will need 200 LG-Infrastructure per 1m pop and normal infrastructure will have no effect.

Both normal infrastructure and LG-Infrastructure can be used on a world with gravity in the tolerable range. Worlds with gravity above max species gravity will not be colonizable.

Civilian infrastructure production on a low gravity world will be LG Infrastructure, produced at one third of the normal rate (same overall cost). Trade in infrastructure will be low gravity to low gravity or acceptable gravity to acceptable gravity .

I believe this change will maintain the concept of colonising low gravity bodies at a higher cost but will be a lot cleaner and easier.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 18, 2016, 05:23:01 AM
Naming Themes

In VB6 Aurora, we have racial themes that include system names, class names and rank names, plus a variety of ship name themes.

For C# Aurora, they are all amalgamated into Naming Themes, which can be used individually for Classes, Systems and Ships. Ranks will be handled separately.

A race will select a Class Naming Theme, a System Naming Theme and a Rank Theme (so you can use current Ship name themes at the Race level). Each Ship Class can also have a Naming Theme.

The Naming Themes comprises everything previously used for Ships, plus the existing Racial Themes separated out into the System and Class elements (and named appropriately so you can replicate existing Race Themes if desired).

This should be a lot more flexible while allowing everything you can do now. It will also make it a lot easier for players to add customised themes.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 25, 2016, 08:35:57 AM
Repair Task in Shipyards Window.

When selecting the repair task in the shipyards window, only classes / ships needing repair and currently in orbit will be displayed. In VB6 Aurora, all classes / ships in orbit are displayed and you have to cycle through to find the damaged ships.

If no ships in orbit are in need of repair, the class and ship drop downs will be empty.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 03, 2016, 07:35:12 AM
Shipbuilding Changes

I'm using this post as a placeholder to post any shipbuilding changes. So far the changes are:

1) You can't refit a damaged ship.
2) Scrapping/Deleting is much more intelligent about moving commanders, teams and ground units from a ship to the scrapping population (in case you accidentally scrap or delete a ship with them on board). Fuel, maintenance and ordnance are also automatically unloaded.
3) When a ship undergoes refit, fuel, maintenance and ordnance are moved from (or to) the refitting population to account for the differences post-refit.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 16, 2016, 05:44:09 AM
Trade Good Modifiers

In VB6 Aurora, civilian production of trade goods is affected by the population size, the race wealth creation rate, the production rate of each specific trade good, the political status of the colony and the wealth modifier of the planetary and sector governors.

In C# Aurora, it will also be affected by radiation and unrest.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 25, 2016, 10:11:17 AM
Reaction Bonus

A commander's initiative bonus has been replaced by a new Reaction Bonus. This serves two functions:

1) Fleets (both player and NPR) will move in ascending order of the average reaction bonus of the ship commanders in the fleet.
2) Response time for orders (when hostiles are present), which is based on fleet training, will be further reduced by the average reaction bonus of the ship commanders in the fleet.
3) Any ship without a designated commander will be treated as if it has a commander with a 0% bonus.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 25, 2016, 10:17:22 AM
Naval Organization

Instead of the Task Forces and Task Groups in VB6 Aurora, C# Aurora takes an approach similar to the optional functionality of the VB6 Naval Organisation tab, albeit with much easier and more flexible UI. There are four primary components of Naval Organisation; Admin Commands, Fleets (VB6 Task Groups), Sub-Fleets and Ships. Every race starts with a single top level Admin Command (which can't be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy.

Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command

Sub-Fleets can only be attached to a Fleet, or to another sub-fleet. You can have an unlimited number of levels within the sub-fleet hierarchy. These are used to organise the ships within the larger fleets. Sub-fleets have no on-map function and all ships within the sub-fleet hierarchy move within the parent fleet. You can detach a sub-fleet, at which point it becomes a full fleet in its own right. Any sub-fleets further down the sub-fleet hierarchy become sub-fleets of this new fleet. A new 'join as sub-fleet' order is available. When one fleet joins another using this order, its ships will automatically form a sub-fleet within the joined fleet, allowing them to subsequently detach as a whole unit.

A Ship can be attached to a Fleet or to a sub-fleet. When attached to a sub-fleet, it is still a member of the parent Fleet at the top of the sub-fleet hierarchy.

The sidebar tree of the new Naval Organisation window (see Screenshots thread) has full drag and drop functionality so you can move Admin Commands, Fleets, Sub-Fleets and Ships around as long as the above rules are followed. You can also drag ships and sub-fleets between different fleets as long as they are in the same physical location. Entire sections of the tree can be moved with a single drag-drop. Also, you can open up multiple Fleet windows and drag and drop between the trees in two different windows.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 01, 2016, 06:34:44 PM
Shipping Line Earnings and Tax

For C# Aurora, the distance a civilian ship has travelled (in terms of systems) will affect how much the shipping line receives in payment and how much tax is generated.

All VB6 payment rates will be halved as a baseline but multiplied by the number of systems travelled. So a civilian ship travelling to a destination two transits away will receive the same payment as in VB6 Aurora. A ship travelling to a destination five transits away will receive 250% of the current payment. This applies to trading and to player contracts.

A civilian ship travelling within the same system will be paid half of the one-system rate (which is half what is currently paid in VB6).

This should reduce some of the early game bloating of civilian traffic but make it workable for the later game with longer distances (especially with the new jump point generation in v7.1 of VB6 Aurora).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 02, 2016, 12:18:16 PM
Load & Unload Cargo

In VB6 Aurora, ships load or unload cargo, colonists, etc. on arrival and then undergo a wait period before their next order (based on how long it takes for the load/unload process).

In C# Aurora, the wait period will take place first and then the cargo will be loaded or unloaded at the end. Because of this change, if the fleet abandons the order before it is complete, no transfer of cargo will have taken place.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 02, 2016, 03:17:13 PM
Refuelling Changes

In C# Aurora, refuelling is no longer instant and ships without specialised equipment cannot exchange fuel in space. A ship can only refuel at a Spaceport, a Refuelling Station, a ship with a Refuelling System or a base with a Refuelling Hub.

A new technology line - Refuelling Systems - provides the basis of the rate of refuelling and allows ships to mount systems to refuel other ships. The baseline system (Refuelling System: 50,000 LPH) sets the racial refuelling rate at 50,000 litres per hour and allows the use of the first ship-mounted Refuelling System. There are ten further steps in the tech progression with the highest tech system allowing refuelling at 500,000 litres per hour.

Spaceports, Refuelling Stations or Refuelling Hubs will always use the highest tech refuelling rate and can refuel an unlimited number of ships simultaneously. However, the ships being refuelled must be stationary.

Spaceports have doubled in cost to 2400 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.

Refuelling 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 refuelling in forward areas, transferring fuel from the surface of a planet to the waiting ships. They have no bonuses for loading or unloading cargo.

A Refuelling 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 tankers that will accompany fleets

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

Refuelling order types will be adjusted to deal with the new requirements. Fuel will be transferred during each movement increment as time passes until the target ship has full tanks. I may add some other options regarding partially filling as well.

I will be adding some rules along the same lines regarding ordnance transfer.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 05, 2016, 03:50:47 PM
Assignment of Ships to Populations

In VB6 Aurora, ships such as terraformers or asteroid miners have to be assigned to populations in order to provide that population with any applicable production. This is because an empire may have multiple populations on the same world and the ships can only provide support to one of them. When a fleet reaches a population, the ships within it are automatically assigned. However, there are still situations (such as transferring between fleets) when this assignment is not always picked up. While the problem can easily be fixed by ordering the fleet to the population, it is not always obvious it needs to be fixed. This can lead to ships sitting idle in orbit.

In C# Aurora, the assignment to the population will be at the fleet level, rather than by ship, and the same auto-assignment will happen when a fleet moves to a population. However, when a population checks orbital space for any assigned fleets during production, it will automatically grab any unassigned fleets in orbit and assign them to itself. This should avoid any situations where ships remain idle.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 06, 2016, 04:05:08 PM
Standard transits by Fleets with Commercial and Military Ships

In VB6 Aurora, fleets that included at least one ship with military engines could only use military jump drives for standard transits, which meant you had to split out commercial-engined ships into a separate fleet and escort them with a commercial jump drive ship.

In C# Aurora, commercial-engined and military-engined ships are treated separately. So if you have a fleet with mixed engine types that also includes ships with commercial and military jump drives, it will still carry out a standard transit if the respective jump drives are large enough for the ships with the matching respective engine types. However, if any ship with either engine type can't jump, the whole fleet will fail to transit.

Squadron jumps are handled differently so I will cover that in a separate post.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 15, 2016, 05:23:40 PM
Refuelling Orders

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

You can flag a tanker as being at one of three refuel statuses; None, Refuel Fleet or Refuel Sub-Fleet. When this flag is set to Refuel Fleet, the tanker will constantly refuel its own fleet as that fleet continues with normal orders (the refuel itself is not an order). Essentially, the tanker will keep the fleet's fuel tanks topped up. The rate of refuel will be based on the refuelling system of the tanker multiplied by the parent race's underway replenishment tech (unless the fleet is stationary). If the flag is set to Refuel Sub-Fleet, the tanker will follow the same rules as above but only for ships within the same sub-fleet (you can use this distinction to control which ships are refuelled within the fleet)

Each tanker class has a minimum fuel setting (in the class window) and will not refuel ships once it falls below that level. Each class & ship has a 'refuel priority', with higher numbers equalling higher priority. The tanker will refuel in descending order of ship priority, then by descending order of class priority. The tanker will automatically move to a second ship (or more) if there is sufficient time and fuel remaining in the sub-pulse.

The current 'Refuel Fleet' order has been replaced with 'Join & Refuel Fleet'. The fleet containing the tanker will become part of the target fleet and switch to a 'Refuel Fleet' status (if not already set).

A new 'Join & Refuel Sub-Fleet' order has been added. The fleet containing the tanker will become part of the target sub-fleet and switch to a 'Refuel Sub-Fleet' status (if not already set). A Join Sub-Fleet order has also been added for more general use.

A new 'Refuel from Refuelling Hub' order has been added. This order requires a second fleet containing at least one refuelling hub as the destination. On arrival, the fleet will be refuelled until all its tanks are fuel, or the refuelling hub runs out of fuel. All ships in the fleet will be refuelled, including tankers. Once completed, the fleet will move on to its next order. If the fleet containing the refuelling hub has any movement orders, the refuelling will not take place and the refuelling order will be marked as completed. Multiple hubs in the target fleet will not increase the rate of refuelling (a ship can only refuel from one hub at once) but they can all contribute fuel.

The existing 'Refuel from Colony' will remain but can only be used at colonies that have either a Spaceport or a Refuelling Station. On arrival, the fleet will be refuelled until all its tanks are fuel, or the colony runs out of fuel. All ships in the fleet will be refuelled, including tankers. Once completed, the fleet will move on to its next order. Multiple spaceports or refuelling stations at the colony will not increase the rate of refuelling.

The 'Unload 90% Fuel to Colony' order now becomes 'Transfer Fuel to Colony'. Any class designated as a tanker can transfer fuel to any colony with either a spaceport or a refuelling station. The transfer is done at the refuelling rate of the tanker. If multiple tankers are in the fleet, they can transfer fuel simultaneously. Note this means that more planning will be needed in this version of Aurora to ensure fleets can be refuelled at the frontier. It will no longer be possible to dump fuel on the nearest available rock. Colonies will require a spaceport or a refuelling station before they can support fleets. Alternatively, tankers can accompany fleets, or a deep space base with a refuelling hub can be established.

A new 'Transfer Fuel to Refuelling Hub' order has been added. Any class designated as a tanker can transfer fuel to any ship with a Refuelling Hub. The transfer is done at the refuelling rate of the tanker. If multiple tankers are in the fleet, they can transfer fuel simultaneously.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 27, 2016, 09:07:01 AM
System Naming

In C# Aurora, you can optionally assign one of the new Naming Themes to a system. Any future exploration beyond that point will use the selected naming theme. This allows you to have different naming themes for different warp chains.

The order of name selection for new systems will therefore be:
1) Actual System Name (for known stars)
2) Next name for Naming Theme associated with the system from which the exploring ship originated (if a theme is set)
3) Next name for Racial System Theme
4) "System #" + System Number

You can still rename systems directly and will be able to use text, or select any name from any name theme.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 07, 2017, 07:39:24 AM
Population Capacity

A new concept, Population Capacity, has been added to C# Aurora. This represents the maximum population that can be maintained on a single body and is primarily determined by surface area. This is the total of all populations on the same body, not per population.

The Earth's population is currently seven billion. However, the rate of population growth peaked at 2.1% at four billion, has been dropping since then (now 1.2%) and is projected to reach close to zero around eleven billion

https://ourworldindata.org/world-population-growth/

Therefore, I am going to use twelve billion as the baseline max capacity for an Earth-sized planet and four billion as the point at which growth rates are affected. Growth will follow the normal rules for up to 1/3rd of max capacity and then will fall off at a linear rate, hitting zero growth at max capacity (replicating the situation on Earth). The max capacity of a body will be equal to: (Surface Area / Earth Surface Area) * twelve billion. I will add some tech options to improve that capacity, particularly for smaller bodies. A planet can physically hold more people than the max capacity but this will result in unrest due to overcrowding.

While 70% of the Earth's surface is water, that plentiful water also improves living conditions (the majority of the world's population is less than 100 km from the nearest coastline). However, there does come a point when too much water will reduce the available living space. Therefore, once water covers more than 75% of the planet, capacity will drop at a linear rate, falling to 1% of normal capacity at 100% water. The 1% assumes a few, small, scattered islands or some form of colony floating on the surface.

Tide-locked worlds (one side always facing the star) have only 20% of normal capacity (after taking into account surface area and water). This is to simulate that the population will be living in a narrow band between the light and dark hemispheres of the planet. To compensate, these worlds also have an 80% reduction in the colony cost factor for temperature (as they are living in the temperate band).

Regardless of the result of the above calculations, a body with gravity at or below the species maximum that is not a gas giant or super-Jovian will always have a capacity of at least 50,000.

The above rules result in the following population capacities

(http://www.pentarch.org/steve/Screenshots/PopCapacity.PNG)

EDIT Jan 21st 2017: Each Species has a population density modifier. This is normally set to 1 but there a small chance it can be higher or lower for random species. Player-created species can specify this density.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 21, 2017, 11:56:26 AM
New Species Attributes

Each Species now has four new attributes, all of which default to 1.0 but have a low chance to be higher or lower:

1) Population Growth Rate Modifier
2) Population Density Modifier (affects max population as some species prefer more open environments while some can accept higher population densities than normal)
3) Research Rate Modifier (increases or decreases research rate)
4) Production Rate Modifier (affects factories, refineries and shipbuilding)

Player-created Species can have custom values set. Also note this is at the species level, not the empire level. Empire modifiers to Research or Production are based on technology rather than innate ability.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 18, 2017, 11:55:06 AM
Command & Control Rules

I am introducing new command and control rules for C# Aurora. The commander of a ship will only apply half his bonus for Crew Training, Survey, Fighter Operations, Engineering (new skill) and Tactical (new skill). However, additional officers can be assigned to the ship with each officer applying his full bonus for his chosen speciality (more on that later). The commander of the ship is now a jack-of-all-trades, applying a portion of his bonus while the specialists provide the larger bonuses. Larger ships gain an advantage as they can afford the space to accommodate the specialists, while smaller ships have to make do with the commander handling everything (at half efficiency). Any bonuses not mentioned here (such as Reaction or Production) will still be at full value for the commander.

Five new command and control modules have been added, the cost of the bridge has been doubled and the role of the flag bridge has been changed. Each module adds one to the Control Rating of the ship.

1) Bridge is 1 HS and costs 20 BP. The required rank for the ship commander is the racial minimum.

2) Auxiliary control is 1 HS and 15 BP. Allows the assignment of an Executive Officer to the ship who will apply his full Crew Training Bonus. The required rank for the ship commander is one above the racial minimum.

3) Science Department is 2 HS and 50 BP. Allows the assignment of a Science Officer to the ship who will apply his full Survey Bonus. The required rank for the ship commander is one above the racial minimum.

4) Main Engineering is 3 HS and 75 BP. Allows the assignment of a Chief Engineer to the ship who will apply his Engineering Bonus to affect maintenance and damage control. The required rank for the ship commander is two above the racial minimum.

5) Combat Information Centre (CIC) is 3 HS and 75 BP. Allows the assignment of a Tactical Officer to the ship who will apply his Tactical Bonus to various combat-related function (TBD). The required rank for the ship commander is two above racial minimum.

6) Primary Flight Control is 4 HS and 100 BP. Allows the assignment of a Commander Air Group to the ship who will apply his full Fighter Operations Bonus. The required rank for the ship commander is one above the racial minimum.

7) Flag Bridge is 5 HS and 125 BP. A fleet that includes a ship with a flag bridge can assign a 'fleet commander' senior to the commander of the ship. If a fleet has multiple flag bridges, the most senior officer assigned to any of them will be the fleet commander. The fleet commander will improve the fleet's overall reaction rating by his Reaction Bonus. If there are no flag bridges in a fleet, the senior ship commander will be the de facto fleet commander, but his reaction bonus will not affect other ships. The required rank for the ship commander of the ship with the flag bridge is two above the racial minimum. There are no longer any task forces or staff officers. Any commander assigned to a flag bridge who is not the most senior in the fleet will be referred to as a 'Flag Officer'.

In cases where different control stations have different required ranks for the ship commander, the highest rank takes precedence.

An officer can be killed if his station is damaged. I may also add 'temporary promotions' if the commander is killed, with the most senior surviving officer taking over as commander until relieved or promoted.

Except for the ship commander and the executive officer, the bonus from each specialist will only apply if their associated module is undamaged. Bonuses from the commander and XO will only apply if the ship has a control rating greater than zero (they can command the ship from any of the surviving control spaces). Ships smaller than 1000 tons automatically have a control rating of 1, even without a bridge. This is to simulate that small ships do not require a dedicated centralised command function.

I don't plan to scale the modules to ship size or add extra crew. That would add extra complexity and make designing ships more difficult. For small ships, most command and control modules won't be used, and once you get past a certain size of ship, they will probably all be used. I am not trying to create a decision as to whether a battleship should have a CIC or Main Engineering, but rather to create meaningful choices for mid-range ships.

For auto-assignment purposes, each ship class now has a specific rank requirement for its commander, based on its command and control modules. The rank requirement for the XO, CAG and Science Officer is one lower than for the ship commander. The rank requirement for the Chief Engineer and Tactical Office is two lower than the ship commander. The rank requirement for a fleet commander is one higher than for the ship commander. You can manually assign higher-ranked ship commanders and fleet commanders if desired but other officers can only be assigned at the specified rank. The commander priority setting for each class of ship remains as before and is still set manually. It also applies to the other officer types as well. Auto-assignment will work in the following sort order:

1)   Class Priority
2)   Survey Ships by descending size
3)   Warships by descending PPV
4)   Unarmed Military Ships by descending size
5)   Construction Ships by descending construction speed
6)   Terraformers by descending terraforming capacity
7)   Sorium Harvesters by descending harvesting capacity
8)   Asteroid Miners by descending mining capacity
9)   Salvage Ships by descending salvage capacity
10)   All other ships (primarily freighters and colony ships) by descending size

Ship commanders will be assigned first (checking every category above), followed by executive officers, science officers, air group commanders, chief engineers and tactical officers. The ships will cycle through in priority order and commanders will be assigned if they meet the criteria for the ship type (correct rank and suitable bonus).

These changes should make ship design more interesting, create better histories for commanders (as they progress through different roles) and provide lots of potential roles for the junior commanders.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 24, 2017, 07:51:04 AM
New Maintenance Rules

In VB6 Aurora, the maintenance facilities of a population, aided by ships in orbit with maintenance modules, have a maximum maintenance capacity measured in tons. Any ship of that size or less can be maintained. Fighters cannot be maintained in this way and have to be stored in hangars.

In C# Aurora, maintenance facilities and modules are handled differently:

1)   Each maintenance facility or maintenance module has a basic capacity of 1000 tons. A new tech line exists that can raise this capacity in increments, starting with 1200 capacity for 2000 RP. The 2000 ton capacity is at 16,000 RP and the max is 3600 tons at 120,000 RP.

2)   Any location that contains a population with maintenance facilities or a ship with maintenance modules is known as a 'Maintenance Location'. This does not need to be in the same location as a population. A Maintenance Location consisting only of ships with maintenance modules could be in deep space.

3)   The maintenance capacities of all populations and maintenance ships of the same race in the same Maintenance Location are added together to create a 'Total Maintenance Capacity'.

4)   A Maintenance Location can fully maintain ships in its location if the total tonnage of those ships is equal to or less than the Total Maintenance Capacity. In other words, maintenance is now based on summing the tonnage of ships to be maintained, rather than supporting all ships under a set tonnage.

5)   If the total tonnage of the ships to be maintained is greater than the Total Maintenance Capacity, each ship will be partially maintained. This is known as the 'Effective Maintenance Rate (EMR)' For example, if the Total Maintenance Capacity is 80,000 tons and the total tonnage of the ships requiring maintenance is 100,000 tons, the EMR is 80%. Each ship will use 80% of the normal amount of MSP required for maintenance. Each's ship maintenance clock will advance at 20% of normal and their chance of system failure will be 20% of normal.

6)   The maintenance capacity of maintenance facilities on a population is modified by the population's Manufacturing Efficiency (available worker / required workers), Radiation Production Modifier, Political Stability Modifier (based on unrest) and Political Status Production Modifier (Conquered / Subjugated, etc.). The capacity of both maintenance facilities and maintenance modules is modified by the racial Economic Production Modifier (amount of debt vs annual income).

7)   Ships can enter overhaul in the same way as they do now, except they can also do this at a deep space Maintenance Location as well as at a population. Overhauls will proceed at a slower rate (and use fewer MSP) if the total tonnage of the ships being maintained exceeds the Total Maintenance Capacity. However, ships undergoing overhaul will not suffer maintenance failures in this situation.

8)   Fighters can be maintained by Maintenance Locations and do not need to be stored in hangars (because now they use capacity whereas the VB6 rule was implemented to prevent unlimited fighters being maintained).

Use of Maintenance Supply Points (MSP):

1)   MSP are used in a very similar way to VB6 Aurora. While a ship is being maintained, it requires total MSP per year equal to Class Cost / 4. A ship undergoing overhaul requires total MSP per year equal to Class Cost.

2)   If the ship is being maintained in a situation where the total tonnage of the ships being maintained is greater than the Total Maintenance Capacity (EMR less than 100%), the MSP requirement will be reduced accordingly (see above).

3)   The ship being maintained will use up MSP from any racial populations in the same location, in descending order of MSP stockpile. If no populations are available, or have no MSP, the maintained ship will use MSP from any Supply Ships in the same location, in descending order of available MSP. Finally, if no other option is available, the maintained ship will consume its own MSP. A ship can use a combination of the above to locate sufficient MSP.

4)   If the ship cannot locate sufficient MSP to meet the requirements for maintenance, this also has an impact on the Effective Maintenance Rate (EMR) for that specific ship. For example, assume a Maintenance Location with a capacity of 80,000 tons is maintaining 100,000 tons of shipping. The EMR for that Maintenance Location is 80%. A ship with a class cost of 1500 BP is being normally maintained and will require annual MSP equal to (Class Cost / 4) * EMR or (1500 / 4) * 80% = 300 MSP. If the ship can only locate 240 MSP, the EMR will be reduced by the proportion of available MSP to required MSP: (240 / 300) * 80% = 64%. The ship will now consume 240 MSP, the maintenance clock will be advanced at 36% of normal and the chance of system failure will be 36% of normal. (in reality the MSP numbers will be much smaller as during a single increment the ship is being maintained for only a small fraction of a year).

5)   The order in which ships are checked for available MSP is based on Class Maintenance Priority, then by Overhaul vs. Normal Maintenance, then by highest maintenance clock.

6)   The chance of system failure, whether away from a Maintenance Location or while being partially maintained, is reduced by the crew grade bonus (or increased for crews with a negative bonus) and the ship's Engineering bonus (50% of commander bonus and 100% of Chief Engineer bonus).

These new rules remove many of the maintenance restrictions on larger ships and make maintenance of FACs and fighters more realistic. They introduce the same economic factors to maintenance that exist for production. In addition, I believe this creates a more realistic environment where the required maintenance facilities / modules are tied to the absolute amount of ships to be maintained, rather than just their maximum size. Finally, maintenance can now be carried out away from population centres, making deep space bases a possibility.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 25, 2017, 01:47:00 PM
Colony Cost

The colony cost algorithm has been updated for C# Aurora to include hydrosphere extent, low gravity and tide-locked worlds and to change the rules for dangerous gases and max pressure. The new calculation is as follows:

Gas Giants, Super Jovians and worlds with a gravity higher than species tolerance cannot be colonised and therefore have no colony cost. Every other body has a colony cost that is equal to the highest colony cost factor from the following list:

Temperature: If the temperature is outside of the species tolerance, the colony cost factor for temperature is equal to the number of degrees above or below the species tolerance divided by half the total species range. For example, if the species range is from 0C to 30C and the temperature is 75C, the colony cost factor would be 45 / 15 = 3.00. The colony cost factor for tide-locked planets is 20% of normal, so in the example given the colony cost factor would be reduced to 0.60.

Atmospheric Pressure: If the atmospheric pressure is above species tolerance, the colony cost factor for pressure is equal to pressure / species max pressure; with a minimum of 2.00. For example, if a species has a pressure tolerance of 4 atm and the pressure is 10 atm, the colony cost factor would be 2.50. If the pressure was 6 atm, the colony cost factor would be 2.00, as that is the minimum.

Breathable Gas: If the atmosphere does not have a sufficient amount of breathable gas, the colony cost factor for breathable gas is 2.00. If the gas is available in sufficient quantities but exceeds 30% of atmospheric pressure, the colony cost factor is also 2.00.

Dangerous Gas: If a dangerous gas is present in the atmosphere and the concentration is above the danger level, the colony cost factor for dangerous gases will either be 2.00 or 3.00, depending on the gas. Different gases require different concentrations before becoming 'dangerous'. Halogens such as Chlorine, Bromine or Flourine are the most dangerous at 1 ppm, followed by Nitrogen Dioxide and Sulphur Dioxide at 5 ppm. Hydrogen Sulphide is 20 ppm, Carbon Monoxide and Ammonia are 50 ppm, Hydrogen, Methane (if an oxygen breather) and Oxygen (if a Methane breather) are at 500 ppm and Carbon Dioxide is at 5000 ppm (0.5% of atmosphere). Note that Carbon Dioxide was not classed as a dangerous gas in VB6 Aurora. These gases are not lethal at those concentrations but are dangerous enough that infrastructure would be required to avoid sustained exposure.

Hydrosphere Extent: If less than twenty percent of a body is covered with water (less than 20% Hydro Extent), the colony cost factor for hydro extent is (20 - Hydro Extent) / 10, which is a range from zero to 2.00.

Low Gravity: If the gravity of the body is lower than the species tolerance, the colony cost factor for gravity is 1.00. In addition, the overall colony cost for the body will be suffixed by 'LG', for example 2.00 LG, which indicates that low gravity infrastructure is required for any population on that body. Normal infrastructure will not count toward the supported population.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 29, 2017, 01:52:05 PM
Terraforming Update

In terms of the general mechanics, terraforming works as it does in VB6 Aurora. Atmosphere measured in atm (atmospheric pressure) is added by terraforming ships or installations. However, there are several significant changes for C# Aurora.

1)   The base terraforming technologies have their atm rates reduced by 60% at the lower tech levels. The rate of tech increase has improved so the higher tech levels are reduced by around 40%. The starting racial tech rate per module/installation is 0.0004 atm per year.

2)   Smaller planets are much faster to terraform. The terraforming rate in atm is modified by Earth Surface Area / Planet Surface Area. For example, the rate at which atm is added to Mars is 3.5x faster than on Earth (1.4x faster than in VB6 Aurora), Ganymede is 6x faster and Luna is almost 14x faster (5.4x than VB6)

3)   System Bodies with gravity of less than 0.1G cannot retain atmosphere and therefore cannot be terraformed

4)   Carbon Dioxide is now a dangerous gas.

5)   Water is now a significant factor in terraforming planets. Any planet with less than 20% water has a colony cost factor for water equal to (20 - Hydro Extent) / 10 (see colony cost rules).

6)   Water vapour can be added to the atmosphere just like any other gas.

7)   Water vapour will condense out of the atmosphere at a rate of 0.1 atm per year and increase the planet's Hydro Extent

8)   Each 1% of Hydro Extent requires 0.05 atm of water vapour. This means that creating 20% Hydro Extent would require 1 atm of water vapour (this will be much faster on smaller worlds because the speed at which water vapour atm is added is linked to surface area). With this in mind, existing water becomes an important factor in the speed at which terraforming can be accomplished, especially on larger worlds.

9)   Water will also evaporate into the atmosphere. The evaporation cycle follows condensation and will stabilise water vapour in the atmosphere of a planet with liquid water at a level of: Atmospheric Pressure * (Hydro Extent / 100) * 0.01 atm. The resulting atm * 20 is the % of the planet's surface that loses water. As the water vapour is removed from the atmosphere, it will replenish from the surface water. This is to allow the removal of water from ocean worlds to create more living space.

These new rules should add more variety to terraforming and, in conjunction with the max population rules, should add more interesting decision-making when choosing which worlds to terraform.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 14, 2017, 10:02:36 AM
Engine Size and Fuel Consumption

In C# Aurora, missile and ship engines follow a single fuel consumption rule. The modifier is equal to SQRT (10 / Engine Size in HS). Thanks to alex_brunius for the formula.

The new rule creates a smooth transition for both engine types, which is more realistic and consistent, provides a bonus to larger ships, makes the fuel portion of missile design more interesting (as fuel is not a major concern at the moment) and allows larger engines to be designed beyond the current 50 HS limit.

This will complement the new sensor changes as they will reduce missile ranges anyway (described in the changes discussion thread but not published here yet)

(http://www.pentarch.org/steve/Screenshots/FuelModelV2.PNG)

As a result of these changes, a new Maximum Engine Size tech progression has been added. The starting max engine size is 25 HS. The research progression is 40 HS, 60 HS, 100 HS, 160 HS, 250 HS and 400 HS, with the costs ranging from 2,000 RP to 60,000 RP.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 18, 2017, 08:27:25 AM
Plasma Carronades

1) The development cost of Plasma Carronade focal size has been halved. For example, a 30cm Carronade is now 4000 RP.
2) The building cost of Carronades has also been halved.

These two changes should make Carronades more viable. A powerful and inexpensive weapon but very short-ranged.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 18, 2017, 05:20:09 PM
Particle Lance

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

The Particle Lance is a large, potentially devastating weapon that is variant of the Particle Beam.

Once Particle Beam Range 200,000 km and Particle Beam Strength 6 have both been researched, the Particle Lance can be researched for 30,000 RP. The Lance is a modification of the normal Particle Beam and is an extra option in the design window.

The Particle Lance modification affects the Particle Beam in the following ways:

2x Damage
2x Size
2x HTK
2x Crew
2.5x Power Requirement
3x Cost
2x Development Cost

As well as the above modifications, which essentially creates a weapon twice as large, that recharges 2.5x more slowly and costs 3x as much, the damage template of the Particle Lance is a single column of armour, rather than the Particle Beam which has a template between that of missiles and lasers. The Particle Lance retains the constant damage of the Particle Beam, creating a weapon that can penetrate enemy armour at significant range.

Here are examples of similar tech level Particle Beam, Particle Lance and Laser.

*************************************************************************

Particle Beam
Beam Strength 6     Rate of Fire: 15 seconds     Maximum Range: 240,000 km
Particle Beam Size: 8 HS    Particle Beam HTK: 4
Power Requirement: 15    Power Recharge per 5 Secs: 5
Cost: 94    Crew: 24
Materials Required: 18.8x Duranium  18.8x Boronide  56.4x Corundium
Development Cost for Project: 2250RP

*************************************************************************

Particle Lance
Beam Strength 12     Rate of Fire: 38 seconds     Maximum Range: 240,000 km
Particle Beam Size: 16 HS    Particle Beam HTK: 8
Power Requirement: 38    Power Recharge per 5 Secs: 5
Cost: 282    Crew: 48
Lance Weapon
Materials Required: 56.4x Duranium  56.4x Boronide  169.2x Corundium
Development Cost for Project: 4500RP

*************************************************************************

25cm Far Ultraviolet Laser
Damage Output 16     Rate of Fire: 20 seconds     Range Modifier: 5
Max Range 800,000 km     Laser Size: 8 HS    Laser HTK: 4
Power Requirement: 16    Power Recharge per 5 Secs: 5
Cost: 100    Crew: 24
Materials Required: 20x Duranium  20x Boronide  60x Corundium
Development Cost for Project: 1000RP
(laser will have 320,000 km range with equivalent tech level fire control)

*************************************************************************

Comparison of Damage Templates at 240,000 km

Particle Beam (6): 2, 3, 1
Particle Lance (12): 12
Laser (3): 3

Two Particle Beams or 25cm Lasers can be installed in the same hull space as the Particle Lance. The Lasers are devastating at close range, the Particle Beams inflict more damage at long range (in terms of DPS), while the Particle Lance penetrates much more armour at long range.

The Particle Lance is intended as a powerful anti-ship weapon that requires a large investment in a particular tech line, lacks the flexibility of lasers or railguns and provides a different armour penetrating option to mesons, although mesons are still superior against shields. Mainly though it is to boost the Particle Beam as a serious weapon choice.

The Particle Lance is not tested under normal battle conditions yet so I may change it a little after play-testing.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 20, 2017, 07:14:40 AM
New Active Sensor Model

A new active sensor model has been implemented for C# Aurora. In VB6 Aurora, there is an issue that active sensor ranges become so huge with large size-50 sensors, that the standard tactic is to create a ship with such a sensor so that it can watch the entire inner system, taking away some of the fog of war. In addition, such extreme-range sensors allow ultra-long range missile combat, giving the race that possesses such sensors a major advantage. The following change is intended to create a situation where:

a) Multiple scouts or pickets become a serious alternative to one huge sensor.
b) Missile combat ranges are reduced
c) Fog of war is increased, leading to more interesting exploration and combat.

The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:

Sensor Range = Racial Sensor Strength * HS * Racial EM Sensitivity * SQRT(Resolution) * 10,000 km

The C# model uses similar basics and leaves all the existing technology in place. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors. In addition, the modifier for resolution has been adjusted from square root to the power of (1 / 1.5). Because of this formula, smaller, lower resolution sensors are now more effective than the VB6 equivalents (much more in some cases), making earlier detection of missiles and fighters possible for non-specialised ships. The new formula is:

Sensor Range = SQRT((Racial Sensor Strength * HS * Racial EM Sensitivity * (Resolution ^ (1/1.5)) / PI) * 1,000,000 km

The following screenshots are based on the Commonwealth in my current campaign, which has active sensor strength 21 and EM sensitivity 11.

(http://www.pentarch.org/steve/Screenshots/NewSensorModel200.PNG)

(http://www.pentarch.org/steve/Screenshots/NewSensorModel100.PNG)

(http://www.pentarch.org/steve/Screenshots/NewSensorModel20.PNG)

(http://www.pentarch.org/steve/Screenshots/NewSensorModel5.PNG)

(http://www.pentarch.org/steve/Screenshots/NewSensorModel1.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 20, 2017, 02:32:01 PM
Power Plant Changes

Power plants will no longer have linear power vs size. Additional power will be produced by larger reactors, using a similar formula to the increase in fuel efficiency for larger engines. This change will provide a reason to create larger power plants and will result in a small improvement in energy weapon capabilities. The table below shows power per HS and total power for a given size of reactor. This value is multiplied by the base technology of the power plant (Pressurised Water, Pebble Bed, etc).

(http://www.pentarch.org/steve/Screenshots/PowerPlant01.PNG)

The additional boost provided by the "Power Plant Boost" technology line provides double the previous bonus, with lower research costs and slightly higher explosion chances. This is intended for smaller ships that are short on space. The updated tech line provides between 10% and 100% additional boost with research costs between 500 RP and 30,000 RP.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 21, 2017, 03:53:43 AM
Engine HTK

Due to their size, Engines in VB6 Aurora create a damage shield because their HTK is very high compared to the amount of damage they are likely to receive. This would only become worse in C# Aurora with much larger engines now possible.

Therefore, the Engine HTK will change from 50% of Size to SQRT(Size).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 27, 2017, 05:10:20 AM
Shield Generators

Shield generators have been overhauled for C# Aurora to make them more interesting.

1) Shields no longer require fuel.
2) Shield generators can be created from 1 HS to 50 HS in size.
3) A new tech line has been added for maximum shield generator size. The starting tech is 10 HS and there are seven further steps from 12 to 50 with RP costs between 2000 RP and 120,000 RP.
3) The strength of the generator is modified by its size using the formula SQRT(HS/10). This means a 10 HS generator will have standard strength, a 1 HS generator will have 32% of normal strength and 50 HS generator will have 224% of normal strength
4) Recharge rates remain as before so a 10 HS shield will recharge at the same rate as an equivalent tech VB6 shield generator. Larger generators will recharge more slowly. For example, a 40 HS generator has 200% strength so will take twice as long to fully recharge.
5) HTK is the square root of the size, so it is easier to take out a single 50 HS generator than five 10 HS generators.
6) Cost of shields has been doubled
7) The only mineral involved in building shields is Corbomite.

In general, this means that shields become stronger than before and larger ships have an advantage when using shield generators. However, they also cost more, require more investment in research and are easier to destroy.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 28, 2017, 07:16:09 AM
Missile Engines

In C#, Missile Engines follow the same size-based fuel consumption rules as Ship Engines using the formula: SQRT (10 / Engine Size in HS)

The above increases the fuel consumption of missile engines based on size alone. However, VB6 also had a flat x5 multiplier for the overall fuel consumption for missile engines as they were treated as a different engine type than ship engines. As C# is aiming for consistency between ship and missile engines, this x5 multiplier cannot remain as it was before. Removing the x5 multiplier entirely would cancel out the fuel consumption increase resulting from the changes in the size-based fuel consumption calculation. As one of the objectives of C# is a reduction in missile ranges, a new rule is required that increases fuel consumption but that is still consistent with ship engines.

Therefore, the calculation for fuel consumption based on boosting engines will now include an additional multiplier if the boost being used is higher than the maximum racial boost tech. Only missile engines have the capability to use higher boosts than the racial maximum, so this still allows consistency between ship and missile engines in the spectrum where they both operate. Once you move outside of the boost range possible for ships, additional fuel consumption can be added without breaking consistency. This rule adds a linear multiplier from 1x to 5x depending on the level of boost beyond the racial maximum. The formula is as follows:

if Boost Used > Max Boost Multiplier Tech then
      High Boost Modifier = (((Boost Used - Max Boost Multiplier Tech ) / Max Boost Multiplier Tech) * 4) + 1;

So if a race has Max Boost Tech of 2x, any missile with a Boost Level of 2x or less will use the standard boost fuel modifier calculation of Boost Level ^ 2.5.

Above a Boost Level of 2x, the linear High Boost Modifier will come into effect, reaching a maximum of 5x fuel consumption at 4x Boost Level.

Here is a comparison between VB6 and C# using MPD engines and an engine size of 1 MSP. The Max Boost Tech for this race is 2x:


VB6 Missile Engine with 2x Boost
Engine Power: 1.6      Fuel Use Per Hour: 81.51 Litres
Fuel Consumption per Engine Power Hour: 50.944 Litres
Engine Size: 1 MSP      Cost: 0.4
Thermal Signature: 1.6
Materials Required: 0.4x Gallicite
Development Cost for Project: 80RP

C# Missile Engine with 2x Boost
Engine Power 1.60      Fuel Use Per Hour 76.8 Litres
Fuel Consumption per Engine Power Hour 48.0 Litres
Size 1.00 MSP  (2.5 tons)      Cost 0.80
Development Cost 80 RP

Materials Required
Gallicite  0.80


VB6 Missile Engine with 4x Boost
Engine Power: 3.2      Fuel Use Per Hour: 922.18 Litres
Fuel Consumption per Engine Power Hour: 288.182 Litres
Engine Size: 1 MSP      Cost: 0.8
Thermal Signature: 3.2
Materials Required: 0.8x Gallicite
Development Cost for Project: 160RP

C# Missile Engine with 4x Boost
Engine Power 3.20      Fuel Use Per Hour 4344.5 Litres
Fuel Consumption per Engine Power Hour 1357.6 Litres
Size 1.00 MSP  (2.5 tons)      Cost 1.60
Development Cost 160 RP

Materials Required
Gallicite  1.60
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 29, 2017, 07:00:09 AM
Missile Launcher Changes

Missile Launchers have undergone significant changes in C# Aurora.

1) Fractional-size launchers can be created. The minimum is still 1 HS but a launcher can now be 1.1 HS, 2.7 HS, etc.

2) The reduced-size launcher techs are all available immediately and do not need to be researched. This means box launchers are available from the start. The progression for reduced size launchers has been altered slightly:
0.75 HS  2x Reload
0.6 HS  5x Reload
0.4 HS  20x Reload
0.3 HS  100x Reload
0.15 HS  100x Reload (Box Launcher) - note that reload for this was x15 in VB6.

If a box launcher containing a missile is damaged, the missile will explode. The chance of this happening can be reduced by a new tech line. The first step reduces the explosion chance to 70% for 1000 RP and the last step reduces to 5% for 120,000 RP. In addition, Box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).

The base reload rate for all missile launchers is now: (SQRT(missile size) * 30 seconds * Reduced Size Modifier)  / Reload Rate Tech.

Assuming a race has reload rate tech of 3, a normal size 1 launcher will reload in 10 seconds, a size 4 will reload in 20 seconds and a size 9 will reload in 30 seconds. This change will dramatically reduce reload times for larger launchers.

The change for box launcher reload rate from x15 to x100 is not as dramatic as it seems for larger missiles due to the new reduced reload times for larger missiles. However, it is still an significant increase from VB6. A size 4 missile mounted on a box launcher will now take about 1h 40m to reload in a hangar and about 17 hours for an ordnance transfer point. A size 6 is about 2 hours and 20 hours respectively.

These changes are intended to:
1) Reduce the disadvantage of larger missiles,
2) Remove the realism issue of not having box launchers available at low tech yet make box launchers a more difficult decision vs standard-type launchers.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 10, 2017, 12:34:07 PM
New Passive Sensor Model

A new passive sensor model has been implemented for C# Aurora, using similar principles to the new active sensor model. In VB6 Aurora, small ship-based passive sensors are not particularly effective compared to active sensors in terms of detection, although their passive nature does allow a ship some sensor capability without giving away its position. Planet-based passive sensors (deep space tracking stations) are very effective as they can be stacked to cover the whole star system,

The C# Aurora passive sensor model substantially improves small passive sensors, particularly against small signatures, while dramatically reducing the benefits of creating large numbers of deep space tracking stations.

The VB6 sensor model is based on the following formula, which increases range in direct relation to sensor strength:
Detection Range = Passive Sensor Strength * Target Signature * 1000 km.  For example, a strength-10 thermal sensor would detect a signature-500 target at 5m km (10 * 500 * 1000).

The C# model uses all the existing technology and tech values. However, the sensor strength now has to cover an area rather than a direct range, creating diminishing returns for larger sensors.
Detection Range = SQRT(Passive Sensor Strength * Target Signature ) * 250,000 km. The same example as above would result in the strength-10 thermal sensor detecting the signature-500 target at 17.7m km.

Because of the great improvement in the performance of small passive sensors, there will no longer be an inherent size-1 passive sensor on all ships. In addition, the smallest functional passive sensor on a missile will be 0.25 MSP.

The screenshot below demonstrates the difference between the two models.

(http://www.pentarch.org/steve/Screenshots/PassiveSensorsV2.PNG)

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 11, 2017, 09:12:19 AM
Missile Updates

The following changes will be made to missiles in C# Aurora:

1) Missile Armour has been removed.

2) Laser warheads have been removed (I may add these back at some point in the future).

3) ECM is now a fixed 0.25 MSP for missiles. The 'Missile ECM' tech line has been removed and if a missile is equipped with ECM it will have the same ECM capability as the current racial ECM technology, The missile design will maintain that ECM capability and will not be upgraded if the racial tech improves. For each level of ECM, the missile will be 10% harder to hit with energy weapons and will reduce the lock of missile fire controls by 10%. This can be negated by linking a similar level of ECCM to the point defence fire controls.

4) Missiles can be equipped with ECCM, which is a fixed 0.25 MSP. The missile ECCM level will be equal to the current racial ECCM tech. In C# Aurora, the ECCM of missile fire controls will only affect the range at which the fire control can lock on. The ECCM of the missile itself will affect the chance of the missile striking its target, if that target has active ECM.

5) Any missile sensor (active, thermal, EM or Geo) has to be a minimum of 0.25 MSP or it will have no effect.

6) Missile series have been removed. Instead, there will be more detailed class loadout options.

These changes will make electronic warfare much more important for missile combat. Missiles with ECM will become harder to shoot down and missiles without ECCM will have a reduced chance to hit targets equipped with ECM. Anti-missile missiles will either be less effective, or larger, vs ECM-protected missiles, while anti-ship missiles are likely to increase in size (and therefore reduce salvo sizes). Large volleys of size-1 missiles will be less effective in a heavy EW environment and no longer have a huge advantage in launching speed (due to the missile launcher changes).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 27, 2017, 02:01:50 PM
Turret Update

A minor update. The benefits of multiple energy weapons in turrets have been doubled. A twin turret now has a 20% reduction in crew vs two solo weapons and has a 10% reduction in gear size. A quad turret has a 40% reduction in crew vs four solo weapons and has a 20% reduction in gear size.

In addition, I found an error in the VB6 code for turret design that meant a turret needed four times more armour than a ship of equivalent size. This has been corrected for C# Aurora, which means armoured turrets are now much more viable.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 09, 2017, 06:08:02 AM
Missile Thermal Detection

In VB6 Aurora, the thermal detection of missiles is based on the following formula:

(Missile Size / 20) * (Speed / 1000)

I have no idea why I coded thermal detection for missiles to be based on size, although I am sure it seemed like a good idea at the time :). For C# Aurora, missiles will use the same formula as ships for thermal signature:

Max Engine Output * (Current Speed / Max Speed) * Thermal Reduction

As missiles (for now anyway), don't have thermal reduction or an option to travel below maximum speed, their thermal signature is equal to the power of their engines. Combined with the changes to passive detection, this means that missiles in C# Aurora will probably be detected by thermal sensors at much greater distances than in VB6 Aurora.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 18, 2017, 05:05:43 PM
Commercial Hangars

Commercial hangars are available in C# Aurora. They are 50% larger than military hangar bays (size 32), have the same cost of 100 BP and the same crew requirement (15).

They are intended for transport of other commercial vessels, temporary transport of military vessels, reloading of box launchers and for repairing ships. With this in mind, a military ship still has normal maintenance requirements while in a civilian hangar.

However, as you can maintain ships in deep space in C# Aurora it will be possible to build a large ship that could provide both commercial hangar space and maintenance, or combine ships with commercial hangars and ships with maintenance modules to provide a logistics hub.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 18, 2017, 05:43:23 PM
Beam Weapon Recharge

In VB6, if a power plant is damaged, it slows down the recharge rate of all weapons by a proportionate amount.

In C# Aurora, power is allocated weapon by weapon until the available power is exhausted. This means that some weapons may not be recharged, but the others will be recharged at the maximum rate. Weapons are charged in order of ascending power requirement. Once a weapon is recharged, it will require no more power and other weapons can begin the recharge process.

This should allocate power in the most effective way to keep a ship in the fight.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 19, 2017, 04:02:13 AM
Commercial Magazines

I've added a non-military magazine to C# Aurora. There are two versions; one with 100 capacity and one with 500 capacity.

In general terms they are cheaper but less efficient in terms of space then military magazines. Also, they have a 100% explosion chance if hit, so don't apply for a job on a commercial ammunition transport :)

Commercial Magazine - Capacity 100, Size 12, Cost 25, Crew 5, HTK 1, RP 2000
Commercial Magazine - Capacity 500, Size 50, Cost 100, Crew 20, HTK 1, RP 5000

Even if you armour the ship, one of the magazines could still explode due to shock damage. As the magazines are fairly large, if they are hit then the ship is probably gone, so it would be a Bad Idea to take a commercial ammunition transport along with the battle fleet.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 06, 2017, 12:11:59 PM
Crew Grade

In VB6 Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to the commander's crew training rating. The maximum number of points is 2000.

In C# Aurora, each ship crew receives grade points during each construction phase. The number of grade points received per year is equal to 50% of the commander's crew training rating, plus 100% of the executive officer's crew training rating. This training will only happen if the ship has at least one command & control system undamaged. The maximum number of points is 1000.

A ship's crew grade bonus is equal to SQRT(Grade Points) - 10. So for VB6 Aurora the maximum is 34% and for C# Aurora it is 21%.

The net effect is that the grade bonus will be received more quickly but has a lower maximum value. The gap will be made up by the bonuses of other officers, such as the Tactical Officer or Chief Engineer.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 09, 2017, 06:15:52 PM
Admin Commands

An earlier post in this thread briefly touched on Admin Commands. http://aurora2.pentarch.org/index.php?topic=8495.msg97344#msg97344

This post provides more details. Every race starts with a single top level Admin Command (which can't be deleted but can be renamed). All other Admin Commands descend in a tree from this one. You can only attach an Admin Command to another Admin Command but you can have an unlimited number of levels in the Admin Command hierarchy. Fleets can only be attached to Admin Commands. Many fleets can be attached to the same Admin Command but each fleet can only be attached to one Admin Command.

An Admin Command can be created at a population with a Naval Headquarters (a new installation). Each level of a Naval Headquarters costs 1200 BP and can be moved with the same cargo requirement as a research facility. Naval Headquarters function in a similar way to Sector Commands, with each doubling of the level adding +1 to the command radius. For example, level 1 has a Radius of 1, level 2 has a radius of 2, level 4 has a radius of 3, level 8 has a radius of 4, etc.. The command radius of the Admin Command is based on the Naval Headquarters in which it is based (with modifications for certain types of Admin Command). A single Naval Headquarters can support multiple Admin Commands.

If a fleet is within the command radius of its parent Admin Command, each ship within the fleet gains benefits based on the type of command and the bonus of the commander assigned to the Admin Command. There are seven different types of Admin Command, with the following capabilities.

Naval: Provides 25% of the Admin Command commander bonus for Crew Training, Reaction, Engineering and Tactical. (For example, if the commander has a 20% Reaction Bonus, a 5% bonus would be provided).

Patrol: Provides 25% of the Admin Command commander bonus for Reaction and Engineering. This command type operates at twice the command radius of the parent naval headquarters.

Survey: Provides 25% of the Admin Command commander bonus for Survey and Engineering. This command type operates at twice the command radius of the parent naval headquarters.

Logistics: Provides 25% of the Admin Command commander bonus for Logistics (cargo load/unload speed) and 10% of the bonus for Mining (including Harvesting) and Terraforming.

Industrial: Provides 25% of the Admin Command commander bonus for Mining and Terraforming, plus 10% of the bonus for Logistics.

General: Provides 10% of the Admin Command commander bonus for Crew Training, Fleet Training, Reaction, Engineering, Tactical and Survey, plus 5% for Industrial and Logistics.

Training: Functions differently to the others. Fleet Training can only take place within the command radius of a Training Admin Command (see later rules post for details). The crew training rating of the Admin Command commander is used as the basis for the speed of training.

Each Admin Command also gains additional bonuses if it is within the command radius of its own parent command. For example, if a survey fleet is within the command radius of a Survey Admin Command it will provide 25% of the bonus of the commander of that Survey Admin Command. If that Survey Admin Command is within the command radius of a parent Survey Admin Command, that bonus would be multiplied by 25% of the parent admin command commander bonus. So if both Admin Commands each had a commander with a 30% survey bonus, the total provided bonus to ships in the command radius of the lower Admin Command would be 15.56% (1.075 * 1.075). If a third layer existed above those two and that also had a commander with a 30% bonus, the overall bonus would rise to 24.23%.

This isn't as easy to achieve as it might seem as each of these Admin Commands will need an assigned commander or the chain will be broken. Also each superior Admin Command requires a commander of higher rank than the inferior Admin Command and any Admin Command with fleets directly attached requires a higher rank than the highest-ranked ship captain in those fleets. If an Admin Command does not have a commander of sufficient rank, it will not provide bonuses. Therefore, large hierarchies are difficult to achieve. However, this does give meaningful commands for those higher ranked commanders that currently are used as the captains of major warships. It also means that if you establish the necessary command infrastructure required to support your fleets across your territory, it can have substantial benefits.

The required rank for each admin command is updated when the commander or naval organisation windows are loaded and during each construction phase. The check for the required level of commander is performed during each construction phase. If this check fails, the player will be notified and the admin command will be ineffective until the next construction phase.

Each increment, the command radius of all admin commands is checked so that all activity within that increment will use up-to-date information. This is dynamic during the turn, so the position of a ship or fleet at the moment it checks a bonus is used to determine the effect of the command network. The command hierarchy is checked each increment and whenever you modify that hierarchy so that you will always have up to date information on what rank is required for each Admin Command.

This command network is created using the new Admin Command tab on the Naval Organization window (see below). The Admin Commands are in green on the main structure chart. Each one is prefixed by the type abbreviation and suffixed by the required rank and current location. Selecting an Admin Command shows the systems within range and any Naval Headquarters in those systems. There is also a list of all Naval Headquarters within your Empire and a breakdown of the different Admin Command types. New commands can be created by selecting a parent Admin Command, a host population and an Admin Command Type. Fleets can be dragged and dropped between Admin Commands as desired. I will also add a movement order specifying a change in Admin Command.

None of this functionality has to be used as all new fleets will be assigned to the single, starting Admin Command. However, for those players who wish to set up their own command structures, I hope this will add an interesting extra dimension to the game. As with all these changes, I may modify things a little as a result of play testing but the essential principles should remain the same.

(http://www.pentarch.org/steve/Screenshots/AdminCommand01.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 26, 2017, 08:16:13 AM
Recovering Technology and Ship Components from Ruins

In order to prevent unbalancing tech advancements occurring while excavating very large ruins, the maximum tech advancement you can achieve from recovering abandoned installations will be based on the tech level of the ruin race. The max development cost of any associated tech will be:

(2 ^ (Ruin Race Level + 1)) * 1000;

This means a level 1 ruin race will have tech up to 4000 RP, a level 2 race up to 8000 RP, etc. with the maximum being a level 5 race with tech up to 64,000 RP.

When standard components are selected for recovery (such as gravitational survey sensors), they will be the best available component within the above limit. If no component of the specified type is available within the limit (for example when the random selection is a 5000 RP Asteroid Mining Module for a level 1 race), nothing will be recovered.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 01, 2017, 06:50:00 AM
Commander Careers

In C# Aurora, the rules for accidental death and commander health remain as they are in VB6 Aurora.

Retirements are handled differently. An naval officer will be checked for the potential for retirement from service once the length of his career exceeds the minimum retirement time for his rank. The minimum retirement point is 10 years for the lowest rank. For other ranks it is equal to 10, plus 5 years for every level of rank above the minimum. So assuming lieutenant commander was the lowest rank, minimum retirement would be 10 years after career start for a lieutenant commander, 15 years for a commander, 20 years for a captain, etc..

For ground forces commanders the minimum retirement is 20 years for the minimum rank. For other ranks it is equal to 20, plus 5 years for every level of rank above the minimum.

For scientists and administrators the minimum retirement is 40 years.

The chance of the retirement occurring is 20% for each year beyond the minimum retirement date. This is doubled if the commander has no assignment. Each increment the chance is checked using: (Increment Length / One Year) * Retirement Chance.

The VB6 concept of 'tour length' does not exist in C# Aurora, so there will no longer be mass-reassignments every couple of years. In addition, the removal of officers after six years with no command will no longer happen. Instead, C# should have a more realistic progression because of the different mechanics. Firstly, inactive or low ranked commanders will tend to retire relatively early, which will keep overall officer numbers down and open up their commands (if one exists) for new assignments. Secondly, ships can potentially have multiple officers, which creates many more assignments. Thirdly, each ship (or other officer position) can only be assigned to an officer of a specific rank. As soon as that officer is promoted, he has to leave that position, which opens it up for another officer. Finally, naval officers in non-command positions (XO, Tactical Officer, CAG, Chief Engineer, Science Officer), will be automatically assigned to any ship command position that becomes available, assuming they have suitable bonuses, opening up their previous role.

Ship commander ranks are based on the following rules:

1) Assume lowest rank if none of the following conditions exist. Otherwise use the highest applicable rank for any condition.
2) Lowest rank + 1 for any ship class equipped with any of the following: Geological or Gravitational Sensors, Auxiliary Control, Science Department, Jump Drive
3) Lowest rank + 2 for any ship equipped with any of the following: Weapons, Military Hangar Bay, Main Engineering, CIC, Flag Bridge
4) Regardless of the above, any ship of 1000 tons or less will be the lowest rank, unless it has one of the control stations (Auxiliary Control, Science Department, Main Engineering, CIC)

Additional officers on the same ship have the following rank requirements:
1) One rank lower than required ship commander rank: Executive Officer, Science Officer, Commander Air Group
2) Two ranks lower than required ship commander rank: Chief Engineer, Tactical Officer

For example, the executive officer on a warship would be lowest rank + 1 (one lower than commander requirement) while the executive officer on an unarmed geological survey ship would be the lowest rank.

Overall, the variety of positions available at different ranks, combined with the positions opening up due to retirements, promotions and assignment of junior officers to ship command, should provide a more interesting career progression.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 02, 2017, 06:08:45 AM
Auto-Assignment of Naval Commanders

Auto-Assignment of naval commanders is similar to VB6, although the process is now more detailed.

Every class of ship has a Commander Priority, a Primary Assignment Priority and a Secondary Assignment Priority. The Commander Priority is set by the player, while the others are set by Aurora. Each class also has a Primary Bonus Type. When the list of ships without commanders is created every construction phase (during the auto-assignment phase) it is ordered by Commander Priority then by Primary Assignment Priority and then by Secondary Assignment Priority.

The ships are cycled through in that order, searching the available commanders (which is any unassigned commander or any commander assigned to a non-command position on a ship) for a suitable match for each ship. A suitable commander must have the primary bonus for the ship or they will not be assigned. In C# Aurora, unassigned commanders still have a small chance of gaining experience, including new bonuses, so they may be assigned in the future even if they currently do not have a suitable bonus.

Primary and Secondary Assignment Priorities and the Primary Bonus are set based on the following rules. Secondary Assignment Priorities are based on descending order for the ship class and the Primary Bonus is based on descending order for the commander.

Geo Survey or Grav Survey
Primary: 1
Secondary: Size
Bonus: Survey

Protection Values > 0
Primary: 2
Secondary: Protection Value
Bonus: Crew Training

Military Vessel
Primary: 3
Secondary: Size
Bonus: Crew Training

Construction Ship
Primary: 4
Secondary: Class Cost
Bonus: Production

Terraformer
Primary: 5
Secondary: Number of Terraforming Modules
Bonus: Terraforming

Harvester
Primary: 6
Secondary: Number of Harvesting Modules
Bonus: Mining

Asteroid Miner
Primary: 7
Secondary: Number of Mining Modules
Bonus: Mining

Salvager
Primary: 8
Secondary: Number of Salvage Modules
Bonus: Production

All Others
Primary: 9
Secondary: Size
Bonus: Logistics

Bear in mind that all of the above is secondary to the priority given to each class by the player, so if you want a particular type of ship to get the best commanders assigned, give it a high priority.

After ship commanders are assigned, the non-command positions are assigned. Ships must have the appropriate command module for each non-command position in order for a commander to be assigned and the commander must have the required bonus. For each of the non-command positions (in the order below), the ships with an available position are ordered using the same rules as above, including the player priority. The positions and requirements are as follows:

Executive Officer
Command Module: Auxiliary Control
Bonus: Crew Training

Science Officer
Command Module: Science Department
Bonus: Survey

Commander, Air Group
Command Module: Primary Flight Control
Bonus: Fighter Operations

Chief Engineer
Command Module: Main Engineering
Bonus: Engineering

Tactical Officer
Command Module: CIC
Bonus: Tactical
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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
Overcrowding
Life Support Failure

If a ship has no life support systems (due to combat damage or maintenance failures), it suffers the following penalties:

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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.

(http://www.pentarch.org/steve/Screenshots/DominantTerrain.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.

(http://www.pentarch.org/steve/Screenshots/GroundRules007.PNG)

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.

(http://www.pentarch.org/steve/Screenshots/Ground010.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.

(http://www.pentarch.org/steve/Screenshots/GroundRules004.PNG)

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.

(http://www.pentarch.org/steve/Screenshots/GroundRules005.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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 recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
6) LY entry to limit Starting NPR Locations to within a specific range of Sol: http://aurora2.pentarch.org/index.php?topic=8495.msg108824#msg108824
7) 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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 with less than 25m pop and 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.
3) Searches for any suitable population with a status of Colonist Destination (which you can set for any pop of at least 25m).

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).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 21, 2018, 08:23:46 AM
Shipping Line Construction

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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 22, 2018, 09:50:05 AM
Chance of Ruins

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

I've added the chance of alien ruins to the game window, so it can be adjusted.

It is normally 20% for any terrestrial world, terrestrial moon or small terrestrial moon with gravity > 0.4G and temperature between 200K and 360K (about -73C to +87C).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 22, 2018, 10:13:26 AM
Structural Shells

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

A 'No Armour' check box has been added to the class window. Clicking this removes the normal armour from the class.

Designs with no armour instead have a new type of armour called 'structural shell'. This costs 1 per unit and has a strength of 20, essentially making it 5% of the cost of normal armour in terms of strength.

There are severe limitation on ships with no armour:
1) They cannot have engines
2) They cannot have military systems
3) The structural shell does not prevent damage. In effect, weapon fire passes straight through the 'armour'

This type of ship is ideally suited for orbital habitats or space stations of some type, such as fuel harvesting platforms, mining stations, etc., that require towing to move.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 22, 2018, 10:22:38 AM
Maintenance Storage Bays

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

In C# Aurora, Maintenance Storage Bays are no longer a military system.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 22, 2018, 10:36:13 AM
Orbital Habitats

This is a copy of a post in the VB6 7.2 Changes List. I didn't release the updated VB6 version so this is still a change from the released VB6 Aurora.

The population capacity of orbital habitat modules has been increased from 50k to 200k. In combination with the new 'No Armour' option this significantly reduces the cost of building orbital habitats. For example, the habitat shown here supports a population of one million for a cost of 1145 BP. To support one million colonists with infrastructure on a colony cost 2.0 world with acceptable gravity would cost 400 BP, so the colony cost would have to be approaching 6.0 before the Orbital Habitat became cheaper. For low-gravity worlds it is comparable with the cost of low-gravity infrastructure and it is the only option for high gravity worlds or small bodies with low population capacities.

Sidon class Orbital Habitat      1,252,970 tons       162 Crew       1144.7 BP       TCS 25059    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 132      Sensors 1/1/0/0      DCR 1      PPV 0
MSP 0    Max Repair 200 MSP
Habitation Capacity 1,000,000   
Lieutenant Commander    Control Rating 1   BRG 
Intended Deployment Time: 3 months   

Commercial Active Sensor (1)     GPS 1920     Range 27.3m km    Resolution 120

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as an Space Station for construction purposes
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 22, 2018, 06:23:45 PM
Space Stations

The rules on construction factories building spacecraft are changing in C# Aurora. Any class with a Structural Shell instead of armour is classed as a Space Station. Space Stations can be built by construction factories at any population that includes a Spaceport. Note this means you no longer need an orbital habitat in order to use construction factories, which means you can create huge deep space logistical bases, terraforming stations or small observation platforms, or anything in between, using construction factories.

The downside to this flexibility is no armour, no engines and no military systems, so space stations will require protection from defensive bases (which can be maintained by the space station if it has sufficient maintenance facilities). As an example, if you were channelling Starship Troopers (movie, not book) you could build the following station and deploy in deep space, near the Arachnid Quarantine Zone:

Ticonderoga class Fleet Base      823,223 tons       5,867 Crew       30,310.1 BP       TCS 16,464    TH 0    EM 0
1 km/s      No Armour       Shields 0-0     HTK 708      Sensors 1/11/0/0      DCR 1      PPV 0
MSP 20,023    Max Repair 2400 MSP
Hangar Deck Capacity 20,000 tons     Magazine 10,000   
Commander    Control Rating 2   BRG  AUX   
Intended Deployment Time: 3 months    Flight Crew Berths 400   
Recreational Facilities
Maintenance Modules: 80 module(s) capable of supporting ships of 128,000 tons
Refuelling Hub - Capable of refuelling multiple ships simultaneously
Ordnance Transfer Hub - Capable of transferring ordnance to multiple ships simultaneously

Fuel Capacity 20,000,000 Litres    Range N/A

CIWS-200 (12x6)    Range 1000 km     TS: 20,000 km/s     ROF 5       Base 50% to hit
Perseus Anti-ship Missile (1200)    Speed: 32,000 km/s    End: 65m     Range: 125.3m km    WH: 6    Size: 4    TH: 106/64/32
Huron Anti-missile Missile (5200)    Speed: 31,700 km/s    End: 1m     Range: 3.5m km    WH: 1    Size: 1    TH: 137/82/41

Commercial Active Sensor (1)     GPS 2520     Range 42.3m km    Resolution 120
Commercial EM Sensor (1)     Sensitivity 11     Detect Sig Strength 1000:  26.2m km

This design is classed as a Commercial Vessel for maintenance purposes
This design is classed as a Space Station for construction purposes
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 24, 2018, 01:36:47 PM
Standing Orders

Standing Orders are the C# equivalent of Default Orders in VB6 and function in exactly the same way. If your ship has no active movement orders, it will act on the Primary Standing Order. If that is not possible, it will act on the Secondary Standing Order.

Standing orders will only be checked if the increment length is greater than one hour. In addition, acting on the Standing Orders for "Move to Gas Giant with Sorium" and "Move to Asteroid Mineral Source" will unset the standing order (to prevent continuous issuing of the same order). Civilians and NPRs will monitor ships in this situation and reactivate the standing order if required.

Conditional Orders are Standing Orders linked to a Condition. When the condition is met, the associated conditional order will be executed where possible. Secondary conditional orders will not be executed if the fleet is already acting on the primary conditional order.

Each potential order is accompanied by an S or an A. This indicates whether the order will look at potential destinations in the same system (S) or all systems (A). When the order involves moving to a different system, the algorithm calculating the best path will take into account whether the fleet will try to Avoid Danger and try to Avoid Alien Systems. These two values are set by the Check Danger Rating and Exclude Alien-Controlled check boxes respectively, which are located on the Movement Orders tab (see Auto Route rules post for more details).

There will be some new standing orders for C#, which I will list here as I add them:

(http://www.pentarch.org/steve/Screenshots/StandingOrders02.PNG)

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 25, 2018, 09:33:29 AM
Waypoints

Waypoints will be much more useful in C# Aurora. It will be possible to add the following five types to the system map:
Clicking on a system body icon when placing a waypoint of any kind will link the waypoint to the system body and it will move with that system body.

Example screenshots below:

(http://www.pentarch.org/steve/Screenshots/Waypoints001.PNG)

(http://www.pentarch.org/steve/Screenshots/Waypoints002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 26, 2018, 02:51:12 PM
Fleet Movement Auto Route

The Fleet Movement Orders section of the Naval Organization window has an option called Auto Route by System. When this option is selected, the normal movement destinations list will be replaced by a list of systems that the Fleet is capable of reaching. Clicking on a system and clicking Add Move will generate all the movement orders from the current system to the destination system. The System Locations option will be automatically selected and the destination list for the new system will be displayed, so the player can complete any specific orders. 

The determination of which systems can be reached is based on three check boxes to the right hand side of the same tab.
Fleets have two stored values, Avoid Danger and Avoid Alien Systems. These are set on by clicking the second and third check boxes above and will affect the algorithm used for Standing and Conditional Orders for that fleet in addition to the Auto Route.

The list of systems will highlight any populated systems in light green and any other colony systems in dark green. The total population will be shown (if greater than zero) or the number of the most important installation type. In order of priority these are automated mines (including asteroid miners), then terraformers (including orbital), then tracking stations. This is similar to the population tree view on the Economics window functions.

These four screenshots below show an example journey. In the first, a US fleet in the Eta Cassiopeiae system (highlighted at the bottom) wants to return to Sol. In the second, the potential system list is displayed. As the Exclude Alien-Controlled option is checked, the fleet cannot travel through the Commonwealth systems starting with EV Lacertae so none of those systems are an option. The third screenshot shows the results as the path finding algorithm takes the fleet on a longer route via Oregon then displays the destination list for Sol. The fourth screenshot shows the journey of a French survey ship. In this case, the algorithm has determined that using Lagrange points in two of the systems will make the journey shorter.

(http://www.pentarch.org/steve/Screenshots/AutoRoute01.PNG)

(http://www.pentarch.org/steve/Screenshots/AutoRoute07.PNG)

(http://www.pentarch.org/steve/Screenshots/AutoRoute03.PNG)

(http://www.pentarch.org/steve/Screenshots/AutoRoute04.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 01, 2018, 03:27:36 PM
Civilian Trade

For C# Aurora, I've updated civilian trade to use a better algorithm.

In VB6, civilian freighters without orders will move to a 'Trade Location', which is defined as a population with a balance in one or more trade goods that is greater than the capacity of the freighter. On arrival, the freighter will check the trade balances and try to find a suitable destination for one of them. If a destination is found, the move will be plotted. If not, the freighter will search for a new trade location. It could be more intelligent but not without a larger performance overhead.

In C# Aurora, a freighter without orders, regardless of current location, will search known space for the closest population that has export trade goods, taking into account any other freighters already en route to collect that trade good (and any path finding restrictions such as danger). If a suitable trade good is located, the freighter will look for the population closest to the pick up point which has an import requirement for that trade good (again taking into account any freighter already en route to drop off the same good at that destination). If no destination is found, the freighter checks the pick up point for any other trade good options with suitable destinations. If that doesn't work, the freighter checks the next population based on distance, etc., until it has checked every possible combination of populations and trade good routes in known space. If a valid route is found, all the orders are plotted including any Lagrange short-cuts. Then the next freighter repeats the process, etc..

Infrastructure is checked first at each population before any other trade good. Freighters understand the difference between low gravity infrastructure and normal infrastructure and will move the correct type of infrastructure to appropriate destinations.

Given that every civilian freighter without orders is checking every system, population and trade good in known space to find a suitable trade route, there might be a concern regarding performance. My current campaign is an ideal test bed, as I have removed every order from every fleet due to the incompatibility of the VB6 and C# database structures. Which means in the first trade phase after program start, the code is checking all 364 civilian freighters in a universe with 495 star systems, 1343 jump points, 380 Lagrange points, 345 populations and 23 different races. That first trade phase, including identifying routes for all freighters and creating 1896 individual movement orders (including load/unload, transits and LG points) required 1.01 seconds.

Colony fleets follow similarly complex rules, explained in the link below. Routing 198 civilian colony fleets using these rules, along with every other ship with Standing Orders, added a further 619 movement orders and required 0.56 seconds.

http://aurora2.pentarch.org/index.php?topic=8495.msg106715#msg106715

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 03, 2018, 01:54:02 PM
Civilian Movement of Installations

As in VB6, Civilians will still transport installations for player races. However, there are changes to the UI, the path finding and the costs for the this service.

In terms of cost, in VB6 the cost was a set fee of 10 wealth for multi-system transportation and 5 wealth for same system, regardless of freighter size. In C# Aurora, the cost is:
5 x Number of Installations x Systems Travelled x (Installation Type Cargo Points / 25000)

So for a standard freighter (single cargo hold) transporting a construction factory to a destination four systems away, the cost would be 20 wealth. The calculation is 5 x 1 x 4 x (25,000 / 25,000). Destinations in the same system as the start point count as half a system.

For path finding, civilian ships will use the same logic as transporting trade goods (see link below). They will search for player contracts before searching for trade goods. Note this means you can effectively commandeer civilian shipping for your own needs in an emergency, but doing so will disrupt normal civilian operations such as moving infrastructure.

http://aurora2.pentarch.org/index.php?topic=8495.msg106954#msg106954

There is a Civilian Economy tab on the Economics window, which has three lists. To the left is a list of installations at the colony, the centre has a list of installations demanded and the right has a list of installations supplied. Above the centre list is a dropdown with all types of known installations. Above the right-hand list are the installations that the colony can supply. For both the latter lists, there is an Amount column, which is the amount Demanded or Supplied, and an Assigned Column, which is the number of the installations for which a freighter contract is already assigned (this is a sub-set of the Amount). The lists can be managed with the buttons below. Adding or editing will trigger a popup box so you can type in the amount required.

The screenshots below show:

(http://www.pentarch.org/steve/Screenshots/Contracts001.PNG)

(http://www.pentarch.org/steve/Screenshots/Contracts003.PNG)

(http://www.pentarch.org/steve/Screenshots/Contracts002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 03, 2018, 02:05:35 PM
Spacemaster Changes to Installations

When in Spacemaster Mode, the Civilian Economy tab gains an extra dropdown and three extra buttons. These allow the Spacemaster to change the number of installations at a colony, or add new types. This replaces part of the functionality from the VB6 SM Modification window.

(http://www.pentarch.org/steve/Screenshots/SMPopMod.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 03, 2018, 04:14:49 PM
Maintenance Locations View

There is a new display option on the galactic map to highlight Maintenance Locations. They are displayed as a dashed blue circle.

(http://www.pentarch.org/steve/Screenshots/MaintenanceLocations.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 03, 2018, 04:19:05 PM
Automatic Pop Selection from Galactic Map

A minor but useful change. If you select a system on the galactic map and then click one of the buttons for the Economics window (Summary, Industry, Research, etc.), the Economics window will open with the most important population in that system (if one exists) already selected. Important in this context uses the same rules as the orders of populations in each system on the Economics tree view.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 11, 2018, 08:17:23 AM
Armour Damage Templates

In VB6 Aurora, the damage templates for each weapon are held in a database table, with one row for each combination of weapon type and damage amount. While this is simple, it mean any new weapon or change to damage model has to be laboriously updated in the table.

For C#, the damage templates are generated in code as needed based on a 'gradient' system. All the damage starts at a single point and is distributed right and left according to the gradient setting. Any column which has damage greater than the gradient, checks left and right. If an adjacent column has a damage amount that is lower than the current column damage minus the gradient, a single point of damage is moved to that column. The adjacent column with lower damage is used first. The code cycles back and forth through the columns until no more adjustments are necessary

For example, missile damage has a 'gradient' of 1. Therefore, there cannot be a gap of 2 damage between adjacent columns. Laser damage has a gradient of 3, so any gap of 4 damage between columns is corrected. Here are some examples for 25 damage:

Gradient 1 (Missile, Carronade, Ramming):  1,2,3,4,5,4,3,2,1
Gradient 2 (Railgun, Particle Torpedo):  1,3,5,7,5,3,1
Gradient 3 (Laser):  3,6,8,5,3

Particle Lances cause damage in a single column, gauss cause only a single point of damage and meson ignore armour.

The template generation takes about a millisecond so there is no performance issue. This means that new weapons with higher gradients can be added very easily.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 13, 2018, 02:39:46 PM
Ship Class Components View

The components view has been expanded considerably for C# Aurora.

The tab still has the functionality from VB6, showing the component breakdown by Amount, Size, Cost, Crew and HTK. To that has been added ordnance loadout, fuel and maintenance supplies, plus a breakdown of minerals and wealth. The mineral and wealth breakdown takes into account the mineral requirement and/or cost for the full loadout of fuel, maintenance and ordnance, so you can see the full cost of the design

Two new columns have been added which replace the damage allocation chart from VB6. Instead, this is the percentage chance that a component of the specified type will be selected for internal damage. E-DAC is for weapons that only target electronics.

(http://www.pentarch.org/steve/Screenshots/ComponentView002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 14, 2018, 08:22:52 AM
Combat Reports

In VB6, understanding the combat events can be difficult given the sheer amount of information. Therefore, C# Aurora uses a condensed system where you no longer see each individual weapon firing, or the damage from individual hits. Instead weapon fire and any resulting damage are shown in a summary format. The side being attacked will also receive some information about the firing ship, using the Alien Ship Name if available.

Here is the summary when a Japanese destroyer opens fire on a Martian Patrol Ship. The different in hull designation in the two reports is because Mars classes the Monoceros as a patrol ship, while Japanese Intelligence classes it as a destroyer.

(http://www.pentarch.org/steve/Screenshots/FiringSummary002.PNG)

(http://www.pentarch.org/steve/Screenshots/DamageReport003.PNG)

Subsequent damage reports in the next two five-second increments as the Japanese ship continues firing with 10cm railguns. The 15cm railguns are recharging.

(http://www.pentarch.org/steve/Screenshots/DamageReport004.PNG)

(http://www.pentarch.org/steve/Screenshots/DamageReport005.PNG)

The ship is finally destroyed by the next volley.

(http://www.pentarch.org/steve/Screenshots/DamageReport007.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 17, 2018, 02:35:07 PM
Point Defence

In C# Aurora, fire controls set to 'Final Defensive Fire' or 'Final Defensive Fire (Self Only)' will fire on hostile missiles, regardless of whether the fire control is set to 'Open Fire'. Fire controls set to Area Mode or for AMMs will only fire defensively when that fire control is set to 'Open Fire'.

When a missile reaches its target, a target ship will use its CIWS first. If that is insufficient, it will use any weapons linked to fire controls set to 'Final Defensive Fire' or 'Final Defensive Fire (Self Only)'. If that is still insufficient, ships or the same race or an allied race with fire controls set to 'Final Defensive Fire' will be checked in increasing order of distance from the target ship.

A target population will use any ground units with CIWS to shoot at incoming missiles. If that is insufficient, the same process as for ships will take place, checking same race or allied ships within point defence range of the planet.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 22, 2018, 01:50:46 PM
Known Stars Changes

This is a placeholder for Known Stars changes as I make them

Added the following stars:

(http://www.pentarch.org/steve/Screenshots/NewStars.PNG)

Renamed several stars:

(http://www.pentarch.org/steve/Screenshots/RenamedStars.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 24, 2018, 02:58:59 PM
Magazine Design

There are several changes to magazine design for C# Aurora.
In summary, magazine explosions in C# Aurora will be much rarer, especially for larger ships, but far more devastating when they do occur.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 25, 2018, 10:33:54 AM
Automated Weapon Assignment

C# has a more intelligent auto-assignment for weapons and fire controls. You can set up a ship with a single click and then adjust as necessary. The code assumes that
The assignment code will take account of damage to the ship and adjust accordingly. In most cases, the above will be sufficient (and will be used for NPR designs). For more bespoke and unusual player ships, some tweaking may be necessary.

As a simple example, the escort cruiser below has six twin turrets and three fire controls. Clicking the button assigns two turrets to each fire control and sets the point defence to final fire.

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment001.PNG)

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment002.PNG)

This ship has a mixture of point defence and offensive lasers, plus fire controls for each. The auto-assign determines which weapons should be assigned to which fire control. All beam fire control are set as final fire so the ship will use all available weapons to defend against missile attack.

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment003.PNG)

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment005.PNG)

This ship has a mixture of missiles and offensive lasers. Note that missiles are automatically assigned to launchers.

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment006.PNG)

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment007.PNG)

This ship has a point defence turret and multiple types of offensive beam weapons, plus an ECCM system.

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment008.PNG)

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment009.PNG)

An extreme example!

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment010.PNG)

(http://www.pentarch.org/steve/Screenshots/AutomatedAssignment011.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 25, 2018, 01:11:59 PM
Communication Attempts

There are two additional constraints on attempting communication with alien races in C# Aurora.

1) Translation checks will only take place if both sides have a status of "Attempting Communication". In other words, you can't translate their language if they refuse to talk to you.

2) For translation checks to happen, both sides must have ships and/or populations in the same system and both sides must be able to detect the other. Detection in this context is Thermal or EM for populations and Active for ships. So you must effectively announce your presence and stay there if you wish to attempt communication (or show the aliens the way to another system for communication attempts).

This should add more realism and a little more tension to first contact.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 07, 2018, 09:09:34 AM
Weapon Failure

At the point when any weapon (energy-based or missile launcher) fires, there is a 2% chance the weapon will suffer a failure. If sufficient maintenance supplies are available, the weapon will be instantly repaired and will fire normally. If maintenance supplies are not available, the weapon will be damaged and unable to fire.

This is partially to simulate the stress of combat on weapon systems, but also as a balance to other rule changes.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 07, 2018, 09:11:09 AM
Atmosphere and Energy Weapons

In C# Aurora, there is no penalty for energy weapons firing in or through an atmosphere.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 07, 2018, 09:56:38 AM
Planetary Bombardment

In C# Aurora, populations can be attacked by missiles and energy weapons. However, because missile warheads are area-effect weapons, they are much more effective at destroying the civilian population and any installations.

Each installation type has a Target Size. The chance of each attack (either a missile or a single energy weapon) destroying an installation is equal to: Weapon Damage / Target Size. For example, a construction factory has a Target Size of 20, so a 10cm laser fired from orbit would have a 15% chance to destroy the target (3 / 20). For the purposes of this check, missile warheads are treated as equal to 20x warhead strength. Therefore, a single 1 point warhead has a 100% chance to destroy a construction factory.

A single energy weapon can destroy only one target per hit. A missile warhead is applied until all damage is used. For example, a 5-point missile warhead is counted as 100. If the first installation hit is a construction factory, that factory is destroyed and the remaining damage reduced to 80. That damage is then applied the next installation hit and so on.

Missile warheads cause radiation and dust levels to increase by an amount equal to their warhead size. Energy weapons increase the dust level by 5% of their damage amount.

Missile warheads inflict civilian casualties at the rate of 100,000 per point of damage. Energy weapons inflict civilian casualties at the rate of 2,000 per point of damage.

Populations will no longer surrender purely due to orbital bombardment. You have to land ground formations to force a surrender.

Energy weapons now provide a way to destroy the industry and infrastructure of a target population, without causing radiation or using up ordnance. However, this will require considerable effort for a large population and consume maintenance supplies due to weapon failures. It will also bring you within range of any ground-based energy weapons. Of course, it will usually be more beneficial to conquer the planet and gain the installations instead of destroying them.

(http://www.pentarch.org/steve/Screenshots/TargetSize.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 07, 2018, 12:56:10 PM
Ground-based Geological Survey

Geological Survey Teams do not exist in C# Aurora.

Instead, a new ground unit component (100 tons) provides 0.1 survey points per day. Ground units with this component may be added to ground formations to provide a geological survey capability. All formations at the same population with a geological survey capability will combine their survey points to conduct a ground-based survey. This can only take place after the orbital survey is complete.

Once the orbital survey of a system body is completed, the potential for a further ground survey will be revealed (None, Minimal, Low, Good, High, Excellent). The ground survey requires the same survey points as the orbital survey, except they are generated by ground forces. Only system bodies with a diameter of at least 4000 km will be eligible for a ground-based survey (in Sol that is Mercury, Venus, Earth, Mars, Ganymede, Callisto and Titan).

Normal mineral generation (at system body creation) has three phases:
1) An overall roll for the potential for minerals to be present, based on radius, density and system abundance. If this roll fails, the body has no minerals.
2) A roll for each type of mineral to be present, based on density and abundance. Duranium has twice the chance of any other mineral.
3) A roll for the accessibility of each mineral generated in step 2). This is based on radius.

Once the ground survey is completed (assuming potential is Minimal or higher), a new mineral generation roll will take place. For this roll:
Step 1 is the same regardless of the potential.
Step 2 is modified by the potential. Minimal is 25% normal, Low is 33% normal (same as teams in VB6), Good is 50% normal, High is 100% normal and Excellent is 200% normal.
Step 3 is modified by High (+ 0.1) and Excellent (+ 0.2). All others are same as normal.

If a deposit of a mineral that didn't previously exist is generated by the ground survey, that deposit is added to the system body.
If a mineral deposit is generated by the ground survey and a deposit of that mineral already exists on the system body, the existing deposit is changed to match the amount or accessibility (or both) of the ground survey deposit if the latter is greater.

The chances that an eligible body (4000 km diameter) will have ground survey potential is equal to:
None 75%, Minimal 11%, Low 8%, Good 4%, High 1.5%, Excellent 0.5%.

For reference, in the Colonial Wars campaign, there are 2145 eligible bodies in 495 systems, so in general about 1.1 worlds per system will have potential of at least Minimal. About 1 system in 46 would have an Excellent potential world.

Here is an example survey ground unit:

Code: [Select]
[b]Geosurvey Vehicle[/b]
Transport Size (tons)  218     Cost  8.72     Armour  20     Hit Points  40
Geosurvey Equipment:
Geosurvey Equipment:

Vendarite  8.72   
Development Cost  436
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 23, 2018, 09:42:51 AM
Jump Point Stabilisation

For C# Aurora, Jump Gates have been replaced by Stabilised Jump Points. This is purely a technobabble change and there is no change in function.

Anything associated with VB6 Jump Gates will be changed accordingly. For example, Jump Gate Construction Modules have been replaced with Jump Point Stabilisation Modules and the Build Jump Gate order is now Stabilise Jump Point.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 04, 2018, 04:03:16 PM
Starting NPR Locations

There is a new option on the New Game window that allows you to specify the maximum distance (in light years) of starting NPRs in Known Stars games. The NPR starting location will be selected from the list of known star systems within that distance from Sol. This gives you some control over how fast you will run into the starting NPRs.

Once a known system is selected, the system bodies for that system will be generated and checked for a suitable planet or moon to establish the NPR. This potential body needs to be in the acceptable range for gravity, temperate and hydro extent. The atmosphere will be changed to something suitable. If nothing is found, the system is generated again and again until a suitable location appears (this won't take long).

A check is also made to see if the NPR location is within reasonable range of the primary star; either by orbiting within about 12 billion kilometres or orbiting within 12b km of a star that allows travel by Lagrange point to the primary (with the LPs also within 12b of each star). I've even checked for the planet/moon orbiting a star with no Lagrange points but that star is within 12b km of the primary, or orbiting a star with no Lagrange points but that star is within 12b km of another star that does have LPs to the primary :)  This is to ensure no NPRs created that are unlikely to interact with the player.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 28, 2018, 04:36:30 AM
Conventional Armour

The new ground combat rules provide the opportunity to simulate current ground forces, such as tanks, artillery, etc. However, the single conventional armour tech does not provide any granularity to show the different between different generations of armour. Therefore the current Conventional Armour tech is replaced by three new techs. I have also slightly reduced the capability of Duranium Armour and increased the research cost to create a more graduated progression and give conventional forces some chance against the first generation of TN vehicles.

High Density Duranium and above remain the same. Duranium Armour becomes available, regardless of current armour tech, once Trans-Newtonian Technology is researched.

Here are the first six armour techs as they now stand:

(http://www.pentarch.org/steve/Screenshots/ArmourGenerations.PNG)

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 28, 2018, 01:02:39 PM
Box Launcher Reloading

In VB6 Aurora, box launchers can be reloaded in a hangar or at maintenance facilities. For C# Aurora, box launchers can only be reloaded in a hangar, or at an Ordnance Transfer Point (a Spaceport, Ordnance Transfer Station or Ordnance Transfer Hub). Reloading at an Ordnance Transfer Point is 10x slower than in a hangar (similar to the penalty for maintenance facilities in VB6 Aurora).

Because of the changes to maintenance facilities in C# Aurora, it will be a lot easier to forward deploy facilities for full-size warships, both on planets and in space, which would increase the potential of box launchers if they could still use those facilities to reload, especially given they are immediately available in C#. The introduction of ordnance-specific facilities for C# provides a good alternative.

The existing changes post for Missile Launchers has been updated to take account of this new rule:

http://aurora2.pentarch.org/index.php?topic=8495.msg102815#msg102815
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 31, 2018, 04:43:54 PM
Fleet Training

Fleet Training in C# Aurora provides the same benefits as VB6 Aurora. The mechanics by which it takes place are quite different.

Any fleet assigned to an Admin Command with a 'Training' specialisation will automatically take part in Fleet Training. Attaching a fleet to a Training Admin Command will start Fleet Training, while removing it will end Fleet Training. For details on Admin Commands, see the following post.

http://aurora2.pentarch.org/index.php?topic=8495.msg103849#msg103849

Each construction phase, each ship in a fleet assigned to a Training Admin Command  will gain Fleet Training Points based on the following formula:
Crew Training bonus of the Admin Command Commander * Ship Crew Grade * Ship Morale * (Construction Phase Length / One Year)

Unlike VB6, a fleet undergoing Fleet Training can perform normal duties and can be given orders if desired (although this is not required). There are no fixed movement or locations for training. However, only military ships can benefit from Fleet Training. While in training, a ship is under the following restrictions:

1) The parent fleet must remain in a system that is within range of its parent Training Admin Command
2) The ship cannot use maintenance facilities
3) The ship does not benefit from a Recreational Location
4) Maintenance Failure Chance is 2x normal
5) The ship's Maintenance Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
6) The ship's Shore Leave Clock increases by 2x time (compared to 1x for a normal ship), unless it is within a military hangar.
7) Fuel is used as if the ship was running its engine at 10% power for the period of training (this is on top of any fuel used in normal movement). The fuel is consumed during each movement phase. A 'ship' without engines does not require fuel for this purpose
8) Training will not take place if the ship is out of fuel or the Training Admin Command does not have a sufficiently senior commander.

These mechanics are intended to simulate that ships assigned to 'Fleet Training' are carrying out intensive training (drills, etc,) during the course of their normal activities. This places a strain on the ship systems and the crew, resulting in increased maintenance and fuel use and a lower overall deployment time. The ship also sacrifices the benefits that would come from a different type of Admin Command.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 02, 2018, 02:10:10 PM
Planet X in the Sol System

In recent years, several theories have been published regarding a potential planet affecting some Kuiper Belt objects, possibly a distant but undetected gas giant. Therefore, a new game option is to "Add Planet X to the Sol System".

The planet will be located at a distance between 125% and 225% of the orbit of the most distant dwarf planet. 10% of the time it will be a terrestrial body, 60% a gas giant and 30% a superjovian. Moons, Trojan asteroids and a Lagrange point may also be generated depending on the type of planet generated. If Planet X has a Lagrange point, a Lagrange point will also be generated for Jupiter. While very distant from the inner system, this could add an interesting variation to the Sol system.

Currently Planet X is named Minerva, although I haven't created any moon or Trojan asteroid names. Suggestions welcome.

Here is one version of Minerva - a superjovian with eight moons, orbiting at 145 AU.

(http://www.pentarch.org/steve/Screenshots/Minerva.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 01, 2018, 10:06:53 AM
Resupply Changes

In C# Aurora, resupply is no longer instant and ships cannot without cargo shuttles cannot exchange maintenance supplies in space. A ship can only resupply at a spaceport, a cargo shuttle station or from a ship with cargo shuttles.

Maintenance supplies are transferred at the rate of 10 per hour, multiplied by the number of cargo shuttle bays and the racial shuttle technology. Spaceports and cargo shuttle stations can resupply an unlimited number of ships simultaneously. However, the ships being resupplied must be stationary.

Resupply order types will be adjusted to deal with the new requirements. Maintenance supplies can be transferred by supply ships during each movement increment as time passes until the target ship has reached capacity (in the same way as underway replenishment of fuel).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 02, 2018, 06:23:12 AM
Combination Orders

Given the number of new logistics options, I am adding some combination orders to C# Aurora where functions can happen simultaneously. For example, "Refuel and Resupply from Colony" will carry out both activities simultaneously, assuming that the ships / colony are equipped with the necessary logistical facilities. The order will complete when the activity with the greater duration is complete.

Other combination orders so far (I will edit here as more are added):

Refuel, Resupply, Load Ordnance from Colony
Join, Refuel and Resupply Target Fleet
Join, Refuel, Resupply, Add Ordnance to Target Fleet

I will add more combination orders during play testing, depending on which are useful, although I can't go overboard or I risk cluttering the orders list.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 02, 2018, 07:42:16 AM
Minimum Fuel and Supply

Because of the new rules for transferring fuel and supplies, ship classes can be given a minimum maintenance supply level and a minimum fuel level. Ships will not unload or transfer fuel and supplies beyond these levels. These functions replace the VB6 rule where a tanker would only unload 90% of its fuel.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 02, 2018, 09:47:56 AM
Damage Control

Damage Control functions in a similar way to VB6 with a few exceptions.

Below is the new damage control tab for the Ship section of the Naval Organization window. The Repair Chance on the rightmost column is the chance for the ship to repair the component in the time specified at the bottom of the screen in the Repair Chance Time text box. SM Repair All is only visible in SM mode and will repair everything, including armour. Auto Queue will queue everything using the automated damage control rules. Clicking the Automated Damage Control checkbox means the ship will automatically queue and repair damage (the queuing is done just prior to damage control in the sequence of play).

(http://www.pentarch.org/steve/Screenshots/DamageControl02.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 08, 2018, 08:07:32 AM
Electronic Intelligence Gathering

A new concept in C# Aurora is ELINT, or Electronic Intelligence Gathering. This is performed by a new line of ship components, the Electronic Intelligence and Analysis Modules. These start at strength 5 and follow a similar strength progression to EM Sensors. One of the prerequisites for each module is the corresponding EM Sensor strength technology.

The ELINT Modules are 10 HS, require 15 crew and cost 20x their strength (this is subject to change as a result of play test). They have a secondary function as an EM Sensor, although a dedicated EM sensor of the same size would be far more effective. Their primary function is to gather electronic and signals intelligence on alien populations and active sensors (and I will add ground forces at some point). Increased strength, through research or multiple modules, can increase the range at which intelligence is gathered but the base rate is fixed. Multiple ships cannot increase the intelligence gathered from a single source, although a single ELINT module can gather intelligence from multiple sources.

If the target can be detected by the ELINT modules' built-in EM Sensors, intelligence can be gathered. The rate is 1 intelligence point per day, boosted by the Intelligence bonus of the ELINT ship commander. For populations, the intelligence is also multiplied by (100 - Population Species Xenophobia) / 100. In other words, it is much harder to gain intelligence when a population has high xenophobia. If the alien language is not translated, all intelligence is reduced by 80%.

Intelligence is gathered per population and per active sensor design (if multiple sensors of the same type are monitored, you only gain intelligence at the same rate as one sensor). Specific alien sensors will now be associated with specific alien classes.

Alien active sensors will initially be displayed with just a strength and not a range or resolution. Once 100 intelligence points have been gathered for a particular design of active sensor, its range and resolution will be displayed. Note that in VB6 you only have an approximation of the alien sensor range. I plan to add active jammers and passive stealth capability, both of which will become more effective against alien sensors based on the intelligence gathered on those sensors (no limit to intel points). I'll provide the detail for this when I post the jammer and stealth rules.

Alien populations will be initially be displayed as they are now, with EM and thermal signatures. Once 100 intelligence points have been gathered, the population size in millions and the number of installations will be displayed. Additional information becomes available at higher intelligence levels:

200 Points:
Number of factories and mines and whether a spaceport and/or a cargo shuttle station are present.

300 Points
Number of refineries and maintenance facilities and whether a refuelling station and/or an ordnance transfer station are present.

500 Points
Number of research facilities and ground force training facilities and whether a naval headquarters and/or a sector command are present.

The intelligence points for a specific population will reduce at approximately 25% per year if ELINT monitoring ends. The information that was gained while intelligence points were at their highest point will remain and is shown in red when viewing the alien population on the Diplomacy window. Current information is shown in green.

Any intelligence gained on a population is also used at the racial level for the purposes of espionage. Each Alien Population Intelligence Point adds one Alien Race Intelligence Point. If the population is less than 100m, the translation of Population Intelligence to Race Intelligence is modified by Population in millions / 100. When 100 Alien Race Intelligence Points have accumulated, a check is made for any intelligence gained. This is the same check as in VB6 for espionage teams and can result in new technology, survey data, new system knowledge or details of an enemy ship class. I will probably add information on alien sensors, ground units and populations to that list.

As a result of these changes, espionage teams have been removed from C# Aurora.

A couple of design examples for the ELINT Module

(http://www.pentarch.org/steve/Screenshots/ELINT01.PNG)

(http://www.pentarch.org/steve/Screenshots/ELINT02.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 08, 2018, 09:15:51 AM
Interrogation of Survivors

In VB6 Aurora, you can gain espionage points from interrogating the survivors picked up from life pods. In C# Aurora, the same principle applies, although they are now Race Intelligence Points and are added to those gained via ELINT.

The rate at which Race Intelligence points are gained from survivors is Crew / 10 + the cube of the rank number of any captured officer (so R3 would provide 27 points). This is more important than the same algorithm in VB6, because there are now potentially multiple officers per ship.

However, unlike VB6, this point gain is reduced if the survivors are from a non-hostile power. The intelligence points gained from neutrals is halved, friendly reduced by 80% and allied by 90%. This is to simulate that aggressive interrogation is unlikely to be used against survivors from a friendly power.

As with other intelligence gains, there is a further 80% reduction if the alien language has not been translated.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 15, 2018, 08:58:33 AM
Ground Force Logistics

Ground Units have two separate logistics requirements. The first is Maintenance, which applies to all units at all times and has a wealth cost equal to 12.5% of Ground Unit cost per annum. The second is Ground Supply Points (GSP), which applies only to combat units during ground combat.

The GSP requirement for a weapon component is equal to Penetration Value * Damage Value * Shots. For example, Personal Weapons is (1 x 1 x 1) = 1. Crew Served Anti-personnel is (1 x 1 x 6) = 6. Medium Anti-Vehicle is (4 x 6 x 1) = 24. Heavy Bombardment is (2 x 6 x 3) = 36.

The GSP requirement for a Ground Unit Class is the sum of its weapon components. For example, a tank with a Medium Anti-Vehicle component and a Crew Served Anti-personnel component would have a GSP requirement of 30. The GSP requirement for a Formation Element is the GSP for the Ground Unit Class in the element multiplied by the number of units. The GSP requirement for a Formation is the sum of the GSP for its constituent Formation Elements. In all these cases, that is the GSP cost to provide sufficient supply for ten combat rounds.

Two new ground unit components have been added; the Logistics Module, which is Size 50 and provides 500 GSP, and the Logistics Module - Small, which is Size 10 and provides 100 GSP. The standard module is available for light vehicle and infantry base types, while the small module is only available to infantry.  Here is an example of a light vehicle with the Logistics Module.

(http://www.pentarch.org/steve/Screenshots/SupplyVehicle02.PNG)

Ground units with either logistics module can be added to any level of the ground force hierarchy, either embedded with the front line combat formations or held at a superior formation, such as a headquarters.

Each Ground Unit has sufficient inherent supply points to fight ten rounds of combat (currently one round takes place every three hours). After that point, only one quarter of units in a formation element that is out of supply will fire in each round. In addition, a formation with out of supply elements cannot use a field position of 'Front Line Attack' (more on this when I publish the full ground combat rules). However, if units with logistics modules are available, ground units can draw supply to both fight the current combat round and replenish supplies used in previous combat rounds.

Ground Units will attempt to draw supply from the formation that sits highest in their hierarchy and is at the same population. If no supply is available, they will move down the hierarchy to their own parent formation, checking at each stage. However, when drawing supply from outside their own formation, units can only draw on logistic modules mounted on light vehicles. Logistics modules with an infantry base type can only supply their own formation.

For example, a formation element of 10 tanks engaged in combat is part of an armoured formation with a brigade HQ formation above it and a division HQ formation above that. The tanks will check for a vehicle-based logistics element within the division formation first, then a vehicle-based logistics element within the brigade formation and finally either type of logistic element within their own parent formation. If no logistic elements are available, the tanks will use their inherent supply, although they can only use that inherent supply for ten combat rounds, unless resupplied. If a unit does not require a full resupply (for example, it still has sufficient inherent supply for eight combat rounds), it will only draw an appropriate fraction of its normal GSP requirement (in this case 20%).

When a formation element of logistics units provides supply, a number of units will be consumed based on the supply required. For example, assume the 10 tanks above each have a GSP requirement of 100, which is 1000 for the whole element. If they draw on a logistics element using light vehicles with normal logistics modules (which have 500 GSP each), two of those logistics vehicles would be consumed. When the GSP requirement does not neatly fit into the 500 point granularity, there is a chance of an additional logistics vehicle being consumed. This chance is dependent on the fraction of supplies required. For example, if there were 12 tanks with a requirement of 1200, then two logistic vehicles would be consumed and there is 40% chance (200 / 500) than a third vehicle will be consumed. This adds an element of uncertainty, as supplies may be consumed faster or slower than normal (although it will average out over time), plus it avoids any tracking of partial supplies per vehicle.

Below is an example of a Formation Template for a Brigade Headquarters that includes 50 Supply Vehicles.

(http://www.pentarch.org/steve/Screenshots/Logistics003.PNG)

Below is an order of battle for a divisional formation. At the divisional level are 240 Supply Vehicles, indicated by LOG 120k (120,000 supply points) in the Formation Attributes column, with smaller numbers within each brigade headquarters formation. The GSP column shows the resupply requirement for each formation or formation element. The total divisional organisation requires 40,338 GSP for a complete resupply and there are sufficient supply vehicles (410) in that organisation to resupply five times. With the inherent supply as well, the entire division can stay in combat for sixty rounds before additional supply vehicles are required.

(http://www.pentarch.org/steve/Screenshots/Logistics004.PNG)

Finally here is a view of a single population, with the order of battle tab in Location mode.

(http://www.pentarch.org/steve/Screenshots/Logistics005.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 16, 2018, 01:10:43 PM
Base Ground Combat Rules

Ground combat is conducted after the naval combat phase of each increment. One combat round will be performed for every three hours that passed in the increment. Combat potentially takes place on any system body where populations exist from two or more hostile powers. If only one side has ground forces present, there may be a conquest (rules and code TBD). If ground forces are present from two or more hostile powers, ground combat will take place.

Ground forces can be assigned one of four field positions; front line attack, front line defence, support and rear echelon. Units in support and rear echelon positions cannot directly attack hostile forces but if they possess elements with bombardment weapons they may be assigned to support a front line formation. Support and rear echelon formations can also potentially provide anti-air cover (more in a rules post on ground-space interaction) and supply to front line units. Only formations with all elements supplied can be placed in front line attack mode. Formations placed in front line attack mode lose any fortification bonus.

Each race involved in a combat on a system body creates a list of its own formations on that system body (even if in multiple populations), plus a list of hostile alien formations, even if they are from multiple alien races in multiple populations. Hostile formations are checked for their weighted size.  This is based on actual size for front line size, 25% for support and 5% for rear-echelon. Each hostile formation is given a range for potential selection, based on its weighted size.

Each front line friendly formation randomly targets a hostile formation. Friendly units with front line defence can target hostile front line formations. Friendly units with front line attack can target any hostile formation, although support and rear echelon are less likely given their smaller weighted size. In fact, the more formations that are pushed into front line positions, the less likely it is that rear areas will be attacked.

Support and Rear Echelon formations that contain formation elements with bombardment weapons can be assigned to support front line formations that are part of the same organisation. Formations in a support position with light bombardment weapons will fire with the front line formations (see next paragraph). Formations in a support position with medium/heavy bombardment weapons or formations in a rear echelon position with heavy bombardment weapons will fire in a subsequent phase - see below.

Once a front line formation (or a light bombardment element in the Support position) has been matched against a hostile formation, each friendly individual unit (a soldier or vehicle) in that formation engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements. The targeting on an individual unit level represents that the different elements in a front line formation will generally be attacking in conjunction (infantry supporting tanks, etc.).

Once all front line attacks have been concluded, each unit in each element providing supporting bombardment will engage either the hostile formation being targeted by the friendly formation they are supporting, or one of the hostile formation's own supporting elements (counter-battery fire). If the hostile formation is targeted, each unit in the supporting artillery element engages a random element in the hostile formation, with the randomisation based on the relative size of the hostile formation elements (the same as front-line vs front-line). If a hostile supporting element is targeted, all fire is directed against that element. This represents the difference between providing supporting fire in a combined arms front-line battle and targeting specific hostile artillery for counter-battery fire. The decision to target the hostile front-line formation vs hostile support elements is based on the relative sizes.

Supporting medium artillery will choose between hostile forces in Front-Line or Support field positions (and will ignore any elements in Rear Echelon field position for purposes of relative size), while heavy artillery can select targets in any field position. In other words, if the enemy has supporting heavy artillery in a rear echelon position, you will only be able to target those elements with your own heavy artillery (or ground support fighters, or orbital bombardment support).

Once all the initial combat is complete, there is a chance for a breakthrough. Each defending formation is checked according to the following procedure:
The breakthrough rules mean that defending formations that suffer casualties may allow attacking formations to penetrate their lines and conduct a second attack. This is more likely under the following circumstances: A single defending formation is attacked by multiple attacking formations, the defender suffers a high casualty percentage in a single ground combat round (potentially because the formation is small in size), the defender suffers disproportionate casualties to elements with larger unit classes, the defender is low morale, the attacker is primarily vehicle-based, the attacker is on front-line attack, the attacker is high morale.

When a formation element is engaged in combat against a hostile formation element, supply is checked. If supply is not available, the number of units firing will be 25% of normal. Each attacking unit uses the following process:
All combat is conducted simultaneously and losses are applied once all firing is completed. Because of the way the above is structured, multi-way conflicts with multiple races on each side are possible.

I will post separately on how spacecraft interact with ground combat.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 17, 2018, 04:09:24 PM
Setting Ground Formation Support

Here is a screenshot of the UI for setting support relationships between superior and subordinate formations. You drag the superior formation on to the subordinate formation. If the Support checkbox is checked, the supporting formation is shown in blue-grey with the name of the supported formation. Any supported formation in shown in orange. Support can only be provided when the supporting formation is a superior formation in the hierarchy of the supported formation, or is directly subordinate to a superior formation in the hierarchy of the supported formation and does not itself have any subordinate formations (an independent artillery formation for example). Supporting formations must be on the same system body as the supported formation. In combat, the support relationship will only function if the supporting unit has suitable bombardment units and is in a support or rear echelon position and the supported unit is in a front line position.

The drag-drop is intelligent and can distinguish between setting support relationships, reassigning formations to a new headquarters, removing headquarters assignments, moving formations from one population to another (on the same system body) and moving elements between formations (more on that last option in the next post).

(http://www.pentarch.org/steve/Screenshots/FormationSupport001.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 17, 2018, 04:17:08 PM
Ground Formation Element Transfer UI

Below is the same screenshot as the previous post but with the Elements option selected. Now the formation elements for each Ground Formation are shown in the hierarchy. For formations with no subordinate formations, the formation elements are shown directly under the parent formation. For formations with subordinate formations, the formation elements are shown under their own node, to avoid cluttering the tree view.

To move elements between formations, you can drag and drop elements from one formation to another, although they must be on the same system body. Normally, the whole element is transferred. However, if the Amount checkbox is checked, a popup box will appear after the drag-drop, allowing you to transfer only a portion of the element. If the receiving formation already has an element with the same ground unit class, the additional units will be added to the existing element.

(http://www.pentarch.org/steve/Screenshots/Elements001.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 22, 2018, 07:05:33 AM
Fighter Pods and Fighter Pod Bays

In C# Aurora, fighter-sized ships can be equipped with a new component, the Fighter Pod Bay, which is similar in function to a small Box Launcher, except it will only hold Fighter Pods (see below).

(http://www.pentarch.org/steve/Screenshots/GroundSupport004.PNG)

Fighter Pods are created on the Missile Design window. The various pod options, such as bombardment pod, autocannon pod and air-to air pod, will appear when the requisite technology has been researched. When one of those options is selected, the warhead strength field is replaced by a pod size field. The player can choose the pod size, with larger pods being more effective. The pod capabilities will be similar to the capabilities of equivalent-sized ground unit components, although the fighter pods have more flexibility in design. For example, a bombardment pod will have three shots, armour penetration equal to Racial Weapon Modifier * ((Tons / 20) ^ 0.6) and damage equal to Racial Weapon Modifier * ((Tons / 20) ^ 1.6).

Fighter pods are ordnance, in exactly the same way as missiles. They are built by ordnance factories, transported in magazines and loaded onto fighters. Unlike missiles, they are not expended when fired and will function during ground combat phases.

(http://www.pentarch.org/steve/Screenshots/GroundSupport002.PNG)

(http://www.pentarch.org/steve/Screenshots/GroundSupport003.PNG)

A fighter can be designed with fighter pod bays. Different pods can be assigned to those bays while the fighter is in a hangar, providing flexibility of loadout. The same fighter could be used for bombardment or autocannon pods, as long as the pods bays are large enough and the parent carrier has both types of pods available. The pods can be assigned to the fighter using the normal ordnance loadout. The pods require a missile fire control to operate, although this can be minimal size (0.1 HS) as there are no range or resolution restrictions.

Pods can also be assigned to normal box launchers, so a fighter designed for space combat can also be used for ground combat in an emergency. However, box launchers are three times larger than the missiles (or pods) they are designed to fire, while fighter pod bays are equivalent in size to the pods, making fighter pod bays are a much more efficient way to mount the pods. Because of this efficiency, the minimal-size fire control and no requirement for active sensors in ground combat missions, dedicated ground support fighters can be much smaller than their space combat equivalents. It is also possible to have hybrid designs mounting both pods and box launchers. Due to the requirement for smaller engines for dedicated ground support aircraft, ship engines can now be designed from 0.1 HS in size.

(http://www.pentarch.org/steve/Screenshots/GroundSupport005.PNG)

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 22, 2018, 11:19:29 AM
Ground Support Fighters

Fighters equipped with fighter pods can provide support to ground unit formations during ground combat.

To be eligible, a fleet with fighters is given an order to "Provide Ground 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 appear in their own section for each population. These fleets can be dragged and dropped on to formations in the same way as superior and subordinate formations. Fleets with this order that are at their target population cannot be targeted in normal naval combat or by STO weapons.

In combat, the ground support fighters attack at the same time as bombardment elements and have the same target selection options as heavy bombardment.

Ground support fighters 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 fighter's to hit chance is affected by its own crew grade and morale.

Each Forward Fire Direction component in a formation allows support from up to six ground support fighters. If more fighters are assigned to a formation than can be supported, the chance to hit is modified by (Number of FFD * 6) / Number of Fighters.

(http://www.pentarch.org/steve/Screenshots/GroundSupport006.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 23, 2018, 09:47:13 AM
Ground-based AA Fire

AA units take part in ground combat normally, using their ground combat values. If an AA unit takes part in both ground-ground and ground-air combat, it will draw supply twice.

Once all direct combat, bombardment support and ground support fire has been resolved, but before damage is allocated, all AA units will be checked to see if they can fire on hostile aircraft, using the following rules:

1) All AA units in a formation that was directly attacked by aircraft will each select a random aircraft from those that attacked that formation.
2) Medium or Heavy AA units in a formation that was not directly attacked by aircraft but is the direct parent of a formation that was attacked will each select a random aircraft from those that are attacking the subordinate formations.
3) Heavy AA units that are not included in the two categories above will fire on a random hostile aircraft, including those on CAP that are not directly engaged in attacking ground units.

An Environment Modifier is calculated, taking into account gravity, pressure and temperature and whether the firing AA unit has capabilities in those environments. Each environment for which the element is not trained has a x2 modifier. There are no terrain modifiers.

The chance to hit is (10% x (Tracking Speed / Aircraft Speed) x (Morale / 100)) / Environment Modifier.

If a hit is scored, the damage vs the fighter is (Ground Damage Value  / 20)^2 rounded down. For example, an AA unit with a ground damage value of 40 would have AA Damage of (40 / 20) ^ 2 = 4.

All AA damage is applied after all attacks have been resolved.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 07, 2018, 12:45:31 PM
Ground Commander Bonuses

Ground force commanders have a much greater variety of bonuses in C# Aurora. The most straightforward are:
In addition to the above, each ground commander has a 'Ground Combat Command' rating, which represents the size of the formation he can effectively command. This rating is given a relatively high score for promotional purposes so officers with high command ratings will tend to progress though the ranks.

If an officer is commanding a formation that is larger than his command rating, the effectiveness of his other bonuses will be reduced by (command rating / formation size). For example, an officer with a 20% defence bonus and a command rating of 5000 is commanding a regiment with a size of 7000. The defence bonus is reduced to 14.3%. In addition, if the largest HQ in a formation has a rating less than the formation size, the effectiveness of the formation commander's bonuses will be reduced by (HQ rating / formation size). These penalties (command rating and HQ rating) are cumulative.

Finally, ground forces officers have a Ground Combat Training bonus, which affects morale. Each construction phase, any formation element with less than 100 morale will regain that morale at a rate of 100 per year, plus the commander training bonus (so a 20% bonus would increase morale recovery to 120 per year). Formation elements can continue to improve morale above 100, using the following process:
For example, a formation element has 140 morale and the commander of the parent formation has a Ground Combat Training bonus of 30%. However, he is commanding a formation that is slightly too large for his Ground Combat Command rating, so he has a Command Modifier of 0.8. The training bonus is 24% (30% x 0.8), which converts to a morale bonus of 24. The maximum morale for the formation is therefore (100 + (5 x 24)) = 220. The morale gain modifier is 1 - ((140-100) / (220 - 100)) = 0.667. Therefore, the formation will gain morale at 24 * 0.667 = 16 points per year.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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:

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:

This post is also a placeholder for additional missions - one of which will be Combat Air Patrol (when I code it).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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". These 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 more ships and fighters are assigned to a formation than can be supported, the chance to hit is modified by:
Number of FFD / ((Fighters / 6) + Ships).

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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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:
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.

(http://www.pentarch.org/steve/Screenshots/STOWeapon003.PNG)

(http://www.pentarch.org/steve/Screenshots/STOWeapon004.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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 damage value of each weapon that fires is cubed, then the total damage is divided by one million. For example, assuming a base ground combat tech of 10 (about TL4):

An infantryman with personal weapons would generate 0.001 collateral damage per combat round (damage 10, shots 1)
Light anti-vehicle (damage 20, shots 1) is 0.008
Light bombardment (damage 20, shots 3) is 0.024
Medium anti-vehicle (damage 40, shots 1) is 0.064
Medium bombardment (damage 40, shots 3) is 0.192
Heavy anti-vehicle (damage 60, shots 1) is 0.216
Heavy bombardment (damage 60, shots 3) is 0.648

Putting that in terms of regiments, 1000 infantrymen would generate 1 collateral damage per round while 50 heavy tanks (about the same size but 2x cost) would generate 11.2 collateral damage, assuming HAV and HCAP. 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.

If attacking forces wish to minimise collateral damage, they will need to restrict the use of heavy weapons.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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 250,000 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.



Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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).

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.

Shipyard complexes have a base population requirement of 1 million, plus an additional requirement equal to (Slipways x Capacity in Tons x 100) for naval shipyards and (Slipways x Capacity in Tons x 10) for commercial shipyards.

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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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.
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.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley 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
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on October 26, 2018, 08:40:40 AM
Conventional Industry

In VB6 Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.05 refineries and 0.1 mines.

For C# Aurora, Conventional Industry provides the same output as 0.1 construction factories, 0.05 ordnance factories, 0.025 fighter factories, 0.05 refineries and 0.15 mines.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 02, 2018, 03:20:32 PM
Linked Windows

C# Aurora has a option to link all the open windows, so that when you change the current Race in one window, all the other windows change to the same race.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 03, 2018, 05:41:28 AM
Tactical Map in Background

C# does not have a starting menu bar in the same way as VB6. Instead, the Tactical Map is the main game window.

Once the Tactical Map is open however, both VB6 and C# have a similar issue. Assume you have the Tactical Map on maximised and you open the Economics window. That window is now on top of the Tactical Map. Now you click the button on the Tactical Map to open the Fleet Window. While that is on top of the Tactical Map, the existing Economics window is now behind the Tactical Map because clicking on the button gave the tactical map focus and therefore precedence over the existing Economics window. Which means if you want to see both Economics and Fleet at the same time you need to manually bring Fleet to the front (or move Economics to a second monitor before clicking the Fleet button).

Therefore C# now has an option called 'Keep Tactical in Background'. While this is active, after pressing the toolbar button on the Tactical Map, the new window will open and then the Tactical Map will move to the background, leaving all other windows in front of it and the newly opened one on top.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 07, 2018, 01:42:47 PM
Mineral Search Window

The new version of the Mineral Search window. This should be more flexible than the VB6 version as you can specify minimum amounts and accessibilities for every mineral, plus the amounts are now nicely lined up so it is easier to compare different bodies. The window will order by the mineral with the highest minimum amount. The filter apply in left to right order, so if you specify gas giants only, it doesn't matter what you specify for asteroids.

For example, here are all bodies with at least 1000 tons of Duranium with 0.3 accessibility or higher.

(http://www.pentarch.org/steve/Screenshots/Minerals001.PNG)

Here is the same but with the added requirement of at least 1 ton of Sorium.

(http://www.pentarch.org/steve/Screenshots/Minerals002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 09, 2018, 04:31:35 AM
Continual Capacity Upgrade Target

In C#, you can set a target capacity when using the Continual Capacity Upgrade shipyard task. The upgrade will end when it reaches that target capacity.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 09, 2018, 05:10:55 AM
Colony Cost of Comets

In VB6 Aurora, the colony cost of comets was not a major concern as there was no low gravity infrastructure. For C#, comets could potentially contain populations, albeit small ones.

Therefore temperature and colony cost now update as comets move towards and away from the sun. This means the population supported by infrastructure will change as well over time. The distance displayed on the system view is the current, rather than maximum, distance. You can flip between current and max colony cost on the System View and it is displayed on Colony Summary of the Economics window and on the Body Info tab of the Tactical Map.

The Unload Colonists Standing Order will ignore comets, so civilian traffic will not attempt to place colonists on comets about to disappear into the void.

I may add some larger comets to make this more interesting. Longer-term, I may also add eccentric planetary orbits with a similar approach to the above. This is an experiment on a small scale to see what issues I encounter

(http://www.pentarch.org/steve/Screenshots/Comets002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 17, 2018, 07:01:13 AM
Orbital Mining Modules

Asteroid Mining Modules in VB6 are replaced with Orbital Mining Modules in C#.

Each race has a new tech line called Maximum Orbital Mining Diameter. The starting tech is 100 km and each additional tech increases the size of the body that can be mined (125 km, 160 km, etc.). The tech line finishes at 500 km. Any system body, including asteroids, comets, moons and small dwarf planets, that falls within this diameter can be mined using Orbital Mining Modules. This does mean that some asteroids will be too large for orbital mining.

The population summary shows parent body diameter and eligibility for orbital mining. On the system view, you can flag those bodies that are eligible for orbital mining. On the Mineral Search window you can choose to filter on eligible bodies.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 25, 2018, 11:58:53 AM
Abandon Overhaul

In VB6, a fleet can issue an Abandon Overhaul order and one month later, any ships in overhaul within that fleet will be returned to a normal maintenance state.

For C#, each individual ship (or a whole fleet) can choose to abandon overhaul at any point. It immediately returns to a normal maintenance state but suffers severe after-effects as the crew try to return the ship to normal working order. The ship has an 'Overhaul Factor' that starts at 0.01 immediately following the abandon overhaul decision and increases to 1.00 over the course of thirty days. The increase takes place in each movement phase sub-pulse, following movement in that sub-pulse. The 'Overhaul Factor' is used in a similar way to crew grade and morale and affects the following:

1) Weapon Chance to Hit.
2) Engine Power
3) Maximum Shield Strength
4) Maintenance Failure Chance
5) Jump Shock Length
6) Fleet Training

For example, a ship six days after abandoning overhaul will have an overhaul factor of 0.2. Assuming no crew grade or morale modifier, engine power and maximum shield strength will be 20% of normal, combat to hit chance will be 80% lower than normal. Maintenance Failure will be 80% higher, Jump Shock length will be 80% longer and Fleet Training will be at 20% of normal.

This rule allow ships to leave overhaul immediately if absolutely necessary (such as hostile vessels closing in), but the short-term penalties are considerable. The Abandon Overhaul order has been removed.

Ships undergoing overhaul in C# Aurora are zero speed for purposes of incoming missile or weapon fire, cannot fire weapons or launch missiles and have zero shield strength.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 25, 2018, 12:03:54 PM
Fleet Maximum Speed

Fleets have a checkbox on the Naval Organization window entitled 'Use Maximum Speed'.

If this is checked, Fleets will automatically recheck their speed at the start of each movement sub-pulse and use the maximum available.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 26, 2018, 08:29:24 AM
Maximum Wealth Balance

In Conventional Start games, races often build up a huge wealth reserve due to a lack of costs. This removes wealth as a consideration for many years and takes away meaningful decisions.

Therefore, in C# Aurora, a race's wealth balance can never exceed double the annual wealth. Any excess beyond that is assumed to be spent on improving the lives of its citizens.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 26, 2018, 11:10:50 AM
Ground-based Xenoarchaeology

Xenology Teams do not exist in C# Aurora.

Instead, a new ground unit component (100 tons) provides 0.5 xenoarchaeology points. Ground units with this component may be added to ground formations to provide a xenoarchaeology capability. All formations at the same population with a xenoarchaeology capability will combine their xenoarchaeology points.

The annual chance for a race to successfully translate the alien language and symbology is equal to the xenoarchaeology points on the planet. For example, a Xenoarchaeology Vehicle is created with 2 components, giving it 1 xenoarchaeology point (cost about 9 BP). If a formation has forty such vehicles, the annual chance would be 40%. The chance in any given construction phase is equal to the annual chance * (construction phase length / year).