Details

Several routines in VGA Planets are rather complex, or use complex formulas. I now have these listed separately on this page, allowing for more indepth explanation while at the same time keeping the other helppages more understandable.

Combat: order in which ships fight
In knowing the order in which ships fight is not only important to know which ship in your battlegroup fights first, but also which ships will fight eachother first altogether. And after that, in which order ships will figh eachother.

To determine the order in which battles are fought, the Host program first lists all ships in one location in order of ascending battlevalue (friendly code battle order). Then it starts at the top of the list, and sees if the ship with the lowest battle value meets the criteria for fighting the next ship on the list. This is not necessarily caused by this ship itself: if the ship has no kill mission and no primary enemy set, it can still fight if there is an enemy ship there with this ship's owner as primary enemy or on a kill mission.

Let's consider the ship that host is checking combat for the initiator (it initiates the search for battles), and the ship which actually triggers the combat, by having a kill mission or the proper primary enemy set, the agressor. It is important to understand the initiator is not necessarily the agressor, although the two are often the same: the ship with the lowest friendly code / battle value usually has such a low value because it is deliberately set to fight first, and likely has both a low friendly code and a primary enemy set.

However, there are cases where the initiator is not the agressor. It's very well possible the initiator has a low friendly code (a Firecloud coming out of a chunnel, for example) but has no primary enemy or kill mission set (the Firecloud most likely isn't looking for a fight).

So while checking for battles with the initiating ship, the battle can be invoked either by the ship itself or another ship. The initiator is not necessarily the agressor. The important thing to remember is that battles are ordered by battle-value, for the initiators.

First of all, it is important to keep this in mind when you are setting the order in which your own ships fight. If you give one ship a low friendly code but no primary enemy or kill mission while giving another ship a non-numerical friendly code and a kill mission, the ship with the lower friendly code is still likely to fight first. It is first on the list of initiators, and if it is checked against an enemy ship and that enemy ship has a kill mission, it will fight. Before your own ship with it's kill mission.

Second, it is something to think of if you are set to fight a group of multiple enemies. Your group will fight as a whole (ordered by battle-value) and their group will fight as a whole (also ordered by battle-value). If you are facing a group of Birdmen and Fascists, and your ship that is set to fight first has the Fascists as it's primary enemy, it may very well first fight a Birdmen ship. This depends on the enemy group. If they have a Birdmen ship set to fight first which has you as it's primary enemy, host first checks your ship (thei initiator) against the enemy ship with the lowest friendly code. If it is set to fight you, you will fight it - even though it doesn't belong to your ship's primary enemy.

