Aurora 4x

C# Aurora => C# Mechanics => Topic started by: Steve Walmsley on April 24, 2021, 10:36:09 AM

Title: v2.0.0 Changes List (also known as v1.14.0)
Post by: Steve Walmsley on April 24, 2021, 10:36:09 AM
Changes List for 2.0.0

This post includes bug fixes or minor changes. Any more significant changes will have their own post.

Changes
Fixes
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 24, 2021, 10:51:59 AM
Retired/Dead Commanders

v1.14.0 allow you to retain or even restore dead and retired commanders.

When a commander is killed or retired, they are added to a new section on the commanders window treeview. Dead and Retired commanders retain all of their history and medals and are listed under the rank at which they left the service. They can also be awarded posthumous medals.

There is a new node entitled "Retired / Dead" which sits at the same level as the four existing top level nodes (Naval Commanders, Ground Commanders, etc.). Within that new node, is an identical hierarchy to active commanders, except that only ranks containing retired or dead officers are displayed (to avoid clutter).

Each retired or dead commander has a default status of (DNR), shown as a suffix to their name, which in this instance means "Do Not Retain". Once the game is shut down, any commander with a (DNR) tag will be removed from the game entirely. This is to avoid cluttering up the game with thousands of ex-commanders. Clicking on a retired/dead commander will reveal a Retain button, which can be used to toggle the (DNR) tag. When you save a game, any retired/dead commander without a (DNR) tag will be saved in the same way as an active commander. When the game is loaded, they will remain in the Retired/Dead section without the (DNR) tag.

If you are in SM mode and click on a retired/dead commander, you will also have a Restore button. Clicking this button will return the commander to active service and restore them to perfect health. They will appear as the least senior member of the rank they held on retirement.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 28, 2021, 06:09:26 AM
Transfer Fleet to Alien Race

On v1.14, you can transfer a fleet to a known alien race. This is done using a button + dropdown combination on Miscellaneous tab in the Fleet view of the Naval Organization window. You select the target race and click Transfer Fleet.

The fleet and any ships contained therein, including parasites, will be transferred to the selected alien race. This can be done in a system that is unknown to the alien race, as the system will be revealed as part of the transfer. The alien race will generate any required alien class and ship records if they do not have any prior knowledge of the ships. There will be no 'overhaul factor' penalty as this is a willing transfer, rather than a surrender or capture.

It is possible, although not recommended for inexperienced players, to transfer the fleet to an NPR. The NPR will assign Ship AIs and a Fleet AI to the fleet based on the Race AIs best estimation of the fleet's role and the capabilities of individual ships. This is by no means foolproof, due to the huge variety possible in player designs, so it could potentially cause problems with the AI if the designs in the fleet are not easily classified. For example, a survey ship, a freighter fleet, terraformer, basic combatant squadron, etc. would be fine, but not a 100,000-ton Battlestar. Common sense (and database backup) is recommended for transfers to NPRs. If you do use transfers to NPRs, please note that in any subsequent bug reports. I'll add a pop-up on the Transfer Fleet button to this effect.

The NPR will determine the fleet type by going through the following list looking for the first matching module. If one is found, the fleet will be classified on that basis and the check will end.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 03, 2021, 07:33:53 AM
Changes to Crew Training / Fleet Training

For v1.14, Crew Training is changing from a numeric to a percentage-based bonus. With the recent demise of the ground combat command bonus, crew training was the only non-percentage-based bonus (except for admin ratings) and therefore created an exception in the rules. It also created some issues around using multiple layers of admin commands to increase the bonus for both crew training and fleet training.

Each percentage point of the new bonus will be equal to 5 points of the old bonus. So 20% = 100. The max starting bonus will be 30% (or 150 in the old bonus) and the new bonus can reach a maximum of 50%. More commanders will receive the new bonus.

As a result of the change to the bonus, the new crew training calculation is as follows:

1) A ship must have a commander or an executive officer with a crew training bonus to conduct crew training. The bonus due to each is calculated separately and then added.

2) The bonus of each officer may be boosted by the parent admin command and any other eligible admin commands in the same hierarchy (see this post for details: http://aurora2.pentarch.org/index.php?topic=8495.msg103849;topicseen#msg103849)

3) The final bonus is halved for the ship commander. The executive officer uses the full bonus.

4) Once the final bonus for each officer is calculated, the incremental crew grade points are calculated as Final Bonus * 500 per year. For example, an executive officer with a 20% crew training bonus supported by a naval admin command with a 30% bonus (of which 1/4 is applied) would add: ((1.2 * 1.075) - 1) = 29% * 500 = 145 crew grade points per year. Maximum grade is 1000 points.

The new Fleet Training calculation is as follows:

1) The base percentage for increase is based on the crew training rating of the parent admin command and any other eligible admin commands in the same hierarchy. This is the full bonus for a Training admin command and 10% of the bonus for a General admin command.

2) This above bonus is multipled by the crew grade, morale and overhaul factor of the ship.

3) Once the final bonus is calculated, the incremental fleet training points are calculated as Final Bonus * 1000 per year. Maximum training is 500 points.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 03, 2021, 09:11:59 AM
Automatic Bridge

This is a minor change, but worth noting separately.

Aurora requires a bridge for any ship of 1000 tons or more. However, it can be annoying when you are experimenting with small systems and the bridge is automatically added when you go slightly over at 1000 tons.

For v1.14, the Design Errors section will note when the ship requires a bridge (at 1000+ tons), but the bridge will only be added automatically at 1100 tons.



Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 03, 2021, 12:48:22 PM
Fleet Active Sensor Button

Fleets now have an active sensor button in the same way as Ships.

If a fleet has any ships with active sensors, the button will read 'Active Off' and will turn off any active sensors. If no active sensors are engaged, the button will read 'Active On' and will turn on all active sensors in the fleet.

If you want a fleet with only some sensors active to turn them all on, then press the button twice.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 03, 2021, 02:26:50 PM
Engine Technology Naming

As there is scope for confusion between Internal Confinement Fusion and Inertial Confinement Fusion, I've removed the Internal Confinement Fusion entirely. Every engine and power plant tech above them has been moved down one level. For example, Magnetic Confinement Fusion is now 40,000 RP instead of 80,000 RP. A new Quantum Singularity Drive (and Quantum Singularity power plant) has been added to the end of the list to maintain the same number of engine and power plant techs.

I've also renamed the lower tech engines to be more distinctive and to avoid having the 'Improved' prefix. The updated list (thanks to nuclearslurpee for the names) is as follows:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 04, 2021, 06:43:14 AM
Scrapping Installations

In v1.14.0, you can scrap installations for thirty percent of their wealth and minerals.

This is done via the Civilian Economy tab of the Economics window. Select an installation and click the new 'Scrap Installation' button. You are prompted to select the number of installations to scrap. Wealth is added to the racial balance and minerals are added to the parent population stockpile.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 04, 2021, 06:57:17 AM
Scrapping Ground Unit Formations

In v1.14.0, you can scrap ground units for thirty percent of their wealth and minerals.

On the Ground Forces window, select a ground unit formation and click the new 'Scrap Formation' button. All elements within the formation will be scrapped. Wealth is added to the racial balance and minerals are added to the parent population stockpile.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 05, 2021, 05:55:04 AM
Re-Establish Ship Contact

In v1.13, a New Contact event is generated when you encounter an alien ship for the first time. There are also Update Contact events when you gain further sensor information or there is a change to existing sensor information.

For v1.14, you will also receive an Update Contact event when contact with a ship is re-established, even if there is no new sensor information. 'Re-established' in this context means that the ship was not detected by sensors of any type prior to the new detection
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 15, 2021, 05:33:08 AM
System AI Update

In v1.13, the system-level AI judges whether it has enough force to engage hostile ships in the system, based on what it has learned about the enemy forces in the past. If the AI judges the situation is to its own advantage, it will attack. However, it sometimes commits those available forces piecemeal, allowing the player to defeat them in detail.

I've updated the System AI logic for v1.14 so it will try to consolidate forces where necessary before committing to that attack. I'm flagging this here so players can report on any changes in AI behaviour (good or bad).
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 15, 2021, 06:30:12 AM
Aether Raiders

v1.14 includes a new 'spoiler' race, known as the Aether Raiders. They are inspired by the Dark Eldar in the WH40k universe and will function as a pirate faction. High level mechanics details follow, so stop reading now if you want to avoid spoilers.

The Raiders are based in a system that has no jump points and cannot be accessed via normal travel. As a result, they developed a technology known as the Aether Gate, allowing them to create their own pathways between their home system and other systems in the galaxy. The Aether Gates are temporary energy structures, although they can exist for months or even years before they are closed down. They cannot be detected by normal surveying methods, although the sudden appearance of a raider ship within existing sensor range will be a very good guide to the potential location.

