Vladki - the problems with a proportion system are:

(1) that this does not aid real world data balancing, as the proportion of overall journey time tolerances to destination specific journey time tolerances is not something that there is reason to believe has a fixed relationship in real world data; and

(2) that the purpose of the different tolerances are quite different, so one would not necessarily want to adjust one when one adjusts the other.

One might, for example, want to increase average overall journey time tolerance in order to allow passengers to visit more often certain distant and important buildings, but not make them any more likely to visit medium-distance unimportant buildings. To do this with a proportion system, one would have to adjust the overall number upwards, then go back and adjust all the individual buildings downwards. Moreover, using the proportion system, one could not just specify individual figures in the .dat files; one would have to back-calculate the time that one wanted to achieve from the proportion for each individual building, which would greatly increase the necessary work.

Freahk - in fact, there are data on people's travel time budgets: this is a well studied area in economics. See, for example, the

Wikipidia article on Marchetti's Constant and

this article discussing that this constant appears to have a wide range. The theory of Marchetti's Constant is the basis for the whole passenger generation system as it is currently implemented, and I looked into this extensively when implementing this. These data suggest that people (in all eras and in all places in the world) spend, very roughly, 1.1 hours per day travelling, but that this average has quite a large range (the second article suggests 74 minutes with an 80 minute range).

I thought that it might be useful to conduct some tests to see what the average per trip tolerance is with current settings. I ran a test using the saved game from the Stephenson-Seimens server, adding up all of the visiting tolerances for passengers and dividing by the number of trips over the course of running for a few minutes: this gave the number 963, the unit of which is tenths of minutes, giving 96.3 minutes as an average visiting tolerance per trip.

The tolerance settings are different on the Stephenson-Seimens server than the Bridgewater-Brunel server. Running the same exercise on the Bridgewater-Brunel server gives the number 1615, or 161.5 minutes. If we use all trips, not just visiting trips, we get 1454, or 145.4 minutes. Reducing the minimum tolerance to 2 and maximum to 9600 gives an average of ~1370.

However, it should be noted that passengers attempt to make more than one trip per day: they attempt to make four on average. So, to get journey times within Marchetti's Constant, the average journey time should be one quarter of somewhere between 74 and 74+80 (i.e. 154), that is 18.5 - 38.5, suggesting that our average journey times are indeed too high. Of course, the average journey time

*tolerance* should be higher than the average journey times, as actual journey times will tend on average to be less than the tolerance, so the tolerance average should be higher than this, but not necessarily by a very large amount.

I then experimented with increasing the skew for visiting passengers. It is currently set at 5, which equates to a cubed recursive skew. Setting it to 6, a multiple cubed recursive skew, and increasing the maximum journey time tolerance to 12,000 minutes, I get an average of 476, or 47.6 minutes' tolerance per journey. Multiplied by 4, this gives 1,904, or 190 minutes of total journey time tolerance per potential passenger per day. (Increasing the skew to 6 whilst retaining the previous minimum/maximum gave an average of ~37 minutes per trip).

With this latter setting (a skew of 6 and no changes to minimum/maximum travel times), I have been testing the current Bridgewater-Brunel game locally in fast-forward.

Here is the game as it is after about one and a half months of running with this altered configuration, including a clear calendar month (that just passed) of the new settings. Passengers transported at Promisnster have fallen from 1,710 in the last clear month of skew = 5 to 624 in the first clear complete month of skew = 6 (ignoring the transitional month in between): that is circa 36% of previous passenger numbers. However, the fall in passenger numbers is uneven. The Docklands Light Riverway in Promister's transported numbers have gone from 3,495/mo to 1,999/mo. The Western Fairies (!?) Whittinghill and Bramingpool have gone from 871 to 321 passengers/mo. The Prominster to Pitham route has gone from 732 to 215. Oddly, I cannot measure any noticeable decline in the oceanic traffic at all; this may be because the trip takes so long that the settings have yet to have an effect on passenger numbers.

I should be grateful if those who are interested in this topic could download and test the saved game with the modified settings to see whether this appears to conform better with historical levels of passenger transport.