Aurora 4x
C# Aurora => C# Mechanics => Topic started 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
- The ground construction code will check to see if anything should be moved from the queue to active tasks before the 5-day construction cycle commences.
- To improve performance, fleet histories for NPRs and civilian shipping will be retained only for the last five years.
- To improve performance, NPRs will not generate 'Out of Fuel' events. This is only for display purposes and will not affect NPRs reacting to low fuel.
- Added Super-Heavy Bombardment ground component.
- Updated the rescue code so that the fleet ship that picks up a specific life pod is the first ship in a list ordered by Descending Available Cryogenic Capacity then Descending (Class Crew - Current Survivors)
- Changed the class designation for auto-assignment so that cargo holds and ELINT are only checked very late in the process.
- 'Assume Fleet is Jump-Capable' checkbox on Fleet window is now applied on a fleet basis, rather than as a general setting.
- Added 10cm railguns as a point defence choice for NPR designs.
- Bodies in Sol system will now start on a random bearing.
- Added Race Intelligence Points to Intelligence Window.
- Comets in Sol system will now start at a random distance.
- There is a rare chance of encountering large or very large comets.
- Added display of STO weapon ranges to the Tactical Map, when the weapon range display option is selected.
- Some Spoilers and NPRs (based on Xenophobia) will not bombard populations except when targeting STO units.
- Maintenance Modules reduced in cost from 200 to 100 BP in line with earlier reduction in cost of maintenance facilities.
- Added a Raise/Lower Shields button for Fleets.
- When removing water vapour via terraforming, the process will no longer be terminated due to a lack of water vapour in the atmosphere, unless the hydro extent is zero.
- Ships in orbit of a conquered colony will only surrender if the population is at least ten million.
- NPR ship designs may include reduced-size launchers.
- Estimated travel time displayed for mineral packets when a mass driver destination is selected.
- Hull abbreviation for classes and ships shown in construction options on Shipyard and Industry tabs of Economics window.
- Spacebar can be used as a hot key for double-click when adding or removing components from a class design.
- The research time for queued projects now includes any ancient construct bonuses.
- Halved the transport requirements for naval headquarters and spaceports to 10 and 40 cargo holds respectively.
- Removed the 50 starting research lab limit for NPRs.
- Factory-built Fighters and Space Stations will use their class naming theme.
- Ground force formations can be drag-dropped between different bodies if SM mode is active.
- Systems with a single star will no longer use "-A" in the star or system body names.
- Wreck sizes will no longer be rounded down to the nearest 50 tons.
- Repair Yard build cost reduced from 2400 BP to 1200 BP. Expansion cost remains the same.
- When disassembling a component, you are informed which tech you gain points toward and, if different, the tech from which those points originated.
- Added SM-only Edit Wealth button to the Wealth/Trade tab of the economics window.
- Removed the star system name for moons and planets in the second field of the mineral search window.
- Automated Damage Control is now the default for new ships. It can be unset by players as needed for detailed control.
- Commanders window will no longer run the commander search when the form is opened.
- Automated design for tankers and harvester sets a minimum fuel level of 10%.
- Added logistics units to Rakhas infantry and armour formations.
- Shield regeneration moved to before the movement phase, instead of after movement but before combat.
- When a shipyard task is created, any movement orders that exist for the target fleet will be removed.
- Gauss turrets are now researched under Missiles and Kinetic, rather than Energy Weapons.
Fixes
- Damage Control and Salvage Modules can now be marked as obsolete.
- Fixed bug that is causing random letters in the text showing the function of a class for auto-assignment purposes.
- Removed empty checkbox that was appearing on user selection popup window.
- Fixed obfuscation of research field names in the Ancient Constructs tab of the Economics window.
- Fixed error if you try to use Add Queue for Research Projects without selecting a tech system.
- Fixed bug that allowed you to launch ordnance that was larger than the launcher capacity.
- Fixed problem with commander bonus check code requiring control station on FACs or fighters.
- Miscellaneous Components can now be researched normally and will appear in the Logistics category. The workaround for v1.13 is to use Instant in SM Mode.
- Changed player race flag to random instead of always using a fixed file.
- Fixed 'New Tech from Conquest' game option so that toggling off now prevents tech transfer.
- Researched cloaking devices are now shown in the 'view tech' window.
- Supply ships will no longer provide MSP for maintenance locations unless either the supply ship or the supplied ship has cargo shuttles.
- Fractional capacitor values will appear when using 'Show Next Tech' in the Create Project window.
- Fixed bug that allowed space stations to be built with alien components that were not available in the population stockpile.
- Fixed bug that allowed space stations to be built with prototype components.
- Fighters on ground-related missions can no longer be targeted by ship-based weapons.
- Fixed #1552 Object Not Found error by ending Death Spiral scenario once Earth crashes into the Sun. Workaround is to manually turn this off.
- Removed Ground Combat Command from list of commander bonuses.
- Fixed minimum number of comets so it works in all systems, not just 50%.
- Fixed a bug that prevented unsurveyed moons appearing as potential destinations when 'Exclude Survey' was ticked and the parent planet was surveyed.
- Deleting a population that contains the top-level admin command will result in that admin command moving to a new population. A naval HQ will be created if no pops with existing HQs are available.
- Ancient Construct tab will only show field and bonus once xenoarchaeological survey is completed.
- Setting the 'Select on Map' checkbox to Checked on the Naval Organization window will immediately centre the map if a fleet is currently selected.
- Time estimate for fleet movement on Naval Organization window now correctly calculates the time for orders that include a minimum distance.
- The 'Create Colony' from the Naval Organization window now works correctly when your Empire has multiple species.
- Fixed the 'Fill Class' button on the Naval Organization window.
- Fixed the 'Generate non-TN Only' flag on Game Details. For clarity this is now 'Generate Pre-Industrial Only'
- You can no longer use SM mode to create a gas called 'None'.
- Fixed the function of the 'Update all formations with same replacement template' checkbox.
- Fixed problem that was slightly increasing logistics bonus for cargo handling.
- Atmospheric pressure calculation fixed for worlds with frozen gases.
- Fixed display error caused by extremely small, but non-zero, mining production on planets with very large deposits.
- Refuelling hubs now count as refuelling systems for the purposes of 'Transfer Fuel' orders.
- Fixed ECM-1 and ECM-2 so they have 6 crew, in line with other ECM components.
- Fixed the 'Fire at Will FC' button so it only changes the selected fire control.
- Fixed a bug that allowed NPRs to build a lot of Diplomatic ships.
- You can now set civilian contract demands for installations for which you do not have the required technology.
- Added a vertical scroll bar to the alien class summary on the Intelligence window.
- Fixed bug in Fire at Will for Missile Fire Controls that allowed selection if targets within fire control range but outside missile range.
- Added code to check ground formation still exists before executing a load order.
- Standing Orders now correctly displayed for the Fleet selected when the Naval Organization window is first opened.
- Fixed problem with very small space stations having armour width zero.
- Save Settings on the game details window was making changes to the game but not retaining those changes on the Game window. Fixed now.
- Fixed bug in 'Move to Gas Giant with Sorium'.
- Selecting an existing missile now correctly displays name and second stage.
- Fixed bug that caused 2-stage buoys without targets to self-destruct.
- Fixed problem with viewing all contacts in all systems on tactical map sidebar.
- Fixed bug that allowed NPRs to be created mid-game on worlds with dangerous gases.
- Restricted max size of newly generated NPR populations to the capacity of the host system body.
- Fixed bug in Unload All Installation movement order that prevented some installations being unloaded by larger freighters.
- You can no longer double-click on events on the Tactical Map when the display option is off.
- Fixed bug that caused NPRs to issue warnings when the threat level was zero. For example, a small diplomatic ship currently generates zero threat but results in a warning.
- Removed the 'Signature vs Passive Detection' line in the missile fire control description as that should only appear for active sensors
- Fixed a bug that prevented player STO units from using their active sensors.
- Maintenance facilities in orbit of a population will now allow the use of resupply and overhaul orders with the population as a destination.
- Fixed bug that prevented maintenance facilities in orbit of a population from drawing maintenance supplies from that population.
- NPRs will now research fuel efficiency.
- Fixed a save bug that rounded down weapon power requirements to whole integers.
- Fixed bug that overestimated damage to formations on ship with damaged transport bays.
- Armour no longer counted for 'Max Repair Cost'.
- The Missile Design window will no longer accept negative values.
- Fixed bug preventing use of neutral populations.
- Fixed bug that allowed fire controls to ignore reduced cross-section due to cloaks.
- Resupply status is now saved to the database.
- Downloading technology from wrecks or disassembling components will ignore any techs flagged as automatic - for example fractional capacitor recharge.
- Fixed a bug that allowed STO weapons to fire on fighters after they landed.
- Fixed a bug that caused area mode PD fire to attack both missiles and the current ship target of the fire control.
- Distance to Lost Contacts shown correctly - was using current distance of ship, not distance of last contact.
- Fixed issues with tiny wrecks being classed as zero size.
- Fixed mineral consumption bug caused by using stockpiled components and building two or more ships without changing shipyard.
- Added jump shock to parasites.
- Fixed rare bug where the Swarm would only allocate microwave weapons to very small targets and therefore continue firing forever.
- Production information for Mining Labour Camps now appears on the Mining tab.
- Fixed display of passive sensors with less than 1.0 strength on tactical map.
- Fixed bug that prevented the assignment of starting build points to conventional races.
- Fixed the 'light-speed tractored ships' bug.
- Ships without fuel are considered as having a speed of 1 km/s for combat purposes - except Swarm who don't use fuel.
- Fractional installations can now be added on the Civilian tab of the Economics window.
- Fixed transfers of units between formations so you can no longer transfer more units than currently exist.
-
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.
-
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.
- Gravitational Sensors = Gravsurvey Fleet
- Geological Sensors = Geosurvey Fleet
- Terraforming Module = Terraformer
- Harvester Module = Fuel Harvester
- Salvage Module = Salvage Ship
- Stabilisation Module = Stabilisation Ship
- Orbital Mining Module = Orbital Miner
- Diplomacy Module = Diplomacy Ship
- Missile Fire Control > Beam Fire Controls
- No Engines = Missile Defence Base
- < 30,000 tons = Missile Patrol
- < 60,000 tons = Missile Squadron
- Else = Missile Fleet
- Beam Fire Controls > 0
- No Engines = Beam Defence Base
- < 30,000 tons = Beam Patrol
- < 60,000 tons = Beam Squadron
- Else = Beam Fleet
- Refuelling System = Tanker
- Troop Transport Bays = Troop Transport
- Cryogenic Module = Colony Ship
- Cargo Hold = Freighter
- Single Ship with Active Sensor Size 3 or higher = Scout
- If no other type, then split into single ships and class as reinforcements (which the AI will allocate where needed)
-
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.
-
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.
-
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.
-
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:
- Radioisotope Thermal Generator + Nuclear Radioisotope Engine
- Pressurised Water Reactor + Nuclear Thermal Engine
- Pebble Bed Reactor + Nuclear Pulse Engine
- Gaseous Fission Reactor + Nuclear Gas-Core Engine
- Magnetic Mirror Fusion Reactor + Ion Drive
- Stellarator Fusion Reactor + Magneto-Plasma Drive
- Tokamak Fusion Reactor + Magnetic Confinement Fusion Drive
- Inertial Confinement Fusion Reactor + Inertial Confinement Fusion Drive
- Solid-core Anti-matter Power Plant + Solid Core Anti-matter Drive
- Gas-core Anti-matter Power Plant + Gas Core Anti-matter Drive
- Plasma-core Anti-matter Power Plant + Plasma Core Anti-matter Drive
- Beam Core Anti-matter Power Plant + Beam Core Anti-matter Drive
- Vacuum Energy Power Plant + Photonic Drive
- Quantum Singularity Power Plant + Quantum Singularity Drive
-
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.
-
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.
-
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
-
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).
-
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.
-
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
-
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.
-
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:
- The 'Minimum Jump Engine Size' tech line is now 'Minimum Squadron Jump Engine Size'.
- Any jump drive below this size has a squadron size of 1.
- Any jump drive below this size cannot perform a squadron transit, even for the mounting ship.
- All jump drives, regardless of squadron jump capability, can perform a standard transit for any number of ships with the matching engine type within the normal size limit of the jump drive.
- For the Create Project window, I've changed the 'Self-Jump' suffix on jump engine size to 'No Squadron Jump'
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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:
- Jump Point: Standard Transit
- Population: Refuel And Resupply From Colony
- Fleet: Join Fleet
- Contact: Follow
- Life Pod: Rescue Survivors
- Wreck: Salvage Wreck
- Survey Location: Gravitational Survey
- System Body: Geological Survey
- Waypoint: Move To
-
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.
-
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:
- Raiders will not launch any raids
- Swarm will not be generated in new systems
- Aether Rifts will not be formed, either in new or existing systems
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.
-
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.
-
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.
-
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).
-
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.
-
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)
-
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.
-
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)
-
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)
-
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)
-
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.
-
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.
-
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.
-
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)
-
Additional Conventional Systems
After reading a discussion on the forum, I've added a few extra systems to make conventional starts more interesting.
- Conventional Active Sensors - Strength 2
- Conventional Geological Survey Sensors - Strength 0.2
- Troop Transport Bay - Conventional
- Cryogenic Transport - Conventional
The troop transport bay and cryogenic transport are double the size of their standard TN equivalents, but otherwise equal in function and cost
-
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.
-
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.
-
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.
-
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.
-
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:
- One rank higher than the highest ranked ship commander directly under that admin command
- One rank higher than the highest required rank of any directly subordinate admin command,
- One rank higher than the highest ranked commander of any directly subordinate admin command
- The manually assigned minimum rank for the admin command - see next post.
-
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:
- Automated Assignment Checkbox: Toggles automated assignment for the specific admin command, which has two effects. Firstly, if no commander is assigned, the colony will undergo automated assignment checks during the construction phase. Secondly, if the current commander is promoted, they will be unassigned.
- Admin Command Priority: When automated assignment takes place, admin commands are checked in ascending order of required rank, followed by descending order of priority.
- Required Bonus: A potential commander must have this bonus to be assigned to the colony.
- Secondary/Tertiary Bonus: Commanders with the Required Bonus are ranked based on descending value of the required bonus, then by descending value of the secondary bonus, then by descending value of the tertiary bonus. The secondary and tertiary bonuses are not required for a commander to be assigned. They are used for ranking purposes only.
- Assign Admin Commander: Clicking this button removes any current commander and then assigns the highest ranked available candidate, which may result in re-assignment of the current commander.
- Assign Admin Vacancies: Checks every admin command without a commander in ascending order of required rank, followed by descending order of priority, and and assigns the best candidate. This is effectively a manual triggering of the construction phase auto-assignment.
- Reassign All Admin Commands: Removes all existing admin commanders then checks every admin command in ascending order of required rank followed by descending order of priority and and assigns the best candidate to each.
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)
-
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)
-
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.
-
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.
- Naval 60% to 64%
- Ground 25% to 28%
- Administrator 8% to 4%
- Scientists 7% to 4%
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.
- Ground 40% to 50%
- Administrator 16% to 8%
- Scientists 14% to 8%
- Naval remains at 80%
-
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):
- Transfer Installation
- Transfer All Installations
- Transfer All Minerals
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.
-
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.
-
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.
-
Commander Bonuses
Several commander bonuses have been tweaked to aid the new on-demand promotion system.
- The chance of political bonuses above 10% has been significantly reduced
- The chance of having a crew training bonus has been increased from 60% to 80% with all of the increase in the 5% and 10% bonus bands.
- The chance of having a ground combat defence or ground combat offence bonus has been increased from 40% to 50% with all of the increase in the 5% and 10% bonus bands.
- The chance of naval officers having a production, mining or terraforming bonus has been increased from 15% to 20% with all of the increase in the 5% and 10% bonus bands.
- The chance of having a tactical or engineering bonus has been increased from 10% to 20% with all bonus bands increased equally
- The chance of naval officers having a logistics bonus has been increased from 10% to 50% with all bonus bands increased equally
-
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.
-
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".
-
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.
-
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.
-
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.
-
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)
-
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)
-
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.
-
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
-
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.
-
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.
-
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)
-
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.).
-
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) :)
-
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 :)
-
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.
-
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:
- There is no associated system body, which means:
- There is no line on the System View window and no mention in any summary of system bodies.
- It will not act as a destination for survey orders.
- There will be no mineral deposits.
- There will be no surface location to place installations, ground forces, fuel, ordnance or MSP.
- Due to the lack of a physical location, no ground combat can take place at a DSP, although any ships or stations at the location can be attacked via boarding combat.
- Minerals can be delivered to the DSP and collected from it, as it assumed these are stored as free-floating resources. They will be displayed as per a normal population.
- For the purposes of population display, the DSP has a colony cost of ‘Not Habitable’ and there are no physical characteristics such as gravity, atmosphere, etc.. It cannot be terraformed.
- Any population for DSP will have to be provided in Ark Modules (see next post)
- The DSP will act as a location for shore leave, if a sufficient population is available.
- Maintenance modules at the DSP will provide a maintenance capacity and allow overhauls, although MSP will have to be drawn from supply ships or supply bases at the location.
- Shipyards can operate at the DSP, as they are orbital, but they will require population based in Ark Modules.
- Repair Bays can operate without population.
- Due to the restrictions, the movement orders that can use the DSP as a destination are more limited than for a planetary population. In general, they will be the same orders available for waypoints, plus mineral-related load and unload orders.
- Orders that have a destination of a fleet in orbit of a DSP will function normally.
- The default order when double-clicking on a DSP is 'Move To'.
- Deep Space Populations do not orbit any stars, with one exception (see next bullet). They remain in their original position.
- When creating a Deep Space Population, if you click on a gas giant or superjovian instead of empty space, the DSP will be created in orbit of the gas giant and will move with the planet. In this case, fleet movement orders will have both the DSP and the gas giant as separate destinations, with one suffixed by (DSP) and the other by (Planet).
- Deep Space Populations have EM and Thermal signatures with the same rules as normal populations.
- A governor can be selected as normal, or set for automated assignment.
- Deleting a DSP on the Economics window will remove it from the Tactical Map.
- DSP cannot be made independent.
- Buttons for instantly adding ground units or installations will not be visible, even in SM mode.
- The Environment tab will be blank
- DSP will appear on the 'All Bodies' tab of the Tactical Map as the first item(s) on the list. Clicking on them will centre the Tactical Map on the DSP.
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 :)
-
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:
- The infrastructure requirement for a colony, and any associated unrest for overcrowding, only considers the surface population.
- Only the surface population is considered for PPV requirements and any associated unrest.
- Even though only the surface population generates unrest for the above reasons, any resulting impact on political stability affects the whole colony.
- If a colony is conquered, the population in the Ark Modules will not be affected, unless the Ark itself surrenders. The Ark will be unassigned from the conquered colony. The same is true for colony transfers
- Both orbital and surface population generate trade and an orbital-only colony, including a DSP, will produce trade goods.
- Both pops are considered for EM/Thermal signatures and for the 1m requirement for ancient constructs
- Standing orders for civilian colony ships will only consider the surface population.
- Shipping Lines require two surface populations to begin producing ships.
- Editing the population amount in SM mode only affects the surface population
-
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.
-
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.
-
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:
- Energy Point Defence. The result of a ship of more than 500 tons firing at missiles.
- Fighter Point Defence. The result of a ship of 500 tons or less firing at missiles.
- STO Point Defence. The result of an STO weapon firing at missiles.
- AMM Point Defence. The result of AMMs from a specific ship intercepting missiles.
- Ship Combat - Energy. The result of a ship of more than 500 tons using energy weapons in offensive mode
- Fighter Combat - Energy. The result of a ship of 500 tons or less using energy weapons in offensive mode
- Ship Combat - Missile. The result of missiles launched by a ship of more than 500 tons intercepting their target
- Fighter Combat - Missile. The result of missiles launched by a ship of 500 tons or less intercepting their target
- STO Combat. The result of a ground element with STO weapons attacking a target in offensive mode
- Missile Vs Ship. The result of missiles without ship-based direction intercepting their target
- Attacked By STO. Summary of hits and damage suffered as a result of attack by STO weapons
- Attacked By Energy Weapon. Summary of hits and damage suffered as a result of an attack by ship-based energy weapons
- Attacked By Missile. Summary of hits and damage suffered as a result of missile attack
- Attacked By AA Fire. Summary of hits and damage suffered by a ship attacked by surface-based AA weapons
- Boarding Damage. Summary of collateral damage suffered by a ship undergoing boarding assault
- Acid Damage. Summary of internal damage resulting from acid-based attacks
- Collateral Damage. Damage suffered as a result of bombardment against a population, where the damage was not to the primary target.
-
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.
-
Sol Bodies with Water
I've added frozen water to the following Sol system bodies:
- Europa 50%
- Ganymede 20%
- Callisto 10%
- Luna 10%
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.
-
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.
-
Terraforming Installations
Ground-based Terraforming Installations have several disadvantages over the space-based Terraforming Modules.
- They are more expensive, at 600 BP vs 500 BP.
- They require 250,000 population to operate and that population will require support from infrastructure.
- They are 5x larger
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:
- Cost is reduced from 600 BP to 300 BP
- Required Population is reduced from 250k to 125k
- Transport size is reduced from 125,000 CP to 75,000 CP.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.