As a result of basing their technology on Aether Gate travel, the Raider ships cannot travel via jump points.

The goal of the Raiders is to accumulate slaves and raw materials. They do this by scouting out systems to find alien shipping, preferably undefended commercial shipping, or small colonies. Shipping is destroyed and colonies are captured, allowing slave transports to collect life pods or colonists and salvage ships to loot the wreckage before heading back through the gate.

The Raiders wish to preserve their forces, unless a very good opportunity is presented, so they are more likely to avoid combat with warships than NPRs or other spoiler races. Raider ships are designed with that philosophy in mind. Generally, they will operate solo or in small groups, although a larger force may be encountered occasionally.

The Raiders are not interested in capturing territory or destroying other races, so they do not pose an existential threat. However, they can prove to be very disruptive to shipping lanes and frontier colonies and their ability to open gates to any system means that they can potentially appear anywhere without warning. New Raider ships will be built over time and their technology may improve too. The individual Raider ships are tracked, so you may encounter the same ship over time in different systems. Destroying ships will reduce their forces and consequently reduce the size and/or frequency of future raids.

Raiders must exit a system via the same gate through which they entered. However, once all raiders leave a system that gate will be shut down. If Raiders return to the same system, a new gate will be opened in a different location.

Aether Raiders have been added as a option to the Game window. There is also an option to prevent them appearing in NPR-claimed systems.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 15, 2021, 09:26:04 AM
Loss of Cargo

When a ship is destroyed, a list of cargo will be included in the destruction event. This includes installations, minerals, components, trade goods, colonists and ground unit formations
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 15, 2021, 09:27:45 AM
Civilian Contracts

I've been reviewing the civilian contracts code to find the long-standing bug. As a result, I decided to simplify the way that supply and demand functions.

For v1.14, as soon as a freighter accepts the contract for a given installation, even if it is in a different system to the pickup point, the supply and demand amounts for the start and destination populations are adjusted accordingly. This makes it much easier to see if the contracts are being met, even though the involved ships may still be underway, and eliminates the potential for oversupply.

If a civilian freighter is lost to enemy action while carrying an installation, the amount lost will be added back to the demand of the destination population.

If a civilian freighter is lost to enemy action before loading an installation, the amount lost will be added back to the supply of the pickup population and to the demand of the destination population.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 15, 2021, 06:22:03 PM
Minimum Jump Engine Size

Minimum Jump Engine Size was intended as the smallest size jump engine that could jump other ships in addition to the mounting ship. A bug allowed ship with a 'self-jump' drive to jump other ships in standard transits when it did not jump itself. After some consideration, I've decided to leave the bug functionality as is, with one minor change. The new rule is as follows:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 16, 2021, 06:13:02 AM
Logistics and Cargo Handling

In v1.13 and earlier, only a ship commander and the parent admin command structure used their logistic bonus to speed up loading and unloading cargo. For v1.14, planetary and system governors will also contribute.

The full calculation is as follows:

Cargo Handling Modifier = Number of Cargo Shuttle Bays * Admin Command Bonus * Ship Commander Logistics Bonus * Planetary Governor Bonus * Sector Command Bonus * Race Cargo Shuttle Load Modifier

Cargo Load Time = (Cargo Capacity * 20) / Cargo Handling Modifier.
Colonists Load Time = (Colonist Capacity * 10) / Cargo Handling Modifier.
Ground Forces Load Time = (Size of Force Loaded * 20) / Cargo Handling Modifier.

If there are one or more spaceports or cargo handing stations on the planet, that adds a single extra cargo shuttle bay to the calculation.

An admin command must have a commander for its bonus to apply. That bonus will apply even if the ship does not have a commander (this is a general rule for admin commands for all bonuses). Admin commands higher up the hierarchy will also apply if there is an unbroken chain of commanders.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 19, 2021, 09:33:41 AM
Overhauls and Movement Orders

For v1.14, you can set movement orders that follow overhauls in the order list.

When a fleet is in overhaul, any existing movement orders will be ignored. Once the overhaul is complete, the fleet will begin following the orders. If an overhaul is abandoned, the fleet will begin following the orders but with the penalties for an abandoned overhaul.

When a fleet completes an 'Overhaul' movement order and moves into an overhaul state, any additional orders will remain in the queue, awaiting completion of the overhaul.

If the cycle orders flag is set, the completed 'Overhaul' movement order will be adding to the end of the movement order list. The Repeat option can also be used for order lists that include an 'Overhaul' movement order.

Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 21, 2021, 12:33:18 PM
Alien Artifacts

I've implemented the Alien Artifacts trade good for v1.14.

The demand for alien artifacts is handled like most other trade goods. Annual demand is equal to population size in millions multiplied by any wealth modifiers. The wealth modifier is 1 without tech advances or environmental or political modifiers.

The supply of alien artifacts is generated by the exploitation of ruins. A new 'alien artifact' recovery type has been added with the same recovery chance as a manned mine. Each artifact recovery will generate from 4-200 artifacts (4xD50). I have increased the average number of installations for each ruin type to account for the extra artifact recoveries.

Once the artifacts are generated, they appear as a trade good that can be shipped by civilians. Any population of five million or more will have a demand for the artifacts.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 30, 2021, 04:47:59 AM
Collateral Damage

I've read a number of reports that collateral damage is high enough to be a disincentive to ground combat, especially for large-scale combat. The original intention was for collateral damage to add a meaningful decision in the use of lighter forces to avoid damage vs heavy forces to win more quickly. However, given the complexity of ground combat and the difficulty in intuitively assessing likely outcomes, I've decided to substantially reduce collateral damage so it becomes a side-effect of combat rather than a significant, but opaque, factor in decision-making.

The collateral damage rules will remain as before (see link below), except that the final divisor will be 50,000 rather than 10,000. This has the effect of reducing collateral damage by 80%.
http://aurora2.pentarch.org/index.php?topic=8495.msg110508#msg110508
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on May 30, 2021, 09:15:30 AM
Regenerate Jump Points and Minerals

Two new buttons have been added to the System View window in SM Mode; 'Regen JP' and 'Regen Min'.

Regen JP will delete all existing jump points in the currently selected system, breaking any existing links, and then generate a new set of jump points. A popup will allow the player to set a minimum number of jump points.

Regen Min will delete all existing mineral deposits in the currently selected system, then run the standard mineral generation process for each body (which can still result in no minerals). Any bodies with existing colonies will be excluded from this process.

The SM buttons also include 'No Geo Survey' and 'No Grav Survey' which will remove the selected survey information for the viewing race.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on June 09, 2021, 10:26:20 AM
Rename Alien Ground Units

The Intelligence window now gives you the option to rename each alien ground unit class in the same way as an alien ship class.

The updated name will be used in all ground combat reports.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on June 09, 2021, 10:34:52 AM
Contacts as Move Destination

When using an alien ship as a move destination, you are actually following one of the contacts associated with that ship (active, thermal, EM or sensor emission). When you lose the contact type you are following, the current movement order has no destination and will be cancelled. Even when you can still see the ship via a different contact type, the order still has to be manually changed to follow that type.

For v1.14, when you lose a ship contact, the game checks for any other current contacts for the same ship and automatically changes the movement order to the remaining contact.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 18, 2021, 09:14:07 AM
Default Movement Actions

On the movement orders tab of the Naval Organization window, double-clicking a destination will trigger a default movement order for that destination without having to select the order type. For example, double-clicking a jump point in the destination list will create a 'Standard Transit' order for that jump point. This 'default action' for double-clicks can be toggled on/off using a new 'Use Default Movement Actions' checkbox.

The default actions for each destination type are as follows:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 02, 2021, 09:25:02 AM
Fleet Raise Shields Button

Fleets now have an Raise/Lower Shields button in the same way as Ships.

If all ships with shield generators have active shields, the button will read 'Lower Shields' and will turn off the active shields. If one or more ships have inactive shield generators, the button will read 'Raise Shields' and will turn on all inactive shields in the fleet. If a fleet does not have any ships with shield generators, the button will not appear.

If you want a fleet with only some shields active to turn them all off, then press the button twice.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 03, 2021, 08:09:37 AM
Minimum Player Systems for Spoilers

Three new fields have been added to the Create Game window to specify Minimum Known Player Systems for Aether Raiders, Star Swarm and Invaders. These can only be set on game start.

If the total number of player systems is less than the specified number then:
Note this is not the same as turning these spoilers off. Raiders and Swarm will still gain tech in the background and Invaders will use the full time since game start to generate forces when they do eventually invade. This option is simply to delay the encounters until the player empire is larger.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 04, 2021, 07:16:42 AM
Events for All Player Races on Tactical Map