Third, knowing who is the initiator determines who gets the righthand side of the VCR. The rule is that the initiator is placed on the righthand side of the VCR. In 99% of the cases, the initiator is the agressor, so the often used statement "agressor gets the right side" holds true. Though not in some cases (think of the Firecloud that wasn't set to fight: it will still get the right side). A more accurate rule would be "the lowest battle-value (friendly code) gets the right side". This is true in 99.9% of all cases (not counting cloaked intercept).

The one rule that is really true is "the initiator gets the righthand side". As said, in 99.9% this is the ship with the lowest battle-value. But sometimes when ships fight eachother, neither of them is strong enough to kill or capture the other ship. The battle times out, and host repeats it's list of initiators. The mechanic is best explained by this example:

If there are three ships at a location (regard their order according to battle-value to be 1, 2, 3) Host works the following way:

• check if ship 1 will fight ship 2 (ship 1 is initiator, agressor can be either ship 1 or 2)
• check if ship 1 will fight ship 3 (ship 1 is initiator, agressor can be either ship 1 or 3)
• check if ship 2 will fight ship 1 (ship 2 is initiator, agressor can be either ship 2 or 1)
• check if ship 2 will fight ship 3 (ship 2 is initiator, agressor can be either ship 2 or 3)
• check if ship 3 will fight ship 1 (ship 3 is initiator, agressor can be either ship 3 or 1)
• check if ship 3 will fight ship 2 (ship 3 is initiator, agressor can be either ship 3 or 2)

So, assuming no ship gets killed and all the battles time out (end before someone actually wins), there will be a total of six battles.

Back to who gets the righthand side: if two ships fight eachother, the first combat is triggered by ship 1 - it is the initiator and gets the righthand side. If this battle times out, host checks ship 2, and sees it will fight ship 1. Ship 2 is now the initiator and gets the righthand side. So even though these are the same two ships with the same friendly codes and everything as in the first battle, the roles are reversed now. The ship with the lowest friendly code now gets the left side, after having had the right side in the first battle.

Combat: left and right side of the VCR

The following information is based in Jan 'Sirius' Klingele's excellent Master at arms article, and on further information from Sirius that will be included in a future update of Master at arms.

There is a difference between fighting from the left-hand side of the VCR and the right-hand side. This difference is originally caused by the way fighters behave in carrier vs. carrier combat. Put simply, fighters launched by carriers from the lefthand side have a better chance in fighter vs fighter dogfights in mid air, and thus carriers from the left side have a better chance against carriers from the right side. To compensate for this, the ship on the right-hand side has a chance to get a bonus mass, making it less vulnerable to fighterhits. This chance of a bonus mass also exists for torpedo-ships fighting from the righthand side, if they fight against a carrier.

Ships fighting from the righthand side against a carrier have a 60% chance to get a bonus mass of 360 kilotons, if the ship's battle mass is already more than 140 kilotons (battle mass includes mass gained by the engine shield bonus). This bonus mass can have a great impact on the battle, because ships that have a battle-mass of 320 kilotons or more only sustain half the damage from a fighter-hit than lighter ships.

So when sending a ship into combat against a carrier, it is always important to know which will benefit you most: getting the lefthand side so your fighters are more effective, or getting the righthand side so your ship has a chance to be more robust in combat. Torpers ofcourse will always want the righthand side, to get the chance of the bonus mass.

Normally, which side is better for you is pretty clear-cut. With medium torpers the bonus mass of the right side is to be preferred, With heavy carriers vs heavy carriers getting the better fighter odds of the lefthand side is preferable. Things become less easy to put down in a rule of thumb when medium carriers come into play. They can either opt for the higher mass (better defense against enemy carrier) or better fighter chances (better offence). This becomes even more complicated when the battle will eventually involve beams firing at enemy ships, as it will put extra emphasis on the defensive strength of the battlemass.

• Torper vs torper: no difference between left and right
• Torper vs carrier: torper has an advantage from the right side, so...
  - If the torper weighs more than 140 but less than 320 kilotons, it wants the right side for the bonus mass
  - If the torper is lighter than 140 kilotons there is no chance for a bonus mass,
    so the torper will want the left side to deny the carrier the left side advantage
  - If the torper weighs 320 kilotons or more already bonus mass has no influence,
    so the torper will want the left side to deny the carrier the left side advantage
• Carrier vs carrier: fighters fight better from the left, chance of bonus mass from the right:
  - if both carriers weigh 140 kilotons or less, there's no chance of a bonus mass so each carrier wants the left side
  - if both carriers weigh 320 kilotons or more, bonus mass doesn't help much so the left side is desirable

These rules do not apply to all carriers, as shown by this example from Sirius: "Take an example of two Geminis with Heavy Phasers, Transwarps and a 60% engine bonus setting (giving the ships a battle mass of 320 kt). Thanks to the 60% chance of the 360 kt bonus, the Gemini on the right side will win in 63.5% of all battles, while the left side has only a 36.0% chance to win (0.5% draws). Naturally this is not a very typical carrier to carrier battle, since the impact of the beams on the enemy capital ship is quite important to decide the battle outcome."

What's missing in the above summary is carrier vs carrier battle where only one carrier has a weight between 140 and 320 kilotons. Another quote from Sirius: "An example where the offensive abilities dominate are two Fed Kittyhawks (no E-S bonus and X-Rays) with 9 bays and 223 kt battlemass (meaning a lot of bays for this size of ship), where the left ship will win in 51.8% against 47.1% of all cases. An example where the defensive is more important are two Valiant Winds (again no E-S bonus and X-Rays) with 3 bays and 180 kt battlemass (relatively few bays for the size), here the right ship will win in 73.8% against 26.2% of all cases."

Advice in either way: read the Master at arms article to get a better understanding of this, and simulate your battles beforehand.

Combat: strength of planets

• Number of beamweapons: SQRT ( (Defenseposts + Basedefenses) / 3)

• Type of beam weapons: SQRT (Defenseposts * 0.5 )
  Or tech starbase's beamtype, whichever is higher}
  Note that 'type' is not the same as techlevel.
  The type-number is the position of the beam in the table below

• Number of fighters: SQRT (Defenseposts - 0.75)
  Fighters stored at the starbase are added to this amount

• Number of fighter bays: SQRT (Defenseposts)
  Having a Starbase adds another 5 fighter bays

• Planetary battlemass: 100 + defenseposts + starbase defenses

The first three formulas are rounded, the formula for number of fighter bays is truncated. The number of starbase defenses are only taken into account when calculating the number of beams. They don't affect the number of fighters or the beam tech level.

Ion Storms: movement, dragging, merging etc.

This information is based on Stefan Reuther's article on Ion Storm Physics:

The speed of an Ion storm seems to be determined by the following rules:

Storms, stronger than 250 MeV always move at warp 8.
Storms with a radius smaller than 200 ly move at warp 6.
Larger storms move at one of the following speeds:
    Warp 2 (20%)
    Warp 3 (48%)
    Warp 4 (32%)
Use the first applicable rule.

The heading of an Ion storm usually changes by 10 degrees.

Storms during the power increase phase:
The storm's voltage is an odd number and increases by 0, 2, 4, 6, 8 or 10 volts while the radius decreases anywehere between 0 and 6 lightyears. When the radius is about to drop below zero, the storm becomes a weakening storm starting at a strength based on it's current voltage plus a random increase. The new radius is 1 - "Old radius".

During the power increase phase a storm's voltage always increases by 1 meV, storms over 320 meV have a 2.5% chance of another one meV increase and storms stronger than 500 meV have another 10% chance to increase another 1 meV. A 600 meV storm for example gets all 3 chances and can increase by 3 meV. When only one meV is added to the storm's voltage the storm will start to weaken, otherwise it will keep on growing stronger.(?)

Storms during the weakening phase:
The storm's voltage is an even number and decreases by 4, 6, 8, 10, 12 or 14 volts. The storm disappears when the voltage drops to or below zero. There is a 33.33% chance that a weakening storm will "pancake" into a weak storm with a large radius. When this happens, the storm's radius doubles and it's voltage becomes the square root of it's current voltage. Next to these effects, the storms radius increases by a random amount between 0 and 10 lightyears per turn.

Storms merging together:
If two storms come close enough, they merge into one. If two storms are close enough for this is determined by the following formula:
  (x1 - x2)^2 + (y1 - y2)^2 < (radius1)^2 + (radius2)^2
To cut a long story short, storms have to overlap somewhat to merge, but they need not cover each other completely. In addition, one of the storms must be stronger than the other (greater voltage); two storms of equal power do not merge.

When two storms merge, the new storm will keep the same Id number, warp factor and heading like the stronger of the two storms. The new center lies on the line between the two original centers, where
 (new x) = x1 + (x2 - x1) * (voltage1) / (voltage1 + voltage2)
or, simplified,
 (new x) = (x1*voltage2) + (x2*voltage1) / (voltage1 + voltage2)
The formula for the Y coordinates is the same with Y instead of X.

This means the new center is closer to the weaker storm than it is to the stronger storm.

The new voltage of the storm:
(voltage of stronger storm) + sqrt(voltage of weaker storm)

The new radius:
(radius of stronger storm) + sqrt(voltage of weaker storm).

Based on it's new voltage and radius and the rules listed above, the new storm can either be in the power increase phase or the power decrease phase.

Ion storms merge after Ion storm movement, but before ships are effected and before generation of new storms.

Effects on ships:
All storms (regardless of their strength) decloak all ships except the advanced cloakers (Resolute and Birdmen). Only ships that are cloaked are not affected by Ion storms. Ships get dragged by the storm for 75% of the distance the storm travels (0.75*stormwarp^2). The damage ships suffer is calculated by the following formula: damage = voltage - shipmass - shipexperience + 20*(10-enginetype). Fuelless ships suffer another 50% damage.

Ships that get damaged lose part of their crew according to the following formula:
crew lost = Stormvoltage - Shipmass - 2*Experience + 0.3*Crew

Experience:
Ships gain experience by movement, surviving combat, alchemy and experience with ion storms. In Ion storms, ships gain one experience points for every 20 volts which the storm is over 140 meV. This means crews start gaining experience when they survive in storms over 160 meV (one point for storms ranging from 160 to 179 meV, 2 points for storms 180-199 meV etc.).

Miscellaneous:
Storms outside the range (0,0)-(4000,4000) disappear the turn after they moved there. It is possible (though not very likely) to have storms at coordinates usually considered invalid.

If there are more storms than allowed in the Host Configuration, the weakest one(s) disappear.

Newly generated storms may have warp factors reported (Warp 5 and Warp 7 for example) that are not possible according to the above rules. However, the Host program re-computes the warpfactors before actual storm movement.

Up to three new storms can be born per turn.

Movement: formulas

It is possible to predict the ending coordinates of a ship, if it has a waypoint that is further away than the ship can travel based on it's warpsetting. To do so, follow these steps:

• First, determine the ship's major direction. Put quite simply, see if it set to move more in the east or west (X) direction, or more north or south (Y). If the waypoint of a ship, relative to it's current position, is 50 lightyears south and 40 lightyears west the major direction is south. The minor direction is west.
• The distance travelled in this major direction is INT [ (warp^2 * major direction) / sqr (major direction^2 + minor direction^2) + 0.5]
• The distance travelled in the minor direction is INT [ movement in major direction * (minor direction / major direction) + 0.5 ]
• Last but not least, add or subtract (movement south and west leads to coordinates with a lower X and Y value) the lightyears calculated from the ship's current coordinates.

An example:
A ship starts at location (0,0). It's waypoint is set to (135, 265) and it's speed is warp 9.

• The ship's major direction is north (Y-axis), the minor direction is east (X-axis).
• Distance travelled in the major direction: INT ( (9^2 * 265) / sqr (265^2 + 135^2) + 0.5 ] = INT [ 21465 / 297.405 + 0.5 ] = 72
• Distance travelled in the minor direction: INT [ 72 * 135 / 265 + 0.5 ] = 37
• The ship will end up at coordinates (37,72) - it will travel 80.95 lightyears.

Note: The INT function rounds a number down to the nearest integer. INT (5.99) = 5 and INT (-2.99) = -3

Movement: fuelconsumption

The exact fuelconsumption calculations in Host 3.22.026 are as follows:

• The distance from your current location to your waypoint is calculated and then rounded down to the nearest integer:
  distance = INT [SQR ( (Xwaypoint-Xship)^2 + (Ywaypoint-Yship)^2 ) ]
• The maximum length of movement is determined by your warpsetting:
  maxtravel = warp^2 (gravitonic accelerators: maxtravel = warp^2 * 2)
• If the distance to your waypoint is longer than the maximum travel (based on your warpsetting), you'll only travel the maximum distance allowed by your warpsetting. The following formula is then used to calculate the amount of fuel burned:
  fueluse = INT [fuelfactor * (TRUNC (mass/10) )  / 10000 ]
  (note: "fuelfactor" in this formula is a value based on the engine's specs and the warpsetting, for default values see table below)
• If the distance to your waypoint is shorter than or equal to the maximum travel based on your warpsetting, the following formula is used:
  fueluse = TRUNC [fuelfactor * ( TRUNC (mass/10) ) * ( (TRUNC(distance) / maxtravel) / 10000 ) ]
  (note: "fuelfactor" in this formula is a value based on the engine's specs and the warpsetting , for default values see table below)
• In case the fuel needed for your travel is more than you have onboard, you only move as much of the journey as your fuel allows:
  movement = distance to waypoint * (fuel onboard / fueluse)
  Or in plain English: you move a fraction of your desired distance, equal to the fraction of fuel you have compared to the fuel you'd need for the entire desired distance.

Note: The INT function rounds a number down to the nearest integer. INT (5.99) = 5 and INT (-2.99) = -3

Fuelconsumption while towing another ship
As can be seen above, in the fuelconsumption formulas a ship's mass gets divided by 10 and rounded down to the nearest integer before being processed. The same happens with the mass of towed ships. The difference between having for instance 299 kilotons of cargo on a ship and towing a ship with a total mass of 299 kilotons is as follows: On a ship with 299 kilotons of cargo, the mass of the cargo is first added to the ship's mass, then the total is divided by ten (effectively adding 29.9 from the cargo) and then that total is truncated. When towing a ship of 299 kilotons, that ship's mass is first divided by 10, then truncated and only then added to the towing ship's mass - effectively only adding 29 kilotons.

Default engine specs / values for "fuelfactor":

	Warp 1	Warp 2	Warp 3	Warp 4	Warp 5	Warp 6	Warp 7	Warp 8	Warp 9
Stardrive 1	100	800	2700	6400	12500	21600	34300	51200	72900
Stardrive 2	100	430	2700	6400	12500	21600	34300	51200	72900
Stardrive 3	100	425	970	5400	12500	21600	34300	51200	72900
SuperStarDrive 4	100	415	940	1700	7500	11600	24300	31200	72900
Nova Drive 5	100	415	940	1700	2600	10500	14300	23450	72900
HeavyNova Drive 6	100	415	940	1700	2600	3733	12300	21450	72900
Quantam Drive 7	100	415	940	1700	2600	3733	5300	19450	42900
Hyper Drive 8	100	400	900	1600	2500	3600	5000	7000	42900
Transwarp Drive	100	400	900	1600	2500	3600	4900	6400	8100

Note:
The above table differs from the more commonly known "fuel burned per kiloton per lightyear travelled" tables. When you divide the values above by warp^2 for each cell, you'll get the 'more commonly known values.

To calculate a ship's mass, calculate the sum of:

• The weight of the hull (fighterbays are a part of the hull's mass)
• The weight of the fuel
• The weight of the cargo (each fighter and each torpedo counts as one kiloton of mass)
• The weight of it's weapons, according to the following table:

Happiness: formulas for happiness change

The formula for native happiness change is as follows:

Happychange = TRUNC[(1000 - SQRT(Native Clans) - Native Taxlevel*85 - TRUNC ( (factories + mines)/2 ) - 50*(10-Native Government) ) / 100]

The values for "Native Government" are as follows:

If the natives are Avian, 10 happiness points are added to the happiness each turn.

Before calculating the happiness change, the Host program checks the current happiness level. If it is already below 30 points, the taxlevel will automatically set to zero - the natives will not pay any taxes. Note that the taxlevel is reset before happiness change is computed, so the value for 'Native Taxlevel' in the above formula will always be zero when the happiness is already below 30 points.

Colonist happiness change
Colonist happiness is calculated through formulas that slightly differ from those for native happiness change. Colonists care less about mines and factories on the planet and ofcourse have no government level, but are influenced by the planet's temperature.

Happychange = TRUNC [(1000 - SQRT(Colonist Clans) - 80*Colonist Taxlevel - ABS(50-Temperature)*3 - (factories+mines)/3 ) /100]

Crystalline Colonists follow yet another formula, they do best at desert planets:

Crystalline Happychange = TRUNC [(1000 - SQRT(Colonist Clans) - 80*Colonist Taxlevel - ABS(100-Temperature)*3 - (factories+mines)/3 ) / 100]

(note: the ABS in the formula for Crystallines is redundant, since 100-temperature is always greater than or equal to 0)

Before calculating the happiness change, the Host program checks the current happiness level. If it is already below 30 points, the taxlevel will automatically set to zero - your colonists will not pay any taxes. Note that the taxlevel is reset before happiness change is computed, so the value for 'Colonist Taxlevel' in both the above formulas will always be zero when the happiness is already below 30 points.

Maximum population: overpopulation dies

For planets hotter than 84 or colder than 15, special rules apply to the maximum population and which part of the overpopulations will die. The Climate Death Rate (CDR) is used to calculate which portion of the present clans will be labelled 'overpopulation'.

The amount of clans a desert or arctic planet can support (if 'overpopulation eats supplies' is not enabled), is calculated through these formulas:

• Arctic: Abs.maxpop = TRUNC [ (299,9 + 200 * temp) / CDR]
• Desert: Abs.maxpop = TRUNC [ (20099,9-200 * temp) / CDR]

Exceptions to these formulas:

• Rebels can have up to 90,000 clans (9 million colonists) on any planet with a temperature of 19 degrees or less.
• Fascists, Robots, Rebels and The Colonies of Man can support a small outpost of 60 clans (6,000 colonists) on planets with temperatures higher than 80 degrees. The online documents and the Winplan helpfile are incomplete at this point, as only the Fascists and Robots are documented to have this advantage.
• Crystalline colonists follow a completely different formula when "Crystal desert advantage" is set to YES.
  Quite simply, with that setting Crystals can support 1000 clans (100,000 colonists) per degree:
  Current.maxpop = Abs.maxpop = 1000 * temperature.
  This does mean they can not have any clans on planets where the temperature is 0 (zero).

A hot or cold planet can have more colonists than would be allowed by these formulas, but as long as the population is greater than this maximum, each turn a part of the population will die. This continues until the population has decreased to the maximum that is allowed based on the planet's temperature.

To know for each specific turn how many clans will survive on an overpopulated planet, Host follows a rather peculiar mechanism: the "current maximum population" is re-calculated for each turn, based on the current population. The "current maximum population" in this mechanism is based on the current population together with the Climate Death Rate as set in the Hconfig (default = 10). 

The first part of this calculation is by the formula Maxpop = clans - TRUNC (CDR * clans/100). If this results in a value of 0, the maximum population is set to 1. Then, if the planet is arctic, a value of  2 * (temperature+1) is added to the outcome of the previous formula. For desert planets, a value of 2 * (100-temperature) is added.

Put together this results in (for all races, except Crystals when the crystal desert advantage is set to Yes) the following formula:

• Arctic: Current.maxpop = clans - TRUNC(CDR*clans/100) + 2*(temperature +1)
• Desert: Current.maxpop = clans - TRUNC(CDR*clans/100) + 2*(100-temperature)

Effectively, the Climate Death Rate is used to reduce the 'current maximum population' by the percentage the CDR is set to (If there are 2000 colonist clans on the planet and the CDR is set to 10%, the current maximum population is calculated to be 1800). Then, an amount of clans is added to the value of 'current maximum population' based on the planet's temperature.

Note that this formula is re-calculated each turn to calculate the 'new' current maximum population. So each turn, based on the population in that turn, the new 'maximum' is re-calculated. The difference between the planet's population and this calculated current maximum population is labeled 'overpopulation'.

At some point, there will be a balance when the value for TRUNC(CDR*clans/100) matches that of 2*(temperature+1) or 2*(100-temperature), and the population will stabilize. At that point, the planet's population has reached it's absolute maximum for the planet's temperature - the "Abs.maxpop" value as found through the first two formulas listed.

Each turn as long as the population is greater than the maximum population, the 'overpopulation' in that turn either dies or eats supplies to survive.

Maximum population: overpopulation eats supplies
If a planet's colonist population exceeds the Current maximum population ("Current.maxpop") according to the above formulas and rules, and the Hconfig option "overpopulations eat supplies" is set to Yes, a number of colonists greater than this maximum can stay alive by eating supplies available on the planet.

To calculate how many can survive and how many supplies are necessary, two steps are taken.

1.    Recalculate the number of supplies
First, a the number of supplies on the planet is re-calculated. This always uses at least one supply unit, plus one supply-unit for every 40 clans of 'overpopulation':
New.supplies = Supplies - 1 - (Colonist clans - Current.maxpop) / 40.

This formula labels the 'overpopulation' that will eat supplies as being the population above the 'Current maximum population' that has been calculated earlier. Effectively, the size of this 'overpopulation' is equal to the percentage of the actual number of clans above the absolute maximum population that the CDR is set to (with a CDR of 10, this means 10%). So, not all the clans that are more than the absolute maximum population are labeled 'overpopulation'. If a planet has a population of 800 clans above the 'absolute maximum population', 80 of them will be labeled as 'overpopulation' if the Climate Death Rate is at it's default 10%. Now, per the above formula, these clans will eat exactly two supply-units, which together with the 1 unit that is always subtracted in this formula means that the 'overpopulation' (Again, 80 clans out of the 800 that are actually above the population limit) of the planet eats no more than three supplies.

2.    Recalculate the Current Maximum Population
After recalculating the number of supplies (accounting for the overpopulation eating them), the value for maximum population is re-calculated, based on the amount of supplies that are left on the planet:
Current.maxpop = Current.maxpop + New.supplies / 40.

Note that the "New.supplies" value in this formula is the outcome of the formula in step 1, and not simply the amount of supplies on the planet after planetary supply-production. The outcome of this formula is the size of the total current maximum population, not the number of clans that gets added to the earlier computed 'Current Maximum Population' because they eat supplies.

As can be seen in this second formula, a number of clans equal to 1/40th of the amount of supplies left on the planet after supplies being eaten by the 'overpopulation' is added to the value of the 'Current Maximum Population'. In other words, every 40 supplies can sustain 1 extra clan of 'overpopulation'. Again, the 'overpopulation' in this case is only the percentage that is labeled 'overpopulation' by the Climate Death Rate. Effectively, forty supply units can sustain 100/CDR clans. At the default CDR of 10%, forty supply-units can thus sustain 10 clans above the 'absolute maximum population'. The 800 clans used in the example of step one, of which 80 are labeled 'overpopulation', would need to have 3200 supply-units present on the planet to survive (even though they only actually "eat" three supply-units).

Maximum population: overpopulation dies

After establishing the current maximum population (either through the regular formula or via the overpopulation eats supplies formulas, depending on the hostconfiguration), the planet's population is checked against this Current.maxpop. If at this point a planet is found to be overpopulated (# of colonist clans is greater than Current.maxpop) the entire overpopulation dies.

Though this might seem to contradict popular belief that only a percentage (related to the Climate Death Rate) dies, it does not. Rather than regarding the CDR in the amount of dying overpopulation, the CDR is used to re-establish the current maximum population (based on the current number of clans) each turn until a stable situation is reached.