Release Notes

## Version 6.42

**NPR Terraforming**
In v6.40, NPRs will build terraforming ships and terraform their own colonies.
**NPR Construction Decisions**
If NPRs are running low on missiles, they will now concentrate on building beam warships until the missile stockpile improves. When considering missile stockpiles they will do this separately for offensive missile ships and AMM ships, so they may stop building missile warships if the supply of anti-ship missiles is low but continue building missile escorts if they have a sufficient supply of AMMs.
NPRs will build more ordnance factories than in the past.
The proportion of warships to escorts will determine which to build, so if they have a lot of warships compared to escorts they will build the latter and vice versa.
**Ground Force Training Facility Changes**
As GFTF are military installations that do not require population to operate they will no longer be affected by the Population Status Production Modifier (based on political status) or the Manufacturing Efficiency Modifier (not enough workers). They will still be affected by radiation and by the Economic Production Modifier (negative wealth).
**Forced Labour**
In v6.40 there is a new type of ground unit - the Forced Labour Unit (FLU). This functions as a Construction Brigade (CB) but with the following differences:
1) It only costs 40 BP, rather than 150 BP 2) It is four times as large, equal to 20 battalions 3) The defence strength is 10% of normal ground combat strength, compared to 50% for a CB 4) It can only be built at populations that have an occupation requirement (currently Conquered, Occupied and Subjugated) 5) 10,000 population is consumed 6) Building one of these units raises unrest by 2% 7) FLU do not count toward occupation strength and do not reduce unrest. Their defence strength (equal to 1/10th of a Garrison Unit) is used in ground combat defence only.
The unit is ideal for expanding construction capacity on conquered planets as (like CBs) it does not suffer due to production or unrest modifiers. While it can be moved to other worlds (or the dilithium mines on Rura Penthe), the transport requirement is considerable. Of course, there is also the consideration of whether your Empire is one that would create forced labour camps.
**Captured Missiles**
In v6.40 NPRs will reload their ships using captured missiles if no other option exists
**Changes to Shipping Lines**
At the moment when a shipping line builds a new ship it checks for ships that are more than 10 years old and are not currently carrying out orders. If it can find one, it is immediately scrapped. The problem is that civilian ships are rarely doing nothing.
In v6.40, when a shipping line builds a new ship it checks for ships that are more than 10 years old regardless of current orders. If it can find one, it is flagged for future scrapping and its default orders are removed. During the 5-day update any ships flagged for scrap and without orders are scrapped at that point. This should result in a lot more of the older ships being scrapped.
I've also added Huge Freighters and Huge Colony Ships, which have 5x the capacity of the Small versions, as potential designs for Shipping Lines. In addition, when choosing a Colony Ship or Freighter the Shipping Line will choose the largest vessel it can afford within the category (after accounting for future dividends) rather than selecting randomly.
**NPRs Respecting Capital Planets**
In v6.30 and earlier, NPRs will send ships to investigate sensor contacts. This can sometimes mean they will visit your home world every time you launch a new ship (if you are within detection range). This is especially a problem in scenarios where two or more races start in the same system on different worlds.
Therefore in v6.40 NPRs will respect a zone of ten million kilometres around the capital planets of alien races who are non-hostile when they decide whether to investigate new non-hostile sensor contacts.
If this works out well in practice, I might start extending the concept of exclusion zones so they can made part of diplomacy.
**Brown Dwarfs for Real Stars**
I've added one hundred and fifty-nine Brown Dwarf stars to the Known Systems list (now at 4420 systems). Until now there haven't been any brown dwarves in real stars games. These are stars detected by the WISE mission (http://en.wikipedia.org/wiki/Wide-field\_Infrared\_Survey\_Explorer) and therefore have names like WISE 1830+4542 or WISE 1348+6603. Renaming them on discovery is probably a good idea
**Black Holes Return**
Somehow the Black Holes have been removed from the Real Stars database. I can't remember if this was deliberate or accidental Smiley so I have put them back in.
**Mineral Generation**
Homeworld minerals have been boosted. Minimum amount is now 50,000, minimum accessibility is 0.4 and there should be generally more minerals overall.
Comet minerals have been adjusted. There will be generally be fewer mineral types per comet and of slightly lower accessibility but with the possibility of larger deposits. This should mean the average comet is less useful but there is more chance of a very good comet. This is to avoid the current situation where all comets are generally reasonably good but few are standouts. Also comet mineral generation will now be affected by the size of the comet and the age of the system (in the same way as other system bodies).
Comets will appear in more systems in v6.40 but there will be about the same number overall in the universe.
The mineral deposits on small system bodies under 100 km in diameter should be a little larger. This is to avoid the small asteroids and moons with a few hundred tons of minerals that are not economical to mine.
**NPR Missile Allocation**
At the moment NPRs can be wasteful in their allocation of missiles against small targets, such as using a whole salvo from a battlecruiser to take out a single fighter. In v6.40 they should use salvo sizes that are more appropriate for small targets, leaving some launchers unallocated if necessary.
**NPR Salvage Ships**
NPRs will begin operating salvage ships in v6.40. To avoid a lot of tricky coding for little game play benefit, any components recovered by NPRs will be disassembled on site and any tech points will be assigned to their capital. They won't get the minerals in the same way though. This should add competition with NPRs, even friendly ones, to be the first to salvage wrecks (as well as giving you another reason to fight the NPR)
Automated design will include a salvager as well.
**NPR Home Systems**
I've run into a problem in my own v6.40 test campaign. I've encountered a second NPR home-world system within two jumps of Sol. Unfortunately it's identical to the first NPR home-world system - oops!
Because Aurora system generation is so complex, the home systems for starting NPRs are pre-generated and added to the game along with the NPR. In v6.30 there are only about 15 different systems and it turns out there was nothing to prevent the same one being selected twice.
For v6.40. I have eliminated the possibility of duplicate systems and increased the number of different pre-generated NPRstarting systems to 60.
NPRs created after the game has started are handled differently and their systems will always be unique. The above only affects the NPRs generated during game creation.
**NPR Scientist Selection**
In the past, NPRs have not been selecting the best scientists for their research projects. This is fixed for v6.40, which should help NPR tech advancement. For those familiar with SQL, the word desc can be quite useful in the order by clause Smiley
EDIT: I also found another issue because the NPR research code queues associated projects in groups for a single scientist, such as Laser Focal Size, Laser Wavelength and Capacitor Recharge. The problem is that the third item in that group is a different field of research. NPRs now check each item in their queue for the best scientist at the time of assignment. Energy Weapon Impacts
I've added a new type of contact for v6.40 called energy weapon impacts. These are very similar to explosion contacts except they occur when an energy weapon scores damage on something (ship, missile, shipyard, population or ground unit).
(mainly so I can see what is going on in my current game when NPRs are firing beam weapons at each other)
**Improved NPR Escort Design**
Just realised there is a flaw in automated design for missile-armed escort ships. The number of fire controls was being set according to ship size (as it is for normal warships), regardless of the number of missile launchers. This meant a ship with 40 Size-1 launchers might only have 3 fire controls. Given the max launch capability of 5 AMM vs 1 ASM, this meant a lot of those launchers would not be used in defensive mode. I've fixed this so NPR escorts have a number of fire controls equal to (size-1 launchers / 5) rounded up. This should result in improved anti-missile performance by NPRs.
**NPR Research Costs**
It has often been pointed out that NPRs fall behind quickly in Research. I just figured out why. Because NPRs don't manage their available wealth as well as a human player, they tend to build too much early on and then run out of wealth. To cope with the lack of money they halt their research program. Therefore in v6.40, NPRs won't pay wealth for research. I know this goes against the general principle of NPRs functioning in a similar way to players, but it is on the same lines as no fuel costs and no maintenance. Ongoing research and reduced costs should make NPRs more capable opponents.
**Interception Movement**
In v6.40, movement of task groups toward non-stationary task groups and non-stationary contacts will use interception movement, plotting a course to rendezvous in the shortest time rather than heading straight for the target. This takes account of minimum distance settings, so where minimum distance is greater than zero, the course will be plotted as the shortest path to a point where the moving TG will be in range of the target TG.
For a target task group or contact to be classed as non-stationary, it must have:
1) Speed > 0. 2) At least one order in its order list. 3) Moved in the previous increment (because some orders don't involve movement or only partially involve movement).
EDIT: Also added interception movement for missiles vs. ships.
(added partially because this has been requested several times over the years but mainly because I am tired of the Russian Fleet (NPR) being dumb in its attempts to catch the raiding Belasco FACs)
**Underground Infrastructure**
Underground Infrastructure functions in the same way as normal infrastructure except for the following:
1) It costs 10 BP per point, compared to 2 BP for normal infrastructure, because of the need to build artificial gravity into the construction. 2) It cannot be transported so it must be built on site. 3) it can only be used on worlds for which the gravity is too low to support a normal colony. In this case, the population lives beneath the surface of the body and makes use of artificial gravity. Because of the difficulties in building and maintaining this infrastructure, the body is treated as colony cost 3.0 for the purposes of underground infrastructure requirements, agriculture/environment, etc..
In essence, Underground Infrastructure is used for hollowing out asteroids and small moons to provide underground living accommodation. It's an immovable underground version of an orbital habitat. Note that as construction of underground infrastructure has to be done on site, you will need either construction brigades or workers living in an orbital habitat manning construction factories up to the point where the asteroid can support enough workers of its own to man construction factories. This makes it a substantial undertaking but allows the creation of asteroid bases etc. Other facilities can be added as normal to the body once workers are available.
This adds some complexity because of the potential interactions between underground infrastructure and orbital habitats so it may throw up the odd bug or two until it's been thoroughly play tested.
**Multiple NPRs in Sol Start**
I'm embarking on something of an experiment for v6.40. Sol starts generally require human control of all faction or war breaks out fairly quickly. So for v6.40 I've added a Truce Countdown Clock during game setup. You specify the time for the clock in years and NPRs will have a fixed neutral relationship with races who start in the same system for that period of time. This means you can setup a multi-race (Trans-Newtonian) start in Sol while controlling only one faction. The other factions won't consider attacking unless you attack them first or the clock runs out. Even after the clock runs out, you may still be able to prevent war with diplomatic teams, etc.
In effect, you will have the time on the clock to establish yourself outside the Sol system before all hell is likely to break lose. Even if they fight each other instead of you Earth is probably going to suffer. This isn't a good scenario for turtling and it forces you to go out into the galaxy with less forces than you might like because of the time constraint. The other factions will also be expanding and you might be settling the same worlds. Order Template Update
Added delete button for Order Templates (and fixed issue with using template when there are already orders in the fleet's queue).
**Fleet Training Change**
Fleet Training rate is currently based on task force commander's crew training plus half the operations officers crew training. For v6.40 this is changing to task force commander's crew training \* task force operations bonus. The latter is equal to the operations officer's operations bonus \* 25% of task force commander's operation bonus.
So if the TF commander has crew training 200 and ops bonus 10% and the operations officer has ops bonus 20%, the fleet training rating for the task force will be 200 x 1.05 x 1.20 = 252
**Miscellaneous**
Shipyards will now be auto-named at start (instead of Shipyard #1, Shipyard #2 etc.) and when new shipyards are constructed. The name will be a combination of one or two surnames from the commander names theme plus one of about sixty different suffixes such as "Shipyard", "Shipbuilding Company", "Navy Yard", etc.. This format will also be used for the auto-rename button for shipyards instead of the current set list of Earth-based shipyards.
Some example shipyard names, using the Warhammer 40k commander name theme:
Styphus-Mael Heavy Industries Adamantis Shipyard Alaric-Phaeron International Galenus Naval Shipbuilding Valefar Enterprises
I've also created a random company name generator for the Create Research Project window. There is a new text box above the System Name, along with a Suggest Name button. You can keep clicking the suggest name until it creates a manufacturer name you like. That will then be used as a prefix for whatever you call the new system. The Company Name will remain there without being affected by any changes to the parameters, so you can use it for several systems without retyping. The Company Name comprises one or two commander surnames plus potentially a suffix such as Corporation, Industries, etc.. You can leave the company name field blank if desired.
A few example company names, using the Warhammer 40k commander name theme:
Crassian Space & Security Vulkan-Ravenor Orias & Galenus Dynamics Anzu-Lazerian Limited Alexander-Vandis Prometheus-Rachmiel Electronics Industries Dominus-Loken Typhon-Macharius Lexandro International Gothicus-Phaeron

## Version 6.40

Shipyards will now be auto-named at start (instead of Shipyard #1, Shipyard #2 etc.) and when new shipyards are constructed. The name will be a combination of one or two surnames from the commander names theme plus one of about sixty different suffixes such as "Shipyard", "Shipbuilding Company", "Navy Yard", etc.. This format will also be used for the auto-rename button for shipyards instead of the current set list of Earth-based shipyards.
Some example shipyard names, using the Warhammer 40k commander name theme:
Styphus-Mael Heavy Industries Adamantis Shipyard Alaric-Phaeron International Galenus Naval Shipbuilding Valefar Enterprises
I've also created a random company name generator for the Create Research Project window. There is a new text box above the System Name, along with a Suggest Name button. You can keep clicking the suggest name until it creates a manufacturer name you like. That will then be used as a prefix for whatever you call the new system. The Company Name will remain there without being affected by any changes to the parameters, so you can use it for several systems without retyping. The Company Name comprises one or two commander surnames plus potentially a suffix such as Corporation, Industries, etc.. You can leave the company name field blank if desired.
A few example company names, using the Warhammer 40k commander name theme:
Crassian Space & Security Vulkan-Ravenor Orias & Galenus Dynamics Anzu-Lazerian Limited Alexander-Vandis Prometheus-Rachmiel Electronics Industries Dominus-Loken Typhon-Macharius Lexandro International Gothicus-Phaeron
**Fleet Training Change**
Fleet Training rate is currently based on task force commander's crew training plus half the operations officers crew training. For v6.40 this is changing to task force commander's crew training \* task force operations bonus. The latter is equal to the operations officer's operations bonus \* 25% of task force commander's operation bonus.
So if the TF commander has crew training 200 and ops bonus 10% and the operations officer has ops bonus 20%, the fleet training rating for the task force will be 200 x 1.05 x 1.20 = 252
**Order Template Update**
Added delete button for Order Templates (and fixed issue with using template when there are already orders in the fleet's queue).
**Multiple NPRs in Sol Start**
I'm embarking on something of an experiment for v6.40. Sol starts generally require human control of all faction or war breaks out fairly quickly. So for v6.40 I've added a Truce Countdown Clock during game setup. You specify the time for the clock in years and NPRs will have a fixed neutral relationship with races who start in the same system for that period of time. This means you can setup a multi-race (Trans-Newtonian) start in Sol while controlling only one faction. The other factions won't consider attacking unless you attack them first or the clock runs out. Even after the clock runs out, you may still be able to prevent war with diplomatic teams, etc.
In effect, you will have the time on the clock to establish yourself outside the Sol system before all hell is likely to break lose. Even if they fight each other instead of you Earth is probably going to suffer. This isn't a good scenario for turtling and it forces you to go out into the galaxy with less forces than you might like because of the time constraint. The other factions will also be expanding and you might be settling the same worlds.
**Underground Infrastructure**
Underground Infrastructure functions in the same way as normal infrastructure except for the following:
1) It costs 10 BP per point, compared to 2 BP for normal infrastructure, because of the need to build artificial gravity into the construction. 2) It cannot be transported so it must be built on site. 3) it can only be used on worlds for which the gravity is too low to support a normal colony. In this case, the population lives beneath the surface of the body and makes use of artificial gravity. Because of the difficulties in building and maintaining this infrastructure, the body is treated as colony cost 3.0 for the purposes of underground infrastructure requirements, agriculture/environment, etc..
In essence, Underground Infrastructure is used for hollowing out asteroids and small moons to provide underground living accommodation. It's an immovable underground version of an orbital habitat. Note that as construction of underground infrastructure has to be done on site, you will need either construction brigades or workers living in an orbital habitat manning construction factories up to the point where the asteroid can support enough workers of its own to man construction factories. This makes it a substantial undertaking but allows the creation of asteroid bases etc. Other facilities can be added as normal to the body once workers are available.
This adds some complexity because of the potential interactions between underground infrastructure and orbital habitats so it may throw up the odd bug or two until it's been thoroughly play tested.
**Interception Movement**
In v6.40, movement of task groups toward non-stationary task groups and non-stationary contacts will use interception movement, plotting a course to rendezvous in the shortest time rather than heading straight for the target. This takes account of minimum distance settings, so where minimum distance is greater than zero, the course will be plotted as the shortest path to a point where the moving TG will be in range of the target TG.
For a target task group or contact to be classed as non-stationary, it must have:
1) Speed > 0. 2) At least one order in its order list. 3) Moved in the previous increment (because some orders don't involve movement or only partially involve movement).
EDIT: Also added interception movement for missiles vs. ships.
(added partially because this has been requested several times over the years but mainly because I am tired of the Russian Fleet (NPR) being dumb in its attempts to catch the raiding Belasco FACs)
**NPR Research Costs**
It has often been pointed out that NPRs fall behind quickly in Research. I just figured out why. Because NPRs don't manage their available wealth as well as a human player, they tend to build too much early on and then run out of wealth. To cope with the lack of money they halt their research program. Therefore in v6.40, NPRs won't pay wealth for research. I know this goes against the general principle of NPRs functioning in a similar way to players, but it is on the same lines as no fuel costs and no maintenance. Ongoing research and reduced costs should make NPRs more capable opponents.
**Improved NPR Escort Design**
Just realised there is a flaw in automated design for missile-armed escort ships. The number of fire controls was being set according to ship size (as it is for normal warships), regardless of the number of missile launchers. This meant a ship with 40 Size-1 launchers might only have 3 fire controls. Given the max launch capability of 5 AMM vs 1 ASM, this meant a lot of those launchers would not be used in defensive mode. I've fixed this so NPR escorts have a number of fire controls equal to (size-1 launchers / 5) rounded up. This should result in improved anti-missile performance by NPRs.
**Energy Weapon Impacts**
I've added a new type of contact for v6.40 called energy weapon impacts. These are very similar to explosion contacts except they occur when an energy weapon scores damage on something (ship, missile, shipyard, population or ground unit).
(mainly so I can see what is going on in my current game when NPRs are firing beam weapons at each other)
**NPR Scientist Selection**
In the past, NPRs have not been selecting the best scientists for their research projects. This is fixed for v6.40, which should help NPR tech advancement. For those familiar with SQL, the word desc can be quite useful in the order by clause Smiley
EDIT: I also found another issue because the NPR research code queues associated projects in groups for a single scientist, such as Laser Focal Size, Laser Wavelength and Capacitor Recharge. The problem is that the third item in that group is a different field of research. NPRs now check each item in their queue for the best scientist at the time of assignment.
**NPR Home Systems**
I've run into a problem in my own v6.40 test campaign. I've encountered a second NPR home-world system within two jumps of Sol. Unfortunately it's identical to the first NPR home-world system - oops!
Because Aurora system generation is so complex, the home systems for starting NPRs are pre-generated and added to the game along with the NPR. In v6.30 there are only about 15 different systems and it turns out there was nothing to prevent the same one being selected twice.
For v6.40. I have eliminated the possibility of duplicate systems and increased the number of different pre-generated NPRstarting systems to 60.
NPRs created after the game has started are handled differently and their systems will always be unique. The above only affects the NPRs generated during game creation.
**NPR Salvage Ships**
NPRs will begin operating salvage ships in v6.40. To avoid a lot of tricky coding for little game play benefit, any components recovered by NPRs will be disassembled on site and any tech points will be assigned to their capital. They won't get the minerals in the same way though. This should add competition with NPRs, even friendly ones, to be the first to salvage wrecks (as well as giving you another reason to fight the NPR Smiley)
Automated design will include a salvager as well.
**NPR Missile Allocation**
At the moment NPRs can be wasteful in their allocation of missiles against small targets, such as using a whole salvo from a battlecruiser to take out a single fighter. In v6.40 they should use salvo sizes that are more appropriate for small targets, leaving some launchers unallocated if necessary.
**Mineral Generation**
Homeworld minerals have been boosted. Minimum amount is now 50,000, minimum accessibility is 0.4 and there should be generally more minerals overall.
Comet minerals have been adjusted. There will be generally be fewer mineral types per comet and of slightly lower accessibility but with the possibility of larger deposits. This should mean the average comet is less useful but there is more chance of a very good comet. This is to avoid the current situation where all comets are generally reasonably good but few are standouts. Also comet mineral generation will now be affected by the size of the comet and the age of the system (in the same way as other system bodies).
Comets will appear in more systems in v6.40 but there will be about the same number overall in the universe.
The mineral deposits on small system bodies under 100 km in diameter should be a little larger. This is to avoid the small asteroids and moons with a few hundred tons of minerals that are not economical to mine.
**Black Holes Return**
Somehow the Black Holes have been removed from the Real Stars database. I can't remember if this was deliberate or accidental, so I have put them back in.
**Brown Dwarfs for Real Stars**
I've added one hundred and fifty-nine Brown Dwarf stars to the Known Systems list (now at 4420 systems). Until now there haven't been any brown dwarves in real stars games. These are stars detected by the WISE mission (http://en.wikipedia.org/wiki/Wide-field\_Infrared\_Survey\_Explorer) and therefore have names like WISE 1830+4542 or WISE 1348+6603. Renaming them on discovery is probably a good idea.
**NPRs Respecting Capital Planets**
In v6.30 and earlier, NPRs will send ships to investigate sensor contacts. This can sometimes mean they will visit your home world every time you launch a new ship (if you are within detection range). This is especially a problem in scenarios where two or more races start in the same system on different worlds.
Therefore in v6.40 NPRs will respect a zone of ten million kilometres around the capital planets of alien races who are non-hostile when they decide whether to investigate new non-hostile sensor contacts.
If this works out well in practice, I might start extending the concept of exclusion zones so they can made part of diplomacy.
**Changes to Shipping Lines**
At the moment when a shipping line builds a new ship it checks for ships that are more than 10 years old and are not currently carrying out orders. If it can find one, it is immediately scrapped. The problem is that civilian ships are rarely doing nothing.
In v6.40, when a shipping line builds a new ship it checks for ships that are more than 10 years old regardless of current orders. If it can find one, it is flagged for future scrapping and its default orders are removed. During the 5-day update any ships flagged for scrap and without orders are scrapped at that point. This should result in a lot more of the older ships being scrapped.
I've also added Huge Freighters and Huge Colony Ships, which have 5x the capacity of the Small versions, as potential designs for Shipping Lines. In addition, when choosing a Colony Ship or Freighter the Shipping Line will choose the largest vessel it can afford within the category (after accounting for future dividends) rather than selecting randomly.
**Captured Missiles**
In v6.40 NPRs will reload their ships using captured missiles if no other option exists
**Forced Labour**
In v6.40 there is a new type of ground unit - the Forced Labour Unit (FLU). This functions as a Construction Brigade (CB) but with the following differences:
1. ) It only costs 40 BP, rather than 150 BP
2. ) It is four times as large, equal to 20 battalions
3. ) The defence strength is 10% of normal ground combat strength, compared to 50% for a CB
4. ) It can only be built at populations that have an occupation requirement (currently Conquered, Occupied and Subjugated)
5. ) 10,000 population is consumed
6. ) Building one of these units raises unrest by 2%
7. ) FLU do not count toward occupation strength and do not reduce unrest. Their defence strength (equal to 1/10th of a Garrison Unit) is used in ground combat defence only.