A new display option on the Tactical Map that appears in SM Mode allows you to see events for all player races. This is identical to the same function on the Events window. An additional column showing the race is displayed when this option is active.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 08, 2021, 08:53:06 AM
Eccentric Orbits

The next version finally adds something I have been considering for a long time – eccentric orbits. You can still have circular orbits as an option, but the assumption for future development will be the new orbital mechanics.

Stellar orbits have an eccentricity of up to 0.9 during normal generation, although they will generally be in the lower end of that range. You can edit this up to 0.95 by modifying the star. Even with this change, stellar orbits will not cross. As an example, a star with an 0.9 eccentricity will have an aphelion nineteen times greater than the perihelion whereas 0.5 eccentricity would be around three times greater.

Planetary orbits will generally have less eccentricity than stars and will often be close to circular. The maximum planetary orbit eccentricity without ‘Gas Giant Effects’ (see next post) will be 0.65, with 70% below 0.15 and 90% below 0.25. Unlike stars, the orbits of planets may cross due to their eccentricity (like Pluto and Neptune). Trojan asteroids and LaGrange points will follow the same eccentric orbit as their parent body. That isn’t entirely correct from a maths perspective, but keeping them in the same orbit looks a lot better and has minimal impact vs their true positions.

Each eccentric orbit is inclined independently. In other words, the ‘stretch’ in orbit for different stars or planets in the same system may extend in different directions. Bodies moving in eccentric orbits will move at different speeds, depending on their location, with the fastest speed at perihelion and the slowest speed at aphelion. Overall, they will still match the year for a circular orbit based on their semi-major axis.

Because planets will be changing their distance from the star, their surface temperature will change over time, which also may impact other environmental factors such as hydrosphere type and atmospheric content. As a result, each planet is effectively being terraformed as it moves. Colony cost will potentially become a range, rather than a fixed number. In practice, minimal eccentricity orbits will not have a major impact on colony cost and even when temperature changes it may not affect overall colony cost due to the greater influence of other factors. Even so, when choosing colony sites, the max colony cost should be considered in addition to the current colony cost.

Comets will no longer use their previous movement rules and will instead use the same orbital mechanics as planets, albeit with eccentricities ranging from 0.5 to 0.999. Their tails will point away from the star, rather than opposite the direction of travel. Their physical characteristics will remain as before.

Moon orbits will remain circular. The orbits of significant moons are likely to have minimal eccentricity anyway. For example, the four Galilean moons have eccentricity < 0.01, Titan is 0.03 and Neptune's largest moon Triton has an almost perfect circular orbit. Also, the conditions on a given moon will be far more influenced by the parent body’s eccentricity than its own. In summary, adding eccentricity to moons would add more to processing time than to gameplay.

About ten percent of non-Trojan asteroids will have eccentric orbits. Those that are eccentric will on average have greater eccentricity than planets, although nothing close to comets. The limited number of eccentric asteroids is to avoid any performance issues and also balance between interesting and overwhelming.

The system view window shows current distance, perihelion and aphelion for stars and planets and the colony cost display can be changed between current and max colony cost. When the ‘Max CC / Temp’ option is active, the total of habitable bodies displayed for each star and the body colours on the grid will reflect the max colony cost and the temperature shown for each body is the temperature used for the max colony cost (which could be higher or lower than current temperature). The atmosphere panel shows current, min and max temperatures and the colony cost panel shows both current and maximum temperature factors.

The population window shows both current and maximum colony cost, if the latter is higher than the former.  The galactic map has a new option so you can toggle between displaying the number of habitable planets based on current or max colony cost. Finally, you can toggle between normal and max colony cost on the mineral search window when filtering by colony cost. NPRs will base their colonization decisions on max colony cost, rather than current.

For Sol, all the planets, dwarf planets, comets, near-Earth asteroids and around 10-15% of other asteroids (the largest or most well-known) currently in the game have been assigned their correct eccentricity and semi-major axis. Their orbital position and direction of eccentricity is randomised. I could try to calculate the correct values for the former but given that games often start in different time periods, it isn’t worth it unless I also add a calculator to set the correct values for a given year.

Here is a screenshot of the inner Sol system. Mercury and Mars have the most eccentric orbits with values of 0.206 and 0.0934 respectively

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

This is with dwarf planet orbits shown and asteroids hidden

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

Oops! Forgot one.

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

Comet Orbits

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

Even further out comets

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

And the furthest...

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

Here is the System view for Sol with current colony cost and temperatures shown. Note that for Mercury, the major planet with the highest eccentricity, the current temperature is 424C and colony cost is 3.21. In the colony cost and atmosphere panels below, you can see the minimum and maximum surface temperatures are 362C and 509C respectively. The latter will result in a colony cost of 3.92, which is shown as the Max Temperature Factor.

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

Below is the same view with the ‘Show Max CC / Temp’ option selected. Mercury now has a colony cost of 3.92 and a temperature of 509C. The colony cost of Mars has changed from 2.11 to 2.51 and the temperature is shown as -70C, rather than -61C. For Mars, the minimum temperature is the worst case whereas for Mercury it is the maximum temperature. Earth is selected and shows the minimum and maximum temperatures of 11.8C and 16.6C, due to the small orbital eccentricity of 0.0167. Both of these are well within the habitable range so the colony cost remains at zero.

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

I’ll be starting a new campaign shortly to test the new mechanics. v1.14 is probably going to become v2.0 given the scope of this change.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 08, 2021, 08:57:33 AM
Gas Giant Effects

A new option for v2.0 is ‘Gas Giant Effects’. This is a change to system generation resulting from the influence of gas giants or superjovians on nearby smaller planets. Any gas giant with a mass of 50 Earth masses or higher will be checked. For gas giants with a mass between 50 and 200, the affected zone will be between Perihelion * 0.67 and Aphelion * 1.33. For gas giants with a mass up to 500, the factors are 0.5 and 1.5, while superjovians over 500 mass will affect from 0.4 to 2.0. The effects of gas giants are checked in descending order of mass.

Each dwarf planet in the zone will be affected in one of three ways: There is a 40% chance that D10 * 0.04 will be added to its orbital eccentricity, a 30% chance it will be captured as a moon by the gas giant and a 30% chance it will be ejected from the system.

Each terrestrial planet in the zone will be affected in one of four ways: 20% chance that D10 * 0.04 will be added to its orbital eccentricity, 40% chance it will be replaced by an asteroid belt, 20% chance it will be captured as a moon and 20% chance of being ejected from the system.

Each smaller gas giant or superjovian in the zone has a 70% chance of being ejected from the system and a 30% chance that D10 * 0.04 will be added to its orbital eccentricity. Note that the effects of the smaller gas giant on other planets will be checked after this change in eccentricity, so the alteration in orbit can affect other planets too. In reality, even the larger gas giant would have some impact on its orbit due to proximity to the smaller gas giant, but this is ignored to avoid disappearing down a deep rabbit hole.

Here is a example of a system where the fourth planet is a superjovian that has changed the orbit of the third (terrestrial) planet. The colony cost of the affected planet is now in a range between 3.22 and 5.24.

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

The overall effect of this option will be to add additional chaos to system generation and will likely result in fewer stable colony worlds. Note that our own solar system is broadly in line with the above rules. The asteroid belt was a terrestrial planet destroyed by Jupiter while Pluto was affected by Neptune. The four gas giants are far enough apart to avoid influence on each other (within the scope of the above).
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 08, 2021, 09:01:17 AM
Twin Planets

Each terrestrial planet has a 1% chance of creating a twin world, represented in-game as a moon with a radius above 90% of the parent planet.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 08, 2021, 12:50:17 PM
Single Orbit View

A new display option entitled 'Selected Orbit' has been added to the Tactical Map. If this option is active and you click on a system body, the orbit of that system body will be displayed even if the selected type of body does not have orbital paths displayed.

For example, the comet Borrelly is selected and all other orbits are turned off.

