Aurora 4x

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

Title: C# Aurora Changes List v1.00
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 twice as expensive - 4 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.

Government tax rates on civilian shipping will work in the same way, except rates will not be halved as a baseline. This will increase the overall tax revenue from civilian shipping.

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 applies to both the payment to the shipping line and the tax.

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 in the same way as insufficient infrastructure.

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. This affect max population capacity, infrastructure capacity and orbital habitat capacity. 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 1250 capacity for 2000 RP. The 2000 ton capacity is at 8,000 RP and the max is currently 6250 tons at 250,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 75% at the lower tech levels. The rate of tech increase has improved so the higher tech levels are reduced by around 60%. The starting racial tech rate per module/installation is 0.00025 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 (90% of VB6 Aurora speed), Ganymede is 6x faster and Luna is almost 14x faster (3.4x faster 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.025 atm of water vapour. This means that creating 20% Hydro Extent would require 0.5 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.6%.

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, with 0 being the highest priority (until v1.12 when 0 is lowest), 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. During the first run through of all ships, 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

After all of the above is completed, three additional cycles are conducted for the commander position on all military ships that lack a commander. The first run through is based on Reaction bonus, the second on Engineering bonus and the last on Tactical bonus.
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
8) Added Ultima Thule. 30 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 Civilian Harvesters. When this is disabled, shipping lines will not build fuel harvesters.
6) Flag for recovering tech due to conquest. You can disable this so no new tech is gained via conquest.
7) LY entry to limit Starting NPR Locations to within a specific range of Sol: http://aurora2.pentarch.org/index.php?topic=8495.msg108824#msg108824
8) Option for Planet X in the Sol System: http://aurora2.pentarch.org/index.php?topic=8495.msg109206#msg109206

You can specify a number of Earth-based player races on the Game Setup window. You will cycle through a number of Race Creation windows equal to the number of races selected. You will still need to create any non-Earth-based races after the main game creation process.
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 that is set as a destination with no other colony fleets inbound, checking its current system first and then using the path finding algorithm to search everywhere else in the empire.
2) Same as 1) but without the check for inbound colony ships.

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

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

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

Because of these changes, Passenger Liners will no longer search their current system for a potential destination (otherwise they could load and unload at the same population).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 21, 2018, 08:23:46 AM
Shipping Lines

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

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

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

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

Creation of new shipping lines will only be possible once the starting shipping line has created its first ship.
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, although it is probably practical at lower colony costs because the ground-based infrastructure would require a larger proportion of population for environment. 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.

A system can also be flagged on the Galactic Map as excluded from auto-route. For example, there may be a shorter route in terms of kilometres but longer in terms of transits. You can block one of the systems on the original route so the algorithm will always choose your preferred path.

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 assigned to point defence 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).

The highest Communication bonus of any commander of a ship with a Diplomacy module in one or more of the contact systems will boost any positive results achieved through the communication process. If no Diplomacy module is present in any of the contact system, any positive gains are halved.

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 1% 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 60%, Minimal 20%, Low 10%, Good 6%, High 3%, Excellent 1%.

For reference, in the Colonial Wars campaign, there are 2145 eligible bodies in 495 systems, so in general about 1.7 worlds per system will have potential of at least Minimal. About 1 system in 23 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 minimum and 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 range 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 without cargo shuttles cannot exchange maintenance supplies in space. A ship can only resupply at a population with a spaceport, a cargo shuttle station or at least one maintenance facility, 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, cargo shuttle stations and maintenance facilities 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 eight 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 eight 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. Note that if all HQ capacity in a formation is eliminated, no commander bonuses will apply.

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". The ships in those fleets can be dragged and dropped on to formations in the same way as ground support fighters. Fleets with this order can still be targeted in normal naval combat or by STO weapons (they do not have the same protection as fighters on ground support missions).

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

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

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

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

Orbital bombardment is a powerful aid to any ground combat, although the ships will be vulnerable to hostile STO weapons and require fire direction from the surface. Ships conducting Orbital Bombardment Support will be firing far less than often than a ship conducting general planetary bombardment, but will do so with more accuracy. This is because the ship will be firing on specific targets as directed by ground-based controllers when the right opportunity arises.
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 'base component damage value' (before modification for weapon technology) of each weapon that fires is cubed, then the total damage is divided by 10,000. For example:

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

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

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

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

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

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

If attacking forces wish to minimise collateral damage, they will need to restrict the use of heavy weapons and orbital bombardment support.  Note that the base component damage value is used on the assumption that higher tech ground units are more destructive but also more precise in their targeting.
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 one million population to operate.

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

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



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.

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

The calculation for Shipyard workers has been changed for C# Aurora and is covered in the following post:
http://aurora2.pentarch.org/index.php?topic=8495.msg112323#msg112323
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, 0.1 financial centres 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).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 22, 2018, 11:30:09 AM
Missile Launch Detection

In VB6, missiles are only detected after their first movement sub-pulse. This is due to the sequence of play of Movement -> Detection -> Combat. Consequently, a missile ship close enough to an opponent for its missile to cover the distance in less than five seconds can avoid point defence entirely, because there is no opportunity to detect the missile before impact.

In C#, an additional detection phase takes place after missile launch, which is restricted to the detection of newly launched missiles at the point of launch. This means that no matter how close the missile ship is to its opponent, the missile will be detected if the opponent has sensors capable of detecting it. The missile will still be in the same location as the launching ship when this detection phase takes place.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 22, 2018, 12:27:16 PM
Alien Weapon Detection

As part of the tactical intelligence in C# Aurora, it will be possible to determine the weapons of alien ships under the right circumstances.

When a ship fires beam weapons, either in the combat phase or in the missile movement phase, each race which has a current active sensor contact for the firing ship will detect the type of weapon (Railgun, Laser, etc), the power of the weapon, the number of weapons fired and the weapon range (based on target location).

When a ship launches missiles, each race which can detect the new salvo at the point of launch will detect the number and size of the launchers on the firing ship (only those launchers that fire missiles will be detected).

If a ship fires or launches multiple times, the interval between firing for each weapon type will be tracked (this won't be perfect because the alien ship may be firing different weapons at different times but will provide a reasonable idea). All the weapon intelligence gathered will be displayed for the Alien Class.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 23, 2018, 02:13:57 PM
Naval Bombardment of Ground Forces in Naval Combat Phase

Ground forces can be bombarded by naval forces as part of normal naval combat. Note this is not the same as Orbital Bombardment Support, which involves ships in orbit working in conjunction with ground forces to deliver precision energy weapon strikes:
http://aurora2.pentarch.org/index.php?topic=8495.msg110310#msg110310

Instead, Naval Bombardment of Ground Forces (NBG) is a mass bombardment of ground-based sensor contacts using either missile weapons or energy weapons, which does not require friendly ground forces on the target body or fire direction support and is an adjunct to Planetary Bombardment:
http://aurora2.pentarch.org/index.php?topic=8495.msg107703#msg107703.

For the purposes of bombarding ground forces, each weapon type on each ship is treated separately for targeting purposes. For example, a ship with both 10cm and 15cm railguns would make two separate rolls to select a target formation, one for each weapon type, and therefore target all weapons of the same type on the same formation. Target formations are selected based on a weighted random roll, with the weighting based on formation size. Once a formation is selected as a target, each shot against that formation selects a random element within the formation, again using a weighted random roll.

Ship using energy weapons for NBG have one third of the chance to hit compared to using Orbital Bombardment Support (as in the latter case they are being directed by FFD units) and do not benefit from any ground support bonus from the ship commander or tactical officer. Their to-hit chance is the base ground combat to hit chance (20%), reduced by two thirds, multiplied by the to-hit modifier of the planet's dominant terrain and divided by both the fortification of the target formation elements the and fortification modifiers of the planet's dominant terrain. In summary, blind-firing energy weapons at general concentrations of enemy forces is not a very effective way of destroying them, especially in difficult terrain, although it can be done given sufficient patience and maintenance supplies. When firing at Detected STO units, the two-third reduction in to-hit chance is not applied, as the STO units have given away their general location.

Ships using missiles for NBG have a 100% base chance to strike their targets, as nuclear warheads require considerably less precision than energy weapons, and may hit multiple targets. This is modified by the to-hit modifier of the planet's dominant terrain and divided by both the fortification of the target formation elements and the fortification modifier of the planet's dominant terrain. One attack is made with the missile's full warhead damage. Two attacks are made with one half damage, four attacks with one quarter damage etc. This division continues while the damage is higher than 1 point of warhead strength. Each of these attacks can also hit multiple smaller targets, such as infantry. The number of sub-attacks is equal to 50 / target size.

This means that a single 8 point missile warhead targeted on infantry will make 15 attacks (1 + 2 + 4 + 8) and each attack will be directed against 10 units, for a total of 150 infantry attacked. However, bear in mind that if the infantry are fortified normally that will reduce the normal 100% chance to hit by a third. If they have help from construction units and are in difficult terrain such as mountains, the chance to hit could be much lower so many of them could survive the attack. Missiles also cause environmental damage so if you plan to use the planet afterwards, this may not be the best approach.

The ground combat damage for an naval weapon is equal to 20x the square root of the damage at the same range in ship-to-ship combat. Armour penetration is equal to half the that 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, 30/60 for a 9-point missile warhead, 40/80 for a 25cm laser. Weapons roll for failure in the same way as in naval combat.

Any weapon used for NBG has the same environmental impact as it would for planetary bombardment. 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 and have no effect on radiation.

Each NBG shot has a one third chance to also strike the population itself, inflicting installation damage and population losses accordingly (see Planetary Bombardment link above for details). Conversely, each energy weapon or missile used for general Planetary Bombardment attack has a one third chance to also attack any ground forces on the planet (using the above rules), regardless of whether those ground forces have been detected. Note that all the to hit modifiers vs ground still apply so the chance of accidentally hitting any ground unit with an energy weapon for example is still very low.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 26, 2018, 10:19:50 AM
Jump Drive Size Requirements

When using a jump drive to open a jump point for other ships, the only requirement is that the jump drive capacity is large enough for the transiting ship. There is no requirement in C# Aurora for ship mounting the jump drive to be as large as the transiting ship.

Relatively small jump tenders or bases will now be able to open a jump point for much larger ships.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 28, 2018, 10:31:27 AM
Meson Update

Mesons have the following changes for C# Aurora:

1) Their cost is based on the same principles as a laser, so mesons will cost the same as an equivalent laser of the same tech level.
2) Mesons penetrate shields as before but their ability to penetrate armour is now limited.
3) A new tech line exists, Meson Armour Retardation, which is the chance for each layer of armour to stop the meson. This starts at 50%, then 40%, 32%, etc. finishing at 7% for TL 12
4) If armour does stop the meson, it scores 1 point of damage on the armour.
5) If the meson hits a damaged armour location, it only has to penetrate the remaining armour in that location.
6) Mesons will destroy missiles without penalty, as missiles are no longer armoured in C# Aurora.

As with everything else, these changes are subject to play test.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 28, 2018, 12:16:27 PM
Shock Damage Update

The recent debate on mesons highlighted some issues with Shock damage at higher levels. Therefore Shock Damage in C# Aurora will operate as follows:

1) The chance of shock damage is equal to: Damage Caused to armour / Size of Ship in HS. For example a 9 point warhead vs a 6000 ton ship has a 7.5% chance of shock damage. A 16 point energy impact vs 10,000 ton ship has an 8% chance of shock damage.
2) Any damage with less than a 5% chance is ignored as too small  (i.e. any damage where the strength is less than 5% of the ship HS)
3) If shock damage occurs, the shock damage is rolled randomly up to 20% of armour damage

Where the armour damage is easily divisible by 5, for example a 15 point warhead, there is a random roll from 1 to max shock damage (1-3 in this case). Where the armour damage is not divisible by 5, the max shock damage is the amount divisible by 5 (rounded) down plus a percentage chance of an extra 1 max shock damage equal to the percentage of 5 remaining. For example, a 12 point warhead would be assigned 2 max shock damage approximately 60% of the time and 3 max shock damage 40% of the time.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 30, 2018, 08:24:15 AM
Boarding Combat

Boarding combat in C# Aurora is similar in principle to VB6 Aurora with some adjustments for the new ground combat mechanics. The boarding attempt process is as follows:
Once on the target ships, the surviving attackers will move inside if there is a hole in the armour. If there is no hole, the boarders will use a breaching charge to destroy one armour at the weakest point every thirty seconds until they gain access.