The unit is ideal for expanding construction capacity on conquered planets as (like CBs) it does not suffer due to production or unrest modifiers. While it can be moved to other worlds (or the dilithium mines on Rura Penthe), the transport requirement is considerable. Of course, there is also the consideration of whether your Empire is one that would create forced labour camps.
**Ground Force Training Facility Changes**
As GFTF are military installations that do not require population to operate they will no longer be affected by the Population Status Production Modifier (based on political status) or the Manufacturing Efficiency Modifier (not enough workers). They will still be affected by radiation and by the Economic Production Modifier (negative wealth).
**NPR Construction Decisions**
If NPRs are running low on missiles, they will now concentrate on building beam warships until the missile stockpile improves. When considering missile stockpiles they will do this separately for offensive missile ships and AMM ships, so they may stop building missile warships if the supply of anti-ship missiles is low but continue building missile escorts if they have a sufficient supply of AMMs.
NPRs will build more ordnance factories than in the past.
The proportion of warships to escorts will determine which to build, so if they have a lot of warships compared to escorts they will build the latter and vice versa.
**NPR Terraforming**
In v6.40, NPRs will build terraforming ships and terraform their own colonies.
**Reduced Size of Beam Fire Controls**
In v6.40, all beam fire controls have been halved in size. So a fire control with 4x range would be 2 HS while one with 4x range and 4x speed would be 8 HS.