(http://www.pentarch.org/steve/Screenshots/Eccentric011.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 09, 2021, 12:27:00 PM
Largest Planet Selected

When you click on the map and there are multiple bodies that could be selected, the highest mass planet within a 5 pixel radius will be selected. The dots for planets and moons have a 5-pixel radius.

This means when you click on a zoomed out planet with multiple moons, you will always select the planet rather than one of the moons.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 09, 2021, 06:58:17 PM
Wide System View

v2.0 has a wide system view option, similar to the wide view for the class window. The only difference is an extension of the system body list to show an extra six columns. The wide version of the window is 1900 pixels vs 1440 for the normal view.

The system view also has several new fields connected to eccentric orbits.

(http://www.pentarch.org/steve/Screenshots/Eccentric016.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 10, 2021, 12:37:47 PM
Colony Cost Projection

One of the challenges with eccentric orbits will be comprehending future colony costs, so you can plan ahead accordingly. So far, you have the current colony cost plus the costs at perihelion and aphelion. Those are useful for understanding potential worst case scenarios, but with some orbits taking years, decades or even centuries, it is useful to have a more granular knowledge of how colony cost will change over time.

The colony cost projection view on the System View window projects the colony cost into the future based on weeks, months, quarters, years, etc. up to centuries. On the wide view you have up to twelve periods ahead for each level of granularity, unless SM mode is active in which case you will only see 8 due to space constraints. That is further reduced to 7 for normal view without SM mode.

The granularity extends to a single orbit for planets and for a single orbit of the parent body for moons. For example, you will see twelve future months for Mars, but only two future years. For Pluto, you can see 300 years into the future due to the 248 year orbit. In this latter case, the colony cost doesn't change much because Pluto can't get much colder.

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

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

(http://www.pentarch.org/steve/Screenshots/Eccentric022.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 15, 2021, 11:25:27 AM
Sub Fleet View

On the Naval Organization window, you can now view the summary details of a sub-fleet in the same way as a fleet. The two screenshots below show the differences between selecting a fleet and a sub-fleet. In both cases, the movement orders, standing orders and history tabs apply only to the fleet (or the parent fleet if a sub-fleet is selected).

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

(http://www.pentarch.org/steve/Screenshots/SubFleetInfo.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 17, 2021, 11:36:45 AM
Fleet Interception Interrupt

Due to the time advancement system, it is possible for an undetected alien fleet to suddenly appear on top of a friendly fleet. This is caused by the alien fleet passing through detection range within a single sub-pulse of the increment - 30 minutes for a 1 day increment for example.

In v2.0, for increments of one hour or more, Aurora will check the movement of all ships where the destination is either a hostile ship contact or a waypoint where hostile ships are also present. The latter case is because NPRs sometimes use waypoints to mark hostile ship locations. If the moving ship will move within 500,000 km of the destination, the increment is reduced to the length of time it would take to each that point. This is then rounded to an increment length which is a multiple of a standard sub-pulse length.

For example, a one day increment is selected. The moving fleet will reach 500k from the target in 25768 seconds. Increments between three and eight hours use 15m (900s) sub-pulses, so the increment length is rounded down to the highest number of 15m sub-pulses within the available time. In this case, that would be 25,200 seconds.

While this will still place the alien ship anywhere from 500,000 km to low millions of the friendly ship, it will no longer appear at point-blank energy range. This may not be 100% accurate, due to the wide variety of situations that can occur in Aurora, but it should massively reduce the chance of the unexpected, point-blank encounter.
           
EDIT: Testing has shown that a situation can occur where one fleet is chasing another but not catching it, in which case the shortened increments can repeat for a long time. Trying to calculate all the relative movements of the respective fleets would be one option, but would be complex and hit performance. Therefore, I've added a simpler solution. After five shortened increments of the same length, another shortening of the same length will be ignored.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 18, 2021, 10:04:34 AM
Starting Tech Points for NPRs and Spoilers

Currently, newly generated races ignore the research speed modifier for their starting tech points and apply it only for subsequent research. For v2.0, the research modifier will be applied to starting tech points for NPRs, Star Swarm, Rakhas and Aether Raiders

Regardless of modifier, the minimum starting points are 100k for Rakhas, 120k for NPRs, 400k for Raiders and 600k for Swarm (to ensure that key components and the essential nature of the threat are preserved). Precursors start with 600k tech points or 20% greater than the maximum player race starting points, whichever is higher. Invaders start with 1m tech points or 50% greater than the maximum player race starting points, whichever is higher.

This change won't make much difference to the early game (or to Precursors/Invaders for most games), but it will mean that later-game NPRs and Swarm in particular are not overpowered in low research rate games. If the early game is a concern, the options for minimum player systems can be used.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 03, 2021, 06:12:48 AM
Military Restricted Jump Points

Aurora already has the concept of 'Military-Restricted Systems', which prevent civilian traffic from entering a system. V2.0 adds 'Military Restricted Jump Points'. Applying this restriction prevents civilian traffic from entering either side of a jump point, but does not restrict civilian traffic from entering the systems connected by that jump point.

The restricted status of the jump point is set on the system view window, where an (MR) tag is added to the jump point destination. When a jump point is set as restricted, or the restriction is removed, the change applies to both sides of the jump point.

The Galactic Map has an option to display the restricted connections.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 06, 2021, 09:30:46 AM
Galactic Map Restricted Distance

A new 'Distance From Selected System (Restricted)' checkbox has been added to the Galactic Map.

This functions in the same way as the 'Distance From Selected System' checkbox, except the distance calculation will ignore any military restricted jump points. See below for a comparison between 'normal' distances on the left and 'restricted' distances on the right.

(http://www.pentarch.org/steve/Screenshots/GalMap006.PNG)  (http://www.pentarch.org/steve/Screenshots/GalMap005.PNG)   
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 13, 2021, 11:03:04 AM
Additional Conventional Systems

After reading a discussion on the forum, I've added a few extra systems to make conventional starts more interesting.
The troop transport bay and cryogenic transport are double the size of their standard TN equivalents, but otherwise equal in function and cost

Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 18, 2021, 04:40:52 AM
Hydrosphere Changes

Currently, when hydrosphere type changes from liquid to vapour there is an immediate conversion of all water on the surface into water vapour in the atmosphere. Conversely, when hydrosphere type changes from vapour to liquid there is an immediate conversion of all water vapour in the atmosphere into water on the surface, except for the small amount of water vapour that always remains in the atmosphere for a liquid hydrosphere. On the rare occasions where there is a direct change from ice to vapour or vice versa, the same principle applies.

Also currently, when terraforming a planet with a liquid or ice sheet hydrosphere type, adding water vapour to the atmosphere results in that water vapour gradually condensing to increase the hydrosphere at the rate of 0.1 atm per year, which adds 4% hydrosphere per year.

For v2.0, planets that change between vapour and liquid hydrosphere types will also use the gradual process. For vapour hydrosphere types, the water on the surface will evaporate at 4% hydro extent per pear. (so 50% would drop to 46% for example). Planets that change from vapour to liquid hydrospheres will follow the existing terraforming rules with no immediate condensation of existing vapour.

In effect, this means that vapour hydrosphere types can retain surface water and their main characteristic is now gradual evaporation of any surface hydro extent, rather than instant conversion to water vapour.

As a result, planets with relatively short but high eccentricity orbits will no longer have rapid changes between hydro extent and atmospheric water vapour. A planet that spends the majority of its time in the liquid water zone will tend to retain most of its water, whereas a planet that spends the majority of its time at a high temperature will end up with most of the water in the atmosphere. This also means that if you terraform a planet from the latter to the former, it can be made relatively habitable and won't revert to colony cost 2.00 due to instant evaporation of its water.

A planet that moves between ice and vapour during its orbit will still go through albedo changes, but this is much more manageable than the 'instant colony cost 2.00' issue of vapour hydrospheres.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 18, 2021, 05:45:10 AM
Dominant Terrain Change

For v2.0, any system bodies with an orbital period of less than six months, or bodies that are a moon of a planet with an orbital period of less than six months, can only be assigned dominant terrains that fall within the minimum and maximum temperatures of their orbit.

Bodies that fall outside this category will change dominant terrain based on their current temperature, which may change as they move around their orbits.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 18, 2021, 10:28:18 AM
New Planetary Terrains

Fourteen new planetary terrain types have been added for v2.0, taking the total to thirty-eight.

Seven of the new terrain types (Arid, Arid Mountain, Arid Rift Valleys, Grassland, Alpine Grasslands, Boreal Forest and Boreal Mountain Forest) have larger acceptable temperature ranges than any of the existing terrain types, but also have a minimum orbital temperature variation of thirty degrees.

The other seven are 'normal' terrain types and include Cold Steppe, Coniferous Forest, Rainforest, Mountain Rainforest, Subartic, Subartic Mountain and Alpine Forest.

As an example, the existing desert and cold desert terrain types have temperature ranges of 10C to 200C and -50C to 10C respectively and both have a maximum hydrosphere of 30%. The new Arid terrain has a range from -50C to 200C and the same max hydrosphere. So if a planet's orbit has too much variation for either desert or cold desert, it might still be suitable for Arid.

Grasslands and Alpine Grasslands vary between -40C and 80C, covering many of the existing types such as Steppe, Prairie, Savanna, etc. but will only be chosen for planets with a temperature range of at least 30C. Boreal Forest and Boreal Mountain Forest have a range between -50C and 40C with same 30C minimum range.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on September 18, 2021, 11:28:23 AM
Combat Capabilities vs Planetary Terrain

For the purposes of specializing ground units, any mountain or rift valley terrain type, including combined terrain such as Jungle Mountain, is treated as Mountain terrain for the purposes of Mountain Warfare.

Any desert, cold desert or arid terrain, including combined terrain such as Arid Mountain, is treated as Desert terrain for the purposes of Desert Warfare.

Any jungle or rainforest terrain, including combined terrain such as Jungle Mountain, is treated as Jungle terrain for the purposes of Jungle Warfare.

If a unit is specialised for the terrain type, the environment modifier is halved. These can be combined, so a unit with both Jungle and Mountain Capabilities would benefit from both in Jungle Mountain terrain and divide the environment modifier by 4.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on October 27, 2021, 06:47:43 AM
Admin Command Required Ranks

For v1.13, the required rank for an admin command is one rank higher than either the highest ranked ship commander directly under that admin command, or the highest required rank of any subordinate admin command, whichever is greater.

For v2.00, the required rank for an admin command will be the highest rank of the following:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on October 27, 2021, 06:49:47 AM
Automated Assignment for Naval Admin Commands

Assignment of admin commands has been manual until this point, due to the difficulty in knowing a player's intentions for a given admin command. For v2.0, I've added the option for players to specify what type of commander they need for an admin command and then let auto-assignment handle the selection. A new section on the Admin Command tab on the Naval Organization window provides options for selecting a suitable commander. The options work as follows:
Manual assignment will still be the best option for important admin commands or where the player wants to assign a commander above the required rank, but the above should significantly reduce micromanagement.

In addition, an optional Minimum Rank can be set for the Admin Command using the fourth dropdown in this section. This option may be used to prevent regular changes in the Admin Command Required Rank when subordinate fleets with commanders of different ranks are frequently moved in and out.

(http://www.pentarch.org/steve/Screenshots/AssignAdmin02.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 11, 2021, 05:24:04 PM
Highlighted Civilian Mining Colonies

Any civilian mining colonies from which you are purchasing minerals are highlighted in light blue. This won't apply if the colony has a population greater than zero, as green text will be used instead.

(http://www.pentarch.org/steve/Screenshots/CMCColour.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 27, 2021, 10:31:33 AM
Hull Numbers

v2.0 adds hull numbers for each ship. These are appended to the hull designation for each ship for display and reporting purposes. For example, the sixteenth destroyer built by a race will be designated as DD-16.

This designation is not affected by class. If the last destroyer of the Tribal class is DD-25, the first ship of the subsequent class with the same hull type will be DD-26.

An option on the Miscellaneous sub-tab of the Ship Overview tab on the Naval Organization window allows you to specify a hull number for a ship, as long as that hull number is not already in use. If you specify a number higher than any existing hull number for that hull type, new ships with the same hull type will increment hull numbers from that point onwards.

An option on the 'Ships in Class' tab of the Ship Class window allows you to reset the hull numbers of all ships with the same hull type. This is done in order of original creation.

There is a display flag on the Tactical Map display options to disable the display of hull numbers for a given race. The difference in display is simply DDG-51 Arleigh Burke vs DDG Arleigh Burke. This display flag applies to all uses of the hull number throughout the game - not just on the tactical map.

There is a display flag on the Miscellaneous tab of the Ship Class window that allows you to toggle hull number display for a specific class. For example, you may not want hull numbers for fighters. The hull numbers are still created for this class, but are not displayed if the toggle is off.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 28, 2021, 11:25:33 AM
Academy Training Rates

For v2.0, Academies will produce ten officers per year instead of five. This is to address the increased number of naval and ground force roles. The ratio of different officer types will change to maintain a similar number of administrators and scientists, so the extra will be naval and ground force officers.
Administrator, ground force and scientist commandants will also change their weighting. They have a percentage chance to generate an officer of their own type before the normal process is followed.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 28, 2021, 05:57:06 PM
Cargo Transfers

v2.0 allows the transfer of installations and minerals from one cargo ship to another (or to a station). Three new orders have been added (so far):
In principle, the task is similar to unloading to a population. To avoid complexities for many-to-many transfers, each transferring ship uses its own cargo handling capabilities. If the receiving fleet has at least one cargo shuttle bay, the transferring ships are treated as having one extra shuttle bay each.

The primary goal of the new orders is allow deep-space transshipment points, which creates the possibility of short-range freighters operating within a small area and delivering to a cargo station, from where longer-range freighters can distribute items to the wider empire. I will expand the transfer orders over time.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 29, 2021, 04:59:35 AM
No Officers Option

For v2.0, a 'No Officers' option has been added to the Ship Class window. A class with this flag will be ignored for the purposes of auto-assignment. Manual assignment will still be possible.

Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 30, 2021, 09:57:45 AM
On-Demand Promotions

Currently, Aurora uses an commander promotion system based on a ratio system. Naval commanders are promoted to maintain a 1:2 ratio between the number of commanders in a given rank and the number of commanders in the rank below it. Ground force commanders use a 1:3 ratio. For v2.0, this is changing to an on-demand promotion system that will operate during the automated assignment phase, rather than in a separate promotion phase.

Currently, automated assignment attempts to find a commander for a suitable role by searching through officers of the designated rank who have the primary bonus associated with the role and do not have a current assignment. For v2.0, an unsuccessful search will trigger a new search for commanders who are one rank lower and have the primary bonus. They must also have been in the lower rank for at least a year and do not have the 'do not promote' flag. If more than one candidate is found, the one with the highest primary bonus will be selected. If multiple commanders have the same bonus, the one with the highest promotion score will be selected. The selected commander is then promoted and assigned to the role. This applies to ship, ground and admin commands.

If the optional political bonuses are in effect, the political bonus will be added to the primary bonus when determining which commander to promote. The chance of the higher political bonuses on commander generation has been reduced.

There will no longer be promotions unless there are roles available to fill. This should result in a command structure that is reflective of the Empire's chosen naval and ground force doctrine.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on November 30, 2021, 10:16:52 AM
Commander Bonuses

Several commander bonuses have been tweaked to aid the new on-demand promotion system.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on December 01, 2021, 03:48:52 PM
Starting Commanders

Even though v2.0 introduces the concept of promotion on-demand, an Empire will still need an initial officer corps. This will be created used the current method of promotion based on ratios, using 2:1 for naval and 4:1 for ground. Once the game begins, promotion will be on-demand (or manual) only.

Starting commanders will be assigned an age of 21 + Random(5). For each rank they are promoted during the initial race creation their age will be incremented by 2 + Random(5).

I also considered having all officers start at the lowest rank and organically change as ships are built, but that prevents the age modification above and could look very odd. Also, Aurora doesn't actually track age. It tracks career start date vs current date and adds 21 years. Therefore adding 'Age' to starting officers is actually changing their career start date to before the game start date.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on December 09, 2021, 05:13:51 AM
Jump Shock

In v1.13, a ship cannot use its jump drive while suffering from jump shock.

For v2.0, this is changed to: "Any ship suffering jump shock cannot transit a jump point, even if the jump point is stabilised".
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 21, 2022, 06:47:39 PM
Limited Research Administration

A new game-level option called 'Limited Research Administration' has been added for v2.0.

When this is active, scientists will start with 20% + 1 of the normal research administration capacity. For example, a scientist normally starting with 15 admin would start with 4: (15 x 20%) + 1. The maximum starting admin will therefore be 7.

Any increases via experience will increase administration by one or two facilities.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 22, 2022, 06:54:55 AM
Commercial Jumps

For v1.13, commercial jump drives are required to transit ships with commercial engines and military jump drives are required to transit ships with military engines.

For v2.0, military jump drives can be used for transit by ships with either military or commercial engines (within the normal size limit of the jump drive).

This applies to both standard and squadron jumps.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 22, 2022, 07:59:47 AM
Automated Refuel Option for Colonies

In v1.13, the various standing or conditional orders that involve refuelling at a colony will use the closest colony with fuel and suitable installations.

For v2.0, you can toggle a colony to be ignored for automated refuelling orders.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 25, 2022, 04:10:48 AM
Cargo Holds Required

To make it easier to understand transport requirements, I've added the number of standard cargo holds for each type of installation at a colony to the Civilian tab of the Economics window.

(http://www.pentarch.org/steve/Screenshots/CargoPoints.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 26, 2022, 07:03:03 PM
Squadrons

For v2.0, I have added an extra organization layer to the Naval Organization window based on a new structure called a ‘Squadron’.

In mechanics terms, a squadron is an administrative sub-division of hangar space on a specific ship. A squadron is created (and named) using the new ‘Create Squadron’ button which becomes visible when a ship is selected. Any number of squadrons can be created for each ship. Once a squadron is created, ships can be dragged into it if they are in the same location as the squadron’s parent ship. Dragged ships will be moved into the hangar of the squadron’s parent ship so sufficient space must exist. If not, you will receive a popup to that effect and the transfer will not happen. You can also drag the entire squadron to a different ship, assuming the same location and sufficient hangar space.

You can ignore squadrons entirely and continue to use the existing mechanics, or perhaps create a single ‘squadron’ for the entire strikegroup for the convenience of having the parasite ships listed under the mothership on the tree view.

Two new movement orders have been added. “Land on Specified Mothership as Squadron” will operate in the same way as the “Land on Specified Mothership (+ Assign)” order with the additional effect that a new squadron is created for the mothership with the name of the landing fleet. All ships in the landing fleet will be assigned to that squadron. “Land and Join Specified Squadron” allows you to choose an existing squadron from a fleet selected as the destination for the movement order. The list of squadrons shown as destination options include the name of the mothership. The ships of the landing fleet will be assigned to the designated squadron once it lands on the squadron’s parent ship.

Using the Detach button while a squadron is selected will create a new fleet with the same name as the squadron and place all ships of the squadron into the fleet. Unlike detaching a sub-fleet, the empty squadron will remain attached to the parent ship because it only exists as an administrative structure of that parent ship. Squadron ships can also be detached individually or as a non-squadron group using the existing mechanics.

After launch, ships will be removed from the squadron. However, ships will remember the last squadron to which they were attached, which is known as their 'Assigned Squadron' (similar to assigned mothership vs current mothership). If you use the "Land on Assigned Mothership" order (now renamed as  "Land on Assigned Mothership / Squadron)" and a ship has an assigned squadron that is present on that mothership, it will be attached to that squadron after landing. Detached ships can also use the “Land and Join Specified Squadron” orders if they are unassigned or wish to join a new squadron.

I decided to use this administrative approach, rather than have squadrons independent of ships, to avoid a situation where the same squadron is scattered across multiple ships or has to be managed in a separate window. To move a squadron to a new ship, you can either use the drag-drop method noted above or detach the squadron from Ship A and send it to Ship B with the “Land on Specified Mothership as Squadron” order. The original (now empty) squadron will remain on Ship A so you may wish to delete that if you do not have a common naming scheme for squadrons.

The Rename, Delete and Award Medal buttons function as normal for squadrons. Deleting a squadron will only affect the administrative function. The squadron ships will remain in the parent ship’s hangar. Award Medal will award the chosen medal to all ships of the squadron. When you click on a squadron in the tree view, a list of squadron ships will be shown with the same information as the equivalent list for a fleet and the ‘Transported Items’ tab will display anything carried by the squadron. The other tabs will be hidden.

This new structure should make it much easier to visualize and manage strike groups.

(http://www.pentarch.org/steve/Screenshots/Squadrons02.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 28, 2022, 04:38:44 AM
Reduced Crew for Short Deployments

Currently the accommodation requirement for a ship class is based on the formula below. Personnel in this context is the total of crew and flight berths.

Accommodation = Personnel * (Planned Deployment ^ (1/3))

For v2.0, the accommodation formula above remains in place but it will use a minimum value of 3 for planned deployment (for the formula only). In addition, if planned deployment is less than 3 months, the formula below will be applied to the final crew (once all components have been included).

Crew = Round Down ( Crew * ( (Planned Deployment ^ (1/3)) / (3 ^ (1/3)) ) );

This effectively reduces the crew to the point where 3 months deployment would be the same in accommodation terms as the full crew with the original planned deployment. In other words, the accommodation requirement is the same in both cases but now the crew is smaller. As this is rounded down, it will have a slight beneficial effect for ships with small crews and very short deployments. The minimum crew is 1.

For example, this fighter with the v1.13 rules appears as follows:

Viper MK I class Fighter      300 tons       13 Crew       57.3 BP       TCS 6    TH 48    EM 0
8001 km/s      Armour 1-3       Shields 0-0       HTK 1      Sensors 0/0/0/0      DCR 0      PPV 1.65
Maint Life 3.12 Years     MSP 35    AFR 60%    IFR 0.8%    1YR 5    5YR 81    Max Repair 24.00 MSP
Captain    Control Rating 1   
Intended Deployment Time: 0.9 days    Morale Check Required   

Zeus Drive Systems ZDS-48B Gas Core Drive (1)    Power 48.0    Fuel Use 924%    Signature 48.00    Explosion 20%
Fuel Capacity 10,000 Litres    Range 0.65 billion km (22 hours at full power)

Ares Kinetics VC-2 Viper Cannon (1x2)    Range 40,000km     TS: 8,001 km/s     Power 1.5-1.5      ROF 5       
Hyperion HV-1 Viper Fire Control (1)     Max Range: 64,000 km   TS: 8,000 km/s
R-1B Gaseous Fission Reactor (1)     Total Power Output 1.5    Exp 10%
Artemis-2M Missile Detection Sensor (1)     GPS 3     Range 2.1m km    MCR 192.7k km    Resolution 1

With the new rules, the crew is reduced to 2 and an extra 2 tons are available, which have been used to increase fuel capacity.

Viper MK I class Fighter      300 tons       2 Crew       57.3 BP       TCS 6    TH 48    EM 0
8001 km/s      Armour 1-3       Shields 0-0       HTK 1      Sensors 0/0/0/0      DCR 0      PPV 1.65
Maint Life 3.26 Years     MSP 35    AFR 60%    IFR 0.8%    1YR 5    5YR 75    Max Repair 24 MSP
Captain    Control Rating 1   
Intended Deployment Time: 0.9 days    Morale Check Required   

Zeus Drive Systems ZDS-48B Gas Core Drive (1)    Power 48    Fuel Use 923.76%    Signature 48    Explosion 20%
Fuel Capacity 12,000 Litres    Range 0.78 billion km (27 hours at full power)

Ares Kinetics VC-2 Viper Cannon (1x2)    Range 40,000km     TS: 8,001 km/s     Power 1-1.5     RM 40,000 km    ROF 5       
Hyperion HV-1 Viper Fire Control (1)     Max Range: 64,000 km   TS: 8,000 km/s     84 69 53 38 22 6 0 0 0 0
R-1B Gaseous Fission Reactor (1)     Total Power Output 1.5    Exp 10%
Artemis-2M Missile Detection Sensor (1)     GPS 3     Range 2.1m km    MCR 192.7k km    Resolution 1

This is really intended for flavour purposes as the actual mechanics impact is minimal, beyond reducing the overall crew requirements for naval forces that are fighter-heavy.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 28, 2022, 01:52:55 PM
Small Craft Refuelling System

I've added a Small Refuelling System to v2.0. This is 50 tons and has a flow rate of 10,000 litres per hour. It can only be mounted on ships of 1000 tons or less and only used to refuel ships of 1000 tons or smaller. This is envisaged as closer to the modern systems used for aerial refuelling rather than the more complex system on replenishment ships which is why it is only suitable for use with small ships.

The Small Refuelling System can interact normally with Refuelling Hubs and Colonies. When tankers are checked as the destination for conditional orders, the size of the ships in the fleet will be taken into account. Fleets with ships larger than 1000 tons will ignore tankers equipped with the Small Refuelling System.

Here is an example of a 1000-ton jump-capable tanker:

Raptor-T class Tanker      1,000 tons       12 Crew       70.7 BP       TCS 20    TH 64    EM 0
3201 km/s    JR 1-50      Armour 1-8       Shields 0-0       HTK 6      Sensors 0/0/0/0      DCR 0      PPV 0
Maint Life 1.45 Years     MSP 50    AFR 200%    IFR 2.8%    1YR 26    5YR 395    Max Repair 32 MSP
Captain    Control Rating 1   
Intended Deployment Time: 1 month    Morale Check Required   

Apollo-10 Military Jump Drive     Max Ship Size 1000 tons    Distance 50k km     Squadron Size 1
Zeus Drive Systems ZDS-64 Gas Core Drive (1)    Power 64    Fuel Use 100%    Signature 64    Explosion 10%
Fuel Capacity 350,000 Litres    Range 63 billion km (227 days at full power)
Refuelling Capability: 10,000 litres per hour     Complete Refuel 35 hours

Artemis-2M Missile Detection Sensor (1)     GPS 3     Range 2.1m km    MCR 192.7k km    Resolution 1
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on January 29, 2022, 09:56:17 AM
Launch All

A "Launch All" button has been added to the Naval Organization window. This will appear when a Fleet, Sub-Fleet or Ship is selected and parasites are present.

Pressing the button will launch all parasites from the selected ship, sub-fleet or fleet into a single new fleet. If the parasites are attached to one or more squadrons, those squadrons and their attached parasites will be created as sub-fleets within the new fleet. Empty squadrons will be ignored.

Below is an example of the fleets created by first using 'Launch All' on the Galactica and secondly on the Battle Fleet.

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

And yes, Squadron 10 wasn't very imaginative with their nickname, but that is an actual squadron on the TV show.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on February 01, 2022, 04:38:38 AM
Non-Combat Resupply

Ground forces will resupply out of combat in v2.0 if they are at a population and logistics units are available.

The amount of supply required will be reduced by the formation commander's logistics bonus. In the existing combat resupply, the commander's logistics bonus is the chance of 'free' supply for each combat round.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on February 20, 2022, 05:42:53 AM
Academy Commandant Display

For v2.0, the Academy Commandant at each colony with one or more military academies will be displayed under the planetary governor on the Governor tab of the Economics window.

(http://www.pentarch.org/steve/Screenshots/Academy.PNG)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 18, 2022, 02:55:00 PM
STO Targeting

This isn't a mechanics change per se, but an update to the AI.

I've noticed that the AI doesn't always make sensible decisions on STO targeting, mainly due to prioritizing low chance/impact shots against warships, while ignoring much closer commercial or unarmed targets. Therefore I've added a little more intelligence to the AI STO targeting code and it will use a custom priority list based on distance, size and known capabilities, rather than the player options (largest, fastest, random, etc.).
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 19, 2022, 07:10:52 AM
AI Ground Offensives

Currently, the AI will only launch ground offensives with certain formation types, such as armour. This can lead to situations where a player can land ground forces on a planet defended by AI infantry and then avoid combat by setting everything to support or rear echelon.

For v2.0, the AI will assess the option of mounting offensive operations with formations that would normally remain in a frontline defence field position. The AI will base this decision on what it knows about player forces, including armour, hit points, offensive capabilities etc., based on the same 'Alien Ground Unit Class' intelligence available to a player. If no information is available, the AI will assume basic infantry until it finds out information to the contrary. This means that an AI may launch offensive operations against a reluctant landing force and then move back to a defensive posture once it learns more.

The AI will take into account the benefits of retaining fortification bonuses vs launching offensive operations.

(you might guess there is a ground invasion happening in my current campaign) :)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 20, 2022, 11:06:43 AM
Mobile Repair Bays

A new component type, Mobile Repair Bays, has been added for v2.0.

Each Mobile Repair Bay is 2000 tons, costs 120 BP and adds 1000 tons of Repair Capacity to a ship. They are a commercial system and stack in the same way as hangar bays. The development cost is 5000 RP.

When in orbit of a population, each ship with Repair Capacity will appear in the population's shipyard list and will function exactly the same as a Repair Yard of the same capacity, except they do not require workers and cannot be expanded or otherwise modified. The shipyard name displayed in the shipyard list is the name of the parent ship. Ships with Repair Capacity can perform repair and scrapping tasks. If a ship-based repair yard is active, the parent fleet cannot be given orders.

The build cost of Repair Yards has been reduced to 1200 BP, although their upgrade costs remain the same as commercial shipyards. In general, Mobile Repair Bays are a little more expensive than Repair Yards, especially for greater capacities, and cannot be expanded, but have much greater strategic flexibility. In effect, Mobile Repair Bays allow forward repair bases to be established without the need for supporting colonists. Here is an example ship:

Phoenix class Repair Ship      58,446 tons       1,160 Crew       3,354.2 BP       TCS 1,169    TH 1,500    EM 0
1283 km/s      Armour 1-134       Shields 0-0       HTK 106      Sensors 6/8/0/0      DCR 1      PPV 0
MSP 35    Max Repair 120 MSP
Captain    Control Rating 1   BRG   
Intended Deployment Time: 3 months   
Repair Capacity: 20000 tons

Commercial Ion Drive (5)    Power 1500    Fuel Use 2.48%    Signature 300    Explosion 4%
Fuel Capacity 250,000 Litres    Range 31.1 billion km (280 days at full power)

Artemis-30NB Navigation Sensor (5)     GPS 1920     Range 31.5m km    Resolution 120
Themis TH-6 Passive Sensor (5)     Sensitivity 6     Detect Sig Strength 1000:  19.4m km
Themis EM-8B Passive Sensor (5)     Sensitivity 8     Detect Sig Strength 1000:  22.4m km

And yes, I know I said I wasn't adding anything else to v2.0 :)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 24, 2022, 10:21:05 AM
Changes to Commercial Hangar Repairs

Due to the addition of dedicated Repair Bays, the repair capabilities of commercial hangars are being changed for v2.0.

Commercial hangars can perform repairs on commercial ships as they do now.

Commercial hangars cannot perform repairs on military ships. Military ships in commercial hangar bays can perform their own repairs, but without the benefit of the parent ship's damage control rating or maintenance supplies. Military ships in commercial hangar bays will still replenish maintenance supplies from the parent ship as normal. In effect, this means that a military ship in a commercial hangar bay cannot perform a repair unless it has sufficient inherent maintenance capacity for that repair and it cannot repair armour. It is treating the parent ship as a supply ship instead.

Military hangars can still repair both military and commercial ships and will repair the armour on both.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 25, 2022, 12:26:40 PM
Deep Space Populations

v2.0 introduces a new type of system object known as a Deep Space Population (DSP).

A DSP can be created in the same way as a named waypoint, by clicking the ‘Create Deep Space Population’ button on the Miscellaneous tab of the Tactical Map, selecting a location on the map and choosing a name. A new population will be created at that location and it will be displayed on the map as a yellow dot with the associated population name. The DSP will appear in the Economics window like any other population, except for the suffix (DSP)

The DSP will function as a normal population with the following exceptions:
This is a completely new concept so I will probably edit the post over the next few days as I encounter things I haven't thought of yet :)
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on March 26, 2022, 01:04:23 PM
Population Changes and Ark Modules

Based on discussion on the forums, I've decided to change the way that colonies distinguish between surface and orbital populations. Currently, orbital habitat modules function as a form of infrastructure. If you add one to a population, it creates extra room for the population to grow into. However, if you remove the habitat, the entire population remains on the planet. This is because the population is associated with the planet, not the habitat.

For v2.0, Orbital Habitat modules are being renamed as Ark Modules. They will be able to transport colonists in the same way as cryogenic modules, although they are far larger because the colonists are not frozen in cryogenic chambers. The Cryogenic Transport category on the Class window has been renamed Colonist Transport and the Ark Module will appear in this category once developed. Ships will have distinct Cryogenic Transport and Colonist Transport capacities, with the latter reflecting the Ark Module capacity. A ship can have both cryogenic and Ark modules, but only the latter will contribute to a colony while the colonists are still on board.

When a ship or station with an Ark Module is in orbit of a colony, any colonists in the Ark Module will be considered as 'orbital population' for that colony. The colonists on the surface will be 'surface population'. The two populations are distinct and growth on the surface will not affect the colonists on board the Ark Modules. In effect, the Ark Modules are acting in a similar way to maintenance modules or terraform modules, in that they are 'lending' their capabilities to the colony. In this case, the colony gains extra population. If the ship or station with the Ark modules leaves orbit, it will take its colonists with it.

This new function also allows huge Ark ships that can transport populations through space and then hold position at temporary DSPs to conduct ship-building, etc., without the need for a suitable habitable world that would be required in the case of cryogenic transport.

Any ship loading or unloading colonists will interact only with the surface population, although the ship with Ark Modules could load colonists that a different ship has just unloaded. Depending on playtest, I may also add load/unload colonist orders that have an Ark ship as a target, although I suspect this would be seldom used in practice. Ark Modules will more likely load colonists once and then retain them indefinitely (with the exception being an orbital colony that builds its own Ark ships).

As the population in Ark modules is awake and functional, there will be some population growth if there is space capacity. This growth will be at an annual rate of 5% x (Space Available / Total Capacity). For example, if an Ark Ship is only carrying 75% of capacity, the annual pop growth will be 1.25%. Available space is likely to be a rare situation, but it could happen after damage and repair, or if an Ark loads a surface population less than its capacity.

Ark Modules have built-in life support and do not need any agricultural/environmental population (as is the case now with orbital habitats). Therefore, the orbital population does not have to be the same species as the surface population and multiple different species can contribute from orbit.

In most cases, colonies will function in a very similar way to now. However, the distinct division between surface and orbital populations does result in some changes:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 06, 2022, 05:57:14 PM
One Second Sub Pulses

For v2.0, increments of 5 seconds will run with 1-second sub-pulses.

In general, this is to make very short-ranged enemy combat more realistic in terms of moves and counter-moves and prevent some odd situations. For example, when fast units are trying to follow an enemy fleet at a certain range, that distance can vary significantly from what was intended if they move first. It can also create situations where fast units with a speed advantage and relatively short-ranged weapons (fighters) cannot get into weapon range of a slower ship that can move more than their weapon range in a 5-second increment.

A 5 second increment will only be interrupted at the end of the increment, not after one of the sub-pulses. Because of this, you may see explosion or energy impact contacts in the wake of ships, rather than on top of them, because point defence and missile impacts will happen mid-increment.

There is a new game option to disable 1-second sub-pulses if this causes a performance issue.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 07, 2022, 05:03:27 AM
Cease Fire All Ships

I've added a 'Cease Fire All Ships' button to the Miscellaneous tab of the Tactical window. Clicking this will apply a cease fire order to every fire control of every ship in your empire.

This is for convenience in large battles, but also to make it easier to avoid a situation where an unknown ship is triggering 'active firing' interrupts.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 16, 2022, 09:48:11 AM
Detailed Combat Events

Many different types of combat events, such as point defence, ship to ship combat and damage, all fall under a single event type - Combat Summary. This limits flexibility for hiding a subset of those events or using different event colours. As an example, in a fighter-heavy campaign, this would allow you to prevent the event window being spammed by fighter point defence or hundreds of small attacks.

For v2.0, Combat Summary events have been split into eighteen different types:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on April 16, 2022, 10:29:55 AM
Fleet Point Defence Summary

A new event has been added for v2.0 that summaries all energy-based point defence by weapon type within each fleet. Here are two example event texts from my current campaign:

Leonidas Attack Force: Ares Kinetics AK-25 Railgun  18 / 320 / 5.6%   Ares Kinetics G20-8 Gauss Cannon Turret  20 / 92 / 20.8%
Viper Squadrons: Ares Kinetics VC-2 Viper Cannon   19 / 146 / 13%

The above reads as the Leonidas Attack Force used two different weapons for point defence. The AK-25 Railgun, which scored 18 hits from 320 shots for a hit rate of 5.6%, and the G20-8 Turret, which scored 20 hits from 92 shots for a hit rate of 20.8%. The Viper Squadrons used only one weapon, the VC-2 Cannon, which scored 19 hits from 146 shots for a hit rate of 13.0%

This new event will allow players to hide some of the more detailed events if desired and just see a summary of the fleet's point defence performance. In this case, there are four Battlestars and two hundred and eighty Vipers, so I will probably keep the individual Battlestar results, plus the summary, but hide the individual fighter events and just use the summary.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 03, 2022, 06:59:51 AM
Sol Bodies with Water

I've added frozen water to the following Sol system bodies:
There are some smaller bodies such an Enceladus that likely have water, but their gravity is too low to support an atmosphere so the presence of water would not help in colony cost terms.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 03, 2022, 07:17:57 AM
Water without Atmosphere

In v1.13, a body generated without atmosphere will automatically be generated without water.

For v2.0, a body without atmosphere has a 20% of an ice sheet if the temperature is 223K (-50C) or less and has gravity of at least 0.1G.

If an ice sheet is present, the hydro extent will be generated normally.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 03, 2022, 07:52:20 AM
Terraforming Installations

Ground-based Terraforming Installations have several disadvantages over the space-based Terraforming Modules.
I considered making space-based terraformers more expensive or larger but I am happy with them in general, so I have decided to make the following changes to the ground-based Terraforming Installations:
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 03, 2022, 11:21:54 AM
Stockpile Transfers

v2.0 adds new 'Transfer Comp' and 'Transfer Missile' buttons to the GU/Stockpile tab of the Economics window. Both function in a similar way.

If you select either a component type or ordnance type from the stockpile and click the corresponding button, there is a popup window listing every other population on the same body, including known alien populations, and the available amount of the component or ordnance type. You select a destination population and the amount to transfer and click OK to make the transfer. There is also a Cancel option.

The populations are listed with Population Name, Population Race (using alien race name where needed) and Population Species, which allows differentiation between different target populations.

If the amount is altered to zero or less, no transfer takes place. If the amount is altered to an amount greater than the available amount, then the available amount is used.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 03, 2022, 01:14:46 PM
Class Design Highlighting

On the treeview for the components contained within a class, any obsolete components will be displayed in orange. Components for which the parent race has no research data, usually alien in origin, will be displayed in red.

Obsolete components in the Race Components list will also be highlighted in orange (which can only happen if the Obsolete checkbox is checked).

A new checkbox called Obsolete Comp has been added below the class treeview. When this is checked, any classes that contain obsolete components will be displayed in orange. Any class containing non-researched components will be displayed in red. I've included a checkbox option in this case because most classes are likely to be in this category in a longer game.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 04, 2022, 10:20:31 AM
AI Threat Assessment Changes

The AI in C# Aurora makes an assessment of the threat presented by each hostile ship and uses that threat level in decision-making. This is partly based on Tactical Intelligence information and partly filled in by using factors such as engine type, size, speed, etc.

Currently, the AI is giving too much weight to the high speed of small craft such as fighters when considering their threat level, so I have made adjustments in that area.

I've also added an AI ability to make assessments about whether a hostile ship may still be in jump shock (time since transit, whether it has fired since transit, etc.) and to reduce threat considerably if that is a positive assessment. This should improve the AI reaction to jump assaults.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 14, 2022, 05:04:52 AM
Hostility Modifier

A new Hostility Modifier option has been added to the Game Options.

Whatever number is chosen (default zero) will be added to the Xenophobia and Militancy attributes of each NPR and deducted from their Diplomacy and Trade attributes. The minimum and maximum attribute values are 1 and 100.

If an NPR has Xenophobia of 100, it will automatically assign any other race as hostile and make no attempt to communicate.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 15, 2022, 05:51:46 AM
Black Holes

Black holes have been added to v2.0

These are 'normal' black holes, rather than the more dramatic VB6 black holes, and do not affect the movement of ships. There are fifteen types, ranging in mass from 1 to 120 solar masses. All black holes are planetless.

In a random stars game, they have a 1.5% chance of being generated and may have one or more companion stars.

In a real stars game, eighty random black holes are generated and added to the Known Stars list (currently 4417 stars). Their location is based on random XYZ coordinates with a range of plus or minus one hundred light years. They do not have companion stars, with the rationale being that these are currently undetected black holes.

Black holes with a mass of 20 or more gain a fixed number of additional jump points, with that number depending on mass. This is in addition to the higher chance of jump points associated with massive stars.

Their main game impact will be the creation of systems that are hard to survey but generally have more jump points.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 16, 2022, 10:59:02 AM
Mass Modifier for Jump Points

The distance from the system primary to the outer ring of survey locations and the number of points to survey each location is modified by the mass of the system primary. The maximum distance for a jump point is the same as the outer ring.

In v1.13, this modifier is the square root of the primary mass in solar masses. Sol is the basis, with 400 points per location and 40 AU (6b km) as the max distance of the outer ring of survey locations.

For example, a star like Altair, with 3.1 solar masses, would require 704 points per location with a max jump point distance of 70 AU. Ras Alhague with nine point six solar masses would be 1239 points and 123 AU, while Rigel, at 21 solar masses would be 1833 points and 183 AU.

For v2.0, this modifier is changing to the cube root for any stars greater than one solar mass. For example, Altair will now be 583 points and 58 AU, Ras Alhague will be 850 points and 85 AU (18.6b km) and Rigel will be 1103 point and 110 AU.

This is to make very large systems easier to survey, although still a considerable effort.
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on July 18, 2022, 04:18:17 AM
Cloaks and Combat

This is more of a bug-fix, but I thought it was worth mentioning separately.

In v1.13, a ship with a cloak is always treated as having the cloaked cross-section, even if the cloak is damaged. For v2.0, the current state of the cloak will be taken into account, so the cross-section will change to normal for detection and combat purposes if the cloak is damaged

I also fixed a bug that allowed missile fire controls to lock on to a cloaked ship using the full cross-section, rather than the cloaked cross-section
Title: Re: v1.14.0 Changes List
Post by: Steve Walmsley on August 01, 2022, 10:57:30 AM
Wealth History

I've added a new section to the Wealth/Trade tab of the Economics window. This shows the wealth balance in each previous construction phase (with the current phase at the top).

The new table includes the date and length of the construction phase, the amount of wealth at that point, the total change in wealth since the previous increment and the daily rate of change (as different increments are different lengths).

This replaces the wealth change amount in the title bar, which was unreliable anyway.