Aurora 4x
VB6 Aurora => VB6 Mechanics => Topic started by: Steve Walmsley 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.
-
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).
-
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
(http://www.pentarch.org/steve/Screenshots/Asteroids.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids2.PNG)
-
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 #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..
(http://www.pentarch.org/steve/Screenshots/Options.PNG)
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
(http://www.pentarch.org/steve/Screenshots/Asteroids3.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids4.PNG)
-
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.
(http://www.pentarch.org/steve/Screenshots/Comets.PNG)
(http://www.pentarch.org/steve/Screenshots/Asteroids5.PNG)
-
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.
-
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.
-
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
-
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.
(http://www.pentarch.org/steve/Screenshots/Overview-Industry.PNG)
(http://www.pentarch.org/steve/Screenshots/Overview-SYTasks.PNG)
(http://www.pentarch.org/steve/Screenshots/Overview-Research.PNG)
(http://www.pentarch.org/steve/Screenshots/Overview-Events.PNG)
-
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.
-
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.
(http://www.pentarch.org/steve/Screenshots/Rated.PNG)
-
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.
-
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.
-
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.
(http://www.pentarch.org/steve/Screenshots/Accom3.PNG) (http://www.pentarch.org/steve/Screenshots/Accom12.PNG) (http://www.pentarch.org/steve/Screenshots/Accom48.PNG)
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.
-
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.
-
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: 5 HS 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 (20 HS): 1,000,000 litres, 70 BP
Fuel Storage - Ultra Large (100 HS): 5,000,000 litres, 200 BP
-
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 :). 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.
Edited 22-Apr to remove the x2 power modifier
Edited 31-Jul to add the fuel consumption penalty for size
Edited 23-Sept to change to a new fuel consumption formula for power modifiers
Steve
-
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 an EM 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.
Here are a couple of screenshots from the updated missile design window.
(http://www.pentarch.org/steve/Screenshots/MissileDesign01.PNG)
(http://www.pentarch.org/steve/Screenshots/MissileDesign02.PNG)
-
All sensors and fire controls now require 100% Uridium, instead of 75% Uridium and 25% Duranium
Engines require 100% Gallicite instead of 75% Gallicite and 25% Duranium
Reactors require 100% Boronide instead of 75% Boronide and 25% Duranium
-
You can build low tech armour and infantry once again in v5.70.
Steve
-
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.
Steve
-
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 infrastruture. 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
-
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.
Steve
-
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.
Steve
-
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 :)
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.
Steve
-
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.
Steve
-
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.)
So a large freighter from the Adonai Colony Corporation that is equiped with ion engines, would be the Adonai Large F3 class. Here is a screenshot showing the names in a campaign:
(http://www.pentarch.org/steve/Screenshots/CivTraffic.PNG)
-
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 :))
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.
Steve
-
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%
Steve
-
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.
-
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)
-
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 :)
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.
-
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 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
-
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.
-
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.
-
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 you create Flight Crew Quarters for example.
-
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.
Steve
-
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.
-
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.
-
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.
Steve
-
Shield Fuel Use
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.
Steve