## Version 6.00

Because of the much higher fuel requirements for engines in v6.00, the fuel requirements of shields are now negligible in comparison. Therefore the rate of which fuel is consumed by shields has been increased by a factor of 24. What was daily use, is now hourly use.
**Recreational Module**
In v6.20, a new ship module is available. The Recreational Module is 100,000 tons, costs 2000 MC and requires 1000 crew. It is a commercial module. If a ship or base is in the same location as a Recreational Module, that counts as being in orbit of a planet with 10,000+ population for the purposes of crew morale.
This means you can create recreational ships (although I am sure the navy personnel would invent alternative descriptions) that can tour bases or anchorages to provide some way for crews who have been away from home for a long time to let off steam.
**Fighter Combat Bonus**
In v6.20, Naval Officers gain a new bonus called the Fighter Combat Bonus. This is a modifier to weapon accuracy for fighters firing energy-based weapons (gauss cannon, railguns, lasers, mesons, etc.). The starting amount for a commander will vary from nothing up to 50%, although anything around 30% or higher will be rare. Unlike most bonuses, this one will top out at around 100%. It doesn't affect missiles fired from fighters.
This bonus simulates that exceptional pilots can maneuver small craft to increase the chance of a hit with energy-based weapons.
**Minor v6.20 Changes**
The "Salvo Name cannot find its target. It will home on the previous target location" message should now only show once per increment, not once per sub-pulse.
Default status of the Show Obsolete checkbox on the View Tech window changed to unchecked.
The button for the Planetary Market (a window in an older version) on the F3 System Map now links to the new Production Overview window. Also, there were two buttons for the Intelligence/Diplomacy window so I have changed one of those to show the Race Details (F2) window instead.
Civilian ships on trade runs will look for the shortest route in the same system, rather than going to the oldest colony.
**No Morale Message for Unaffected Ships**
This is a v6.20 change.
Morale messages will now only be shown for ships that are likely to be affected by low morale. This includes armed ships and survey ships. As a reminder, morale modifies crew training and fleet training scores, so the factors affected by low morale are:
Weapon accuracy Survey speed Maintenance failures Transit delays for weapons/sensors Speed of response to orders during combat
So freighters, colony ships, fuel harvesters, terrafomers, jump gate construction ships and all the other 'commercial' type classes, are very unlikely to be affected by low morale. Aurora has its own internal classification for designs based on what they contain, so if you decide to put a weapon on a terraformer for example, Aurora will class that as a warship for the purposes of determining whether to show morale messages.
**Automated Removal of Crew Quarters**
This is a v6.10 change but I am going to keep the change log here for the v6.00 bug fix releases
When you remove components from Ship designs, any excess crew quarters will be removed automatically. If you don't want excess crew quarters removed, for carriers for example, there is a checkbox in the top right of the Class window called "Keep Excess Q". You set this in the same as way as flagging the ship as a Collier or Tanker. Excess Crew Quarters will be retained in the class design, allowing you to create Flight Crew Quarters for example.
**Minor Updates**
1. ) Class Design now shows an error for insufficient power for energy weapons
2. ) The species selected by default in places such as Race window and System window is the species of the racial capital, rather than the most populous species.
3. ) When using "Combine with other Task Group" or "Move Ships between Task Groups" section on the Fleet window (F12), the Assigned Population is set for the transferred ships.
4. ) When using the Release Tractor order, or Detach Ship Type order, Assigned Population will be set for the detached ships.
5. ) Added a new 50% Size, 50% Tracking Speed option for Beam Fire Controls
6. ) Bases with fuel capacity are now supplied with fuel when they are built (assuming fuel is available)
7. ) Terraforming is now a Biology tech.

