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.
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.
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
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)
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 MR 24 MSP
Captain Control Rating 1
Intended Deployment Time: 0.9 days Morale Check Required
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)
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
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
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
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
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.
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
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.
Terraforming Installations Update
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.
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.
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
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.
Scrapping Installations
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
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.
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.
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.
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).
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.
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.