Once inside the target ship, a boarding combat round is conducted every sixty seconds. This is very similar in principle to ground combat, albeit without support artillery, aircraft, etc. and with no concept of front-live vs rear. There is no 'fortification' in the ground combat sense, but the defenders are given a fortification level of 2 to simulate the advantages of defence within the ship. Also, because this is a confined space and there are likely to be fragments of formations, each individual unit on each side randomly selects a target formation element on the opposing side, using a weighted random selection based on size, and conducts an attack using the normal ground combat procedure:

The commanders of each formation provide a bonus to hit with their Ground Combat Offence bonus and provide a bonus to fortification (base fortification is 1 on attack and 2 on defence) with their Ground Combat Defence bonus. Any units on either side with 'Boarding Combat' capability have double the normal chance to hit.

For the purposes of boarding combat, the crew is a temporary formation with a single element composed of 'crew' ground units and a morale equal to the current crew morale. A crew member is equipped with light personal weapons and has 'armour' equal to half the lowest racial armour for infantry. Casualties in this temporary formation translate into crew losses and morale losses translate into the same impact on crew morale. Given that the crew is not well equipped for a fight of this type, it would advisable for ships to carry a small marine detachment if there is a chance they may face boarding attacks. If the target ship is a carrier, formations based on parasite ships will fight to protect the mothership.

If all the defending units are killed, the ship is transferred to the new owners (I may also add some surrender rules so you don't need to kill all the crew). To simulate the difficulties in making use of a captured ship, especially as the defenders have no doubt locked out the controls and sabotaged whatever they can, the captured ship is treated as if it just abandoned an overhaul and is given an overhaul factor of 0.01:  http://aurora2.pentarch.org/index.php?topic=8495.msg111157#msg111157

If a ship is captured, the associated Alien Class is updated with complete information.

Collateral damage can occur during boarding combat using the same rules as for ground-based collateral damage. All the damage is applied to the ship as a single internal hit. Because of the relatively small-scale of shipboard combat, any fractional points of collateral damage have a percentage chance of becoming full points equal to (fractional damage / 1). Damage to transport bays due to collateral damage will not kill defending troops (as they are fighting on the ship and not located in the bay).

If a ship is struck by external damage during boarding combat and one or more components are destroyed, there may be casualties among the boarding combatants on both sides. The damage to each engaged element is equal to:
(destroyed component size / ship size) * (0.25 + (Random(10) * 0.05))

The random roll is made for each element separately.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 05, 2019, 01:15:15 PM
Maximum Engine Power Modifier

The research costs for the Maximum Engine Power Modifier line of technology have all been halved. The Minimum Power Modifier line of technology remains at the VB6 research costs.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 06, 2019, 08:05:00 AM
Ruins in Sol

There is a very small chance that one of the larger bodies in Sol may have alien ruins. This can happen on Mars, Mercury, the Galilean Moons, Titan, Triton, Pluto or Eris. This is only about 5% for Mars, 3% for Mercury, 1% for Titan or Ganymede and fractions of a percent for the others.

I wasn't going to mention it but I just found ruins on Mercury in the 3rd test game :)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 11, 2019, 11:18:34 AM
Genetically Enhanced Soldiers

Infantry units can be given capabilities, known as Genetic Enhancement, which increase their hit points and make them more resistant to damage. So far there are three options:

Basic Genetic Enhancement: RP 5,000, HP x 1.25,  Cost x 1.5
Improved Genetic Enhancement: RP 10,000, HP x 1.6,  Cost x 2.0
Advanced Genetic Enhancement: RP 20,000, HP x 2,  Cost x 2.5

Once researched, the new capabilities can by chosen from the available capabilities list during ground combat design. These are all Biology/Genetics techs and the first in the sequence can be researched following Genome Sequence Research

The above may change as a result of testing and I may add other enhancement options
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 27, 2019, 03:42:02 PM
Shipyard Worker Requirements

Shipyards in VB6 require one million workers as a base, plus 100 workers for each ton of capacity in naval shipyards and 10 workers for each ton of capacity in commercial shipyards.

For C#, the base requirement is removed. Instead, naval shipyards will require 250 workers for each ton of capacity and commercial shipyards will require 25 workers for each ton of capacity. This is intended to bring shipyards in line with other major industry sectors such as construction factories, mines and research facilities

As an example, here are the shipyards from my current test campaign with the old and new requirements:

(http://www.pentarch.org/steve/Screenshots/SYWorkers.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 30, 2019, 05:51:43 PM
Wealth Generation

In VB6 wealth generation is based on total population. Therefore some real-world nations with large populations (which I use in multi-race starts), generate a lot of excess wealth, even though in reality their wealth output is more in line with their industrial output. India is a good example of this situation. VB6 tries to solve this by having an option to set lower starting wealth per capita for a nation. However, that penalises the race throughout the whole game. In addition, conventional starts generate huge wealth excess as the population is initially producing wealth with minimal industry to consume it.

For C# Aurora, wealth is produced only by workers in TN installations, simulating that wealth is more closely tied to industrial potential than total population. Each 1 million workers produces a baseline 100 wealth per annum, although this can be improved by a new Wealth Generation tech line that replaces the VB6 Civilian Economy tech. This wealth is generated regardless of whether the installation to which the workers are assigned is currently building or producing anything. Wealth Generation tech starts with 120 wealth per million workers for 3000 RP, then 140 for 5000 RP, etc.. Workers in Conventional Factories and Forced Labour Camps do not produce wealth.

Financial Centres generate additional wealth equal to the tax from 250,000 workers (I may adjust this based on play test). Financial Centres can be transported to other colonies (unlike VB6). In addition to their other output, Conventional Factories function as 1/10th of a Financial Centre. Conventional Factories can be converted to Financial Centres at a cost of 20 BP, using 10 Corbomite and 10 Uridium. It is also worth noting here that tax generation from shipping lines has been doubled for C# Aurora.

The C# method has a few advantages over the VB6 method:

1) High population, low industry nations are now easy to handle as most of the population does not generate wealth (it is assumed that the wealth from agriculture and service is used to cover welfare, health, education, etc. with a net wealth of zero).
2) Conventional starts do not generate huge excess wealth
3) As a nation industrialises, its wealth generation capability grows naturally, which reflects historical trends.
4) The planned wealth reserve cap can be removed.
5) Financial centres grow in importance and have more of a wealth impact (in relative terms) compared to VB6.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 08, 2019, 11:45:43 AM
Fuel Storage Costs

I've realised that fuel storage is very expensive in Aurora compared to other 'storage' modules. In terms of cost per HS they are more expensive than hangars or magazines, three times as expensive as cryo, seven times as expensive as troop transport bays and sixty times more expensive than cargo bays. They are also about six times more expensive than most productive modules (Terraform, Salvage, Harvester, Jump Point Stabilisation, etc.). BTW I realised this by wondering why a tanker was taking so long to build. The reason was that because build time is based on cost but modified by size, high 'cost density' ships take a long time and that was greatly exacerbated by the fuel storage.

On that basis, I am reducing the cost of fuel storage considerably for C# Aurora, although it is staggered so the cost benefit of larger modules is improved.

Fuel Storage - Tiny: 5,000 litres, 0.5 BP
Fuel Storage - Small: 10,000 litres, 0.8 BP
Fuel Storage - Standard: 50,000 litres, 2 BP
Fuel Storage - Large: 250,000 litres, 5 BP
Fuel Storage - Very Large: 1,000,000 litres, 10 BP
Fuel Storage - Ultra Large: 5,000,000 litres, 25 BP
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 02, 2019, 11:10:03 AM
Starting Financial Centres

New Trans-Newtonian Races will start with a number of financial centres equal to one quarter of the number of construction factories.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 02, 2019, 11:16:56 AM
Manufacturing Sector

The maximum service sector size has been reduced from 75% to 70%. The effect of this is an increase in the manufacturing population by 5% of total population. For a population on a colony cost zero world with max service sector (a home world for example), the manufacturing sector will be 25% of population, rather than 20%.

This change is because of the increased worker requirements for shipyards, plus the increased need for financial centres and maintenance facilities. I considered lowering the starting numbers of factories, but decided to maintain the existing balance and free up more population instead. Otherwise, the standard start will generally have a manufacturing efficiency problem.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 05, 2019, 05:49:34 PM
Ship Commander Rank

The required rank of a ship commander is set automatically by Aurora and will be the lowest race rank, unless one of the following component rules is activated. Component rules are not cumulative so only the highest requirement applies.

If a ship is greater than 1000 tons and has any of the following component, the required rank is lowest rank + 1: Weapons, survey sensors, a jump drive, a hangar deck.
If a ship has any of the following component, the required rank is lowest rank + 1: Auxiliary Control, Science Department, Primary Flight Control.
If a ship has any of the following component, the required rank is lowest rank + 2: Main Engineering, CIC, Flag Bridge.

The Class Window has a checkbox entitled Senior C.O. If this is checked, the class will have a required rank one higher than the above rules require (to allow the player to designate certain classes as worthy of a more senior officer than normal).

The rule is an enhancement to the command and control rules: http://aurora2.pentarch.org/index.php?topic=8495.msg101818#msg101818
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 12, 2019, 04:30:48 PM
Ship Thermal Signature

In VB6 Aurora, a ship always has its maximum thermal signature even when not moving. The fleet can be set to a lower speed if desired, which reduces the signature, but that isn't directly related to movement. As it doesn't seem realistic that a stationary ship and one moving at full speed should have the same thermal signature, C# Aurora will handle thermal signatures in the following way:

If a fleet has movement orders, each ship in that fleet has a thermal signature equal to: (current speed / max speed) * max thermal signature (the same as VB6).  This applies regardless of whether the order involves a change in position, so a freighter in transit and one loading cargo are both 'moving'. 

A ship in a fleet without orders has a baseline thermal output equal to 5% of its size in hull spaces (or 0.1% of its size in tons). For example, a 10,000 ton ship without orders would have a thermal signature of 10 (200 HS x 5%). There is no distinction for commercial shipping on the basis that some commercial functions (mining, terraforming, harvesters) would generate heat and even freighters would have less thermal shielding than similar size warships. The minimum thermal signature for a ship with movement orders is also the base thermal output.

This has significant implications for scouting, as passive sensors will now only detect large stationary alien warships from a relatively short range.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 16, 2019, 03:27:36 PM
Jump Point Transit Shock

When a ship transits a jump point, it will suffer jump shock. This temporarily disables active sensors, fire control systems and jump drives.

A ship making a standard transit will suffer a delay equal to: (120 seconds + Random 1 to 60 seconds) * Ship Bonus.
A ship making a squadron transit will suffer a delay equal to: (20 seconds + Random 1 to 10 seconds) * Ship Bonus.

The ship bonus is equal to: 2 - ((1 + Crew Grade) * Morale * Overhaul Factor).

