NewTownGrowthSwitchesdetails

New Town Growth Switches (details)

How the new town growth switches work

This section describes the switches that apply in "towngrowthratemode 2". They fine tune and control every detail of town growth.

As described in the previous section, TTD internally uses an inverse growth rate, i.e. the number of 70-tick time units between attempts to build a new house. However, the enhanced rate calculation uses a direct growth rate, defined as the average number of new town buildings per 38400 time units, which is approximately 100 years. At the end of calculations this rate is converted to the inverse growth rate. If the inverse growth rate is greater than 255, it's reduced and town growth is blocked randomly to have the same effect on the average.

For comparison, with "towngrowthratemode 0" (TTD's original calculation), the rates are:

number of active stations	average rate (new houses per 100 years)
0	20
1	182
2	256
3	349
4	480

or, if a building fund is active, the rate is fixed at 640 new houses per century. These rates are as they're normally in TTD, except that a bug with 5 or more stations (see the previous section) is fixed.

For the new growth rate calculation, we have the maximum and minimum rate, the towngrowthratemin and towngrowthratemax switches. Let ratediff be the difference between the maximum and the minimum, i.e. ratediff = towngrowthratemax - towngrowthratemin

Then the base rate delta multiplier (BRDM) is calculated as follows: BRDM = (AS*ASW + PO*POW + MO*MOW + PI*PIW + MI*MIW + GI*GIW + FI*FIW + WI*WIW + SI*SIW + DI*DIW)

/ (ASW + POW + MOW + PIW + MIW + GIW + FIW + WIW + SIW + DIW)

where the two-letter abbreviations represent growth boost components (explained in detail below) depending on, respectively:

AS	the number of active stations
PO	percentage of passengers transported (`passengers out')
MO	percentage of mail transported (`mail out')
PI	incoming passengers (`passengers in')
MI	incoming mail (you get the picture...)
GI	incoming goods
FI	incoming food
WI	incoming water
SI	incoming sweets/candy
DI	incoming fizzy drinks

Each component is a number between 0 and 1, so the result (BRDM) is also between 0 and 1. The rest are weighting factors, represented by the following settings in the configuration file:

ASW	tgractstationsweight
POW	tgrpassoutweight
MOW	tgrmailoutweight
PIW	tgrpassinweight
MIW	tgrmailinweight
GIW	tgrgoodsinweight
FIW	tgrfoodinweight
WIW	tgrwaterinweight
SIW	tgrsweetsinweight
DIW	tgrfizzydrinksinweight

The higher the weighting factor for some component is relative to the other weighting factors, the more influence the asociated growth boost component has on the final growth rate. Note that it's the relation betwen weighting factors that matters; for instance, if all the other weighting factors are zero, the following set tgractstationsweight = 10

tgrpassoutweight = 5

yields exactly the same results as tgractstationsweight = 2

tgrpassoutweight = 1

The growth boost components are calculated as follows:

AS = NTB / tgrtownsizebase) * TSF) + (1 - TSF

where NTB is the number of buildings in the town and TSF+==tgrtownsizefactor/255 (i.e. it's a value between 0 and 1, which determines how much of the growth rate depends on the town size, in percent). This can be used to add a bit of `exponentiality' to the growth of towns (remember, the growth rate is expressed in new buildings per time unit, so with a constant rate larger towns will appear to grow more slowly).

Then the real growth rate is calculated: RGR = towngrowthratemin + ratediff*CRDM

where CDRM+===+RDM if RDM <= 1, and CRDM=1 otherwise.

Then, if a town building fund is active in this town, 600 is added. Then, if the town is one of those supposed to be larger (see the largertowns switch), the rate is doubled. And this is the final growth rate, in new houses per century.

As a final note, the real growth of towns is a second- or third-order effect of the final growth rate, so don't expect towns to grow exactly at the rate you've calculated from the formulae above.... But on the average it shouldn't be far off.