**Fractional Shields**
In v6.00, fractional shields no longer affect combat.
Example #1: A ship with 0.2 shield points is hit by 3 points of damage. The ship takes 3 damage and the 0.2 shield points remain. Example #2: A ship with 3.4 shield points is hit by 5 points of damage. The ship takes 2 damage and the shields are reduced to 0.4.
**Updates to Fuel Consumption**
I have edited the engine, missile engine and missile design posts to include a change to the fuel consumption formula for power modifiers and to the base fuel consumption of missile engines. A more detailed explanation of the change and the rationale behind it is in this post:
http://aurora2.pentarch.org/index.php/topic,5359.0.html
**Task Force Training Speed**
Due to the fuel changes in v6.00, the speed of ships on task force training is reduced to 1/4 maximum speed. Otherwise, the cost of training in terms of fuel becomes too high and I didn't want to reduce the time requirement.
**Updates to Older Posts**
The following Morale-related updates apply to older posts in this thread that I have edited. This post is just to highlight the changes for anyone who read those posts before I edited them.
Morale Effect on Surveying The rate at which a ship generates geological or gravitational survey points is modified by morale
No Life Support If a ship has no life support remaining, either due to battle damage or maintenance failures, emergency systems will keep the crew alive for a while but within a few days whatever jury-rigged systems the crew manage to create will begin to fail and crew members will start to die. The percentage will vary but on average about 50% of the remaining crew will die during each 5-day update. Any survivors that have been picked up by the ship will also start dying. Instead of the overcrowding modifier, morale is divided by 10.
Undermanning Morale can also be affected by undermanning. If a ship's crew falls below half its normal complement, morale will be affected. The formula is Morale = Current Morale x ((Current Crew \* 2) / Normal Crew) This could be made more complex by looking at the crew required to run the remaining undamaged systems but I think that adds complexity without a corresponding improvement in gameplay.
As you can imagine, an undermanned ship without life support is not going to be responding to orders very quickly Smiley
Ship can use a new Add Replacement Crew order to bring their crew up to its full complement. This order can be issued at colonies with at least one million population and takes the replacement crew from the racial pool.
**Accurate Fuel Use for Tugs**
In v5.60 and earlier, Tugs use fuel based purely on their own speed. In future, tugs will take into consideration the mass of the ship they are towing. Normally, the amount of engine power used for fuel consumption is determined by:
Engine Power Used = Current Speed / Max Speed
For tugs, this will change to:
Engine Power Used = ((Ship Size + Towed Size) / Ship Size) x (Current Speed / Max Speed)
**LPs Included in Multi-system Pathfinding**
At the moment NPRs use Lagrange Points (LPs). This is straightforward as NPR orders are non-persistent so I don't have to worry about plotting LP orders for multiple systems at once . Civilians don't use them because they tend to create long-term orders and then stick to them unless threatened. However, for v5.70 I am adding LP calculation to the code that works out multi-system paths for player and civilian ships, as well as in-system civilian pathfinding. This means that civilians should start making intelligent use of LPs. Any other multi-system paths based on default orders or conditional orders should also start using LPs as well.
**Update to Missile Engines**
I have updated the main missile engine post with new rules for increased fuel usage for small missile engines and changed the examples to reflect the changes. This post is just a brief overview as readers may not realise the main post has been edited. The relevant section is below
Engine Size: Missile engines can range in size from 0.1 MSP to 5 MSP in 0.1 MSP increments. It is hard to create very small fuel efficient engines, so smaller missile engines suffer a penalty to fuel consumption. The formula is: Fuel Modifier = Int ((Engine Size in MSP / 5) ^ (-0.683)). There is no need to remember this formula as the % change to fuel consumption is shown for each size option in missile engine design. For example, the following sizes of missile engine have the listed fuel consumption penalties
5 MSP: 0% 4 MSP +16% 3 MSP +41% 2 MSP +86% 1 MSP +200% 0.5 MSP +381% 0.3 MSP +583% 0.1 MSP +1346%
**Another Attempt to Fix Robot Defenders Bug**
This bug has been around a long time but I think I might have fixed it (although I may have said that before Smiley)
First I need to mention that activated robots have their own population and that population is flagged as a "ground combat only" population (GCOP). At the moment, to conquer a population you have to attack it when there are no remaining defenders. So if you destroy the last remaining robot battalion, you will defeat that enemy 'population' during the next ground combat phase. However, during the ground attack phase, if a robot 'population' attempts to attack you and has no units (and is flagged as a GCOP), that population is deleted.
Which means that if you attack first during ground combat and destroy the last robot unit, then the robots try to attack you, their GCOP will be deleted. Which in turns means that when you try to attack that population during the next ground combat turn it doesn't exist. Now, the intention in the code is that if you attack a GCOP and conquer it, you don't have that population transferred to you. It is just deleted. However, because that population was already deleted during the last ground combat phase, there is no longer a record flagging it as a GCOP. Furthermore, your population record still has a valid attack order and a population target ID and at no point does the ground combat code actually check the enemy pop really exists - it just believes the attack ID in your own population record is valid.
So you attack the non-existent pop and conquer it (because there are no enemy ground units with that pop ID). Because the record no longer exist, the program doesn't know it was a GCOP and therefore tries to transfer that non-existent pop to your Empire. It also helpfully transfers your ground units to that non-existent pop to provide occupation forces, which means the ground forces vanish into the ether - oops!
So, I have added some extra checking code, including turning off any attack orders against a robot population that gets deleted.
In the meantime, the workaround is to just defend against any robot attack rather than counterattack.
**Civilian Fuel Harvesters**
Civilian Shipping Lines will build fuel harvesters in v5.70. These harvesters will (slowly) make their way to gas giants with Sorium and start harvesting. Unlike other civilian shipping, these fuel harvesters will appear as potential destinations when you select Task Groups on the F12 orders window, so you can order your fleets to refuel from them. Refuelling from civilian harvesters costs 1 wealth for each 10,000 litres of fuel.
Once a civilian fuel harvester is full, any excess fuel is sold to the private sector. This also generates tax revenue equal to 20% of the fuel price.
Naming of Civilian Classes
Now the civilian shipping lines are designing their own ships, I have changed the naming convention for civilian-designed classes, as in my current campaign they were racing through the racial class names. It also wasn't obvious what the capability of each ship was from the name. They now use a combination of the short version of the shipping line name, an optional large or small designation, a letter designation (F = Freighter, C = Colony Ship, etc.) and a number indicating the tech level of the engines (1 = nuclear thermal, 2 = nuclear pulse, etc.)
**Correct Allocation of Export Tax**
I'm playing a test campaign at the moment for v5.70 and I've realised that export taxes are not being correctly assigned. When a civilian freighter transports trade goods, the tax revenue for the government is equally split into two parts - the export tax and the shipping tax. The export tax should go to the parent government of the population from where the trade goods are picked up while the shipping tax goes to the parent government of the shipping company. Although these are usually the same government, it will be different if the goods are being picked up from a foreign power.
In the current version, both these taxes were being incorrectly assigned to the parent government of the shipping company. This has been fixed for v5.70.
This means that if you have goods available for export and a foreign shipping line picks them up, you will still receive export taxes but not shipping taxes.
**Survivors and POWs**
Due to the new crew rules, tracking survivors is more important than before so I have added some extra detail, When you rescue survivors from your own ships or those of other races, they remain within their crew groups while on board the rescue ship. The ship window shows a list of the crews rescued (using ship name / race name) and how many in each crew. Those from alien ships are shown as POWs. In the past, alien POWs were effectively ignored once interrogated but now they take up life support, their presence is tracked. If you decide that you don't want aliens taking up your precious life support (or your own crews that lost their ships), there is an "Eject Into Space" button. Only RP considerations prevent its use Smiley
The other option for POWs is to unload them at one of your colonies. The total POWs for each alien race will be shown for each of your populations. If you retake an alien population that has POWs of your race, they are added back into your crew pool. You can also accidently kill your own crewmen if they are held prisoner on a world that you bombard.
**Shipping Lines Class Designs**
Shipping Lines will now design their own ships, rather than using player designs. Those designs can be viewed in the Class window but you can't unlock them. You can obsolete them if you don't wish to view them as this won't affect the shipping lines.
Each shipping line will design ships independently and will design their own engines as well. The engines won't appear as tech you can use for your own ships. Otherwise the list of engine components would get cluttered. They will take advantage of new engine tech and other systems as you develop them.
When a new ship is built, the shipping line will retire the oldest ship of the same general type (with a minimum of 10 years older) that is not currently carrying cargo. So its possible a civilian ship will last longer than 10 years, due to always being active when the shipping line is looking for a ship to scrap. As a ship will not have cargo more than 50% of the time, its luck will probably run out at some point.
All civilian ships will be scrapped when they reach 15 years old, regardless of whether a new ship has been built.
With these changes, a shipping line is generally going to have a relatively modern fleet, with the oldest ships ranging from 10-15 years.
**Effects of Crew Morale**
In the previous post about Crew Morale (see link below), I explained how low morale could happen. This post covers the effects of morale below 100%.
http://aurora2.pentarch.org/index.php/topic,4835.msg49116.html#msg49116
Fleet Training Fleet Training Points are always modified by Crew Morale when any action involving fleet training takes place. For example, a ship with a 60% fleet training rating and 80% crew morale would act as if it has a 48% fleet training rating (60% x 80%). Fleet training affects how quickly ships will respond to new movement and firing orders when hostile ships are present.
Crew Grade Any action that uses crew grade as a modifier will also be affected by low morale. This includes weapon accuracy, maintenance failures and transit delays. The current crew grade modifier is determined by the following formula:
Crew Grade Modifier = 1 + (Round Down ( Square Root ( Ship Grade Points) - 10) / 100)
So for 100 grade points the crew grade modifier = 1.00. For 500 grade points, the crew grade modifier = 1.1236.
This final modifier is multiplied by the crew morale. So with 80% morale and 500 grade points the final modifier would be 0.8 x 1.1236 = 0.8989
This is applied as a straightforward modifier to weapons fire. For maintenance failures the chance of failure is multiplied by (2 - Crew Grade Modifier), which means a modifier greater than 1 results in less failures than would normally be expected. For modifier less than 1, there will be more maintenance failures than normal. For transit delays, the length of the delay is multiplied by (2 - Crew Grade Modifier).
Surveying The rate at which a ship generates geological or gravitational survey points is modified by morale
As most of the above effects are combat or maintenance-related, with the exceptions of surveying and transit delay, commercial shipping is unlikely to suffer much of a penalty from crew morale. Therefore, to qualify for commercial status, a class design must include crew quarters for at least a three month deployment duration.
**A couple more minor changes**
Unrest due to overcrowding only starts if the required infrastructure is equal to the actual infrastructure \* 1.05. In other words, unrest due to overcrowding won't begin until the population is 5% greater than the support provided by the available infrastructure. This should prevent meaningless events due to the pop moving back and forth over the currently allowable limit.
The following events no longer generate an interrupt: Officer Promoted New Officer Officer Health Unrest Increasing Unrest Decreasing Promising New Officer Exceptional New Officer Outstanding New Officer
**Themes Added**
I've added a new Warhammer 40k commander name theme for v5.70 and two new ship naming themes, one for WH40K Empire and one for WH40K Chaos.
**Missile Design**
Note: Updated 23rd Sept 2012 to change the fuel consumption formula for the power modifier
Missile engines are now designed in the same way as shipboard engines and you can have multiple engines per missile. The missile engine tech progression has been removed as you use the normal engine tech progression for missiles. (see the earlier section on missile engines). Missile engines use exactly the same fuel consumption rules as normal engines. Although you can boost them twice as high, which means you may end up much higher fuel consumption per Engine Power Hour, you don't have to, which means you can create some ultra-long range missiles. The constraint on effective missile range is now going to be targeting, which reflects reality as well. Also, bringing all engine types (Ship, FAC, Fighter, Drone and Missile) into a single design process with the same fuel rules is much cleaner and much better from the perspective of internal consistency.
There are no longer missiles, drones and buoys. There are simply missiles. The flexibility in the new missile design process will allow you to cover the abilities of all three previous missile categories. The drone engine tech progression has been removed.
Missile sensors must be powered. The power requirement for any sensor is equal to its 20% of the sensor strength. So one missile size point (MSP = 1/20th of a HS) allocated to an EM Sensor using a base EM sensor strength of 8 would result in anEM sensor strength of 0.4 (8/20). This would require a reactor with a power output of 0.08 (0.4/5). The reactor space is allocated automatically but displayed as if it was added by the player. Ship-based sensors do not require reactors as their needs can be met from the general power generation of the ship. On a per HS basis, passive sensors are much less powerful than active sensors at the same tech level, which means missiles will require less reactor space per MSP of passive sensors compared to active sensors.
There is no longer a separate 'buoy' category but you can create the same effect by designing a missile with sensors and no engine. The necessary reactor space will be added automatically. Missile reactors have unlimited endurance so there will no longer be a need to replace buoys every few years. While unlimited endurance is unrealistic, modern naval reactors have a service life measured in decades so this is a compromise between realism and a desire to reduce micromanagement. I may add some form of failure during very long term deployment - a failing IFF system on a mine could be entertaining - but I haven't decided yet.
You can create a single stage missile with both an engine and a reactor, which means you can create a self-deploying 'buoy' without the need for a two stage missile, although there are situations in which you might still use a two-stage missile anyway.
Costing has been updated for missile designs. The cost of the individual elements is now as follows:
a) The cost of the missile engine is equal to half that of a ship engine of the same power. This is because the missile engine is designed for short term use only. b) Reactors and sensors are designed for long term use so they have the same cost as a ship-based system of equal power. c) The warhead cost remains one quarter of the warhead strength d) Agility cost is now 2% of the Agility Rating. Agility Rating is equal to the racial Missile Agility multiplied by the number of MSP allocated to Agility. So if your racial Missile Agility was 32 and you allocated 0.5 MSP, the Agility Rating would be 16 and the cost would be 16/50 = 0.32 BP. e) Missile Armour costs one quarter of the amount of armour and Missile ECM is 5% of the ECM strength. These are both unchanged.
Missiles that have sensors will now remain on the map forever, with two exceptions:
a) If a missile has geo sensors and no other type of sensor, it will self-destruct when the geosurvey of its target planet is completed. b) If a missile has a warhead, it will self-destruct when its fuel runs out.
These changes will allow much more creativity in missile design and will also make missiles potentially even more effective, although that includes AMMs too. However, the changes will push missile costs up a little as well and logistics have always been the primary disadvantage of missiles. The changes will also allow for more effective recon and geosurvey drones.
**Missile Engines**
In the new version of Aurora, you will design individual missile engines rather than just allocating a set amount of space to the engine during missile design. You can allocate more than one engine of the same type to a missile design. I'll cover the update to missile design separately though as this post is purely about designing missile engines. It is worth mentioning here though that there will no longer be missiles and drones. Both will be covered by a single design process and the new engines will allow missiles with similar performance to drones.
The four elements of missile engine design are described below.
Engine Technology: Exactly as ship-based engines. For example, the Magneto-plasma Drive has a rating of 16 power per hull space, so a Magneto-plasma missile engine of 1 Missile Size Point (MSP), which is 1/20th of a hull space, would provide 16/20 = 0.8 power.
Fuel Consumption: The base fuel consumption of a missile engine is five litres per Engine Power Hour (which is one point of engine power for one hour) and can be improved through research. So a max size missile engine (5 MSP) with 4 power and a racial fuel consumption technology of 0.6 litres per engine power hour would use 12 litres per hour. This is higher than shipboard engines as missile engines are designed for single use and therefore long-term fuel efficiency is a low priority in their design. They are also solid-fuelled for easy storage, which is less fuel efficient than liquid-fuelled ship-based engines.
Engine Size: Missile engines can range in size from 0.1 MSP to 5 MSP in 0.1 MSP increments. It is hard to create very small fuel efficient engines, so smaller missile engines suffer a further penalty to fuel consumption. The formula is: Fuel Modifier = Int ((Engine Size in MSP / 5) ^ (-0.683)). There is no need to remember this formula as the % change to fuel consumption is shown for each size option in missile engine design. For example, the following sizes of missile engine have the listed fuel consumption penalties
5 MSP x1.00 4 MSP x1.16 3 MSP x1.42 2 MSP x1.87 1 MSP x3.00 0.5 MSP x4.82 0.3 MSP x6.83 0.1 MSP x14.47