For example, if a ship has 100% morale, an overhaul factor of 1 (which is normal) and crew grade of 10%, the ship bonus would be (2 - (1.1 * 1 * 1) = 0.9. So any delay would be multipled by 90%.

The length of jump shock for NPRs is halved. This is to compensate for the fact that humans can make much better decisions in this situation, in particular with regard to ensuring the right mix of jump ships and warships is available in the right place at the right time to take advantage of squadron transits. If I get around to coding more detailed strategic decision-making in this situation for NPRs (not a priority for V1), I'll make them the same as player races.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 24, 2019, 12:24:20 PM
Fleet Order Templates

When a fleet is given a set of orders on the Naval Organization window, those orders can be saved as an 'Order Template'. This is as simple as clicking the Save Template button and typing a name into a popup box.

When the Order Templates option is chosen in the top left of the Movement Orders tab, all Order templates that start in the same system as the currently selected fleet are displayed (see first screenshot). To use a template, select it from the list and click Add Move. All the orders are created accordingly (see second screenshot). This is similar to the same functionality in VB6 but the UI allows a lot more templates to be easily accessible.

Templates can be deleted with the Delete Template button.

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

(http://www.pentarch.org/steve/Screenshots/Templates002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 24, 2019, 12:37:13 PM
Commander Name Themes

C# Aurora allows a Race to have an unlimited number of Commander Name Themes. This is handled on the Race window.

When a Race is created, a single theme is selected as part of the creation process. Unless the player makes changes, 100% of commanders will use this initial theme. The player can choose additional themes, assigning each one a weight. When a new commander is generated, the name will be randomly assigned a theme based on the weight of each theme.

The first screenshot shows a race with a single commander name theme. The second shows the same race with multiple additional themes. The top left section of the Race window shows the main theme (the greatest weight) plus the number of additional themes.

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

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

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 30, 2019, 04:41:43 PM
Missile Engines Integrated into Missile Design

In VB6, you research missile engines first and then use that engine within a missile design. This can be tedious, especially if you are not sure exactly what engine size you need. Therefore, for C# the missile engine design has been removed from the Create Research Project window and integrated directly into the Missile Design window.

The best engine and fuel efficiency tech will automatically be used, so the player decides on the engine size and power boost. The engine design takes place behind the scenes and is confirmed when you design the missile. This means you can play around with the engine design and missile design at the same time. See first screenshot below.

If no engine is required, just tick the No Engine option. See second screenshot.

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

(http://www.pentarch.org/steve/Screenshots/MissileDesign002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 25, 2019, 10:55:42 AM
Potential Colony Locations

VB6 Aurora has a window entitled Available Colony Analysis, which is used to search for new colony sites.

In C# Aurora, this function has been built into the System View window. If you click the 'All System View' button, the Stars section is replaced with search filters. Several areas that are not required in this mode, such as the jump point list, are hidden from view. The All System View button changes to the Normal View button, which will return you to the standard single system view.

While in the All System Mode, you can narrow the search for potential colony sites across all systems while retaining all the functionality of the system view window.

For example, here the Jovian Federation is looking for worlds with a colony cost of 4 or less that have minerals present. The results are sorted by Colony Cost and then Hydro Extent descending. The Federation has yet to develop jump tech so all the bodies are from the Sol system.

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

The second screen shot is from my previous campaign and shows a search for worlds with acceptable gravity, oxygen present, not in an alien-controlled system, below a colony cost of 4, with a pop capacity of at least one million and that have minerals present. This is sorted by colony cost and size of mineral deposits.

(http://www.pentarch.org/steve/Screenshots/SystemBodySearch002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on May 28, 2019, 06:39:07 PM
Race Comparison Window

C# has a comparison window that allows you to see a high level comparison between different Races. It is simple and read-only, but useful for a high-level overview.

The window expands to the number of player races in the game. I may also add some additional comparison information over time.

(http://www.pentarch.org/steve/Screenshots/RaceComparison001.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 15, 2019, 11:21:13 AM
New Spoiler Race

C# introduces a new optional spoiler race - the Rakhas.

The Rakhas are the remnants of an ancient civilisation that once had colonies across the galaxy. Their populations were virtually wiped out and the tiny number of survivors have regressed to a primitive, tribal lifestyle, although they retain some elements of Trans-Newtonian technology. The Rakhas have no ships and are confined to planetary surfaces, with each remnant colony effectively a different race with potentially different levels of technology. These populations consist only of ground forces with no 'civilian' population and due to the ancient history of alien invasion the Rakhas will resist any invader. The Rakhas are large, heavily-muscled humanoids with skin colouration ranging from green to grey.

Their surviving technology is sufficient for Trans-Newtonian infantry and mechanised forces. Some Rakhas tribes will also retain STO weapons. The ancient Rakhas experimented with genetic modification during their final wars, so some tribes will retain genetic advantages for combat and all tribes will be familiar with warfare in the dominant terrain of their home world (desert fighting, jungle fighting, etc).

The Rakhas have wider environmental tolerances than humans and their colonies were generally created on worlds with large quantities of accessible TN mineral deposits. Therefore, the remnant tribes will usually be encountered on worlds with oxygen atmospheres that posses multiple accessible mineral deposits. There is a small chance that a tribe may have survived on a hostile world.

Orbital bombardment is an option to wipe out the Rakhas, although as the planets that Rakhas tribes inhabit will generally be valuable in terms of habitability and resources, any attacker may wish to avoid catastrophic damage to the environment.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 23, 2019, 11:50:48 AM
Automated Medal Awards

In terms of basic concept, Medals in C# have a similar function to VB6. You can create a medal with a name and description, associate a medal image and assign a promotion score boost (or penalty). You can assign that medal as desired to different officers for role-playing reasons. A minor addition for C# is that you can flag a medal as allowing only a single award, or allowing multiple awards.

The major change for C# is that medals can now be assigned automatically. A lengthy default list of conditions for medal awards will be available and, within the constraints of the available measurement types, additional conditions can be added. Medals can be associated with one or more conditions and the medal will be awarded if a commander meets one of those conditions (unless it is a single-award only and the commander already has it).

This first screenshot shows the Medal Window, with the first medal on the list selected. At the bottom of the window are options for changing text or image, setting promotion score and the multiple award flag and adding/removing conditions for the medal.

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

The second screenshot shows a list of available conditions. This is only an initial list to show examples of what is possible. All these conditions are already working. I will also add to this window the ability to create new conditions. They will have to use one of the existing measurement types, but you can choose different measurement amounts. This thread is open for suggestions of different measurement types: http://aurora2.pentarch.org/index.php?topic=10435.0

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

The third screenshot shows the commander window with medals awarded. A major side-benefit of the medals code is that each commander will now display a list of every measurement type where he has activity (panel in top middle-left). This screenshot is using random data, so it doesn't match the medal assignments on the previous screenshots.

The medal images are from VB6 so I think I need some updated ones, preferably in PNG format with transparent backgrounds.

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



Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 23, 2019, 12:41:58 PM
Human NPRs

C# has a new option for NPR generation called Human NPRs. If this option is selected, when a NPR is generated (except for Starting NPRs) there is a one-third chance that a check is made to see if the NPR is 'human'. 'Human' in this context is the species of the oldest population of the oldest player race. This is because you may want to play as a non-human race, or modified human race, and still retain the option of your species appearing as an NPR.

If the check is made and the system body is capable of supporting humans, then the species of the new NPR will be human. Human NPRs will generally be smaller (on average about half the size) of normal NPRs. You also gain +20 to communication checks when two races have the same primary species.

This option is to allow a campaign taking place in the aftermath of the collapse of a large human Empire. As the Empire, or one of its major populations, expands once again, human remnant populations may still be found in distant systems.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 25, 2019, 05:46:20 AM
Manual Medal Awards

The previous post on medals covered automated medal assignment. This covers manual awards, for which there are two options:

1) An award to an individual commander on the Commanders window using the Award Medal button (as per VB6).
2) Mass Awards to large numbers of commanders at once, primarily for the purposes of 'Campaign Medals'.

On the Fleet window, you can select a Ship, a Sub-Fleet, a Fleet or a Naval Admin Command and click Award Medal. The following window pops up:

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

You choose the medal and the type of command positions to which the medal will be awarded. Every commander with a command included in the selected types that is on a ship included in the selected organisation will be awarded the selected medal. This would include commanders of any ground formations present on the ships if that command type is selected. If a fleet is selected, all ships in the fleet are included, including any in sub-fleets. If an Admin Command is selected, every ship in the complete hierarchy of that Admin Command will be selected. Mass Awards use a confirmation popup after you close the Medal Award window, as a mistaken mass award would require some sorting out :)

On the Naval Forces window of the Galactic Map there is an Award Medal button. This will pop up the same Award Medal window. The selected medal will be awarded to every commander with one of the selected command types in the system currently selected on the Galactic map, including commanders of ground formations at populations in the system if that command type is selected.

On the Ground Forces window in the Order of Battle tab are two new buttons; Formation Medal and Hierarchy Medal. Formation Medal functions in a similar way to the Award Medal on the Commander window. The medal is awarded to the single commander of the currently selected formation. Hierarchy Medal is a Mass Award option with two functions, depending on whether a formation or a population is selected. When a formation is selected, the mass award is to all commanders in the downward hierarchy of the currently selected formation, included the commander of the selected formation. When a population is selected the mass award is to the commanders of all formations at that population.

When awarded medals manually, a popup box will appear after the medal is chosen, allowing you to enter an optional medal citation. This citation will appear if you mouse-over the medal in the commander view.

This new Mass Award option should result in a much more visual history of different commanders with the display of their various campaign medals.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on June 26, 2019, 02:13:54 PM
Mining Company Names

This is only a 'miner' cosmetic change :)

When civilian mining companies are created, they will be given a company name which will become the population name. This is similar to shipyard naming using a family name from the racial naming theme plus a 'company name' such as Smith Minerals & Ores or Jones Resources Group. This is purely cosmetic and has no game play impact, but serves to differentiate the civilian mining outposts.

Note that this doesn't rename the system body. Population and system body names are separate in C# Aurora, so you can still create your own population with a different name on the same system body. The Economics window already has an option to show both system body name and pop name if they are different so you can still see the locations if desired.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 14, 2019, 06:45:18 AM
System OOB

Another cosmetic change. A new tab on the Fleet window lists your forces by system in text format. This is intended partially as a quick reference but mainly to allow easy posting of current deployments into an AAR. Any military ships over 1000 tons have their names listed. I'll probably create some options in the future for more flexibility on what is displayed.

(http://www.pentarch.org/steve/Screenshots/Crusade/SystemOOB.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 16, 2019, 12:21:44 PM
Adding Your Own Naming Themes

Adding your own naming themes is very simple in C# Aurora.

1) Create a text file with one name per line.
2) Click the button shown below
3) Enter the theme name in an input field that pops up
4) Select the file using a standard windows file dialog box.

The name theme is added to the database for the current game and all future games.

