*Note: Although I have posted this on the Simutrans-Experimental board, much of this relates equally to Simutrans-Standard, as the code for calculating passenger and mail quantities is not distinct between the two*.

*The reference to hourly quantities in the linked spreadsheet, however, is relevant only to Experimental.*Following discussion of the excessive passenger numbers in the recent

Bridgewater-Brunel Simutrans-Experimental online game, I decided to look into the code to work out exactly how the passenger and mail generation is calculated to work out some bases for calibration. It turns out that, in simple terms, the code works like this: assuming a bits per month setting of 18 and a passenger factor setting of 8, each building in a city will be stepped once per month. Increasing the passenger factor from 8 to 9 will increase the monthly stepping from 1x per building to 1.112x, 10 will give 1.125x, 11 137.5x and so forth. Increasing the bits per month by 1 will double this number, but will also double the month length, and vice versa on decreasing it by 1.

Each step will generate exactly one packet. This packet might be either mail or passengers and can contain one or more of either mail or passengers (but not both). Each packet has a 3/4 chance of being a passenger packet and 1/4 chance of being a mail packet. The number of passengers or bags of mail in the packet is determined by the passenger/mail level shown in the building's dialogue box. For passengers, 6 is added to the level, and the resulting number divided by four. For mail, 8 is added to the level, and the resulting number is divided by 8. Fractions are rounded down to the nearest whole number. This has the consequence that buildings with a passenger/mail level of zero still generate passengers and mail, and still generate passengers and mail at exactly the same rate (1 unit per packet in both cases) as buildings with a level of 1. It takes a mail level of 8 to increase this number beyond 1 for mail, and a passenger level of 2 to reach a packet size of 2, and of 6 to reach a packet size of 3. Any intermediate numbers have precisely the same effect as the next number down: in other words, building levels [0 and 1], [2,3,4 and 5], and [6,7,8 and 9] all have exactly the same effect on passenger generation as each other and building levels [0,1,2,3,4,5,6 and 7] and building levels [8,9,10,11,12,13,14, and 15] all have exactly the same effect on mail generation as each other. I should note that the passenger factor affects what level that buildings are set to be.

Adding these together, a town with 100 buildings (a small but solid town in Simutrans terms) each of level 0 or 1 will produce 75 passengers and 25 bags of mail per month if the passenger factor is 8 and the bits per month setting is 18. However, at the settings currently in use on the Bridgewater-Brunel server (taken from Pak128.Britain-Ex 0.8.4), being a passenger factor of 10 and a bits per month setting of 21, in a town with 100 buildings all of which have a level of 0 or 1, 750 passengers and 250 bags of mail would be generated each month.

If we assume an average generation of 1.25 packets per step on the basis that some significant number of buildings will be at level 2 or over, we get 937.5 passengers per month and 312.5 bags of mail per month. A town of 200 buildings, not an uncommon size for a larger town, would have figures of twice this level: 1,875 passengers and 625 bags of mail per month.

Not all of these passengers and bags of mail would be transported, of course: many would not be able to reach their destination at all or in time, but even at a rate of 16% for passengers and 18% for mail (which are the percentages actually transported from the town of Caringford in the online game), this still gives numbers of 150 passengers per month for a 100 building town or 300 passengers for a 200 building town, and 56 bags of mail per month for a 100 building town or 112 bags of mail per month for a 200 building town. (In fact, these figures underestimate the load, because every town has a town hall of at least level three, and often has attractions, such as a church, which has a level of 12: the real figures for Caringford, a town of 134 buildings, are 1,917 passengers generated of which 442 were transported in the last complete month as at the date of writing).

Whilst these figures may not seem very great at first glance, it does well to bear in mind that a Simutrans-Experimental month is defined in terms of a certain number of hours and minutes, and that the frequency of services is measured according to those hours and minutes rather than according to the number of months. In the current online game, following the default for Pak128.Britain-Ex 0.8.4, the bits per month setting is 21, with the result that there are 6 hours and 24 minutes (or 6.4 hours) in every month. 442 passengers and 645 bags of mail (also the most recent figure from Caringford) every 6.4 hours equates to 69 passengers and 100 bags of mail being transported every hour, and a total of 300 passengers and 74 bags of mail being generated every hour that might be transported if the networks were capable of it. For a game year of 1800, this seems rather excessive, and seems to account in part for the very great passenger and mail numbers seen in the game.

I attach

this spreadsheet (in .ods format) to show my calculations in reaching these figures, and to encourage experimentation to suggest an optimum passenger factor as well as any refinements to the code better to simulate all of this more accurately.

**Edit**: I forgot one important feature of the passenger generation algorithm in the above description (and spreadsheet): return journeys. Every passenger trip other than one between two points in the same town generates a return trip. That is, if a passenger packet is generated at stop A bound for stop B, then, unless stop A and stop B are in the same town, a packet of the same size is automatically generated at stop B bound for stop A at the same time. This has the effect of substantially increasing the number of passengers over and above what the above calculations indicated.