```
Power / Efficiency Modifiers: Missile engines use the same principle as ship engines and use the same tech lines (Max Engine Power Modifier and Min Engine Power Modifier). However, the upper end of the range is doubled for missile engines. So if the Max Engine Power tech is x1.75, missile engines can use up to x3.50. The rationale is that these are designed for single use, unmanned craft and therefore have significantly different engineering requirements, such as no radiation shielding or maintenance access requirements. As with ship-based engines, increasing power has a significant effect on fuel efficiency and decreasing power can provide huge savings in fuel efficiency. As the missile modifier is double that of ships, power can be increased by up to six times normal and decreased to 10% of normal if you have the prerequisite techs. The dropdown on the missile engine design window has options from the minimum possible to the maximum possible in 0.05 increments. So 0.40, 0.45, 0.50, 0.55 ...... 1.80, 1.85, etc. Each engine power modifier percentage is accompanied by a fuel consumption modifier, based on the formula Fuel Efficiency Modifier = Engine Power Modifier ^ 2.5

```

For example, a 1 MSP missile engine with a x3.00 engine power modifier would have a x15.59 fuel consumption modifier for the engine power modifier and a x3.00 fuel consumption modifier (x3) for the size of the engine, which is a total fuel consumption modifier of x46.77.
A 0.5 MSP missile engine with a x5.00 engine power modifier would have a x55.90 fuel consumption modifier for the power modifier and a x4.82 fuel consumption modifier for the engine size.
Here are the three examples of 1 MSP magneto-plasma drive missile engines, using x1 power, x3 power and x6 power, with a racial base fuel consumption of 0.6 Litres per Engine Power Hour
0.8 EP Magneto-plasma Drive Engine Power: 0.8 Fuel Use Per Hour: 7.2 Litres Fuel Consumption per Engine Power Hour: 9.006 Litres Engine Size: 1 MSP Cost: 0.2 Thermal Signature: 0.8 Materials Required: 0.25x Tritanium 0.2x Gallicite Development Cost for Project: 40RP
2.4 EP Magneto-plasma Drive Engine Power: 2.4 Fuel Use Per Hour: 336.92 Litres Fuel Consumption per Engine Power Hour: 140.385 Litres Engine Size: 1 MSP Cost: 0.6 Thermal Signature: 2.4 Materials Required: 0.25x Tritanium 0.6x Gallicite Development Cost for Project: 120RP
4.8 EP Magneto-plasma Drive Engine Power: 4.8 Fuel Use Per Hour: 3811.86 Litres Fuel Consumption per Engine Power Hour: 794.137 Litres Engine Size: 1 MSP Cost: 1.2 Thermal Signature: 4.8 Materials Required: 0.25x Tritanium 1.2x Gallicite Development Cost for Project: 240RP
As you can see, you will able to create missiles with more power than you can at the moment but also missiles with far more endurance. Just not both at the same time Smiley. Missiles with a range of several billion kilometers will be possible. The problem will become targeting the enemy rather than designing a missile with the necessary endurance.
**Changes to Engine Design and Fuel Consumption**
Note: This post was updated on 23rd Sept 2012 with a new fuel consumption formula
Engine Design
I've completely changed engine design for v5.70. This shares a lot in common with the Newtonian Aurora engine design, although without the real world physics. Different engine platforms no longer exist, so you will no longer research "FAC" and "fighter" engine types. Engines are classed as "Commercial" for maintenance purposes unless they trigger a "Military" flag - more on that later. The elements of engine design are now as follows:
Engine Technology: This is exactly as before. The engine technology names are the same and the amount of engine power per HS of engine for each type is the same.
Fuel Consumption: This is similar in concept to the old Fuel Efficiency, although it is now modified by other factors in engine design. Fuel Consumption is far more important than in the past. The initial consumption rate starts at one litre per Engine Power Hour (which is one point of engine power for one hour). So an engine with 25 power using the base fuel consumption technology would use 25 litres of fuel per hour. Additional technology levels will lower the fuel consumption rate (0.9 litres per EPH, 0.8 litres per EPH, etc.). On the engine design summary an engine is rated in the total number of litres of fuel per hour it consumes and also the amount per Engine Power Hour. The total amount is derived from Engine Power x Fuel Consumption per EPH. So an Engine with 15 power and a Fuel Consumption per EPH of 0.5 would consume 7.5 litres of fuel per hour.
Engine Size: You can now select the size of engine from 1 HS to 50 HS. Larger engines are more fuel efficient so fuel consumption is reduced by 1% for every HS of engine. For example, a 10 HS engine reduces fuel consumption by 10% and a 25 HS engine reduces it by 25%. There is no longer any restriction on the number of engines so you can have twin engined fighters if you wish.
Thermal Reduction: As before, this reduces the thermal signature of engines, which, without thermal reduction, is equal to their power.

```
Power / Fuel Consumption Modifiers: There are two new tech lines to research, called Max Engine Power Modifier and Min Engine Power Modifier. These establish the range within which you can change engine power from that provided by the base engine technology. Increasing power increases fuel consumption per EPH and decreasing power can provide significant savings in fuel consumption. Power can be increased by up to 300% of normal and decreased to 10% of normal if you have the prerequisite techs. The dropdown on the design window will have options from the minimum possible to the maximum possible in 0.05 increments. So 0.40, 0.45, 0.50, 0.55 ...... 1.80, 1.85, etc. Each engine power modifier percentage is accompanied by a fuel consumption modifier, based on the formula Fuel Consumption Modifier = Engine Power Modifier ^ 2.5

```

For example, assume you choose to increase Engine Power to 1.5. The Fuel Consumption would be 1.5 ^ 2.5 = 2.76, so for a power increase of 50%, the fuel consumption per EPH would increase by 176%. This is shown on the dropdown as "Engine Power x1.50. Fuel Consumption per EPH x2.76".
Crew Requirement: The crew requirement for engines has been significantly reduced. It is now equal to Engine HS x Power Modifier (rounded down). So an engine with 5 HS and a 25% increase in power would require a crew of 5 x 1.5 = 7.5 (rounded down to 7). The old method was simply Engine HS \* 5.
Here is the design summary for an engine of 5 HS, using Magneto-plasma Drive technology and Fuel Consumption technology of 0.6 per EPH with a 25% increase in power and no thermal reduction.

```
Magneto-plasma Drive

```