(http://www.pentarch.org/steve/Screenshots/EnterTheme.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 17, 2019, 11:42:54 AM
Survey Site List

Given the number of potential ground survey sites, it could be difficult to keep track. Therefore I have added a new tab to the tactical map that contains a list of current known sites.

(http://www.pentarch.org/steve/Screenshots/SurveySites.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 20, 2019, 08:23:28 AM
Logistics Reports

A new Logistics Report tab on the Fleet window lists all relevant ships for each of five categories. Fuel, Maintenance Supply Point, Ordnance, Deployment Time (for crew) and Time Since Overhaul. A dropdown is used to select each category and the ships are sorted by those most affected in the selected category. Screenshots below show examples for four of those categories. MSP is very similar to fuel.

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

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

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

(http://www.pentarch.org/steve/Screenshots/LogisticsReport_Deployment.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on July 27, 2019, 09:46:19 AM
Ship Ordnance Templates

In VB6, you can set an ordnance template for each class. When a ship loads ordnance it will load ordnance based on that parent class template.

For C#, you can create optional ship ordnance templates. If a template is created at the individual ship level, it will override the parent class template when the ship loads ordnance. If there is no template at the ship level, the parent class template will be used.

A new tab on the Ship section of the Naval Organization window shows the class and ship ordnance templates for each ship, plus the current actual loadout for the ship. This tab can be used to change the ship ordnance template in a similar way to setting the class ordnance template on the Class window. You can copy the existing class ordnance template into the ship template if you only want to make minor changes. You can rename and obsolete missiles from this tab.

The first screenshot shows a ship with a class template, but no ship template. The second screenshot shows a recon-focused ship ordnance template.

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

(http://www.pentarch.org/steve/Screenshots/ShipTemplate002.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 07, 2019, 10:22:22 AM
Tracking Time Bonus vs Missiles

Energy weapons and beam fire controls engaging missiles can gain a bonus to their tracking speed based on how long the missile has been on active sensors. Similar functionality was added to VB6 but is not working. The benefit of this has been toned down a little from the planned functionality in VB6 as fuel considerations in C# will reduce the max boost used for anti-ship missiles and avoid the late game missile speed vs tracking speed disparity.

The gain in tracking speed is equal to one percent for every five seconds a missile is continually tracked by active sensors. This is subject to a maximum time based on the associated tracking time tech. The starting tech costs 1000 RP and adds tracking bonus for the first 30 seconds. The tech name format is: Max Tracking Time for Bonus vs Missiles: 30 Seconds (6%)

This time increases with subsequent tech to 45, 60, 80, 120, 160, 200, 250, 320 and 400. Each tech is approximately double the cost of the previous one.

Note this is a bonus to tracking speed, not the base to-hit chance. If the tracking speed is already higher than the missile speed, this bonus will not improve the chance to hit.

I considered adding this to all energy-weapon fire for consistency, but decided it was reasonable to keep it to missiles only, given their more predictable courses.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 10, 2019, 08:48:03 AM
Tactical Map Popup Menu

When you right-click on the tactical map, any fleets, population or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 12, 2019, 12:23:41 PM
Naming Options for Ships

In C# you can choose a naming theme for all the ships of a certain class, just as you can in VB6. C# also adds some new options.

You can choose for each class whether you want the names from the theme to be selected in order or selected randomly.

Each class has Prefix and Suffix name options. I'll steal Father Tim's example from the suggestion he made: Wind-class destroyers could be auto-named Arctic Wind, Bitter Wind, Cold Wind, Desert Wind, or Dragon-class carriers could be auto-named Red Dragon, Night Dragon, Gold Dragon, Shadow Dragon, etc.. So if you create a Colours naming theme for example, you can apply it to many different classes but with a different prefix or suffix.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 17, 2019, 06:20:12 AM
Final Defensive Fire Changes

In VB6 Aurora, a fire control can only fire at a single target in any increment. For C# Aurora, an exception is made for fire controls firing in automatic final defensive fire mode.

A fire control in this mode will continue to fire on incoming salvos as long as it has unfired weapons remaining. Each individual weapon or turret will only be able to engage a single salvo. This means point defence ships no longer need a large number of fire control systems, although there is still a design choice in terms of redundancy.

In VB6 Aurora, missiles moved in descending order of speed. I've updated that for C# Aurora to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first (and be engaged first by final defensive fire).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 21, 2019, 03:02:12 AM
Save Button

C# Aurora doesn't continually update to disk in the same way as VB6 Aurora, which is one of the reasons why it is much faster. Instead, there is a Save Button.

When you click Save, the database prior to the save is copied to a new file called AuroraDBSaveBackup.db and then the AuroraDB file is updated with the current game. The previous AuroraDBSaveBackup.db is copied to a file called AuroraDBPreviousSaveBackup.db, so you have automatic backups of your last two saves. To restore a previous save, you need to delete AuroraDB.db rename the backup file to AuroraDB.db.

If you close without saving then your game will revert to the last save. Saving takes about thirty seconds.

This has been part of C# Aurora from the start, but it was brought to my attention in another thread that I hadn't 'officially' mentioned this
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 21, 2019, 09:05:44 AM
Surrender

An AI fleet may surrender to the enemy in certain circumstances. Generally, the fleet will have to be unarmed, badly damaged or not capable of fulfilling its mission and also be under attack from energy weapons.

In that situation, the fleet may try to evade, it may surrender or it may attempt to ram. The chances of each will depend on the Determination and Xenophobia of the crews. Certain spoiler races will not surrender.

When a ship surrenders the Overhaul Factor is set to 0.01, the same as a ship captured by boarding.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 25, 2019, 06:40:31 AM
Auto Refit Tasks

A new shipyard task has been added for C# Aurora, the Auto-Refit.

This is exactly the same as a Refit Task except for one difference. When the task is finished, the shipyard will automatically start a new refit task using the same target class. For example, if you auto-refit Class A to Class B, when the task is finished the shipyard will check for another Class A in the same location to refit. If one is found, the shipyard will automatically create the task.

You can refit fighters in shipyards in C#, so this new task will remove a lot of micromanagement that would otherwise be necessary.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 28, 2019, 08:15:24 AM
Alien Ground Unit Intelligence

As you fight alien ground forces, you will gain intelligence on the alien ground unit classes. This intelligence is displayed on the Diplomacy and Intelligence window alongside intelligence on alien ships, classes, sensors and populations.

For each different type of ground unit class you engage, you may gain intelligence if you have your own ground forces on the same ship or system body. New intelligence is gained under the following circumstances.

I might change the 20x multiplier based on play testing.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 29, 2019, 06:25:00 PM
Ground Combat Events

Ground combat in C# is very detailed with many things happening in each combat round. There are a number of new events at varying levels of detail to serve as combat reports. Note that a formation (such as an Imperial Guard Regiment) consists of several formation elements, each containing one or more units of a single ground unit class.
There may be other events as a result of more play-testing. The above may be too granular for some players so you can filter out the events you don't want to see, or you can see very granular detail for role-playing and AAR purposes.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on August 30, 2019, 10:35:29 AM
Change to Maintenance Facility Cost

Because of the changes to maintenance in C#, maintenance facilities have become much more important for two reasons:

1) You can no longer use the same maintenance facilities to support multiple ships, so you need far more maintenance facilities in general. For example, if you build a 20,000 ton ship, you also need 20,000 tons of extra maintenance facility capacity to support it.
2) The only source of maintenance supply points is from maintenance facilities as you can no longer build them with construction factories.

Because of the above, the cost of maintenance facilities has been reduced to 60 BP. They remain the same in other aspects, such as transport size, manning requirements, target size, etc.

Note: In general I am very happy with the maintenance changes. They allow you to setup distant bases capable of handling larger ships much more easily and, together with the new shipyard worker requirements and the need for more financial centres, they are putting much more pressure on the number of available workers.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 01, 2019, 09:32:45 AM
Create New Lagrange Points

Ships designed for jump point stabilisation (creating jump gates in VB6) can also stabilise new Lagrange points.

Any planet with a mass of at least 150 will already have a stable Lagrange point that allows any numbers of ships to jump to other stable Lagrange points. Planets less than 150 mass also have Lagrange points but they are not stable and therefore not visible on the map. A ship with a stabilisation module can stabilise these Lagrange points so that all ships can use them. It is much easier to stabilise high mass planets, so gas giants are commonly used for this purpose, but it is possible even for larger terrestrial worlds given sufficient time. It is not possible to stabilise the Lagrange point of a planet with less than 0.25 mass.

The time in months required to stabilise a Lagrange point for a given planet is equal to: 60 / SQRT (Planet Mass). The production bonus of the ship commander will reduce this time.

For the solar system:
Jupiter has a mass of 317 so it already has a stable Lagrange point.
Saturn has a mass of 95 and would require six months.
Uranus has a mass of 14 and would require 1.3 years.
Neptune has a mass of 17 and would require 1.2 years.
Earth has a mass of 1 and would require 5 years.
Venus has a mass of 0.82 and would require 5.5 years.

Mars has a mass of 0.11 and Mercury has a mass of 0.055 so they are too small.

A new 'Stabilise Lagrange Point' order is available for planets where stabilisation is possible. The stabilisation ship remains at the associated planet while the task is carried out. Apart from the location and different required time, this is very similar to a jump point stabilisation task.

The time required for any given planet can be found on the System View in the very last column (you will need to scroll right).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 14, 2019, 08:27:05 AM
Minerals for Maintenance Supplies

One of the major practical game play changes I have found through play-testing C# Aurora is the ease with which new naval bases can be created (because of the new maintenance system).

However, that brings a new issue. As you can no longer build MSP using construction factories in C#, you need to make full use of the MSP production of maintenance facilities or you start to run out of MSP (which is happening to me now because I am not doing that). The reason I am struggling to build MSP at the new bases is that MSP require eight different minerals. 1 MSP costs 0.25 BP and requires the following minerals (in tons): Duranium 0.05, Neutronium 0.025, Tritanium 0.025, Boronide 0.025, Mercassium 0.025, Uridium 0.025, Corundium 0.025, Gallicite 0.05. There is a lot of micromanagement required in either mining those minerals locally or moving them manually (and I keep forgetting which eight minerals :) ).

Therefore, for game play reasons and my own sanity I've decided to reduce the number of minerals required. I summed all ship components subject to maintenance for all military ships in my current game (including AI) to determine the most common minerals. Duranium and Gallicite were about the same, Uridium was about half of those and everything else was much lower, around one sixth or less of Duranium. Therefore I am going to change MSP minerals to Duranium 0.1, Uridium 0.05, Gallicite 0.1. That is much easier to remember and more reflective of reality. While that does increase overall Duranium consumption a little, I have also changed some buildings to use less Duranium, which I will post about separately.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on September 14, 2019, 08:42:24 AM
Planetary Installations

There are a few additions and changes for planetary installations, including changes to mineral requirements. Here is a table of the current situation.

(http://www.pentarch.org/steve/Screenshots/Installations.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 04, 2019, 05:35:37 PM
Salvage in Orbit

When a wreck is salvaged in VB6, the recovered minerals and components so to freighters in the same fleet as the salvage ship.

In C#, the same is true. However, if the wreck is in orbit of a population from the same race as the salvage ship, there are no freighters available and either a ship in the salvage fleet or the population has cargo shuttles, the recovered minerals and components are added to the population stockpile.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on November 24, 2019, 06:44:50 AM
Interrupts for Active Weapons

In VB6, the game interrupts if you have weapons set to fire and no valid targets. It also interrupts when recharging is complete for weapons set to fire, even if nothing is in range.

For C#, the game checks to see if the target exists and is in range for each individual fire control. If not, there is no interrupt. Instead, you get a single event message per ship stating that ship is trying to fire on a target that is out of range or doesn't exist but the increment otherwise happens normally. This means you can set all your weapons up and assign targets while well out of range. Increments will proceed normally until you are within range, at which point the weapons will start firing.

Once in range, the recharge interrupts will happen (so if your weapons have a 40 second cycle time you can just hit 2 minutes and time will advance 40 seconds).

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 08, 2019, 04:27:53 PM
Launch Ready Ordnance

You can use the Launch Ready Ordnance order at any movement destination, including a waypoint. Any ordnance assigned to a missile launcher that is assigned to a fire control will be launched at that point. The fire control does not need to be set to 'fire'. The missile will be launched without an assigned target.

This is useful for deploying buoys or mines or just launching missiles without a known target.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 16, 2019, 11:33:47 AM
Refit Size

The 'size difference' element of refit cost has changed for C# Aurora. In C#, the size difference acts as a modifier to the refit cost, rather than as a standalone cost.

In VB6 the size element cost is: ABS(Current HS - Refit HS) * 5.

For C# the size element cost is: (ABS(Current HS - Refit HS) / Current HS) * Refit Cost.

While this change is more realistic in general, it can lead to some weird situations where the refit cost from a large ship to a small ship is relatively low because the small ship is a version of the large ship with systems removed and no other changes. Therefore, C# adds a new restriction that you cannot refit to a design that is more than 20% smaller or 20% larger than the existing design. This also avoids cluttering the 'Refit from' dropdown when you have a lot of classes.

This change affects what can be built in shipyards. As in VB6, you can build the class for which the shipyard is tooled, or any other class to which the build class can be refitted for less than 20% of its cost. The new size restriction will prevent some classes from being eligible in this situation.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 16, 2019, 12:23:31 PM
Civilian Destinations

In VB6 Aurora, civilians will treat any population of less than 25m as an automatic destination. Once a population is above 25m, the player can choose whether the population is a destination for colonists, a source of colonists or neither.

For C#, the population level at which the player can intervene has changed to the lower of 10m or half the capacity of the system body. Since the jump point generation changes in the later versions of VB6, the universe is more 'stretched out', so populations are much slower to reach the 25m mark.

I've also changed the population at which all trade goods become available to 10m (it was 20m for five trade good types).

10m aligns with the point at which civilians will consider creating mining colonies in the same system.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 18, 2019, 08:09:27 AM
Multiple Window Instances

I'm not sure if I mentioned this anywhere so...

In C# Aurora, you can open multiple instances of each window except for the tactical map. So you can have multiple class windows, galactic map windows, fleet windows, etc.. Each time you click the Fleet window button (for example) another Fleet window opens.

This is useful for comparing classes for example. However, you can also drag and drop between two windows of the same type. For example, you could drag a ship from a fleet on one window and drop it on a fleet on a second window, or drag a ground unit from one Ground Forces windows under the hierarchy of an HQ on the second Ground Forces window.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 21, 2019, 06:20:26 AM
Populations as Text

This change is purely to aid AARs.

The Economics window has two new buttons; 'Pop as Text' and 'All Pop as Text'. Pressing the first pops up a window with a text version of the population. The text lists population amount, shipyard capacity, maintenance capacity and the number of each installation present. This is intended for copying directly into an AAR. The text is already highlighted so you just press ctrl - c to copy it. An example is shown below.

The 'All Pop as Text' button does the same, but for all populations instead of just one. This 'press a button and copy' was how I did the 'State of the Imperium' section in my last campaign post. The populations will appear in the same order as the population tree on the left of the window. If you exclude civilian colonies from the tree, they will be excluded from the text as well.

Terra
Population: 1576.67m
Naval Shipyard Capacity: 489,622 tons
Commercial Shipyard Capacity: 2,520,000 tons
Maintenance Capacity: 666,000 tons
Research Facility: 48
Ground Force Construction Complex: 9
Construction Factory: 562
Ordnance Factory: 246
Fighter Factory: 100
Mine: 104
Automated Mine: 10
Fuel Refinery: 400
Maintenance Facility: 333
Financial Centre: 132
Deep Space Tracking Station: 9
Mass Driver: 1
Military Academy: 5
Naval Headquarters: 1
Spaceport: 1
Infrastructure: 30
Low Gravity Infrastructure: 100
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 21, 2019, 07:07:43 AM
Delete Empty Colonies

With the new ground survey rules, I find I am creating colonies for the purpose of the survey and then being left with empty colonies scattered throughout the Imperium. I also have colonies that were created for various purposes but are now abandoned or never exploited.

Therefore, I have added the 'Delete Empty' button to the Economics window. This button will remove any colonies where all the following conditions are true.

There are no colonists
There are no installations
There are no abandoned installations
There are no ground forces at the colony
There is no ordnance stored at the colony
There are no components stored at the colony
There are no fleets orbiting the colony
There are no fleets with this colony as a destination
There is no ground survey potential
The colony is not exempt from deletion (see below)

A second button 'Empty Exempt' toggles a flag to prevent the colony from being deleted when the 'Delete Empty' button is pressed. The exempt status is noted on the colony summary. This is for those worlds that you do plan to exploit at some point, even though it currently meets the conditions for deletion.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 21, 2019, 12:49:55 PM
Fleet Distance and Time

When a fleet is given orders, the Naval Org window will show both the distance and time required for those orders, so you now know (for example) when vital Gallicite shipments will reach your home world. See at the top of the screenshot below.

There are a few other enhancement, such as military tonnage in the fleet (which helps with checking maintenance requirements) and total fleet cost.

(http://www.pentarch.org/steve/Screenshots/Crusade/FleetDistance.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 26, 2019, 07:52:29 AM
Fire Delay

The Fire Delay mechanic for inexperienced ships has changed for C#. The delay is about half that in VB6 and is on a bell curve. I decided to reduce the delay because it was never a major issue for long-range missile combat but it could be a very long time in energy range combat. The new mechanic reduces the delay overall and makes the maximum delay far less likely. Note that this is not the same as a jump delay, which remains the same.

A fire delay happens when a ship with less than 100% Fleet Training either opens fire or changes target. The formula is as follows:

Round ((1 - (Fleet Training Points / 500)) * (1 - Reaction Bonus) * Random(10) * Random(10) * 0.5)

For example, a ship with 20% fleet training (100 points) and a 10% reaction bonus would be: Round (0.8 * 0.9 * Random(10) * Random(10) * 0.5), which is anything from no delay to 36 seconds, with the likely outcomes in the middle of that range. 15-20 seconds for a relatively inexperienced ship is long enough to disrupt coordination in a close-range battle, but not so long it is crippling or difficult to accept in terms of reality. A ship with 100% fleet training will suffer no delay and ships with high percentages are more likely to have no delay.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 26, 2019, 07:56:39 AM
Fleets as Text

This is similar to the earlier 'Populations as Text' function. A new button on the Naval Organization window will open a window with a text version of the ships in the fleet. The text lists each ship class in the fleet with the names of each ship of that class alongside. For ships of 1000 tons or less, the number of ships is displayed, rather than the names. This is intended for copying directly into an AAR. The text is already highlighted so you just press ctrl - c to copy it. An example is shown below. I added the italics manually afterwards.

Expeditionary Fleet
Lunar III class Cruiser: Agrippa
Dictator II class Cruiser: Fortitude
Dominator class Cruiser: Ultima Praetor
Endeavour II class Light Cruiser: Endeavour, Sword of Voss
Dauntless IV class Light Cruiser: Divine Crusade, Guardian, Hammer of Truth, Vigilant
Vanguard III class Strike Cruiser: Angelic Blade, Dread Argent
Cobra III class Destroyer: Arbitrator, Omnis Arcanum
Firestorm IV class Frigate: Harrower, Just Persecution, Liberator
Sword III class Frigate: Achilles, Mariatus, Rapier
Falchion III class Jump Frigate: Scimitar
6x Thunderhawk II class Assault Transport:
16x Starhawk III class Bomber:
5x Aquila class Lander:
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on December 27, 2019, 02:56:52 PM
Ground Combat Hostile Force Intelligence

I've already posted the rules regarding how you learn about the different classes of hostile ground units: http://aurora2.pentarch.org/index.php?topic=8495.msg116121;topicseen#msg116121

This post covers intelligence regarding the size and composition of the hostile force in a given ground combat zone. After each combat round, an update is provided on the estimated hostile force. The estimate becomes more accurate as time passes. For each type of hostile ground unit om the combat zone, the following process is used:

The Intel Error Range is 200 / Number of Combat Rounds.
Intel Error is 1 + (Random (Intel Error Range) / 100);
50% of the time, the actual number of alien units is multipled by the Intel Error and 50% of the time the actual number of alien units is divided by the Intel Error.

For example, if there are 1000 units of a particular alien class, the intelligence following the second combat round could indicate between 500 and 2000 units. After 10 combat rounds, the intelligence reporting range will be 833 to 1200 units.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 02, 2020, 07:44:04 AM
Civilian Movement Restrictions

A system can be flagged as 'Military Restricted' on the Miscellaneous tab of the Galactic Map. Once flagged, civilians will avoid the system. Civilians will also avoid any system flagged as alien-controlled.

A population can be flagged as 'Military Restricted' on the Civilian Economy tab of the Galactic Map. Once flagged, civilians will avoid the population.

When a system or population is flagged as restricted, any colony ships en route will be diverted to other destinations. Freighters en route will abandon their cargo and seek new trade runs. You will receive a popup warning on that basis before confirming the new status.

N.B In the past, I have been very reluctant to have restrictions on civilians, mainly because this would allow the players to effectively exercise direct control and consequently the civilians would just become an extension of the government. For example, using the above option, you could restrict every system except the one that you would like civilians to colonise. However, there are many ways to exploit Aurora if that was the goal of the player, so I've decided to leave it to players to role-play their preferred way of handling civilians.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 04, 2020, 03:35:40 PM
Point Defence Fire Control

VB6 has a restriction that each fire control can only engage a single target during point blank fire. I've removed that restriction for C#. Each weapon can still only engage a single salvo.

In VB6, missiles moved in descending order of speed. In C# that has changed to descending order of speed then by descending order of salvo size, so the largest salvos of the same type of missile will move first. Consequently, your point defence will engage the largest salvos first.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 12, 2020, 10:05:46 AM
Tractor Any Ship

I've added a new order to "Tractor Any Ship in Fleet". A tug with this order will tractor the largest ship in the target fleet, without you having to specify the ship.

This allows you to create an order cycle to move a group of space stations (terraformers, fuel harvesters, orbital miners, etc.) from one location to another without having to specify each ship individually. With the new space station rules in C# Aurora, this will happen a lot, so this new order is designed to protect my sanity :)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 22, 2020, 05:12:45 AM
Story Characters

A commander can be flagged as a 'Story Character'. A Story Character will not suffer accidents or ill health and will not be automatically retired. This could be abused for scientists :) but I will leave it up to players how they want to use this option.

You can also flag a commander as 'Do Not Promote'. The commander will remain in his current rank and not undergo automatic promotion.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 22, 2020, 08:24:32 AM
Engine Technology Progression

I've updated the engine technology progression to include a couple of extra early levels that will smooth out the speed progression. In addition, Ion has been increased from 12 to 12.5 and Plasma Core Anti-matter changed from 60 to 64. See below for old and new engine progressions. Also (not shown), I've changed conventional engine power from 0.2 to 1.0 to make the conventional era more interesting.

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

Power plants have been updated on the same lines, with two new additions and minor changes to power ratings

(http://www.pentarch.org/steve/Screenshots/Crusade/PowerPlants.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 22, 2020, 12:30:39 PM
Diplomacy Part 1: Basic Framework

This post replaces the previous post on the Diplomacy module and covers the basic framework for Diplomacy in C#. Future posts will provide more detail, such as territorial claims.

Diplomacy Module
The Diplomacy Module is new for C# Aurora and replaces Diplomatic Teams. It also affects communication attempts. The module is 30 HS, costs 300 BP and requires 50 crew. The minerals required are Corbomite, Mercassium and Vendarite. It is a starting technology in both TN and conventional starts.

Communication
For communication checks to take place both sides must have ships and/or populations in the same system and both sides must be able to detect the other. Communication 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. Diplomacy cannot take place until full communication is established. Alien races may take exception to your presence in this situation, based on a number of factors will be covered in a future post.

For communication attempts, the highest Communication bonus of any commander of a ship with a Diplomacy module in one or more of the contact systems will boost any positive results achieved through the communication process (which is otherwise the same as VB6). If no Diplomacy module is present in any of the contact systems or the commander has no communication bonus, any positive gains toward full communication are halved.

Basic Diplomacy
Basic diplomacy follows similar principles to VB6 Aurora. Actions by each side generate positive or negative diplomatic points. As the total of diplomatic points goes above or below certain thresholds, high level treaties (trade, sharing of data, etc.) are put in place and the general level of cooperation changes (hostile, neutral, friendly, allied).

The primary method of generating diplomatic points is via the Diplomacy module. The module must be located in a system where the target alien race has ships and/or populations and both sides must be able to detect the other. Diplomacy can only take place when full communication has been established. The highest Diplomacy bonus of any commander of a qualifying ship is used. The number of points generated per year is as follows:

Diplomacy Points = ((Diplomacy Bonus * 4) + 1) * 100 * (1 – (Target Racial Xenophobia / 100))

For example, an officer with 20% Diplomacy trying to influence an alien race with Xenophobia of 40 would have the following calculation: (((0.2) * 4) + 1) * 100 * (0.6) = 108 Points.

If there is contact but no Diplomacy module in a contact system or the commander has no Diplomacy bonus, then no points are generated from this process (although other factors may generate points - covered in a future post).

If there is no contact at all, even via civilian ships, then Diplomacy Points will move toward zero, from either direction. The annual rate of change is the Xenophobia of the viewing race when the starting point is positive and 100 – Xenophobia when the starting point is negative. For example, the view of a race with 25 Xenophobia will only fall 25 points when the starting point is positive but will rise by 75 points when the starting point is negative. Low Xenophobia races are quicker to forgive transgressions and vice versa.

Existing treaties or diplomatic statuses will improve relationships over time. Different treaties have a base influence that is measured in diplomatic points per year multiplied by (1 – (Racial Xenophobia / 100)). For example, a trade treaty has a base influence of 100 diplomatic points per year. If two races have respective Racial Xenophobia of 30 and 60, then while a treaty is in place the view of the first race will improve by 70 diplomatic points per year while the view of the second ace will improve by 40. It takes longer to build trust with higher Xenophobia races.

Trade, Geological and Gravitational treaties all have a base influence of 100. A research treaty has a base influence of 200. A diplomatic status of friendly has a base influence of 100, while a diplomatic status of allied has a base influence of 200.

Positive and Negative diplomatic points will be gained through other events, many of which will be defined in future posts. An example of a negative impact is combat. Negative diplomatic points are suffered due to damage inflicted by an alien race using the following rules:

Each point of damage from a hit that only damages shields: 0.1
Each point of damage from a hit that causes armour damage but not internal: 0.25
Each point of damage from a hit that causes internal damage: 1.0
Each point of space-based damage to populations, ground forces or shipyards: 1.0
Each ton of ground forces destroyed in ground-based combat: 0.01

If diplomatic relations are above the hostile level (-100), then even a single point of damage through combat will reduce relations to that point. However a period of mutual non-interaction following a small clash will probably return the diplomatic status to neutral. For example, if communications are established you may ask a survey ship to leave your system (mechanics in a future post). If that didn't work or you did not have communication, you can slightly damage that ship. An unarmed ship would retreat from hostile aliens and the immediate impact would be the alien race treating you as hostile. However, with no further combat in the short term, the status would soon return to a wary neutrality. Future communication and diplomacy would still be an option. Larger wars are harder to resolve but peace treaties will be covered in a future post.

I know that "future posts" are mentioned several times, but I wanted to lay out the basic framework so I can build upon it.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 26, 2020, 09:35:15 AM
Diplomacy Part 2: Intrusion into NPR Territory

In each construction phase, each NPR will determine a value for each known system. In order of ascending importance, the values are: Alien Controlled, Neutral, Claimed, Secondary, Primary, Core, Capital. The value is calculated on a number of different factors, including existing population and installations, whether it is a logistics node, mining potential, terraforming potential and proximity to other important systems. Neutral is the default state for a system in which the NPR has no current interest, while Alien Controlled is a system which the NPR acknowledges is in the territory of another race as a result of accepting a claim from that race (see Part 3).

If you have forces or a population in a system that has at least Secondary value to an NPR, you are detected and you are currently viewed as neutral or friendly, the NPR will issue a warning which will appear as an event. This will still happen even if you haven't detected any NPR forces. You will be notified which fleet or population received the message. If communication has not been established, you will receive notification of an "unintelligible communication of unknown origin". If you have established communication, the text will reflect the severity of the situation.

This communication can be as mild as a suggestion that your forces leave in the near future and as strong as demanding you depart immediately or be fired upon. There are five levels of severity for messages and the one chosen by the NPR primarily depends on the 'Threat Level' (see below), although it may also issue a stronger warning at lower threat levels if the NPR believes that war will soon follow without a player withdrawal.

The threat level is based on three factors; the NPR’s estimate of the value of the system, any status modifiers due to the existing diplomatic relations and the Xenophobia of the NPR. This is calculated as follows:

Threat Level = Base Threat Level * Status Modifier * (Racial Xenophobia / 100)

Base Threat Level
Secondary = 2.5
Primary = 5
Core = 10
Capital = 20

Status Modifiers
Friendly Status = 0.5
Neutral with Diplomatic Points >= 1
Neutral with Diplomatic Points < 0 = 2

In addition to the messages, the threat levels generate a negative impact on diplomatic relations. The penalty in diplomatic points for intrusion into NPR territory is based on the Threat Level above plus the ships and population that the NPR can detect. The calculation for the annual point penalty is as follows:

Diplomatic Point Penalty = SQRT(Total Detected Ship Tonnage + (Total Detected Population EM Signature * 10)) * Threat Level

Each construction phase, the diplomatic penalty applied is equal to the annual penalty multiplied by (Construction Phase Length / Year)

Shipping Line vessels will be ignored for this purpose if a trade treaty is in force. NPRs will treat ships without military engines that have not demonstrated any weapon capability as 10% of their normal tonnage. If at least one ship is detected, the minimum rating for Detected Ship Tonnage will be 1000 tons. If at least one population is detected, the minimum rating for Population EM Signature will be 100. NPRs deduct 10,000 tons from the tonnage of one Diplomatic Ship (see Part 8) per system for threat purposes if that class type has never fired weapons and the Diplomatic Ship is in a non-Core system. If the NPR only has one system, it is not treated as core for this purpose.

This table shows the diplomatic point penalties for different ship tonnages in different value systems, assuming an NPR Xenophobia of 50. For populations, use EM Signature * 10 for ‘Tonnage’.

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

The warning message is issued during the first construction phase after detection and repeated during each subsequent construction phase where the violation still exists. Allied Races do not receive warnings as they can freely enter the NPR territory. Hostile races do not receive warnings as they are attacked instead. Trading will allow some exceptions to the rules above and I'll cover that in a future post. I will also cover situations where the NPR considers claiming a system with a large existing player population in the 'Alien Controlled' update.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 28, 2020, 02:43:00 PM
Diplomacy Part 3: Claiming Systems from NPRs

In the same way that NPRs can warn players to leave a system, a player can warn an NPR. On the Intelligence and Foreign Relations window, there is a tab for Known Systems for each NPR. You can select a system and then set a 'Protection Status' for the selected system in connection with the selected NPR. Alternatively, you can set a protection status for the system on the galactic map and that status will be set for any alien race when they are first detected in the system. The six statuses are shown below with their ‘Demand Number’ (0-5) and their ‘Demand Strength’.

Protection Status
0. No Protection 0
1. Suggest Leave: 1
2. Request Leave: 1.41
3. Request Leave Urgently: 1.73
4. Demand Leave: 2
5. Demand Leave with Threat: 2.24

If you set a status for a specific combination of system and NPR, then if that NPR is detected by you in that system during a construction phase it will be informed of your demand unless it is already allied or hostile.

The impact of the message on the NPR decision to accept or reject your demand is shown by the ‘Demand Strength’ in the list above, which is the square root of the ‘Demand Number’. A Request is 41% more likely to work than a Suggestion, while a Demand with Threat is 2.24x more effective than a Suggestion. The Demand Value represents the idea that, from the perspective of the NPR, the forcefulness of your language may represent a willingness to use force.

While the strength of your demand plays a part in the NPR decision, it also has a significant effect on relations with that NPR. So a higher demand might increase the chance the NPR will leave, but it also increases the chance of starting a war. If you demand the NPR leaves a system it doesn't care about you will cause fairly minor damage, but you could have made a polite request and it may have left with hardly any impact on relations. If you demand an NPR abandons what it regards as a primary system, that might work if you have a significant military advantage and the NPR is aware of it, but it might also cause the NPR to open fire immediately.

System Values
1 Neutral
2 Claimed
3 Secondary
4 Primary
5 Core
6 Capital

This relationship impact is equal to (Demand Number ^2) * (System Value ^2) * (Xenophobia / 50). So a demand to leave a primary system would have the impact of 256 * (Xenophobia / 50), while a request to leave a claimed system would have an impact of only 16 * (Xenophobia / 50).

The demand will be rejected if the NPR has not detected populations of your race with a total EM signature of (10 * Xenophobia) or more. The NPR will base this on actual populations, not currently detected populations, as it is assumed you will provide the necessary evidence to back up your demand.

Otherwise, the demand will be accepted based on Demand Value plus the following additional factors:

Accessible System Value
For each system that would no longer be accessible if the claim was accepted, including the target system, a value is assigned equal to (System Value ^2)/4. For example, a Claimed system is worth 1, a Secondary system is worth 2.25, a Primary system is worth 4, etc. Each individual system value is calculated first and then the results are summed.

Military Advantage
This assessment depends on the total size of your military forces that have been detected by the NPR during the last five years in comparison to its own (with an assumption of some as-yet-unseen forces) and its assessment of relative technology based on its observation of your ships. I don't want to go into too much detail on the Player Military Advantage, but if the NPR believes the racial balance of forces is equal, Player Military Advantage will be equal to 1. For the NPR to believe you have an advantage, it will need to see some firepower. This is based on total known forces, not local known forces, so generating a high Military Advantage number is difficult unless you show off a large portion of your forces. You won't be able to simply send in a survey ship and ask the NPR to move out

Population Factor
This is equal to SQRT(Total EM Signature of Player Populations in System / Total EM Signature of NPR Populations in System). However, this factor can never be higher than the fourth root of (Total EM Signature of Player Populations in System / 100). For example, if the player had 1000 EM Signature and the NPR has 200 EM Signature, the factor would be 1.78 (because the fourth root of (1000/100) is lower than SQRT(1000 / 200). This is to limit the advantage when the populations are relatively small or the NPR has no populations. Population Factor is the best ’peaceful option’ as demonstrating a large population is much more likely to achieve a decision in your favour.

Resistance
(Xenophobia + Militancy + Determination) / 150. If the NPR has low militancy, low determination and low xenophobia, it will be much easier to push around, and vice versa. This is difficult to assess because it is an unknown factor.

If Military Advantage * Demand Value * Population Factor) > (Accessible System Value * Resistance), the NPR will accept the claim.

For example, if the NPR has militancy, determination and xenophobia all at 50, then the value to overcome for a Secondary system is 2.25. If there are no populations and you use ‘Demand Leave’ which is worth 2x, you will need a Military Advantage greater than 1.125. Making this demand will cause a negative relationship impact of (4^2) * (3^2) * (50/50) = 144. If you have a significant advantage in population in the system, then you require a smaller military advantage or can use a lesser demand.

If the NPR rejects your demand to withdraw, the protection status for that system for that NPR is reset to No Protection, so that further diplomatic penalties are not incurred. If you want to re-instate the demand (at whatever level), it will generate a new penalty.

If the NPR decides it must withdraw based on its assessment of the situation, it will evacuate its ships and transfer any colonies to your control. These will start at a status of Occupied. The system will be set to 'Alien Controlled' (Player controlled) from the perspective of the NPR and it will ignore the system when deploying forces. This will change if conflict breaks out.

Note that the player vs NPR and NPR vs player functionality for claiming systems are a little different. Both sides can send messages to each other and the types of messages are effectively the same. The difference is the method of delivery and the potential reaction. This is because I wanted to give the player maximum flexibility in Diplomacy, while still proving a structured approach for the NPR. For example, the player view of the NPR in terms of diplomatic points does not drop if the NPR ignores demands to leave. The player can decide whether it is necessary to go to war.

This is a complex set of interactions, so I may modify after play test (or if someone spots any errors in the algorithms).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 29, 2020, 12:49:12 PM
Diplomacy Part 4: NPR vs NPR Claims

NPR vs NPR Diplomacy works as a combination of NPR vs Players and Player vs NPR.

As described in Part 2, when an NPR detects alien forces in a system that is claimed by the NPR, the NPR will issue a warning. When the target is a player this appears as an event message as per Part 2. When the target is another NPR, the first NPR sets a protection status (in the same way as a player does in Part 3) that corresponds to the same demand level as it would send to a player.

For example: An NPR detects an alien force in a system that it claims and decides this represent a threat level of 12. If the alien is a player, the NPR will send a message to the player that will appear as an event. The message will be on the lines of "We demand you leave" and that message will continue to be sent each construction phase. If the target is another NPR (let's call this NPR-B), then NPR-A will set a protection status of 'Demand Leave' instead.

Next phase (or in some cases later in the same phase), NPR-B will see the withdrawal demand from NPR-A, just as it would see a similar demand from a player. It will react to that demand in exactly the same way except for one crucial difference; NPR-B will not reduce the diplomatic points for NPR-A.

So why all the messing about with slightly different methods for Player vs NPR, NPR vs Player and NPR vs NPR? Because NPRs, even though they are much smarter in C#, will still not have the human capability to make intuitive estimates weighing the strategic benefit of claiming a system claim vs the potential downsides of reduced diplomatic relations. This strategic deficit in AI vs human ability is handled by the different reactions to claims.
The difference is that the NPR is always faced with an immediate decision and does not have to consider wider implications. The player has the ability to take those wider implications into consideration and is free to make his own decisions on relationships. When NPRs do confront each other, either one will leave because the system is not important or they will start making demands of each other, which takes care of the dual negativity. I know it sounds complex, but I think it the best option to handle the different situations.


Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on January 29, 2020, 04:24:45 PM
Diplomacy Part 5: Restrictions on NPR Claims

There are several situations where NPRs will not make territorial claims:
The above is based on the concept that an AI is unlikely to claim a system where it knows there is a good chance that claim will cause a war. Note that from the NPR perspective an 'alien race' includes player races.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 02, 2020, 08:20:37 AM
Diplomacy Part 6: Independence

In C#, you can declare a colony independent using a button on the Economics window. Colonies may also become independent in other situations, such as a rebellion following high unrest. Independence is far more complex than it first sounds, because the population will be under the control of a new race that is essentially a copy of the original race. The process is as follows:
The new race will gain the following knowledge from the original race.
For manual independence, any naval forces will have to be transferred using the Transfer Fleet option. In the case of a rebellion, some ships may be transferred automatically.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 08, 2020, 04:18:57 PM
Star System Design Part 1: Modifying Stars

C# Aurora allows you to manipulate star systems in SM Mode. While it would be difficult to design a system during the original generation process, due to the complexities involved, you can now add or modify stars and system bodies. This post covers modifying stars.

You click on a star in the System View and then click Change Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.

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

Here is an example from my current test campaign that changes the B component of Alpha Centauri from a K1-V star to an F0-V, which is much hotter. The star will orbit more quickly due to the increased mass, plus all the planets orbiting the star are affected by the increased mass and luminosity of the different star. Temperatures will change, along with potentially hydrosphere type and atmospheric composition (as gases freeze out or boil). Oceans or ice sheets may convert entirely to water vapour given a significant temperature rise. Planets may change their tide-locked status.

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

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

These two screenshots show the effect of moving the star further from the primary.

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

(http://www.pentarch.org/steve/Screenshots/Crusade/Engineering004.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 08, 2020, 05:29:38 PM
Star System Design Part 2: Adding Stars

Adding a new star is straightforward. You click Add New Star. The dialog below pops up and allows you to select spectral class, orbital distance, bearing and parent star.

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

This screenshot shows the result of adding the above star to the Alpha Centauri system. New stars do not have any planets or other system bodies. These are added separately and will be covered in a future post.

(http://www.pentarch.org/steve/Screenshots/Crusade/Engineering007.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 09, 2020, 12:08:52 PM
Star System Design Part 3: Modifying System Bodies

Modifying system bodies is a more complex process than stars due to the number of factors involved. There are factors that are tied to each other, such as mass, radius, density and gravity, plus certain types of bodies have different rules (planets vs moons, gas giants vs rocky worlds).

Therefore, the following factors can be changed; distance to parent body, diameter, density, hydro extent, albedo, atmospheric composition and dominant terrain. The dominant terrain is restricted to those terrains permitted by the other factors. Factors such as colony cost, gravity, temperature, atmospheric pressure, length of year, maximum population, tidal lock status, atmospheric retention, time required to stabilise a Lagrange point, etc. will all be derived from the factors that can be changed. For example, if you change the diameter or density, the mass and gravity will automatically change. If you change the distance to parent, the temperature and year will change and perhaps the tidal lock status. Finally, factors such as escape velocity, magnetic field, etc. are not shown here because they have no current game play impact, even though escape velocity will change as a result of modifications to density or diameter.

The basic type of system body (terrestrial, dwarf, etc.) cannot be changed, but it will be possible to delete one system body and add a new one of the desired type. This is to ensure all system bodies follow the basic rules of their type, even if they are later modified.

Below is the System Body Modification popup window. You can change the green fields in the top left, the dominant terrain dropdown and can add and remove atmospheric gases by choosing a gas and the desired atm (0 to remove). As you make each change, everything else updates.

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

For example, here is what happens if the diameter is halved. Gravity, mass and max population all fall, while the terraform rate vs Earth and the time to stablise a Lagrange point both increase.

(http://www.pentarch.org/steve/Screenshots/Crusade/Engineering012.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 09, 2020, 02:03:22 PM
Star System Design Part 4: Deleting Stars and System Bodies

Deletion of stars or system bodies is straightforward. Click on the target object and then click Delete Body or Delete Star. You will be given two popup warnings and then the object will be deleted. Deleting a star will remove any system bodies in orbit. Deleting a planet will remove any moons of that planet. Any populations on affected system bodies will be deleted. Deleting the primary star is not possible.

When a star is deleted, any remaining stars will be renamed accordingly. For example, if you delete the B component of a primary, the original C component will now become the B component. When a planet or moon is deleted, the orbit numbers of the planets or moons will be adjusted accordingly.

For example, here are the before and after views of the Alpha Centauri-A system when the fourth planet is deleted.

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

(http://www.pentarch.org/steve/Screenshots/Crusade/Engineering016.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 10, 2020, 06:07:53 PM
Star System Design Part 5: Adding Planets, Comets and Asteroid Belts

Below is the form for adding all new system bodies except for additional moons. You choose a system body from the drop down, which includes Terrestrial, Dwarf Planet, Gas Giant, Superjovian, Comet and Asteroid. Each body type has a distance parameter plus one or more other additional options.
Once the planet parameters are selected, press OK and the new body or bodies will appear in the System View. You can select them and use Modify Body to customise if desired.

The various zones shown at the top affect how Aurora determines parameters such as atmosphere, hydrosphere, mineral deposits, albedo, density, number of moons, total mass of asteroid belts and a variety of other factors. There is far too much detail to list, but generally bodies in the life zone will have better conditions and mineral deposits, followed in decreasing order by Inner, Outer and Extreme. These zones also exist in VB6. Of course, those factors only affect initial generation so you can override that by directly modifying a body post-creation.

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

In the next post I will cover adding moons to existing planets.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 11, 2020, 03:29:36 PM
Star System Design Part 6: Adding Moons and Lagrange Points

Below is the form for adding moons to existing planets. During planet creation you can specify appropriate moons to be created at the same time using standard moon generation based on the type of planet and is orbital distance. This form, accessed via the Add Moons button, is for creating additional moons which do not have to obey normal size restrictions. The form allows the addition of up to five moons (the drop-downs all start with no moon) with type and distance specified. If more than five moons are needed, the form can be used multiple times for the same parent planet.

After initial generation you can use Modify Body to specify additional detail if required.

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

The Add Lagrange button adds a Lagrange point to the currently selected body, even if it would not normally qualify for one.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 12, 2020, 06:52:23 AM
Gauss Cannon Research Changes

I've lowered the research point requirements for Gauss Cannon.

The Rate of Fire tech starts at 2 shots with the following progression in RP from 2 to 6 shots: 1500, 5000, 15,000, 45,000, 135,000. Eight shots is 450,00 RP.
The Launch Velocity still has six levels with the following progression in RP: 500, 1500, 5000, 15,000, 45,000, 135,000
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 12, 2020, 07:42:35 AM
Star System Design Part 7: Deleting Asteroids and Lagrange Points

Deleting individual asteroids can be done by using the Delete Body button. To delete an entire asteroid belt or all the Trojan asteroids for a particular planet, click one of the asteroids in the belt or one of the Trojans and click Delete Asteroids. There will be two warnings before all the affected asteroids are deleted.

Lagrange Points can be removed by selecting the parent system body and clicking Remove Lagrange.

Below is the final version of the System View in SM mode with all system engineering buttons present.

(http://www.pentarch.org/steve/Screenshots/Crusade/Engineering019.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 14, 2020, 06:20:10 AM
Lagrange Points for Moons

In C#, it will be possible to have Lagrange Points for moons. These will not occur naturally, but there are two situations where it is possible. Firstly, you can use a ship equipped with a Stabilisation Module on any moon with a mass of at least 0.25 Earth masses. The time required will depend on the mass of the moon but it is likely to be several years. Secondly, you can place the Lagrange Point manually using the new System Design functionality. The latter option does not have any mass restriction.

This will provide a way to have ships jump very close to the parent planet of the moon, which is very useful in logistics terms but very dangerous if you are at war.

Of course, it is entirely a coincidence that Battlestars will now be able to jump into orbit close to Ragnar Anchorage.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 15, 2020, 07:27:40 AM
Maintenance Storage Bays

VB6 has the Maintenance Storage Bay, which is 5 HS and carries 1000 MSP.

In C#, the new 1% weapon failure rate means that the ship design process will have to account for that additional MSP expenditure when considering engineering systems. This includes small craft such as fighters which may mount a single energy weapon or multiple box launchers. The issue for fighters is that adding sufficient engineering to cover that potential MSP cost may give them maintenance lives of many years, which is unnecessary and not very realistic.

Therefore, C# adds several new maintenance storage options. These create a reserve of maintenance supplies that can be used to repair weapons but do not affect failure rates or maintenance life. I've also doubled the storage capacity because the MSP capacity of normal engineering was not significantly lower in many cases.

Maintenance Storage Bays in C#
Large: 2000 MSP, 5HS
Standard: 400 MSP, 1 HS
Small: 80 MSP: 0.2 HS
Tiny: 40 MSP 0.1 HS
Fighter: 20 MSP: 0.05 HS.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 23, 2020, 10:44:07 AM
Ground Forces Text Summary

The 'Temp as Text' button on the Formation Templates tab of the Ground Forces window will pop up a window with a text version of the selected template composition, which can be copied using ctrl-C and pasted into an AAR. Format is as follows:

Colonial Marine Battalion
Transport Size: 4,914 tons
Build Cost: 156.4 BP
400x Colonial Marine
96x Colonial Marine - LMG
12x Mortar Section
24x Anti-Tank Section
4x Forward Air Control Party
16x Centaur AFV
8x Supply Section
2x Marine Battalion HQ

The 'Total Force Text' button on the Order of Battle tab of the Ground Forces window will pop up a window with a text version of your entire ground force, which can be copied using ctrl-C and pasted into an AAR. Format is as follows:

Total Ground Forces
Total Formations: 116
Total Transport Size: 439,767 tons
Total Cost: 30,210 BP

21,600x Colonial Marine
5,184x Colonial Marine - LMG
1,440x Colonial Marine Raider
1,140x Anti-Tank Section
760x Centaur AFV
570x Mortar Section
448x Supply Vehicle
396x Medium Howitzer
380x Supply Section
360x Colonial Marine Raider - LMG
348x Minotaur Battle Tank
190x Forward Air Control Party
132x Manticore Medium AA
120x Marine Battalion HQ
104x Sphinx Planetary Defence Installation
52x Hydra Planetary Defence Installation
48x Marine Raiding Force HQ
12x Minotaur Command Tank
11x Regimental HQ
4x Marine Company HQ
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 23, 2020, 04:29:51 PM
Adding Your Own Commander Name Themes

Adding your own commander name themes was not possible in VB6. I've added that option for C# where the theme follows the pattern of First Name - Surname, with the option for both male and female names.

1) Create three text files with one name per line for Male First Names, Female First Names and Surnames. There is no naming convention for file names.
2) Click the second button shown below
3) Enter the theme name in an input field that pops up
4) Select the male names file using a standard windows file dialog box. You are prompted which file to select.
5) Select the female names file using a standard windows file dialog box. You are prompted which file to select.
6) Select the surnames file using a standard windows file dialog box. You are prompted which file to select.

The new commander name theme is added to the database for the current game and all future games.

(http://www.pentarch.org/steve/Screenshots/Crusade/CommanderNameThemes.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 23, 2020, 04:40:12 PM
'Battlestar Greek' Commander Name Theme

I've added a new Naming Theme for my latest test campaign. It mixes names from Battlestar Galactica with names from Greek Mythology, so I've called it Battlestar Greek. It is a little weird :) but matches the theme for the campaign so I'm going to make it one of the standard themes. Here is a sample of some randomly generated names.

(http://www.pentarch.org/steve/Screenshots/Crusade/ExampleNames.PNG) (http://www.pentarch.org/steve/Screenshots/Crusade/ExampleNames03.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on February 27, 2020, 05:56:52 AM
Ship Achievements

All the medal conditions that potentially apply to ship commanders are recorded for the ship as well. This is maintained separately from the ship commander, so when a commander moves on to a new ship, the current ship retains its achievements, which will continue to increase under the next commander. A ship does not need a commander for the achievements to be recorded. Currently the recorded ship achievements include the following:

Hostile Ships Destroyed
Military Shipping Tonnage Destroyed
Commercial Shipping Tonnage Destroyed
Hostile Missiles Destroyed
Ground Forces Tonnage Destroyed
Armour Damage Taken
Internal Damage Taken
Star Systems Discovered
Ruins Discovered
Bodies With Minerals Discovered
Jump Points Discovered
Habitable World Discovered
Combat Drop - Transport
Tons Salvaged
Stablisations Completed

The ship total for each of the above is displayed on the Ship Design Display tab, under the Ship Overview tab on the Naval Organization window.

EDIT: If a ship has an assigned mothership, the parasite still gets the credit, but the assigned mothership receives a separate credit flagged with (SG) for strike group. Separate achievement entries are shown for the carrier itself and the strike group, even if they are the same achievement.  So if a Battlestar has destroyed 10,000 tons of shipping directly and its Vipers have destroyed 20,000 tons, the achievement list for the Battlestar will show:

Military Shipping Tonnage Destroyed: 10,000 tons
Military Shipping Tonnage Destroyed (SG): 20,000 tons.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 06, 2020, 07:07:34 AM
Prototype Components

When designing components in the Create Research Project window or the Turret window, you have the option of the Prototype button instead of the Create button. Prototype components are researched instantly and are available in the class design window, where they will appear with a (P) suffix. There is a display toggle on the class design window for prototype components.

Prototypes can be obsoleted to remove from the display. In this case, they will only appear if both the obsolete and prototype options are checked.

On the turret window, prototype energy weapons will be displayed with a (P) suffix. Any turret containing a prototype energy weapon can only be a prototype. The Create button will be unavailable.

If a class contains a prototype component, it will be displayed with a (P) suffix on the class tree and in the class summary on the Class Design window. A shipyard cannot be retooled for a class that contains prototype components.

Prototypes will allow you to try out different class designs without having to research all the potential components.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 06, 2020, 07:52:31 AM
Assigned Mothership Display

In playing my BSG campaign, I found it difficult to keep track of which mothership was the parent of each survey FAC. Therefore, I have added Assigned Mothership as a field on the ship design display and also added assigned mothership name and fleet to the summary at the top of the Fleet tab of the Naval Organization window.

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

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


Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 06, 2020, 08:44:13 AM
Future Tech for Prototypes

The Create Project now has a Show Next Tech checkbox. When this box is checked, you will see the the next tech that can be researched in the design options. For example, if you have researched 12cm and Visible Light for lasers, then checking the box will add 15cm and Near Ultraviolet to the design options.

When using the Next Tech option, only Prototype Components can be created.

Prototype Components created when the Show Next option is active will be classed as Future Prototypes and will have an (FP) suffix.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 06, 2020, 11:33:40 AM
Researching Prototypes

If you select a prototype component on the Class Design window that can be created with current technology (i.e. not a future prototype), you will see a 'Research Proto' button appear. Clicking this turns the prototype into a Research Prototype. Research Prototypes have an (RP) suffix on the class window.

Research Prototypes will appear in the Research tab of the Economics window in their appropriate Research Field. They can now be researched like any other component, except they are still available in class design as a prototype until the research is complete. At that point, the prototype flag will disappear. If that was the last prototype in a class, that class can thereafter be tooled in a shipyard.

The combination of this and previous posts means that any component can in one of four states. A 'normal' component (no suffix), a 'current' prototype (P), a future prototype (FP) and a research prototype (RP).

The various prototype changes mean you can build a prototype class design using prototype components and then research all those components, making the class available for use.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 08, 2020, 11:44:42 AM
Diplomacy Part 7: Banned Bodies

If a non-spoiler NPR has a relationship of neutral or higher with another race, it will generally avoid approaching 'banned bodies'.

An NPR will decide for itself which bodies are banned, but in general these will include:
NPRs will not create populations on banned bodies and will not attempt to conduct geological surveys on those bodies. The NPR will not generate points of interest within a few million kilometres of banned bodies. It is still possible that NPR ships will approach due to other considerations, such as moving between two points unrelated to banned bodies, but in general this should prevent the VB6 situation of NPR battle fleets making port visits to your home world.

The banned bodies list is updated at game launch and during each construction phase. Banned bodies do not exist for populations of races with which the NPR has a hostile relationship. If there are two populations on a planet, one of which is hostile to the NPR and one neutral, the body will not be banned.

For example, in the Space 1889 campaign, the Martians will generally avoid Venus, Earth, Luna, all the moons of Jupiter and all the moons of Saturn. They will still survey the Trojan asteroids and they still may pass close to the banned bodies when on an unrelated mission.

NOTE: I looked at various ways of applying this in reverse. The NPR would generate a list of important planets and check for player race ships within a certain range, perhaps ten million kilometres. If they were detected, that would trigger a response, even if the NPR would otherwise not object to the player being in the system. The problem is that the player would have to be checking each ship path to ensure that didn't happen. I even added code to avoid this problem by only flagging player ships that remained within ten million in two consecutive construction phases, but even that is not foolproof. Essentially, the player knows the NPRs is trying to avoid his populations and will react to NPR movements accordingly, but understanding that is much more difficult for the AI. In the end the game play benefit is outweighed by the considerable micro-management required on the part of the player, or by the amount of code that would be needed to avoid accidentally passing through restricted zones. In most situations, the player would want to avoid being detected anyway so this situation would usually only be relevant where a truce countdown is in effect and the player and the NPR share the same home system. The player can RP that situation if needed.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 14, 2020, 08:38:24 AM
Transponders

In C# Aurora, transponders have three modes; Off, Friendly and All. A transponder set to Friendly will only be detected by Friendly or Allied Races. A transponder set to All will be visible to all races, even hostile ones.

Civilian Shipping will have transponders set to Friendly.

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 14, 2020, 10:53:34 AM
Player Race Banned Bodies

Player Races can ban bodies in the same way as an NPR. Unlike an NPR, the player can select which bodies are banned. This is done via a toggle on the system view. There is an option to ban / un-ban all moons of a planet at once.

Civilians will not create mining colonies on banned bodies and survey ships with standing orders will not attempt to conduct geological surveys on those bodies. It is still possible that player ship will approach due to other considerations, such as moving between two points unrelated to banned bodies. Note this is different to a military restriction, which applies only to the interaction of civilian shipping lines with existing populations.

This player banned bodies function is mainly for role-playing purposes as NPRs react to a player presence in a system, rather than in proximity to a specific body, although it could also be used to prevent the creation of civilian mining colonies.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 15, 2020, 06:12:57 AM
Shipping Line Names

You can rename shipping lines in C# Aurora. Just click on the 'Admin Command' that represents the shipping line on the Naval Organization window and click Rename. You provide a full name for the shipping line and a short name for the ship naming.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 16, 2020, 04:47:27 AM
Screen Resolution

I've mentioned the minimum resolution a few times in different places, but I think it is worth including here, especially as it just came up on the Discord.

C# Aurora will launch with a minimum resolution of 1440 x 900. The windows will not be re-sizeable except for the Tactical Map and the Galactic Map and even in that case it is because those windows are intended to fill the whole screen. The Class design window has a 'Wide' option that takes it to about 1800 x 900.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 16, 2020, 07:29:57 AM
Group Contacts
Similar contacts can be grouped in C# Aurora. This is done via a checkbox on the Tactical Map sidebar entitled 'Group Contacts'. This is similar in concept to the 'Hide Active IDs' in VB6 Aurora but implemented a little differently.

When Group Contacts is active, any contacts with the same alien ship type, the same current coordinates, the same coordinates from the previous increment, the same active sensor emissions and the same contact status will be grouped together. The 001, 002, etc. suffix of the normal contact string will be replaced with a prefix showing how many contacts in the group. If there is only one contact in a location, the grouping is ignored and the normal contact information is displayed. The difference is shown below:

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

(http://www.pentarch.org/steve/Screenshots/Crusade/HideIDOn.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 16, 2020, 11:43:52 AM
Lost Contacts

The 'Lost Contacts 1 Month' checkbox will update the tactical map to display any ship contacts less than one month old, rather than the default of current contacts only. This is more sophisticated than the VB6 equivalent and will also provide more information on current contacts where available. For example, you may be currently tracking an alien ship by its thermal emissions only, but you had an active contact a week ago. When Lost Contacts is active, you will see both the current thermal contact combined with the older active contact.

Any ship contact that is only visible because of the lost contact option will display [LOST] after the contact information. A ship contact with a combination of current and older information will display [PARTIAL] after the contact information.

There is also a 'Lost Contacts 1 Year' checkbox, which functions exactly as above except for the period of time. If both boxes are checked, one year takes priority.

Here is a section of my current system map with and without the Lost Contacts option active. The Hegemony of Titan ships near the bottom only appear when Lost Contacts is active. The Venusian freighters at the top left are present in both screenshots, but have more information available when Lost Contacts is active

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

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

Lost Contacts can be combined with Group Contacts. Here are two screenshots of Martian ships in orbit of Mars with Group Contacts active. Lost Contacts is active in the second screenshot.

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

(http://www.pentarch.org/steve/Screenshots/Crusade/GroupLostOn.PNG)
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 16, 2020, 02:19:29 PM
Alien Classes Text Summary

As with the other text summaries, this is a tool for generating text to paste into after-action reports.

A button on the Intelligence & Foreign Relations window will generate a summary of alien class information for the selected alien race. Here is a summary from the Martian Empire in my current campaign. Weapons will also be shown when known.

Alien Class Intelligence - Martian Empire
5x XX Xining   84,250 tons   Thermal 84
1x XX Jiangwei   73,200 tons   Thermal 1,600   1,092 km/s
5x XX Changsha   59,850 tons
8x FT Su Small F4   34,650 tons   Thermal 640   923 km/s
8x CS Su Small C4   22,000 tons   Thermal 640   1,453 km/s
1x XX Houxin   20,100 tons
15x XX Kaifeng   19,300 tons
1x XX Luda   17,700 tons   Thermal 800   2,253 km/s
15x XX Houjian   12,850 tons   Thermal 282   1,092 km/s   AS #61
9x XX Dalian   12,850 tons
3x XX Hegu   12,800 tons   AS #61
3x XX Hainan   12,700 tons   AS #61
10x XX Jinan   12,500 tons
4x XX Luhu   6,900 tons   Thermal 400   2,892 km/s
16x XX Yinchuan   6,400 tons   Thermal 140   1,092 km/s   AS #61
7x XX Huangwen   6,400 tons
1x XX Chongqing   6,400 tons
1x XX Zunyi   6,400 tons
4x XX Jianghu   5,400 tons   Thermal 200   1,836 km/s
8x FH Su H4   Thermal 320   248 km/s
3x XX Xian   Thermal 200   1,724 km/s
Total Known Tonnage 2,293,300
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 26, 2020, 11:00:55 AM
Survey Speed

The game details window has an option to change survey speed in the game. 100 is the normal rate. For example, if survey speed is changed to 50, all surveys will take twice as long, whereas if survey speed is changed to 125, surveys will happen 20% faster.

The survey speed modifier is applied to the survey points produced by survey ships. Everything else remains the same.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 27, 2020, 08:48:02 AM
Diplomacy Part 8: Diplomatic Ships

A Diplomatic ship is any ship equipped with a Diplomacy Module. These can be built by the player or by NPRs.

Diplomacy Modules and therefore Diplomatic Ships are important for communication attempts and essential for basic diplomacy (influencing an alien race to view your race more positively). See link below for full details.
http://aurora2.pentarch.org/index.php?topic=8495.msg118258#msg118258

When a Diplomatic Ship is involved in diplomacy or communication attempts, the opposing race will know the origin of those messages. If the Diplomatic Ship is on opposing sensors, the identity of that ship will be noted in an event for the opposing race and its parent class will be flagged as a diplomatic vessel. If diplomacy is underway, the name of the Ambassador will also be passed to the opposing race.

If the Diplomatic Ship is not on opposing sensors, the location of the signal from that ship will be communicated to the opposing race. This may be a system body, a jump point or simply a point in space.

Any damage to NPR Diplomatic ships, regardless of whether the opposing race knows that status, will be treated as triple damage for the purposes for affecting diplomatic relations. If a diplomatic ship is attacked without an existing hostile relationship, the relationship will fall to -300 from the perspective of the owner of the ship (rather than the normal -100 for attacking when not hostile).
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on March 28, 2020, 12:24:06 PM
Detecting Engine Type

Thermal sensors are able to detect whether a ship moving faster than 1 km/s has military or commercial engines. This information is added to the intelligence for the associated alien class.

The thermal contact strength for a ship will be preceded by "M" or "C" if the engine type for the parent class is known.

NPRs will treat ships without detected military engines that have not demonstrated any weapon capability as 10% of the normal size when assessing their threat level

Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 01, 2020, 06:18:57 AM
Change Scientist Research Field

There is a new option on the Commander window to change the research field of a scientist. Any field can be chosen, but the current research bonus is reduced by 75%.

This is the same effective rate at which a scientist can already operate in a different field. However, they will now start to gain experience in the new field.
Title: Re: C# Aurora Changes List
Post by: Steve Walmsley on April 04, 2020, 09:06:00 AM
Mineral Search Flag

A new option on the galactic map allows you to mark individual systems with a "Mineral Search Flag". There is a display option to show which systems have been flagged.

On the Mineral Search window, you can restrict the search to systems with the flag set, in conjunction with the existing filters.

This will allow you to search for mineral deposits within a subset of systems, in addition to the current options of a specific system or all systems.