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:
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.
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.
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.
Beamweapons | Kill | Explode |
Laser | 10 | 3 |
X-ray laser | 15 | 1 |
Plasma Bolt | 3 | 10 |
Blaster | 10 | 25 |
Positron Beam | 9 | 29 |
Disruptor | 30 | 20 |
Heavy Blaster | 20 | 40 |
Phaser | 30 | 35 |
Heavy Disruptor | 50 | 35 |
Heavy Phaser | 35 | 45 |
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.
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:
An example:
A ship starts at location (0,0). It's waypoint is set to (135, 265) and it's
speed is warp 9.
Note: The INT function rounds a number down to the nearest integer. INT (5.99) = 5 and INT (-2.99) = -3
The exact fuelconsumption calculations in Host 3.22.026 are as follows:
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:
Beam Weapons | Mass | Torpedolaunchers | Mass | |
Laser | 1 | Mark 1 Photon | 2 | |
X-Ray Laser | 1 | Proton Torpedo | 2 | |
Plasma Bolt | 2 | Mark 2 Photon | 2 | |
Blaster | 4 | Gamma Bomb | 4 | |
Positron Beam | 3 | Mark 3 Photon | 2 | |
Disruptor | 4 | Mark 4 Photon | 2 | |
Heavy Blaster | 7 | Mark 5 Photon | 3 | |
Phaser | 5 | Mark 6 Photon | 2 | |
Heavy Disruptor | 7 | Mark 7 Photon | 3 | |
Heavy Phaser | 6 | Mark 8 Photon | 3 |
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:
Government type |
Government |
Anarchy | 1 |
Pre-tribal | 2 |
Early tribal | 3 |
Tribal | 4 |
Feudal | 5 |
Monarchy | 6 |
Representative | 7 |
Participatory | 8 |
Unity | 9 |
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:
Exceptions to these formulas:
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:
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.