Engine Power: 100 Fuel Use Per Hour: 99.57 Litres Fuel Consumption per Engine Power Hour: 0.996 Litres Engine Size: 5HS Engine HTK: 2 Thermal Signature: 100 Exp Chance: 12 Cost: 50 Crew: 6 Materials Required: 0x Duranium 50x Gallicite Military Engine Development Cost for Project: 1000RP
Because of the power modifier the fuel consumption per EPH is increased by 75% and due to the size of the engine the fuel consumption per EPH is decreased by 5%. The Fuel Consumption per EPH is calculated as the base racial technology of 0.6 litres per EPH, x0.95 for engine size, x1.7469 for the 25% engine thrust modifier, which equals 0.9957. Fuel use in litres per hour is therefore 100 power x 0.9957= 99.57 litres.
Now lets look at an engine designed with fuel consumption as a priority. This is an engine of 25 HS, using Magneto-plasma technology, with an 60% decrease in thrust and no thermal reduction.
Commercial Magneto-plasma Drive Engine Power: 160 Fuel Use Per Hour: 7.28 Litres Fuel Consumption per Engine Power Hour: 0.045 Litres Engine Size: 25 HS Engine HTK: 12 Thermal Signature: 160 Exp Chance: 4 Cost: 32 Crew: 10 Materials Required: 0x Duranium 32x Gallicite Commercial Engine Development Cost for Project: 800RP
The Fuel Consumption per EPH is calculated as the base racial technology of 0.6 litres per EPH, x0.75 for engine size, x0.1012 for the -60% engine power modifier, which equals 0.045537. Fuel use in litres per hour is therefore 160 power x 0.045537= 7.2859 litres per hour. So this engine produces sixty percent more power then the previous engine yet uses only 7% of the fuel. However, it is five times larger so the base speed is much lower and you will use a little extra fuel pushing the mass of the engine itself. The result is that a ship with this engine will take longer to get there but it will use a lot less fuel on the journey. Note this is classed as a commercial engine and the one above was classed as military. Any engine that exceeds 50% base engine power or is smaller than 25 HS is classed as military for maintenance purposes.
Changes relating to Fuel
As fuel consumption is now higher than in the past, I have made a number of changes to systems related to fuel.
Gas giants have a 50% chance of Sorium compared to 20% in the past. The minimum accessibility for gas giant Sorium is 0.3.
Fuel Harvesters have been reduced in size and cost by 50%. Their crew requirement has been reduced by 80%
Three new Fuel Storage Systems have been added. They are shown below with the current 1 HS system for comparison. Fuel Storage systems no longer require any crew.
Fuel Storage (1HS): 50,000 litres, 10 BP Fuel Storage - Large (5 HS), 250,000 litres, 30 BP Fuel Storage - Very Large (20HS): 1,000,000 litres, 70 BP Fuel Storage - Ultra Large (100 HS): 5,000,000 litres, 200 BP
**Updated Crew Requirements**
The following is a list of changes to crew requirements for each module. I'll go through the whole thread and answer the questions when I get a little bit more time.
Active Sensors, Beam/Missile Fire Control, EM/Thermal Sensors, Cloak, Jump Drive, Reactor: was Hull Spaces x5, now Hull Spaces x2. Asteroid Mining Module: was 100, now 50 Cargo Handling Systems: still 10 each Compact ECM/ECCM: was 10 now 3. Damage Control: was 25, now 10 ECM/ECCM: was 20, now 6 Engineering: was 10, now 5 Grav/Geo Sensors: was 25, now 10 Hangar Deck: was 25, now 15 Jump Gate Construction module: now 20% of previous. 100 for base module. Laser, Meson, Microwave, Particle Beam, Plasma Carronade, Railgun: was Hull Spaces x10. Now Hull Spaces x5. Magazine: was HSx1.5, now HSx0.5, although min 1. Maintenance Module: was 125, now 50. Missile Launcher: was Hull Spaces x Size Modifier x10. Now Hull Spaces x Size Modifier x5 Salvage Module: was 200, now 80. Shields: was 3 per unit, now 1 Small Craft ECM/ECCM, was 4, now 1 Terraforming Module: Was 200, now 100. Tractor Beam: was 20, now 10
Jump Drive Changes
All jump drive tech efficiencies have increased by 1, so the tech progression now starts at 4. The research costs are effectively halved as the RP cost for efficiency 5 is now the same as it used to be for 4, etc..
Jump Drive Cost was (JumpDriveHS ^ 2) / 4 Jump Drive Cost now (JumpDriveHS ^ 1.8) / 4
This is a bigger change than it looks. For example, a 10,000 ton efficiency 5 jump drive is now 191 BP instead of 400 BP. A 15,000 ton efficiency 5 jump drive is now 397 BP instead of 900 BP.
**Major Changes to Crew Accomodation in v5.70 and Introduction of Crew Morale**
This has turned out to be a little more complex than I anticipated Smiley
The following changes will make crew accommodation a much more significant factor in ship design and require the ship designer to consider the amount of time the ship is likely to be deployed in deep space. Ships deployed on long missions without suitable accommodation to keep the crew happy will suffer from low crew morale, which in turn will affect the performance of the ship. Crews forced to work in overcrowded conditions will be equally unhappy.
The basic requirement for crew accommodation is now 1 ton per crewman, or 50 crewman per HS. This is 4x more space than is allowed for a colonist in cryogenic suspension and 1/10th of the space allowed for a passenger in a cruise liner (Luxury Passenger Accommodation). This will suffice for ships who intend to spend no longer than a month away from port. For longer voyages, the ship will need additional living space for the crew. This is based on a per-man requirement but much of the additional space would probably be shared recreational space. As this is a significant increase in crew quarters requirements, I intend to revisit the crew requirements for all modules.
The top left of the Class Window now allows you to enter a Deployment Time in months, which is used as a basis for suitable crew accommodations. This number can be fractional and/or less than 1 but must be greater than zero. The amount of crew accommodations required is equal to the base amount multiplied by the cube root of the deployment time in months. So for a 3 month deployment, the requirement is 1.442 tons per man. For 12 months it is 2.289 tons and for 48 months it is 3.634 tons. For a deployment time of 0.033 months (about a day) the requirement is 0.321 tons per man. The design window will now automatically allocate crew quarters to meet this requirement, using a combination of 1 HS and 0.2 HS systems (I may add a larger one too). You can add more crew quarters than you need to create spare capacity (more on that later) but you can't reduce it below the minimum required.
If the Deployment Time is less than 0.5 months, the required crew is halved. If the Deployment Time is less than 0.1 months, the required crew is reduced by 2/3rd. During every 5-day increment, every ship is checked for any problems with crew morale (I'm using morale as a catch-all for unhappiness, tiredness, etc.). The length of the deployment since the "Last Shore Leave" date is checked. If the number of months since the Last Shore Leave is greater than the designed Deployment Time of the ship, then morale will be less than 100%. Crew Morale is set to Ship Deployment Time / Months since Last Shore Leave. For example, if a ship has been out for 15 months and the deployment time of the class is 12 months, morale will fall to 12/15 = 80%.
Nice and simple until you get to carriers Smiley. Many fighters and other small craft will have intended deployment time of only a few days compared to months or years for their parent carrier. Moreover, the crew of those fighters are likely to spend a lot more time on the carrier than on the fighter itself. For added complexity, there is no guarantee that the crew of the fighter have been out in space for the same amount of time as the crew of the carrier.
Under the new rules, the parent carrier now needs to provide accommodations for the crews of any parasite craft. That is provided for by Spare Berths. You will need to add enough extra crew quarters to provide space for the flight crews. If a ship has a hangar, this is shown on the class summary as "Flight Crew Berths" rather than "Spare Berths". A parasite craft tracks its own Last Shore Leave date but while on the carrier it uses the designed Deployment Time of that carrier. So assume a fighter that last had shore leave six months ago is transferred to a carrier that has been out in space for 4 years - a year past its Deployment Time of 36 months. The crew of the carrier is not happy, having been out in space a year longer than they expected. The crew of the fighter is fine. They have only been out in space 6 months and the carrier has nice spacious accommodations.
When a fighter is out in space (and may or may not have been launched from a carrier), it tracks both the "Months since Last Shore Leave" and "Months since Last Launch". If the last launch was later than last shore leave (which may not always be the case) then that is used for purposes of its current trip. For example, the crew of a fighter has been in space overall for four years but only on its current mission for several hours. During the morale check, it compares the last launch date against the accommodations actually on board the fighter, which will be far less generous than those on the carrier.
However, it is possible that the morale for (Months since Last Launch / Fighter Deployment Time) would result in a higher morale than (Months since Last Shore Leave/ Carrier Deployment Time). As the crew would still be suffering from the effects of being out in space so long on board the carrier, their morale can never be higher than it was when they launched. I know that sounds a little complicated. In summary, what you need to bear in mind is that when you launch a fighter, you need to worry about the length of its deployment from the carrier. That will have an effect on the morale of its crew based on the time since launch and the accommodation on the fighter. However, if the crew was unhappy when they launched, they aren't going to get any happier during the mission.
To improve morale, a ship needs to spend time on orbit of a planet with at a population of at least 10,000. This should be enough to provide bars, nightclubs, brothels, art galleries, etc.. Note that maintenance facilities are not required. You just need people. While in orbit, the Last Shore Leave date will increase at the rate of 10x actual time. Once the Last Shore Leave date moves closer to the present day than the Deployment Time of the crew's ship, their morale will be back to 100%. Of course, if you can get the Last Shore Leave back to the present, the crew is ready for another long mission. Otherwise, it is more of a break during the existing mission. It's worth noting that the small colonies you set up to support the naval forces on the front lines may one day grow into something much larger as civilian traffic moves into the area.
In addition to long deployment times, the crews will lose morale due to overcrowding. Each 5-day, the total number of crew on the ship, plus the crew of any parasite craft, plus any survivors you have picked up plus any survivors on the parasites, is compared to the number of available berths. If there are more personnel than berths then morale will fall. Crew Morale is multiplied by (Berths / TotalPersonnel). So overcrowding and staying out too long are a really bad combination.
The above ends the current situation where a FAC can pickup a couple of thousand survivors. To enable ships to pick up survivors without causing massive overcrowding, I have added a couple of new systems. The "Cryogenic Transport - Emergency" and "Cryogenic Transport - Small". They are 1 HS and 5 HS respectively with capacities of 200 and 1000. While they can be used as normal colonist tranportation, their intended function is to allow ships to carry small cryogenic facilities to allow them to pick up survivors without causing overcrowding or compromising their life support systems. The 1 HS version might be a standard fitting on a cruiser and the larger might be used by "hospital ships". When a ship is transporting survivors, the number of available cryogenic berths is deducted from the number of survivors before considering total personnel numbers in the overcrowding calculation. Any survivors on parasites with available cryogenic facilities will also be excluded from total personnel.
Low morale affects both crew training and fleet training. Whenever a check is required that involves either rating, it is first multiplied by the morale percentage. This means that a ship with low morale will be slow to respond to orders and will not function well in combat. I'll provide a few more details on this in a future post as this post is mainly about how we get to low morale rather than the effects.
As well as the morale effects of overcrowding, it is possible the ship's life support systems may be overloaded. Even though some ships will have extensive crew accommodations, most of that will be recreational facilities. The life support element of those systems is based on the expected crew numbers plus a 20% safety margin. If overcrowding exceeds 20%, there is a chance that life support systems may start to fail. During each 5-day in which Total Personnel/Berths is greater than 1.2 (i.e. more than 20% overcrowded), each crew quarters system is checked for failure. If failures occur they will be automatically fixed by the ship's onboard maintenance supplies until those run out.
The percentage chance of failure for each crew quarters is equal to: ((Total Personnel/Berths)-1) x 10
For example, if a ship has 40% overcrowding, the chance of failure for each crew quarters is (1.4 - 1) \* 10 = 4%. While that doesn't seem very high, if there are a lot of crew quarters on the ship, one or two may fail. Once maintenance supplies run out, even small failures will result in even more overcrowding and the effect may snowball.
If a ship has no life support remaining, either due to battle damage or maintenance failures, emergency systems will keep the crew alive for a while but within a few days whatever jury-rigged systems the crew manage to create will begin to fail and crew members will start to die. The percentage will vary but on average about 50% of the remaining crew will die during each 5-day update. Any survivors that have been picked up by the ship will also start dying. Instead of the overcrowding modifier, morale is divided by 10.
Finally, morale can also be affected by undermanning. If a ship's crew falls below half its normal complement, morale will be affected. The formula is Morale = Current Morale x ((Current Crew \* 2) / Normal Crew) This could be made more complex by looking at the crew required to run the remaining undamaged systems but I think that adds complexity without a corresponding improvement in gameplay.
I will include an option to turn off crew morale / life support overload checks in the same way as turning off overhauls but I think leaving it on adds an interesting extra dimension to the game.
**New Geological Survey Team Mechanics**
A common complaint about geological teams is that they can spend years on a small body such as an asteroid without either finding anything or confirming that nothing exists. Therefore I am completely changing the mechanics for geology teams in v5.70.
The chance of completing a survey team check during one year will be simply based on a combination of planet size and team skill. The formula is (1000 / BodyRadius^(1/3)) \* (TeamSkill / 100)
So a team with a skill of 100 surveying the Earth would have a 53.9% chance of completing the task each year A team with a skill of 120 surveying the Moon would have a 99.8% chance of completeing the task each year A team with a skill of 150 surveying an asteroid with a 50km radius would have a 407.2% chance of completing the task each year.
During each 5-day increment, the chance will be equal to: Yearly Chance \* (Increment Length in Seconds / Seconds in a Year). So in a 5-day increment of 450,000 seconds, a 100% annual chance would be a 1.45% increment chance.
If the check is successful a new mineral generation check takes place for that body. This check is identical to the one performed when the system was originally generated, except the chance for each individual mineral to be generated is 33% of normal. If the check for any of the individual minerals is successful, the size of the new deposit is compared to the one originally generated. If the size of the new deposit is greater then the amount of the original one, the amount of the mineral is changed to the new amount. If the accessibility is also higher then that is increased to the new level. If the size of the new deposit is less than the existing one but the accessibility is higher then the accessibility is increased to the new value.
I considered changing accessibility to a the weighted average of the old and new. However, if I did use a weighted average to increase accessibility of larger existing deposits, I would also realistically have to decrease accessibility in the case of a larger new deposit with lower accessibility. Players would often prefer smaller high accessibility deposits so this would often be a penalty not a bonus. In the end I decided simply changing it to the higher value was easier. The player benefits in all cases and the 75% reduction in generation chance should prevent this being too overpowered.
For example, assume a planet currently has:
Duranium: 100,000 at 0.8 Neutronium 50,000 at 0.6 Tritanium: 25,000 at 0.7
The team makes a successful survey completion roll and a new mineral generation check is performed. A deposit of 30,000 tons of Gallicite is generated. There is no existing Gallicite deposit so that new deposit is added to the planet. A deposit of 160,000 tons of Duranium at 0.7 accessibility is generated. The existing deposit is changed to 160,000 and retains the existing 0.8 accessibility A deposit of 20,000 tons of accessibility 0.9 Neitronium is generated, The existing deposit remains at 50,000 tons and the accessibility is increased to 0.9. No new Tritanium deposit is found so that remains as it is.
Whatever happens as a result of the successful check, including no new minerals, the survey is completed. The chance of the survey team making multiple discoveries over a long period is now replaced with a chance of multiple discoveries during the single check.
You cannot use these new mechanics for homeworlds, due to their different starting situation with regard to minerals. Instead, homeworlds now begin with the team survey flagged as completed.
EDIT: I've also changed the experience mechanic for geo survey teams. They now have a chance of XP at any point while they are working rather than after a task is complete. This because of the widely varying length of the task for different size bodies.
**Engineers Name Change and New Ground Unit**
The existing Engineer Regiment is now the Construction Brigade. Apart from the name change, everything is the same as before.
There is now a new Combat Engineer battalion, which has the same combat strength and cost as a Marine Battalion. Instead of the marine bonus for fighting on ships, it has double strength when attacking or defending a PDC (note: I may change this a little before release)
I've also corrected the bug of starting races having access to TN ground forces they have yet to research.
EDIT: Also, a new civilian mining complex will have a low tech infantry garrison if the TN Garrison unit has not yet been researched.
**High Rated Officers Overview**
Another addition from Newtonian Aurora.
I've added an extra function to the Commanders window. A new "Highly Rated" button brings up a frame on the commanders window covering the bottom right quarter of the screen. It shows a summary of the best officers in various categories. If you move between Empires or use the Replace All button while the summary is open, the summary will dynamically update.
**Disabling Sensors System-wide**
In v5.70 there is an SM option to disable all sensors in a particular system. It is located on the Sensors tab of the system map sidebar. Once activated, there will be no detection phase for ships and planets in that system until it is turned back on again. The reason for this function is because one of the downsides of a multi-system Earth start is the number of detection checks grows exponentially as you add extra races. If you happen to be playing a game in which you want to start multiple races on Earth but there will be a period without the likelihood of combat, you may want to disable sensor checks in Sol for a while for performance reasons. I think this option will be used rarely but it will be very useful in a few specific situations.
**Production Overview Window**
The next version of Aurora (v5.70 at the moment) features a new Production Overview window. This is something I have developed for Newtonian Aurora that I have now added to Standard Aurora. It allows a player to look at all of his industrial projects, research projects and shipbuilding from all populations on a single window. Items that will complete within 3 months are highlighted in green and items that will complete within a year are highlighted in light blue. There are four tabs - one each for Research, Shipbuilding and Industry and a fourth called Imminent Events. This last tab lists all items from all three sectors that will complete within three months, ordered by estimated completion date. This allows a player to quickly look at all of his major production tasks and see when they will be completed. It also has a subset of the time buttons so you can advance time from this window.
In SM Mode, you can look at all Research, Shipbuilding and Industry tasks from all player races on the same window, which will make keeping track of multiple race campaigns MUCH easier. If you click on a task (either in player or SM mode), the Economics window will open for the appropriate combination of race, population and tab. Here are some screenshots from the NATO vs Soviet Union campaign using this new window in SM Mode.
**Logistics Changes**
I have added a new "Load/Unload Minerals to Reserve Level" order. This will first attempt to unload every mineral type but only up to the colony reserve level for that mineral and then attempt to load every mineral type above the reserve level. If there is no loading or unloading at the destination, the fleet will move on to the next order.
I've also added a "Load/Unload Fuel (To Set Level)" order. You specify a reserve fuel level as part of the order. The fleet's tankers will either unload fuel to bring the colony up to the reserve level or attempt to load excess fuel above that level.
Finally, I've added a "Load/Unload Supplies (To Set Level)" order. You specify a reserve maintenance supply level as part of the order. The fleet's supply ships will either unload supplies to bring the colony up to the reserve level or attempt to load excess supplies above that level.
All of the above are intended to aid in automating your Empire-wide logistics network.
**Minor System Generation Changes**
Trojan asteroids can now appear in systems other than Sol in the L4 and L5 points of gas giants and super-jovians. The chance of Trojans being generated and the number generated is based on the cube root of the associated planet's mass.
I've corrected the problem in system generation that can sometimes lead to missing numbers in the roman numerals assigned to planets. For example, in v5.60 you might see Sirius I, Sirius II and Sirius IV as the first three planets in a system. In v5.70, all the planet numbers should be consecutive.
I've changed the ordering of system bodies in the F9 window. Because of the proliferation of asteroids in systems, displaying them in a meaningful way in relation to planets is problematic. Therefore, all asteroids in a system will now appear in one group after all planets and moons. The asteroids will be in order of distance from the star. Comets will appear in one group after asteroids.
**Updates to the Sol System #6**
Today's Sol update includes an additional fifty moons, split between the following planets (new total in parantheses):
Jupiter: 7 (22) Saturn: 15 (29) Uranus: 16 (28) Neptune: 5 (14) Pluto: 2 (3) Quaoar: 1 (1) Orcus: 1 (1) Haumea: 2 (2) Eris: 1 (1)
I have replaced the random Sol comets with 25 real comets. The furthest point of their orbit from the Sun is correct for all the real comets but the current distance in that orbit will be randomised for each game. There are now 619 distinct system bodies in Sol, including planets, moons, asteroids and comets. All of these are real-life objects.
**Updates to the Sol System #5**
More Asteroids!
I have removed the Kuiper belt (185 random objects) from the existing Sol System and replaced it with a further 161 real-life asteroids. These break down as one hundred and thirty-five Trans-Neptunian objects (TNO), eighteen more Jupiter Trojans, two more Neptune Trojans, the three known Mars Trojans, the single Earth Trojan and two more Centaurs.
Some of the TNOs have high eccentricity orbits and for the moment Aurora only supports circular orbits. Of course, this doesn't make a lot of difference in game terms because some of these eccentric orbits are thousands of years and in a normal game's timescales the body would only cover a tiny fraction of that orbit. Therefore, where I can find information on the current distance of an object, I have created a circular orbit at that distance. Where I can't find that information, I have created a circular orbit based on its semi-major axis.
Because the orbits of the new dwarf planets can be close together and are in the midst of the asteroid belts, I have made them a separate category in terms of turning off orbit paths, names, etc..
**Updates to the Sol System #4**
I am planning to separate Trojans from regular asteroids. They will orbit with the planets rather than with the asteroids.
At the moment, the planets, moons and asteroids in the Sol system are always at the same point in their orbit at the start of every game. From v5.70 onwards, every body in the Sol system will be assigned a random point in its orbit at the start of each new Sol-based campaign. This means every game will be unique in terms of the Sol system starting layout.
**Updates to the Sol System #3**
Another Sol Update. Long ago, I created the existing Sol - Mars asteroid belt in the current Sol system by generating systems until I got a suitable asteroid belt at the right distance and then transplanting it into the Sol system in the database. Saved all the entry of asteroid data Smiley
However, now I am on a Update Sol campaign I decided to got for something a little better. I removed the 179 Mars - Jupiter asteroids from the DB and replaced them with over 300 actual asteroids from Sol, with the correct names, sizes, distances and physical data (gravity, escape velocity, etc.). Within these 300+ new asteroids are regular Mars - Jupiter main belt asteroids, a number of Jupiter trojans (which occupy the area around the L4 and L5 lagrange points of Jupiter, some near-Earth asteroids, such as Apophis, Apollo, Cruithne, etc., a few Neptune trojans and several Centaurs located between the orbits of Jupiter and Neptune. This makes the inner Sol system a much more interesting place.
I've spent the last two evenings entering asteroids on to a spreadsheet before importing them into Access. A serious sign of uber-geekness is that I actually enjoyed tracking down all the data Smiley. Now I need to recharge my enthusiasm batteries before tackling the outer system objects and perhaps some real comets for Sol instead of the random ones.
**Updates to the Sol System #2**
Another change. It turns out that planets have been orbiting in the wrong direction all this time Smiley
They should orbit anti-clockwise (counter-clockwise for the US) but until now they have been orbiting clockwise - oops!
As Aurora Lagrange points are at the L5 location, they will still be following planets in their orbit but the change in orbital direction for v5.70 means they will be on the other side of the planet from where they are now (i.e clockwise from planetary location rather than anti-clockwise).
**Updates to the Sol System #1**
I've updated the Sol system, adding the dwarf planets and correcting the density, gravity, mass and escape velocity for all the major moons.
The new dwarf planets added are Ceres, Eris, Haumea, Makemake, Orcus, Quaoar and Sedna. As they have such long orbital periods I have used their current distance from the Sun rather than their average distance. Pluto is also now classed as a dwarf planet. Those planets and any planets that used to be listed as "Chunks" will now be listed as dwarf planets in the F9 view. I considered adding the moons for the new dwarf planets but the data on them is extremely limited so I haven't for the moment. I'll probably come back and tackle that at some point though.
There were some significant mistakes in the physical data for many of the existing moons. In fact, some were so wrong I can't imagine where I got the original information. I have used the Wikipaedia entry for each moon to source the updated information. This will result in some changes in terms of possible colonization as Titan's gravity has dropped considerably.
After Mars/Mercury at 0.38g, the highest gravity can be found on:
Io: 0.183 Luna: 0.165 Ganymede: 0.146 Titan: 0.140 Europa: 0.134 Callisto: 0.126 Eris: 0.084 Triton: 0.079 Pluto: 0.067 Haumea: 0.044 Sedna: 0.043 Makemake: 0.041 Titania: 0.039 Quaoar: 0.038 Oberon: 0.035
To make life a little more interesting, I am going to widen the range of racial gravity tolerances possible for a new race. A random race will have from 50% to 90%. Humans will start with 90%, which makes the Moon, Titan and the Galilean moons all possible colony sites and will widen human options in other systems. I've also halved the "Genome Sequence: Base Gravity" research costs.
In the past the mean surface temperature of the Earth in Aurora has been 22C. I've now changed it to the correct value of 14C. I've also increased the base human temperature range from 22C to 24C, giving a range of -10C to 38C, which seems reasonable in terms of the environments in which humans live in Earth. -10C might be a little on the chilly side but we can survive reasonably well without space-age infrastructure to assist.
Finally, I have updated the Known System data in Aurora with the work I did for Newtonian Aurora. There are now 4250 Known Systems in the database, including all known systems within 100 LY of Sol.

## Version 5.50

2. ) New Glossary of Terms tab for the Class Window, to explain the various abbreviations in the class summary
3. ) New 'Wreck Detected' event, which will notify players when a new wreck appears in a system where they have planetary sensors or a ship
4. ) Removed non-hostile targets from default target list on F8 window and added option to include non-hostile.
5. ) Added current target to end of fire control name in the fire control section of F8 window
6. ) Same contact remains selected in F8 target list if you change fire control or ship selection.
7. ) F8 Contact list is sorted alphabetically
8. ) On the F8 window you can choose to highlight contacts that are currently targeted by either the current task group or the same empire. The targeted contacts are shown with a preceding (T)
9. ) You can now transport Ground Force Training Facilities in cargo holds. They require the same space as a research lab
10. ) Clicking on a wreck on the system map will centre the map on the wreck
11. ) All ground units need to be researched before they can be built
12. ) The temperature range research projects for creating new species offer a much greater temperature range than before
13. ) Turret design has been modified - see below
14. ) The Civilian Colonisation status for pops over 25m can now be set to Destination, Source or Stable. Stable means neither a source nor a destination.
15. ) Civilian colony ships will now take account of other colony ships when deciding on their destination - see below
16. ) Jump Drives now suffer from transit effects and cannot jump again until transit effects wear off
17. ) Manual missile launches at waypoints cannot take until transit effects wear off
18. ) Explosion contacts will state if they are ground burst
19. ) You can conduct alien autopsies on species you recover from life pods to learn their environmental tolerances.
20. ) Added Black Hole system - see below
21. ) Population list for F2 window now shown as tree view with option to display by system or by function/system (see below)

