Author Topic: Change for v6.00  (Read 26040 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Change for v6.00
« on: April 21, 2012, 09:31:14 AM »
I am going to put all the various posts covering rule changes for v5.70 in this thread so it will be easier for players to figure out what will be in the new version.

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.
« Last Edit: September 01, 2012, 10:13:14 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #1 on: April 21, 2012, 09:32:00 AM »
Updates to the Sol System #2

Another change. It turns out that planets have been orbiting in the wrong direction all this time :)

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).
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #2 on: April 21, 2012, 09:32:57 AM »
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 :)

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 :). 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.

Here are a couple of screenshots. The first shows the main belt, near-Earth and Jupiter Trojan asteroids. The second shows the Centaurs and the Neptune Trojans




 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #3 on: April 21, 2012, 09:34:00 AM »
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.
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #4 on: April 21, 2012, 09:35:15 AM »
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..



The first screenshot shows the outer system with the updated outer asteroids. Dwarf Planet orbital paths are turned off. Note Pluto in the inner edge of the belt at about 11 o'clock. The second screenshot shows the increased number of Jupiter Trojans and the extra few inner system asteroids. Note that because the new random bearing changes that Jupiter is starting in a different point of its orbit. The bearings of the Trojan asteroids will also be randomised within a 20 degree section of arc with the midpoint in the L4 and L5 lagrange points of their parent planet (depending on whether they are L4 or L5 Trojans). In reality the Trojans cover about 26 degrees of arc but there are a lot more asteroids in reality too. The Trojans (and all other bodies) will still retain their exact orbital distances even though the bearing are randomised




 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #5 on: April 21, 2012, 09:36:16 AM »
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.

The first screenshot shows a few of the comets. The asteroids scattered between Jupiter and Uranus are Centaurs. The line of the asteroids in the top right are Neptune's leading Trojans, scattered around the L4 Lagrange point. Neptune is outside the field of view, which is why there is no orbital path. The second screenshot is of the inner system and includes several more comets. As you can see, the inner Sol system is looking a lot more interesting than before.




 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #6 on: April 21, 2012, 09:37:03 AM »
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.
« Last Edit: April 21, 2012, 09:50:45 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #7 on: April 21, 2012, 09:39:23 AM »

If one construction project ends and a new project is moved from the production queue, that now generates an event.

If you encounter an alien race that has the same homeworld, you automatically know the Race name and how to communicate. This saves a lot of messing around in the Alien Race window for multi-Earth starts

The SM can now set a fixed relationship toward an alien race using a new checkbox on the Alien Race window. If he sets this checkbox, the relationship will not change during the normal 5-day cycle. This is a way to prevent political status changes during a multi-Earth start, if desired.
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #8 on: April 21, 2012, 09:39:33 AM »
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
« Last Edit: April 21, 2012, 09:50:17 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #9 on: April 21, 2012, 09:41:05 AM »
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.









« Last Edit: April 21, 2012, 09:49:44 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #10 on: April 21, 2012, 09:41:47 AM »
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 exponentionally 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.
« Last Edit: April 21, 2012, 09:49:22 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #11 on: April 21, 2012, 09:42:16 AM »
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.



« Last Edit: April 21, 2012, 09:49:03 AM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #12 on: April 21, 2012, 09:43:39 AM »
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.
« Last Edit: May 21, 2012, 04:17:31 PM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #13 on: April 21, 2012, 09:44:17 AM »
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.

« Last Edit: October 05, 2012, 07:19:56 PM by Steve Walmsley »
 

Offline Steve Walmsley

  • Aurora Designer
  • Admiral of the Fleet
  • Posts: 6505
  • Thanked: 848 times
    • View Profile
    • http://www.starfireassistant.com
Re: Change for v5.70
« Reply #14 on: April 21, 2012, 09:45:34 AM »
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 :)

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.

The following screenshots show 3, 12 and 48 month options for a ship with a crew of 275. Tons per Man shows the multiplier for the deployment time. Capacity per HS shows hows many crewman will be supported by 1 HS of crew quarters. Accom HS Req is the number of hull spaces required for the crew and Accom HS Avail shows how many have been added to the design. In the case of the 3 month option there are actually 277 berths on the ship so 2 are spare berths. I'll get back to cryo berths later.



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 :). 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.
« Last Edit: August 19, 2012, 01:08:08 PM by Steve Walmsley »
 

 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51