**Major Bug Fixes**
* Fixed the bug where completing a research project by disassembling tech might delete a population.
* Fixed the bug where your freighters entering populated systems cause an alien race to attack even when a trade treaty is in place
* Fixed bug where parasites still on board their mothership would attempt to ram
* Fixed bug that prevented lagrange points being used in cycled orders

**Improved Est Time for Maintenance**
The existing Est Time field on the Class Summary provides a more useful guide to the likely time before maintenance supplies run out than the base failure rate. However, the value in this field is calculated based on the most expensive component failing, which will not always happen. If the component is expensive but small this will be even more of a distortion as the selection of a system for failure uses the combat DAC. So for v5.50 I have added a much more detailed calculation for the Est Time field and also renamed it the Maint Life field.
In v5.50 Aurora looks at the chance of each individual system failing within a given year and creates an aggregate annual failure cost, based on the cost of each component multiplied by the percentage chance of it being selected for maintenance failure. This will lead to higher but more accurate Maint Life figures. This also allows for more detail in the maintenance line of the class summary. Shown below are the new v5.50 version and the older v5.42 version of the class summary. AFR is just an abbreviation of annual failure rate and MSP is an abbreviated way to show Maint Capacity. 1YR shows the estimated cost of maintenance failures for one year of continual operations after an overhaul. 5YR shows the estimated cost of maintenance failures for five years of continual operations after an overhaul. This is 15x greater than for 1 year because of the increasing chance of failure with each year that passes after an overhaul. Based on player suggestion I have also changed the order the information is presented to emphasise Maint Life over AFR.
Although this looks a little more complex due to the extra information, it should make understanding the maintenance requirements of a design far easier and more accurately reflect the potentially significantly different failures of designs that may have a similar overall size and cost. It will also give players an idea of how many MSP they are likely to expend and they can therefore plan MSP production accordingly.

```
Eridani class Missile Cruiser    15,000 tons     1016 Crew     2718 BP      TCS 300  TH 2100  EM 0
7000 km/s     Armour 7-54     Shields 0-0     Sensors 16/36/0/0     Damage Control Rating 8     PPV 114
Maint Life 4.82 Years     MSP 906    AFR 225%    IFR 3.1%    1YR 64    5YR 962    Max Repair 180 MSP

```

```
Eridani class Missile Cruiser   15,000 tons     1016 Crew     2718 BP      TCS 300  TH 2100  EM 0
7000 km/s     Armour 7-54     Shields 0-0     Sensors 16/36/0/0     Damage Control Rating 8     PPV 114
Annual Failure Rate: 225%    IFR: 3.1%    Maint Capacity 906 MSP    Max Repair 180 MSP    Est Time: 1.62 Years

```

**Ground Unit Research**
All ground units need to be researched in v5.50 before they can be built.
* With TN tech you can research Mobile Infantry, Replacement, Engineer and Garrison.
* Assault Infantry requires Mobile Infantry
* Marine and Heavy Assault battalions requires Assault Infantry.
* Marine Company requires Marine Battalion
* Brigade HQ requires Mobile Infantry
* Division HQ requires Brigade HQ

**Changes to "Genome Sequence: Base Temperature" tech line**
* 5,000RP: Base Temperature +10C
* 10,000 RP Base Temperature +20C
* 20,000 RP: Base Temperature +30C
* 40,000 RP: Base Temperature +40C
* 80,000 RP: Base Temperature +50C

et cetera
This should make this range of tech more worthwhile in the future.
**Turret Design**
Turrets can now have fractional sizes. However, this means that with the current rules there is no longer any advantage to having twin, triple or quad turrets, as they are just exact multiples of the single turret in terms of size, crew, etc.. Therefore I have also made the following changes:
Large turrets receive a discount in terms of the size of the turret gear required. The discount is 5% for twin, 7.5% for triple and 10% for quad. So for a single turret that required 1.5 HS of gear, a twin turret would require 2.85 HS and a quad would require 5.4 HS. The total crew for the turret receives the same discount.
Additional armour for the turret is based on its total volume, using the current armour technology and exactly the same formula as for a ship the same size as the turret. As with ships, larger turrets will require less material per weapon to provide a given level of armour. Armour increases the HTK of the turret by (Armour Level \* Number of Weapons). So adding 2 armour to a quad turret would increase the HTK by 8.
An example:
The Eridani have a 20cm Laser which is size 6. Their fire control tracking speed and turret tracking speed are both 6250 km/s and they have laminate composite armour. A single, unarmoured turret with a tracking speed of 25,000 km/s will appear as below. The new SPW parameter indicates the total size per weapon, which for a single turret is equal to the turret size.
Single Turret

```
Damage Output 10x1      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 8.4    SPW: 8.4    Turret HTK: 3
Power Requirement: 10    Power Recharge per 5 Secs: 5
Cost: 75    Crew: 60

```

The twin unarmoured turret and the quad unarmoured turret, also with a 25,000 km/s tracking speed, are shown below. As you can see, the SPW figure is slightly lower for the larger turrets.
Twin Turret

```
Damage Output 10x2      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 16.56    SPW: 8.28    Turret HTK: 6
Power Requirement: 20    Power Recharge per 5 Secs: 10
Cost: 149    Crew: 114

```

Quad Turret

```
Damage Output 10x4      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 32.64    SPW: 8.16    Turret HTK: 12
Power Requirement: 40    Power Recharge per 5 Secs: 20
Cost: 295    Crew: 216

```

Now lets add armour thickness 2. As you can see, this makes the turrets harder to destroy and the difference in SPW is much more pronounced due to the efficiency savings when armouring larger turrets. These changes should make large armoured turrets a serious option for ship designers.
Single Armoured Turret

```
Damage Output 10x1      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 11.73    SPW: 11.73    Turret HTK: 5
Power Requirement: 10    Power Recharge per 5 Secs: 5
Cost: 115    Crew: 60

```

Twin Armoured Turret

```
Damage Output 10x2      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 21.8    SPW: 10.9    Turret HTK: 10
Power Requirement: 20    Power Recharge per 5 Secs: 10
Cost: 212    Crew: 114

```

Quad Armoured Turret

```
Damage Output 10x4      Rate of Fire: 10 seconds     Range Modifier: 4
Max Range 400,000 km    Turret Size: 40.87    SPW: 10.22    Turret HTK: 20
Power Requirement: 40    Power Recharge per 5 Secs: 20
Cost: 394    Crew: 216

```

**More Intelligence for Civilian Colony Ships**
In v5.42, civilian colony ships only consider whether there is sufficient infrastructure at their destination to support the existing population plus their own colonists. This doesn't cause a serious problem in the early game. However, when you have fifty civilian colony ships who all decide to ship 100,000 colonists to a world with one million pop and enough infrastucture to support 1.1m, it can mean a seriously negative growth rate.
Therefore, in v5.50 civilian colony ships will consider whether there is sufficient infrastructure at their destination to support the existing population plus their own colonists plus the colonists of all other colony ships (both civilian and state-controlled) currently en route to that population.
This is obviously a significant performance overhead. To compensate, civilian colony ships will use the colony cost of the potential destination population as it was at the end of the terraforming phase of the last 5-day increment, rather than calcuating it every time they check a population.
**Black Hole System**
I have added black holes to Aurora for v5.50. These are only available in Real Stars games for the moment but I may expand that to random games as well, depending on how well they work out. Obviously there are no known black holes close to Sol so some artistic licence is involved. I am just assuming we haven't spotted them yet Smiley. Or I guess the technobabble could be that the high gravity of distant black holes causes long-range jump points to form. I have considered black holes (and other stellar phenomena) for a while but I couldn't come up with a simple mechanic, especially as gravity doesn't really play a part in Aurora at the moment. Hopefully the following will be fun and straightforward and capture the basic scariness of black holes.
Each black hole is rated from Class I to Class X. The pull of the black hole is equal to 1000 km/s multiplied by the class, so a class IV black hole has a pull of 4000 km/s. If a fleet has a speed greater than the pull of the black hole then its speed is reduced by that pull but it can otherwise function normally. So a scout ship capable of 4500 km/s moving through a system with a class III black hole would move at 1500 km/s instead. If a fleet has a speed less then the black hole, then any orders are ignored (although not cancelled) and it is pulled straight toward the black hole at a speed equal to black hole pull minus fleet speed. So a fleet with a speed of 3200 km/s in a system with a class VI black hole would be pulled toward the black hole at 2800 km/s. On the system map, this pull speed is shown as a negative, so the aforementioned fleet would be shown as travelling at -2800 km/s.
When a fleet enters a black hole, all the ships in the fleet are instantly destroyed and leave no wreckage or life pods. A battle fought in a black hole system is going to be interesting because damaged ships are likely to get dragged away from the battle as they slow down. I haven't coded it yet but wrecks and lifepods will be pulled toward the black hole as well. As it would be very difficult to salvage a moving wreck I am also considering just not having any wreckage in black hole systems, although I would still have life pods.
A black hole system can be surveyed for jump points just like any other system. For purposes of the survey locations a black hole has stellar mass equal to its class, so higher class black hole systems will be harder to survey.
NPRs and civilians are aware of discovered black hole systems and will avoid them unless they have a sufficient speed advantage over the pull of the black hole.
**New Population List**
In v5.50, the F2 Economics window will list colonies using a treeview, rather than a simple list. They are grouped by System, with the systems in order of total population. Each colony is shown with its primary attribute, such as population, number of automated mines, number of civilian mining complexes, etc. You can turn civilian mining complexes on/off to exclude those colonies from the list. This should make organising colonies a lot easier when you have a large empire.

EDIT: I have added an alternative view of populations. You can now group them function and system instead of just by system. Clicking the Group by Function checkbox will display populations as below. I have not expanded all branches for this screenshot.