Possible additional calibration mechanism for passenger transport

[jamespetts]

I notice that the number of passengers being transported on the Bridgewater-Brunel server seems higher than one might expect for the 1750s. I notice that this has been discussed in the in-game chat. Ideally, we would want realistic numbers of passengers being conveyed for realistic reasons: it would not do to vary the number of passengers wanting to travel just on the basis of the numbers on the year in a calendar; that, after all, is not how it works in reality. What is needed is a new mechanism that will affect the numbers of passengers travelling in a realistic way and will work equally realistically in all eras.

The best candidate mechanism so far is one that targets passengers' willingness to take long journeys (measured in time) to relatively unimportant destinations. This is only relevant to visiting passengers, since commuting passengers have much lower maximum journey time tolerances in any event.

Currently, visiting passengers are generated with a randomised travel time tolerance, which can be anything from 2 minutes to tens of hours (although is more likely to be near the middle of that range using a mechanism to replicate a normal distribution). They then pick at random a destination from the list of all visiting destinations, weighted by the visitor demand of that destination. If they can reach that destination within the travel time tolerance, they go there. If not, they pick another destination and keep going until their allocated number of alternative destinations runs out. The travel time tolerance is fixed at the beginning and is not affected by the destination.

My current proposed revision is this: each visiting destination will have three new data:
(1) minimum destination journey time tolerance;
(2) maximum destination journey time tolerance; and
(3) destination journey time tolerance applicability percentage.

These will all default to 0 in the pakset, in which case, the system will behave as it does now. However, if these values be set, then the current system will be modified as follows. For each visitor destination that a given passenger checks, if that visitor destination has a journey time tolerance applicability percentage of > 0, there will be a chance, weighted by that percentage, that the passenger will use the destination journey time tolerances of that building. If this be set to 100, passengers bound for this building will always use the destination tolerances.

When a passengers use the destination tolerance, a randomised destination journey time tolerance of somewhere in between the individual building's minimum and maximum will be generated. Passengers will then only travel to this building if it can be reached in a time equal to or less than the lesser of their general journey time tolerance or the destination specific journey time tolerance.

This is intended to simulate the fact that, not only do passengers have, for each potential trip, a maximum amount of time that they are able to travel, they also have a tolerance of how long that they think it worth travelling to reach any given destination, which may be less than the amount of time that they would be able to spend travelling.

This will mean that buildings such as parish churches, small town halls, local parks (and, in the later game, small shops, the smaller sports stadia and so forth) will, if set up with appropriate data, only attract relatively local passengers, whereas more important buildings, such as castles, cathedrals, large city halls (and, in the later game, attractions such as the larger sized sports stadia) will attract passengers from far away. Because it will be possible to configure the settings so that there are only a few buildings, which occur infrequently and only in larger towns, that attract a significant number of non-local passengers in this way in the early years, and allow later buildings to be more attractive to longer journeys, this will allow an increase in passengers' willingness to travel in later times. It will also mean that long distance travel tends to concentrate on the centres of larger towns, rather than being more evenly dispersed as it is now.

I should be very grateful for feedback on this. I note that it is proposed largely because it would potentially make a large difference to balance whilst requiring only a relatively small coding effort.

[Ranran(retired)]

I think that few people use public transportation to go to work in old age. (The distance is also short.)

EDIT:
I looked at the passengers in my carriage, they are only visitors.
Maybe they have traveled too many times?

[Vladki]

@ranran - then it is ok, isn't it. In early years commuters will mostly walk (short distance), and only visitors going for longer distance use some vehicle.

@James: that sounds good, perhaps using both tolerances (traveller's and destination's) at the same time, and use smaller of them. As a traveller who can spend only 10 hours travelling, will not be able to travel to a destination 20 hours away, even if the destination's time tolerance would be even higher.

Also maybe revise my earlier suggestion on journey price tolerance. I.e. not strictly excluding passengers from using some means of transport due to being lower class than the vehicle, but do it according to the total journey price. If the expensive vehicle is the only option, and walking is too slow, even less wealthy traveller may be able to pay higher fee for short distance. But if the journey is too long, he would have to use lower class vehicle, which may not be available at the moment.   This would e.g. enable "very low" class to use "low" class trains to commute, but not to travel far away. Same with stagecoaches - wealthy people could use them to travel around the world, medium class only to visit the nearest market or church, and poor people not at all.

[Mariculous]

That's a difficult one, to be honest.

From my thoughts, I guess normal distribution is not a good choice.

I'd expect very many short distance visiting trips, e.g. to the local grocer or a neighbor, a fair amount of visiting trips to medium distances, few visiting trips to far-away destinations, but still also visiting trips to very far-away destinations, i.e. journey times of more than 24 hours, although these are quite rare for sure.

Normal distribution won't give us such a figure.
We have to keep in mind it's not the actual journey time itself that is normal distribiuted, it's only the maxiumum acceptable time that is normal distribiuted, so the distribution of actual journey times is closer to the above expectation.
Still there are too many medium distance journeys in the current figure.
From my observation, most passengers are generated to destinatons between 3 and 4 hours. That's definitely not what I would expect.
In any epoch,I'd expect quite local journeys to a local grocer or a nearby friend to be the most frequently ones.


About the suggestion: I do also think that journey times will be more of a matter for generic destinations than for unique destinations.
For example, a grocer or barneyard is usually not quite unique. People will usually prefer the one that is closest, although there are for sure some differences, so they won't always do so.
Friends do also most often live nearby and if they don't people will usually visit them less frequently than another friend that lives nearby.
On the other hand, monuments are quite unique. People will travel longer distances to visit such. Cologne is full of Asians visiting the Cathedral and further locations.
If you ask them why they came there, it is very unlikely they will say "oh, I always wanted to go shopping in a German supermarket, so I travelled to Cologne."
Attractions are not that unique but still likely attract passengers from farer away.

I don't agree with your suggested three parameters, however, because that sounds quite complicated for any pakset author.
I guess a more simple solution like a uniquenes factor for buildings might be more sensible.
Let's think of the maximum journey time the "willingness to travel long distances".
That means, if a maximum journey time of 2 hours was calculated and selected a destination that has a uniquenes of 4, that means it's fine for this traveller to travel to that destination if the (expected) journey time does not exceeed 8 hours.
We could set that factor to less than 1 to get some attractions only attract local passengers, just as in your suggestion.



To point this out again:
I think it would be a nice feature to somehow specify passengers' willingness to take long journeys to a specific building, but I do also think that the main cause for what we see on Bridgewater currently is the choice of the distribution function that is used to randomise maximum journey times and not the lack of such a feature.

[freddyhayward]

While large attractions are a better driver of tourism, smaller and generic attractions would still see a lot of long-distance travel. Of course it is difficult to simulate a holiday where tourists stay at a hotel and visit different local attractions. perhaps the train chaining mechanic deals with this partially but I don't know. in any case, a traveler to rome might visit primarily to see the coliseum, but would also want to experience restaurants and visit public squares, fountains and statues.

[jamespetts]

Ranran - in the 1750s, most commuting is done on foot, just as in reality. One would need more concentrated centres of employment for there to be any significant commuting by public transport. In reality, commuting by public transport was only really a thing from the mid 19th century onwards.

Vladki - the idea is indeed that it is the minimum of the two tolerances that would be used.

Freahk - how do you envisage a single integer "uniqueness factor" being used in an algorithm? I cannot immediately see a way of doing this at present. Also, what do you suggest as an alternative to a normal distribution algorithm? Normal distribution can only not be the best algorithm if there is a specific better algorithm.

Another thought, incidentally, is to allow buildings to be able to specify a visitor capacity, which would have the same algorithm as the employment capacity at present. This would prevent huge numbers of visitors wishing to visit the small local shops that we see in the pakset that are not industries, intended to represent something like a cobbler. The ultimate intention would be for local consumer industries to be the main driver of local visiting passengers, and thus to make freight transport important for passenger transport to be effective, allowing passenger transport success alone to be used as the metric for how much that towns should grow.

[Mariculous]

That's something I also thought about.
Effectively this would be a relation in between journey time and onward trips.
A passenger that started a long journey will do some onward trips before returning home.
Onward trips are randomised when a passenger is about to go home, so relating the onward trip likelyhood to the time it takes to go home might work.
That would, however, not assign a fixed hotel to a passenger and will generally increase the number of journeys around destinations that attract people from far-away.
However, the first might be acceptable, the second even desirable.

Freahk - how do you envisage a single integer "uniqueness factor" being used in an algorithm?

As described, calculate tolerable journey time, select a potential destination, calculate journey time to that destination, compare maximum_journey_time * destination.uniqueness < actual_journey_time

Don't think of maximum journey time as a definite time, rather think of it being a willingness to travel long times that, multiplied with uniqueness, results in an actual maximum journey time (to that specific destination)

A uniqueness of 1 would result in the exact same behavior as currently, uniqueness of greater than 1 will increase the distance passengers travel to that destination, valuses smaller than 1 will decrease it.

Ranran - in the 1750s, most commuting is done on foot, just as in reality. One would need more concentrated centres of employment for there to be any significant commuting by public transport. In reality, commuting by public transport was only really a thing from the mid 19th century onwards.

In some capitals on bridgewater, such quarters exist and allowing "verly low" people to use your public transport will attract quite a lot commuters.
However, usually you don't want to do this. Especially with the very high passenger generation currently, you rather want to reassign classes to higher levels instead of lower ones.

Another thought, incidentally, is to allow buildings to be able to specify a visitor capacity, which would have the same algorithm as the employment capacity at present. This would prevent huge numbers of visitors wishing to visit the small local shops that we see in the pakset that are not industries, intended to represent something like a cobbler.

That might be a useful adddition to the other features, but I don't expect it to work well on its own.
Further, when seperating visiting trips from shopping trips, I guess this might be a good mechanism for the new city growth. It might however not work well at all with current citygrowth.

The new city growth algorithm migt build industries, shops and housings depending on how many commuting and shopping slots are actually used.
If few shopping or commuting slots are used, it will attempt to build housings nearby, although also ensuring it doesn't build these directly into the industry quarter.
If many shopping slots are used, it will attemt to build new shops nearby the most used shops.
If many commuting slots are used, it will attempt to build new industries or shops nearby the most used ones.

Also, what do you suggest as an alternative to a normal distribution algorithm?

As mentioned, it's difficult, especially due to the way we attempt to find a destination within journey time, but I guess a gamma distribution should work better, but I am unsure about the exact parameters.
The parameters might even difer from time to rime.

[Vladki]

Take this as a brainstorming ideas.

- I like the idea of visitor capacity similar to employment capacity. Actually that is the only thing about the building (whether res/com/ind/cur/mon/hq/factory/station/signalbox/... ) you can sensibly put into dat files.
- Uniqueness should be simply the number of the same objects on the current map. So in one game there may be only one Stonehenge, attracting people from all around the map, while in another it would spawn in every other village, and most people will be satisfied by visiting the local henge. On the other hand a unique villa (type=res) may appear somewhere, and attract architecture fans from far away, or the last open-air market (com/factory) offering some special local produce would attract far away customers. Or even futuristic high-level company headquarters or town hall... So the lower the number of same object, the higher the uniqueness
- For simplicity, uniqueness should only reduce the travel time tolerance. Maybe not simply by division (travel_time_tolerance / number_of_same_objects), but perhaps something that does not fall that fast - 1/sqrt ? (time / sqrt (uniqueness))
- So the original travel time tolerance would be a time a visitor is willing to travel to an absolutely unique destination

- The random distribution of travel time tolerance, should IMHO be similar to distribution of wealth. Although they are not equal, a poor man may be willing to travel long time (on foot), as well as rich man. They'll just cover different distances. But the distribution may be similar. Lets say that most people will be willing to travel for time X (the median), probably only very few people will not be willing to travel at all, or only very short time (that would be people with some disabilities). But on the other side there will always be someone willing to travel almost infinitely (definitely more than 2x). So the graph would be with sharp rise from zero to X, and then something like logarithmic going down... Perhaps something like https://en.wikipedia.org/wiki/Gamma_distribution with k=2 and theta=2

- Still thinking how to add the financial tolerance to the mix?

EDIT: on second thought, the uniqueness may be one of the most important factors in limiting the travel time tolerance. The journeys generated should only say the type of destination they are interested in:
- commuting (anything that accepts commuters)
- shopping (visitors to com/ind/factory, maybe also hq & town hall) - similar frequency as commuting
- leisure (visitors to monuments, attractions, and other friends = res) - lower frequency (weekends only - so about 1/7 or 2/7 frequency of commuting and shopping)
If the destination buildings are distributed as they are in real world, the time tolerance would be similar - there are many shops to choose from, so traveling too far does not make sense, and vice versa.

[Mariculous]

Uniqueness should be simply the number of the same objects on the current map.

I don't think so, although uniqueness might be a little missleading.

Let's take sfootball stadiums as an example again, as stonehenge should actually be monument anyway if these were not restricted to cities.
At a specific time, people will prefer a specific football stadium and they will accept long journeys to get there.
That is what uniqueness is about. I'd also argue housings have a higher uniquenes than san average shop does, but there might be quite special shops that will again have a greater uniquenes.
It doesn't actually matter how many of these exist in the world, it's simply a measurement of "how important is visiting that specific destination to the average potential visitor."

It's effect, btw. will be roughly the same as James suggestion.


However, your suggested variant of uniqueness is also not a bad one, I just don't think it would work well for housings.
Each single housing is actually quite unique. However, there will be very many houses of the same type spread around the world, so long journeys from hosing to housing will effectively never happen.


Thanks for agreeing with gamma distribution, I didn't pay too much attention to the stochastic lecture, although I passed that exam

[Vladki]

At football, usually more fans of the local team come to see the match than of the guest team. So the uniqueness must be somehow individualised. Someone will travel to far away stadium, someone not.

[Mariculous]

It is only the maximum tolerabe time that is induvidually adjusted by the stadium in my suggestion.
There is no mechanism at all that prevents local passengers from going there.
Fans of the local team will also very much likely consider longer journey times to get to their home stadium than they would consider to visit a fountain.
Especially larger stadiums, implied the club is successful, have a rather huge "terretory" where most inhabitants will be fans of that club.

[Vladki]

Especially larger stadiums, implied the club is successful, have a rather huge "terretory" where most inhabitants will be fans of that club.

That should be achieved by having more small/local/lower league football grounds - and a few big stadiums (premier league). The small, but omnipresent stadiums would reduce the travel time limit more, than the few big ones.

[jamespetts]

I should note that this thread was really intended to discuss some specific and limited changes to passenger generation that might have a large effect for a very small coding effort. Anything requiring major coding effort will have to go into the queue of major features and wait potentially many, many years before being implemented. The idea of having more than two different types of trips (visiting and commuting), for example, would require major re-engineering of the memory structures used to store visitor targets, and would require very significant and complex additional balancing/calibration work in the paksets. There would be likely to be very significant consequences in many other parts of the balance of passenger generation each one of which would have to be considered in great detail and dealt with, each means of dealing with which requires a currently entirely unknown amount of coding work which could in principle be very great indeed.

In relation to alternatives to a normal distribution, it is not immediately clear how a gamma distribution would be different to a normal distribution in practice (and I must confess that I do not fully understand Wikipedia's description of a gamma distribution, which seems to require an extremely high degree of mathematical knowledge to follow). May I ask why and how you think that a gamma distribution would be better?

For reference, here is the code that generates the normal function. As you will see, this can be skewed by simuconf.tab settings:

Code Select Expand


uint32 simrand_normal(const uint32 max, uint32 exponent, const char*)
#endif
{
#ifdef DEBUG_SIMRAND_CALLS
sint64 random_number = simrand(max, caller);
#else
uint64 random_number = simrand(max, "simrand_normal");
#endif

if(exponent == 0)
{
// Non-normalised random number.
return random_number;
}

if(exponent == 1)
{
// Normalised but unskewed.
random_number += simrand(max, "simrand_normal unskewed");
random_number /= 2ll; // Averaging a larger numbers will create a stronger normal peak, but it will still be unskewed.
return (uint32)random_number;
}

// Any higher number than 3 would produce integer overflows even with unsigned. 64-bit integers
// if the model was followed. Interpret higher numbers as directives for recursion.

uint32 degrees_of_recursion = 0;
uint32 recursion_exponent = 0;
if(exponent > 3)
{
degrees_of_recursion = exponent - 4;
if(degrees_of_recursion == 0)
{
recursion_exponent = 2;
}
else
{
recursion_exponent = 3;
}

exponent = 3;
}

const uint64 abs_max = max == 0 ? 1 : max;

for(int i = 0; i < exponent - 1; i++)
{
random_number *= simrand(max, "simrand_normal");
}

uint64 adj_max = abs_max;

if(exponent >= 3)
{
// This was originally a for loop, but doing this more than once
// overflows even an unsigned 64-bit integer with largeish max values.
// A single squaring can fit in a 64-bit integers even with max values
// in the millions.
adj_max *= adj_max;
}

uint64 result = random_number / adj_max;

for(uint32 i = 0; i < degrees_of_recursion; i ++)
{
// The use of a recursion exponent of 3 or less prevents infinite loops here.
const uint64 second_result = simrand_normal(max, recursion_exponent, "simrand_normal_recursion");
result = (result * second_result) / abs_max;
}

return (uint32)result;
}


In relation to uniqueness, it is not clear why the proposed algorithm would work better than that which I suggest; this would allow journey time tolerances in excess of that generated by the existing system, requiring the existing system to be completely recalibrated, which would take this outside what can sensibly be done as a small project. Given the amount of work that has already gone into calibrating the existing journey time tolerances, there would have to be extremely clear evidence that an alternative is very significantly superior in order for it to be worthwhile discarding all of that work and starting again with at least equally and probably very significantly more work. The relationship between the uniqueness factor and the overall journey time would be potentially very complex in the uniqueness model, and therefore extremely difficult to calibrate clearly.

The reason that I proposed the model that I did is because it leaves entirely untouched the existing journey time tolerance calculation, and simply adds an additional factor that limits the tolerance to certain destinations. This has the particular advantage that it simulates the balancing of utility in expending travel time to go to a particular type of destination. I do not think that measuring uniqueness by testing how many similar buildings that there are really makes sense for this, as uniqueness per se is not what causes people to be willing to travel a very long distance to go somewhere. People might be willing to travel for 5 hours to an office building where the building itself is entirely unremarkable because the person has a business meeting with the specific company in that building, yet be entirely unwilling to travel more than 1 hour to visit the International Museum of Cloth Caps even though there is only one such institution in the world. Measuring uniqueness will also cause problems when new types of (very ordinary) buildings first appear.

As to onward journeys, these already exist in the passenger generation code and have done for some years.

[Vladki]

I'm no expert on random functions. I just think that the journey time tolerance in real world is not so nicely symmetric as the normal distribution is. And the gamma function seem to look more fitting. But I have no hard data for that, and might be completely wrong. Anyway we can skip that, and change the function later if we find some data. IMHO the time tolerance is vaguely related to wealth - poor people cannot afford to travel long distance, so even if they'd be willing to, they can't...

I think that first building of a kind that becomes more common later, should have at least slightly higher potential of attracting people from far away. First "supermarkets" in post-communist countries surely did. So maybe not as abolute as I originally proposed, but maybe it could be used as one of the factors in your proposal. Have the applicability percentage in dat file, and calculate the destination min/max from number of occurences, or vice versa. Or it could be used to alter the parameters of the random function.

Also counting the visitors in similar way as employees could play nicely - no more visitors if the destiantion is full (especially stadiums).

[Mariculous]

The idea of having more than two different types of trips (visiting and commuting), for example, would require major re-engineering...

That was just a little excursion on how "visiting capacities" could be used for the upoming citygrowth re-implementation.

May I ask why and how you think that a gamma distribution would be better?

In comparisation to a plain normal distribution, gamma function will give us a figure that raises quickly to the maximum and then falls rather slowly and the closer it gets to zero, the slower it will fall.
That's actually what I would rather expect from journey time distribution. Keep in mind, that we don't pick the actual journey time, but a maximum journey time.

Skewed normal distribution might be an otion to get something better than the current figure without coding effort.
It might be fine for our purposes, so if we don't use them yet, we should try it out, otherwise we might want to try a larger skew before implementing something new.

Without any journey time statistics, including all modes of transport, being specific to visiting trips and providing historical data, we can only place guesses anyway.
I don't think such data is available out there.

In relation to uniqueness, it is not clear why the proposed algorithm would work better than that which I suggest

That depends the exact meaning of "works better" here.
Functionally and from ease of implementation, both should be roughly the same.
The uniqueness paraeter would however, be much easier to use for pakset authors and will scale with *_totelance settings made in simuconf.
Setting fixed, absolute min/max times in dats is not a good idea imho as maximum journey times figures are configured in simuconf, thus the relation of journey times to buildings with this dat parameter set will break when modifying the dats.

If you don't always want to apply that factor, i.e. simulating that a specific destination might be quite important to some people, whilst for other people not more important other destinations, you could add your suggested chanche parameter in addition to uniqueness.

Actually, your suggested solution would also allow passengers to exceed the currently well calibrated journey times. If that's an argument against my suggestion, it's against your suggestion either.

[Vladki]

I did RTFM (simuconf.tab) and found that we already use skewed normal distribution. I didn't know that. Psoitively skewed normal distribution is what I had in mind. I just did not find it when I was looking at all the random distributions.

Setting fixed, absolute min/max times in dats is not a good idea imho as maximum journey times figures are configured in simuconf, thus the relation of journey times to buildings with this dat parameter set will break when modifying the dats.

That's good point. Therefore I suggest using uniqueness factor to increase or decrease the time tolerance from simuconf.dat. Uniqueness could be either statically defined in dat file: default=100% with rare buildings having uniqueness >100%, common buildings <100%. Then just multiply the tolerances with uniqueness factor.   

Or do it as suggested before: divide by (square root of) number of ocurrences in the current game. Or do some other calculation, that could also increase the time tolerance but I don't know where to put the threshold - how many buildings of the same type should be considered as rare...

[Mariculous]

Uniqueness could be either statically defined in dat file: default=100% with rare buildings having uniqueness >100%, common buildings <100%.

That's exactly the idea, yes.

Or do it as suggested before: divide by (square root of) number of ocurrences in the current game.

I still kind of like that idea, but I don't see the point why a newly built housing should attract more visitors than an old one, just because there are many houses of that old type in the world, whilst only a few af the new ones exist so far.
Same goes for shops in general. Sure, the only supermarket will attract a lot of people, but a simple grocer won't attract more just because it doesn't use the same building as all grocers before did.

I still like that feature, but I gues it needs more consideration on how to handle different buildings that are actually of the same type and entirely new buildings.
That said, I guess this would rather be a major feature than a quick fix.

[jamespetts]

As Vladki notes, we already use a skewed normal distribution, so it is not clear what specific algorithm change is being suggested here, what effect that that change would have, or why that effect would more accurately model how real passengers travel. I posted the relevant code extract for the current algorithm above.

I also do not understand the benefit of having destination specific journey time tolerances scaling with the general journey time tolerances. The intention is for them to be entirely separate, and for passengers' actual tolerance for any given destination to be the minimum of the two. For this reason also, therefore, I do not understand the suggestion that the proposed system would allow the current maximum to be overriden: can you elaborate?

I am afraid that I am still not persuaded by the benefit of actual prevalence of a building in the game world being a measure for destination specific journey time tolerance for the reasons given previously.

[Vladki]

Passenger time tolerances can be easily adjusted in simuconf.tab, but per-building time tolerances are "hard-coded" in pak/dat files. So it may happen that a building that was originally designed with higher time tolerance, might end up with lower time tolerance (if user fiddles wit simuconf.tab). Therefore I think the building should have defined only % increase or decrease of what is defined in simuconf.tab. I think it would be much easier to understand for players, pak designers, etc....

Let's have an example. Most city buildings will probably not have defined any building specific time tolerances, but a big football stadium probably will. range_visiting_tolerance=10000, football stadium will have e.g. 15000. But what if the player decides that his simucitizens have plenty of spare time and are willing to travel 20000. The the football stadium will have lower time tolerance than ordinary buildings. If it would be specified as 150%, it will scale nicely and still attract people from larger distance than ordinary houses. It will be one simple and easily understandable (and implementable) option.

[Mariculous]

I guess everything has been said about "destination specific journey time tolerances scaling with the general journey time tolerances".
I don't see any disadvantage over dat file "hardcoded" journey times here.
Suggested chanche parameter might be interessting, but it's not restricted to either of the two suggestions.

I guess we all agree that there is a huge amount of passengers on bridgewater currently that can barely be handled with the available vehicles.
The following is not meant as a short-term "hotfix" to the current journey, but as thoughts on what is going wrong with our well balanced real-world journey figure. Obviously, it's not as realistic as what we might expect, so at least one of the related parameters must simulate reality quite badly.

So what parameters do we have that directly or indirectly affect this?
Total number of inhabitants
Inhabitant density
Inhabitant classes
Number of journeys an inhabitant attempts per day
max journey time distribution
destination selection logics
vehicle capacities
vehicle speeds

I might have missed some.

From the above I'd consider the following fixed as these are balanced to real-world data:
(Inhabitant density), Number of journeys an inhabitant attempts per day,  vehicle capacities, vehicle speeds

So the parameters left are: (Inhabitant density), Total number of inhabitants, Inhabitant classes, max journey time distribution, destination selection logics and maybe further parameters that I have missed.

- Inhabitant density of housings itself is balanced to real-world data, but the (relative) amount of buildings of different types that are actually placed in simucities might not.
- Total number of inhabitants should not cause this excessive amount of passengers, as our capitals got less inhabitants than real-world capitals of that time.
- Inhabitant classes might be a factor. Especially I am wondering if the binary "can afford it" or "cannot afford it" behavior simulates reality well enough on average. In the real-world passengers won't decide "public transport is a little faster and I can afford it", they will consider if it's worth to spend that money ust to be a little bist faster. That might be an important factor, which plays a huge role in old days where transportation is expensive and not much faster than walking, whilst a rather small factor one public transportation gets considerably faster and less expensive.
- max journey time distribution might be a factor. As discussed before, I'd expect much less passengers in the medium distance range around 3-5h, but that's simply a guess. We might need (but likely won't find) historical data about visiting journey time figures to base this in real-world data.
From my subjective feeling, there are too many journeys to 2-4 hours far-away destinations. More skew, a different distribution or suggested building specific ourney times can help here.
- destination selection logics is another point that results in a diversion between randomised max journey times and the actual journey time, but it won't result in too many passengers, rather the other way round due to journey_time <= max_journey_time, so we can safely assume that's not the cause for the current situation

[jamespetts]

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.

[Vladki]

What do you mean exactly by proportion system? As I had two suggestions, which both could be considered somehow proportional.
a) simple one - have only one new dat file option that allows to increase or decrease the travel time tolerance to this object - in % of travel time tolerance deined in simuconf.tab
b) the complex one adjusting time tolerance by occurence of the object in game..

I suppose that you meant a)

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.

To achieve this it would be better to modify the dat files of the important buildings. I would expect that unimportant buildings will not have building specific time tolernace, and use the defaults anyway. (Whether the tolerances being defined as absolute or proportional)

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.

Sorry I don't understand ... "proportion for each individual building" ? what is that?

[Mariculous]

Well I found data that stated average daily journey time around 2000 specific to many countries. I cannot remember them all but UK was slightly above 60 minutes, Germany was around 80 minutes and some variation was mentioned.

From such data we cannot derive a distribution. Much more preciese data is required for this, in the best case a dataset of a fair number of passenger journey time records.
I found exactly one source that was a little more preciese, but it was related to commuting trips only. It was not preciese enought to derive a distribution from anyways.

Simply based on an average journey time and an average range of variation, the distribution could be anything, even including uniform distribution around the average time within the variation range.
If you found any more preciese data about this, please let me know so I might try to derive a distribution from that data.


In any case, your tests sound quite promising and I'll definitely have a look into it tomorrow.

[jamespetts]

By "proportion system", I meant any system in which the individual buildings' journey time tolerance scales in some way in proportion to the overall journey time tolerance; this, I think, is indeed (a); I have already responded to (b).

I am not sure that I understand the idea of adjusting the important rather than unimportant buildings. The most important buildings would not have any individual limitation on journey time tolerance: the passengers' general journey time tolerance would deal with this. Only with buildings one specifically wants to mark as ones which passengers are unwilling to spend as much as their general tolerance travelling to visit are buildings that would have something other than the general tolerance specified.

As to the proportion for each individual building, if one wanted to designate a particular building as one which passengers should not be willing to travel (for example) more than an hour tor reach, with the (a) system, one would have to work out what proportion of the general maximum that an hour is and specify that proportion as the value for that building; whereas with the originally proposed system, one would just specify an hour directly, which is much easier.

[jamespetts]

Freahk - one indeed cannot extrapolate a distribution from an average alone, but we can extrapolate a distribution from an average, a minimum and a maximum, and we can infer minimum and maximum journey times by looking at basic real world data about how long that it actually takes to get from one place to another. There was a time when it used to take the best part of a day to get from central London to Highgate, for example; trans-atlantic voyages took weeks, and longer voyages in the days of sail could take months. People were regularly willing to endure such travel times.

For minimum travel times, think of the amount of time that one might be prepared to travel from one's office to get lunch' during a 1 hour lunch' break when one needs to eat the lunch' in that time. This may depend on preferences, but may easily be as low as 10 minutes considering that this would make a 20 minute round trip and take a third of the available rest time just in travelling. It might even be lower than this.

[Vladki]

Ok, James. Maybe we both look at it from completely different view. I thought that the general time tolerance would be left as is, and that most buildings will not have anything specified. Only some exceptional buildings will have a special time tolerance, most often higher then the general one. E.g.: small football ground will be at the defaults, but big stadium, will have higher time tolerance, as football fans of big teams are often willing to travel far away to watch the match (football championship...).  On the other hand a local recycling and garbage collection centre, would have much lower time tolerance than the default. Therefore I thought it would be easier to say that big football stadium has e.g. 3x times (300%) higher time tolerance than small one, or that recycling centre has only 1/4the (25 %) time tolerance than the general one.  I don't mind having absolute tolerances for buildings, or even both, and let pak designers to choose.

[jamespetts]

Ok, James. Maybe we both look at it from completely different view. I thought that the general time tolerance would be left as is, and that most buildings will not have anything specified. Only some exceptional buildings will have a special time tolerance, most often higher then the general one. E.g.: small football ground will be at the defaults, but big stadium, will have higher time tolerance, as football fans of big teams are often willing to travel far away to watch the match (football championship...).  On the other hand a local recycling and garbage collection centre, would have much lower time tolerance than the default. Therefore I thought it would be easier to say that big football stadium has e.g. 3x times (300%) higher time tolerance than small one, or that recycling centre has only 1/4the (25 %) time tolerance than the general one.  I don't mind having absolute tolerances for buildings, or even both, and let pak designers to choose.

I chose a mechanism that lowers, rather than raises, the base tolerance for a reason, and that is so as not to disrupt the existing calibration of the journey time tolerance system so as to match Marchetti's Constant as described above. The existing system is calibrated to work for passengers who are potentially willing to make long distance journeys, and the issue was that they were doing so too much in times where there was little of interest to which to make such journeys, at least in most places, so the sensible solution is to reduce, rather than increase, the tolerance.

However, given the findings in relation to the average above, consideration will have to be given to:

(1) whether simply adjusting the skew is sufficient; or
(2) whether what we need to do is implement the suggested feature and adjust the skew and increase perhaps significantly the maximum journey time tolerance so as to get the correct ~1.1 hour journey time tolerance per 16 hour quasi-day average again but with passengers normally refusing to travel long distances to uninteresting destinations.

This may need some extensive testing. I should be interested in any observations from the Bridgewater-Brunel saved game above as a starting point for adjusting only skew.

[Vladki]

I think that getting the distribution function right is the most important thing. If the distribution is right, it should not matter too much what is the destination. (That should be already solved by visitor demand).

[Mariculous]

but we can extrapolate a distribution from an average, a minimum and a maximum,

No, no, no, not at all!
We can at most determine parameters of a given distribution from that data.
Anyways, let's see how the new parameters behave in practice.


About relative time values against absolute values, Imho simuconf configurable values should always scale consistently with hardcoded and hard-dat-ed values.
Fixed ourney times in dats won't do this.
Do we have definte journey time figures to specific destinations?
If not, pakset authors had to place reasonable guesses on these anyways, in which case I don't see the advantage in guessing an absolute value over guessing a relative value.
In fact, both require the pakset author to have a rough understanding of what the general max journey time figure looks like.


Anyways, let's adjust the distribution properly and then see if any new feature is required, as suggested.
As mentioned in the very beginning of this thread, imho the right choice for the distribution and its parameters is the most important factor to get a realistic passenger figure.

[jamespetts]

Freahk - do I understand you to suggest adjusting the journey time tolerance skew on the running Bridgewater-Brunel server? Did you want to test the saved game where this had already been done first?

[jamespetts]

I have been running some more in depth tests to measure not just journey time tolerances on average, but actual journey times on average. On the Bridgewater-Brunel server with existing settings, the results are as follows:

Average journey time tolerance: 1500 (150 minutes)
Average journey time: 610 (61 minutes)

Multiplied by 4, this gives us 600 and 244 respectively.

Running with a skew setting of 6 in the saved game linked above, we get:

Average journey time tolerance: 432 (43 minutes)
Average journey time: 289 (29 minutes)

Multiplied by 4, this gives is 173 and 116 minutes respectively, still slightly higher than the goal of ~80 minutes actual average.

Reducing the minimum visiting journey time tolerance from 12 to 2 gives:

Average journey time tolerance: 317 (33 minutes)
Average journey time: 325 (32 minutes)

Multiplied by 4, this gives 134 and 130 minutes respectively.

With these changes, the percentage of passengers successfully reaching their destination drops from 68% to 32% in the 1757 Bridgewater-Brunel saved game. Profits of player companies are affected as follows:

Constellation Ferry:
Before: 16,596c
After: -183c

Azuma Shipping:
Before: 41,865c
After: 5,291c

East Oceanic:
Before: 70,104c
After: 30,240c

funny company:
Before: 3,099c
After: -699c

Prominster Shipping & Coaches:
Before: 52,854c
After: 8,244c

Ves Transport Corporation:
Before: 13,208c
After: 5,934c

Wystoke Ferry Company:
Before: 50,682c
After: 5,604c

I shall run some more tests, but I should in the meantime be interested in comments on these observations and results.

Edit: Further tests indicate that, with a skew of 6 and a 2 minute minimum journey time, 0.18% of trips generated have a journey time tolerance of > 10 hours. With a skew of 5 and a 12 minute minimum journey time (the current settings), 5.1% of trips have a tolerance of > 10 hours.

[Vladki]

Why the multiplication by 4 ?

[jamespetts]

Why the multiplication by 4 ?

This is because Marchetti's constant is a value for daily travel time, and, on average, each unit of population in Simutrans-Extended makes approximately 4 trips per day.

For example, Prominster on the Bridgewater-Brunel map, has a population of 43,136. Each game month in 1757, this town generates circa 84,034 passenger trips. 84,034 / 43,136 = 1.94 passenger trips per unit of population per game month. Each game month is 6:24 (or 6.4 hours). We do not model a day/night cycle, so ignore inactive parts of the day. Each day is thus assumed to be 16 hours long. Each day is therefore 2.5 months. 2.5 * 1.94 = 4.85 - so we should perhaps be multiplying by 4.85 rather than 4.

[jamespetts]

I have now carried out some further testing, this time on the Stephenson-Seimens saved game from the in-game year 2021.

Running with a skew of 6, a minimum journey time tolerance of 2 minutes and a maximum journey time tolerance of 20,000 minutes, walking, private car and player transport usage is all down to around 60% of previous levels (testing in particular in Daring so as to isolate the effect of congestion). Buildings reported much lower visiting success rates - I am still in the process of testing this by allowing the game to run long enough to see the pattern more clearly using the minimap. With default settings, there is very little patterning of visitor success in the Stephenson-Seimens map, since all buildings have a very high visitor transport success percentage, and the map is largely just overall green. It is important to get a good patterning based on (1) a town's own amenities within walking distance; and (2) the quality of transport (both public and private road) in that town for the planned town growth mechanism, which is based on local transport success rates.

As to absolute numbers, we first need to think of what we are aiming for. UK government statistics show that, in the 21st century, people make ~1,000 trips per year on average. That equates to approximately 2.7 trips per day. The total number of attempted trips per passenger per day is, as set out above, 4.85. Therefore, we would expect approximately 56% of those to be successful in a world with transport as good as it is in 21st century Britain. The Stephenson-Seimens map is mixed in that regard: many towns have no road access to other towns, but public transport is generally better than reality; the overall effect is difficult to calibrate precisely, but we should be aiming for something not too far off reality.

With the modified settings, we are getting a total passenger success rate of 66%, down from 76% with the default settings (a skew of 5, an 8 minute minimum journey time and an approximately 5,000 minute maximum journey time). Thus, it seems that increasing the skew and reducing the minimum journey time does produce more realistic passenger generation.

As to increasing the maximum journey time, this has given us a journey time tolerance average of 484 (48 minutes), with an actual journey time average of 488 (48 minutes). Of course, in computing whether this aligns with Marchetti's Constant, we need to take into account the actual number of trips made, not the ideal number of trips that passengers would like to make, so we must multiply the figure by 4.85 multiplied by 66%. This gives us a value of 153 minutes, which is somewhat in excess of the ~80 minutes that we are looking for.

In terms of the very long journeys, perhaps more relevant to the Bridgewater-Brunel server than the Stephenson-Seimens server, 0.81% of all journeys were recorded as having a tolerance of over 10 hours, up from only 0.18% with the maximum journey time unaltered. This suggests that increasing the maximum journey time is an effective way of allowing the very long journeys that people are sometimes willing to make, but it may be that more refinement of this figure is necessary.

For reference:

5,000 minutes = 83 hours
9,000 minutes = 150 hours
15,000 minutes = 250 hours
20,000 minutes = 333 hours

[Mariculous]

Note: this post is 3 posts behind, so does not respond to the latest 3 posts.

No, these changes are bad, I'm losing too much profit!
Well just joking. I'd expect a fair portion of the decreased profit to be related to services that exceed the demand a lot.

I found one of two sources about journey times I had mentioned agin, so I'll do an excursion to eurostats data and will return to your observations after that.
I am sorry, the linked document is in German language, so I'll extract and translate the most important points to you.
https://ec.europa.eu/eurostat/documents/3433488/5298273/KS-SF-07-087-DE.PDF/0d50ff3c-a042-4c49-85e8-5333c92a7186

The paper is from 2007, the included data is from different years.

Page1:
In The average European citizen was using any kind of transporation one hour per day.
A UK citizen is using any kind of transportation 59.7 minutes per day, of which 36.5 minutes are spent in a private car.
It is unclear in which year that stat was recorded and if that data includes walking and bike journeys. (see page 5)

Page 2:
The average UK citizent does 2.9 journeys per day which take 63.3 minutes per day, an average distance of 31.8 km per day and an average of  in the UK.
That data was recorded from 1999-2001

In the UK, that journey time was related to the following:
50% free time activities, 20% shopping, 20% commuting, 5% business trip, 5% related to education.

It is unclear if that data includes walking and bike journeys (see page5)

Pages 3 and 4 are about the relation to journey distance and the way the data was recorded.

Page5:
This page is about passenger-distance distributed to different modes of transport. It can be noted that walking and bike data does not seem to be available for the UK.
The recorded average yearly passenger-distance was the following:
private car: 678 millard
other private motor vehicles: 10 millard
Bus: 48 millard
Rail: 52 millard
Aircraft: 9.9 millard


back to your observations:
From these it sounds like it results in much more realistic journey times on average.
It is very hard to tell if the journey time figure is also fairly realistic.

I'd expect actual journey times to be roughly half of maximum journey time on average, thus I am a little confused about your observation that actual journey times will be very closely to the maxmum tolerable time.

[Vladki]

Just a note to Stephenson-siemens -- I think we did a good work to have the map covered by public transport as much as possible

[Ves]

Interresting results, and I would kind of still be profitable, which is a good thing! 😝

I remember we talked about a while ago (years, maybe) that passengers would ignore the waiting time on their first stop, as to simulate them showing up only when they expect a convoy to depart. But I dont remember wether that is actually incorporated?

[jamespetts]

Some further testing in relation to patterns of visitor success on the Stephenson-Seimens map before and after the changes.

Before



After



As can be seen, although the overall map is a different colour, indicating that fewer successful visiting trips are being made overall, there does not appear to be any stronger patterning in the new state of affairs than in the old.

The purpose of the patterning is to allow the planned town growth mechanism to find the best places to put new buildings on the basis of the transport success of neighbouring buildings, so it is important to have differential data so that the system can pick appropriate places to build. As can be seen, the level of differentiation is very much the same in the before and after versions.

This does suggest that it is likely to be beneficial for the town growth system to use relative visitor success to determine town growth rather than absolute numbers (except, perhaps, for floor thresholds of absolute numbers) so that an essentially fixed rate of population growth can be distributed among different towns on a competitive basis, with those localities with the highest success rates receiving the most growth, albeit in a semi-randomised manner so as to prevent all growth happening in just one location. Other localised desirability data will also need to be taken into account.



Freahk - thank you for link to the German source: that is interesting. I had wondered about walking statistics yesterday evening: it is very important that they be included, as statistics relying only on motorised transport would result in a significant distortion when applied to Simutrans-Extended.

Fortunately, checking the latest UK statistics, I find that this does include walking, so these statistics can safely be used as the basis for the calibration.

As to actual journey times closely matching average tolerances, remember, these are mean averages, so it is possible for a great majority of journey times to be much lower than the average tolerance, but a few to be very high. Also note that the alternative destination system will result in the code effectively optimising for reachable destinations, and, if these destinations tend to be only just within tolerance, one might well see actual journey times matching tolerances, as we do when we reduce the tolerances.



Ves - this system was ultimately rejected on the basis that what counts as the first stop is uncontrollably arbitrary: in the example of a long sea voyage with a very low frequency, people living right next to the dock would use the dock itself as their first stop, and halve the long waiting times of the ships as intended, but people living on the other side of town might catch a 'bus to the dock, and their first stop would be the 'bus stop, not the dock, so this would be unworkable in practice.



One other thing needs to be considered with Marchetti's Constant: that is the relationship between the duration of individual trips and the number of trips made. It will be recalled that the principle of Marchetti's Constant is that there is a fixed travel time budget: people tend to spend approximately 80 minutes per day on average travelling. This means that passengers might make a large number of short trips or a smaller number of long trips, and so the system should replicate this relationship between the number of trips and the duration of trips. The current system does not do this.

A possible solution to this is to multiply the journey time tolerance of passengers by 100 divided by the success percentage of the building in question, at least for visiting passengers: for commuting passengers, the number of trips per day is fixed, of course. So, for example, if a building's visitor success is 50% and the base journey time tolerance generated is 10 minutes, this would be multiplied by 100 / 50 = 2 to get the adjusted tolerance, in this case being 20 minutes. If the success rate were 100%, this would be multiplied by 100 / 100 = 1 (10 minutes). If the success rate were 10%, this would be multiplied by 100 / 10 = 10 (100 minutes).

This would result in visiting passengers from poorly connected areas being willing to take longer trips than those from well connected areas, as one might expect in reality. This would, of course, result in increased success, which would in turn lower the multiplier until an equilibrium were reached.

However, this would also increase journey time tolerances overall, and may require further recalibration of the journey time tolerance figures to get a result that falls within the normal value for Marchetti's Constant.

[Ves]

Ok. Did we also talk about then that the passengers additionally would "skip" the waiting time of the longest waiting time on the jurney? So that passengers would ignore the waiting time of the first, as well as the longest waiting time. The narrative would be that the passengers know the schedule of all the lines they are taking, and are planning to leave with that in consideration. Although it would probably not be perfect, it would certainly help circumvent the issue you describe.

[jamespetts]

Ves - I cannot recall that suggestion being discussed, but such hackish mechanisms are almost invariably unworkable in that they lead to manifold anomalies and cause more problems than they solve. For example, this would mean that keeping passengers at an interchange for 10 hours on an urban metro line would have no effect. This would prevent one of the important systems for preventing extreme station overcrowding (of the sort that plagues Standard) from working.

In any event, passengers are inconvenienced by low frequencies even if they can plan their schedules, as the service in question does not depart when they want it to depart, and they are unable to travel at the optimum time for them, so it makes sense to take into account waiting time even in circumstances where the passengers might in reality choose to wait at home rather than at a station.



I have now had a chance to test the mechanism to which I refer above with various skew, minimum and maximum settings, largely on the Stephenson-Seimens server, as this most closely replicates conditions in 21st century Britain that are comparable to the available statistics.

With the mechanism implemented and with the skew/mode set to 7, the minumum visiting time set to 2 minutes and the maximum to 20,000 minutes, we get an average journey time of 40.5 minutes with a success rate of 66%, giving a daily journey time average of 126 minutes per person. Notably, the average tolerance per generated is just 26.3 minutes, suggesting that there are a lot of low tolerance passengers generated who do not travel at all. Thus, the average is getting closer, but I am doubtful that a skew as high as 7 is workable here.

Tests continue...

[Mariculous]

I remember we talked about a while ago (years, maybe) that passengers would ignore the waiting time on their first stop, as to simulate them showing up only when they expect a convoy to depart. But I dont remember wether that is actually incorporated?

Handling this properly would require a much more extended waiting time system.
If trains are scheduled to arrive only every 2 hours, but they do so all at once, waiting for each other, there effectively won't be any waiting time either.
This can be observed in the real-world quite frequently, but simulating this would be very complicated, thus I'd also consider it to be fair to handle all kinds of transfers the same: Waiting time is half of line frequency, as would be on average if lines arrival times were uniform distribiuted.

This means that passengers might make a large number of short trips or a smaller number of long trips, and so the system should replicate this relationship between the number of trips and the duration of trips. The current system does not do this.

That's the nature of working with statistical models instead of actually simulating each single inhabitant.
Thus, it is important to get a fairly well matching distribution. On average, we get many short journeys and few long journeys. If the distribution is selected well, it will result in the same figure as actually simulating each single inhabitant according to Marchetti's Constant would do.
I do not think it's a quite good idea to force individuality into a statistical model. Further note, the number of journeys per day is also an average!
Some inhabitants might do 10 journeys per day to the local kiosk, to buy a single bottle of beer each time, others might stay home for months, whilst even others might try to get around globe using only trains and ships.
So if there is a house spawning 10 very long journeys in a row ba (very low) chanche, that's fine as long as on average the journey time figure fits the real-world.

One aspect on the suggestion is interessting but needs a whole discussion on it's own, I suspect:

This would result in visiting passengers from poorly connected areas being willing to take longer trips than those from well connected areas, as one might expect in reality.

I suspect that one is quite difficult to calibrate and it would reduce the effect of a good transport network on the overall passenger numbers.

Imho, such a system would require a different system of private car ownership, which does not follow a fixed figure from the real-world but is instead based on a per-house public transportation reputation value.
There are two thresholds in the reputation: The privatecar_ownership threshold and the niggled threshold.
Any inhabitant above the privatecar_ownership threshold does not own a private car at all. Anyone below is considered to own a car, anyone below the niggled threshold will always prefer the car.

When searching a route, inhabitants will always calculate a private car and public transport route.
They will weighten up expected journey times, congestion and overcrowding.
If the private car is considered better, the public stransportation reputation will fall, otherwise it will rise.

The logic which service will actually be used remains the same:
If the inhabitant does not have a car, but using the car would be better, he still cannot use a car and will take public transport.
If the inhabitant does always prefer the car and public transport would be better, he will still use the private car.

Newly built houses will have a public transportation reputation of surrounding buildings, with some randomised varations.

So that passengers would ignore the waiting time of the first, as well as the longest waiting time.

When commuting to university, I always have to wait 23 minutes (it had been 27 minutes a few years ago) at one station, where three trains per hour continue on my route.
The connection is simply scheduled to miss the half-hourly line by 7 minutes (it was 3 minutes a few years ago) and the hourly express service by 13 minutes.

I'd really like to simply skip that waiting time and get the express train at my transfer station, so I could leave my home 55 minutes later and still arrive at the university in time, only 5 minutes later than currently (because of a little better bus connection at the destination)

Sadly, reality is mean. I can't! I always have to wait 23 minutes. There are alternative routes, but none of these is faster.

[jamespetts]

I have been undertaking some further testing, as I have been concerned that increasing the skew results in an especially large numbers of journeys with very short tolerances being generated.

On the Stephenson-Seimens map with a random mode/skew of 6, a minimum visiting tolerance of 5 and a maximum visiting tolerance of 9600, with the new mechanism enabled, I get the following statistics:

Average tolerance: 38 minutes
Average journey time: 40 minutes
Average journey time minutes per Simutrans day: 163

Proportion of passengers with a tolerance of >10 hours: 0.37%
Proportion of passengers with a tolerance of <10 minutes: 39%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.27%

Thus, it seems that increasing the skew is simply creating a large number of passengers with a tolerance so low that they fail to travel entirely on almost every occasion, which is not a useful method of calibration: there is no point in these passengers being generated if their chance of travelling even on an extremely well served map is negligible.

Further testing is required.

Edit: A further test. With skew increased to 6, the new mechanism in use, but not modifying the current Stephenson-Seimens minimum and maximum visiting journey time tolerances, (8 minutes minimum, circa 5,600 minutes maximum), I get the following statistics:

Average tolerance: 33 minutes
Average journey time: 39 minutes
Average journey time minutes per Simutrans day: 162

Proportion of passengers with a tolerance of >10 hours: 0.07%
Proportion of passengers with a tolerance of <10 minutes: 26.5%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.5%

Note that I am currently measuring only the initial trip: for onward journeys, the tolerance for those journeys is subtracted from the starting tolerance, and earlier statistics in this thread included those lower tolerances, whereas those in this post do not.

Edit 2: A further test, this time using the Stephenson-Seimens settings without modifications (i.e. skew of 6, 8 minutes minimum visiting tolerance, circa 5600 minutes maximum visiting tolerance), but with the new mechanism, I get the following:

Average tolerance: 100 minutes
Average journey time: 57 minutes
Average journey time minutes per Simutrans day: 212

Proportion of passengers with a tolerance of >10 hours: 2.63%
Proportion of passengers with a tolerance of <10 minutes: 7.73%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.68%

Edit 3: A further test, this time with the new mechanism disabled, otherwise with the same settings as the immediately preceding test. The results are:

Average tolerance: 90 minutes
Average journey time: 56 minutes
Average journey time minutes per Simutrans day: 205

Proportion of passengers with a tolerance of >10 hours: 2.13%
Proportion of passengers with a tolerance of <10 minutes: 13.4%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.54%

Edit 4: Here is test under edit 1 repeated (skew 6, other settings unchanged from Stephenson-Seimens) but with the new mechanism disabled:

Average tolerance: 31 minutes
Average journey time: 39 minutes
Average journey time minutes per Simutrans day: 146

Proportion of passengers with a tolerance of >10 hours: 0.03%
Proportion of passengers with a tolerance of <10 minutes: 40%
Proportion of passengers with a tolerance of < 10 minutes who made a successful trip: 0.24%

[Mariculous]

Sounds a little like passengers attempting to get somewhere impossible in that time even considering a "perfect" network.
Some rather overestimating heuristics or an entirely different destination selection method for short journey times might be required here.
Maybe place a rather optimistic guess on which distance can be travelled within the tolerable time and restrict potential destinations to be within that range.

We could get such an optimistic guess by maintaining per air-distance journey time stats of calculated routes.
Longer journeys will have greater average speeds, thats why different stats need to be recorded for different distances and it needs to underestimate journey times, otherwise we will never get close to the maximum tolerable time.

Alternatively, we might pick any destination and calculate the route. If the journey time is exceeded, we will iterate that journey back to a point that can be reached within journey time, select a new point that we expect to be reachable within the remaining journey time and do a few attempts to find a suitable destination around that point, using a rather understimated average journey time (e.g. walking speed) to check if these actually are within journey time tolerance.

The real-world idea behind this is, that people will not even attempt to reach a 50 km far-away destination in ten minutes.4

[jamespetts]

Freahk - the approach that you suggest is not consistent with the underlying design and purpose of the passenger generation algorithm. Generated passengers are desired trips, not attempted trips. The inherent desirability of a destination is a fundamentally different thing to its reachability: the current system is specifically designed to simulate that separation, and the alternative destinations system to simulate the fact that people will choose less than ideally desirable destinations on the basis of reachability. This system was designed to replace an earlier, much cruder system using distance ranges because that system produced intractable anomalies.

Rather than use the crude proxy of distance for destination choosing in passenger generation, it is better to calibrate the parameters of the current system to work better. One thing to consider is increasing the minimum journey time, as it is in reality likely to be rare for people to be willing to make a trip outside their homes, but only if that trip can be completed in less than 10 minutes. A 12-15 minute minimum journey time may well be worth considering.

Before looking into that, however, I am in the process of re-running the above tests but with more fine grained data about tolerances to get a better idea of the distribution produced by each minimum, maximum and skew set. The result of the first of these tests, with the current Stephenson-Seimens settings unchanged (skew 5, minimum visiting journey time tolerance of 8 minutes and maximum of 5,400) is as follows:

Average tolerance: 89 minutes
Average journey time: 56 minutes
Average journey time minutes per Simutrans day: 205

Proportion of passengers with a tolerance of >10 hours: 1.9%
Proportion of passengers with a tolerance of <10 minutes: 13%
Proportion of passengers with a tolerance of <30 minutes: 40%
Proportion of passengers with a tolerance of <1 hour: 53%
Proportion of passengers with a tolerance of <3 hours: 68%

This shows a very high proportion of trips (32%) with a tolerance of >3 hours, which does suggest that a skew of 5 leads to excessive journey time tolerances overall.

Edit 1: Running the same test again, with skew at 6 instead of 5, we get the following:

Average tolerance: 31 minutes
Average journey time: 37 minutes
Average journey time minutes per Simutrans day: 147

Proportion of passengers with a tolerance of >10 hours: 0.02%
Proportion of passengers with a tolerance of <10 minutes: 40%
Proportion of passengers with a tolerance of <30 minutes: 70%
Proportion of passengers with a tolerance of <1 hour: 75%
Proportion of passengers with a tolerance of <3 hours: 79%

Edit 2: The same test again, but with a skew of 7 gives the following:

Average tolerance: 23 minutes
Average journey time: 36 minutes
Average journey time minutes per Simutrans day: 135

Proportion of passengers with a tolerance of >10 hours: 0%
Proportion of passengers with a tolerance of <10 minutes: 59%
Proportion of passengers with a tolerance of <30 minutes: 78%
Proportion of passengers with a tolerance of <1 hour: 79%
Proportion of passengers with a tolerance of <3 hours: 79%

Edit 3:

Here is a chart of the distribution curves with the three levels of skew:



Edit 4: For clarity, I should note that all of these results were obtained with the system for adjusting journey time tolerance based on the passenger success rate of the origin building disabled.

Edit 5: Re-running the test, but with altering the minimum an maximum as well as the skew, with the minimum now being 12 minutes and the maximum now being 12,000 minutes and with a skew of 6, we get these results:

Average tolerance: 45 minutes
Average journey time: 42 minutes
Average journey time minutes per Simutrans day: 171

Proportion of passengers with a tolerance of >10 hours: 0.35%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 56%
Proportion of passengers with a tolerance of <1 hour: 70%
Proportion of passengers with a tolerance of <3 hours: 77%

Edit 6: The same minimum and maximum with a skew of 7 gives:

Average tolerance: 28 minutes
Average journey time: 36 minutes
Average journey time minutes per Simutrans day: 114

Proportion of passengers with a tolerance of >10 hours: 0.002%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 70%
Proportion of passengers with a tolerance of <1 hour: 78%
Proportion of passengers with a tolerance of <3 hours: 80%

[Mariculous]

Freahk - the approach that you suggest is not consistent with the underlying design and purpose of the passenger generation algorithm.

In which case you'll have to conform with passengers that only have a short period of time, e.g. in a short lunch-break, to very rarely arive anywhere they actually desire to go.

it is better to calibrate the parameters of the current system to work better

I'd be very surprised if you ever get an acceptable success rate in case of such short maximum journey times by simply calibrating the parameters.

[jamespetts]

In that case, you'll have to conform with short distance passengers not finding a detination in many cases, although there would be suitable destinations in that range.

What exactly do you mean by "suitable destinations" here? A place where it is reasonable for a person to go is not the same as a place where a person wants to go. If somebody wants to buy a rug, a person will not go to a shop selling rope and candles just because he/she cannot get to a shop selling rugs within a reasonable time, even though it is perfectly reasonable for a generic person to make a trip to a shop selling rope and candles. People do not, in reality, first decide that they will make a trip and then think where would be a suitable place for them to go. Rather, people start with a desire to achieve something, and, if leaving the house and going somewhere else is necessary to achieve that end, do so if and in so far as this can be done within what the person in the particular circumstances considers a reasonable time.

Thus, one would expect a system that simulates reality to be one that has people not making trips where the journey time to a desired destination is too long even where there are other destinations nearby that a person might reasonably want to go to in some circumstances. Indeed, the planned town growth mechanism relies on there being a difference in the number of successful trips made by people who live very close to a lot of desirable destinations and those who do not.

Edit 1: I am now repeating some of the above tests with the success influenced journey time tolerance re-enabled. Here is the first result.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes

Average tolerance: 73 minutes
Average journey time: 49 minutes
Average journey time minutes per Simutrans day: 155

Proportion of passengers with a tolerance of >10 hours: 1.08%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 35%
Proportion of passengers with a tolerance of <1 hour: 57%
Proportion of passengers with a tolerance of <3 hours: 73%

Edit 2: Here is the second result.

Skew: 7
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes

Average tolerance: 42 minutes
Average journey time: 40 minutes
Average journey time minutes per Simutrans day: 129

Proportion of passengers with a tolerance of >10 hours: 0.03%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 52%
Proportion of passengers with a tolerance of <1 hour: 70%
Proportion of passengers with a tolerance of <3 hours: 78%

[Mariculous]

Usually people won't desire a far-away building, if there is not anything special about it.
E.g. we got very many kiosks here, a few nearby supermarkets and so on.
The weekly shopping is usually not done in the most local supermarket, because we got the car available, there's a little preference of that supermarket and we got a much larger time budget.

Frequently it appears that there is something missing for dinner or the bread runs out in the evening, in which case we got a rather short time budget, so we simply walk to the ~200m far-away supermarket.
I have never even thought about going to the much farer-away supermarket in that case, nor it's it's a hidden desire to have a door-to supermarket hyperloop, which would allow me to travel these 3 kilometers 15 minutes, including the shopping itself.


So the second suggestion above is about first randomising any destination. If that's within tolerable journey time, it's fine. Otherwise attemt to find the same building that actually is withing journey time tolerance.
this should be fairly realistic in case of commercial and industry visits, but might not be in case of residental visits.

The first suggestion above is about resticting the area of "desired" destination to an overestimated area of which could be reached in case of very good transport, so people won't desire to make a trip to Japan  within their lunch break, as I don't think anyone in the real-world would seriously desire this.
It is important that this area is an overestimation, based on the global best case, so effectively success rates will rise, especially in case of short distances, but but there will also be many more misses in areas that are served worse than others.

[jamespetts]

Usually people won't desire a far-away building, if there is not anything special about it.
E.g. we got very many kiosks here, a few nearby supermarkets and so on.
The weekly shopping is usually not done in the most local supermarket, because we got the car available, there's a little preference of that supermarket and we got a much larger time budget.

Frequently it appears that there is something missing for dinner or the bread runs out in the evening, in which case we got a rather short time budget, so we simply walk to the ~200m far-away supermarket.
I have never even thought about going to the much farer-away supermarket in that case, nor it's it's a hidden desire to have a door-to supermarket hyperloop, which would allow me to travel these 3 kilometers 15 minutes, including the shopping itself.

But the only reason that you do not think about places that are geographically far away is the amount of time that it takes to get there. If and in so far as these buildings were closer in time, you would be more likely to consider going there. If all supermarkets in the world were equally close in terms of travel time, then you would have a preference as to which one to go to. For supermarkets, your preference would be weak, and most alternative supermarkets would suffice. In Simutrans-Extended terms, you would have a high number of alternative destinations.

For other things, your preferences would be stronger: you would not go to a local supermarket instead of a distant antiques shop, even if the distant antiques shop were too far to get to. Your underlying desire to do something that can only be done in a far-away destination is not affected by the fact that the destination is far away (and by far away here I mean far in time): only whether you are reasonably able to fulfil the desire is so affected. Such preferences for more specific destinations are simulated in Simutrans-Extended by the passengers with a lower number of alternative destinations.

So the suggestion above is about first randomising any destination, if that's within tolerable journey time, it's fine, otherwise attemt to find the same building that actually is withing journey time tolerance.

This is exactly what the alternative destination system does, except that there is no concept of "the same building" (and there is not in the system that you suggest, either).

Edit 1:
As can be seen from the above results, there is no single setting that keeps the average within Marchetti's Constant whilst giving reasonable numbers of journeys at the far ends of the spectrum, so I am testing another method for calibration, which is a uniform proportion reduction in journey time tolerance by a specified percentage (in effect, an adjunct of the system described above for calibration of journey time tolerance by success percentages). These tests are run with the method for adjusting journey time tolerances based on building success percentages enabled. The first results are as follows.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 75%

Average tolerance: 59 minutes
Average journey time: 45 minutes
Average journey time minutes per Simutrans day: 144

Proportion of passengers with a tolerance of >10 hours: 0.7%
Proportion of passengers with a tolerance of <10 minutes: 0.008%
Proportion of passengers with a tolerance of <30 minutes: 45%
Proportion of passengers with a tolerance of <1 hour: 64%
Proportion of passengers with a tolerance of <3 hours: 75%

Edit 2: Here is another set of results.

Skew: 7
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 125%

Average tolerance: 48 minutes
Average journey time: 44 minutes
Average journey time minutes per Simutrans day: 138

Proportion of passengers with a tolerance of >10 hours: 0.06%
Proportion of passengers with a tolerance of <10 minutes: 0%
Proportion of passengers with a tolerance of <30 minutes: 34%
Proportion of passengers with a tolerance of <1 hour: 65%
Proportion of passengers with a tolerance of <3 hours: 78%

[Mariculous]

But the only reason that you do not think about places that are geographically far away is the amount of time that it takes to get there.

If I got a few hours available for shopping in the supermarket, which is usually the case on saturdays, I won't desire nor attempt to move to the next city to do so if there is nothing special about that supermarket. It doesn't even matter if that's within my tolerable time or not, as long as it takes longer to get there and even if it's roughly the same time, I'd rather prefer the one that is closer.
I don't take the motorway to get to the next town, just because it's 5 minutes faster, but twice the distance either.

For other things, your preferences would be stronger: you would not go to a local supermarket instead of a distant antiques shop, even if the distant antiques shop were too far to get to.

Which is obviously an entirely different thing as there is something special about that destination that cannot be found nearby.

This is exactly what the alternative destination system does

It doesn't. It allows people that wanted to get to an far-away antiques shop, to visit a friend instead, if the shop is not within journey time.
This might be fairly realistic, as can be observed in the real-world "Oh I don't have enough time to do this anymore, so I'll do something different and do the other thing tomorrow", but is exactly your counter argument against my suggestion.

and there is not in the system that you suggest, either

Well that's what was actually meant by a suitable destination.

Anyways, let's stick with these people not getting something to eat in their lunch break, although there is a baker just over the road, whilst these people got a desire to get their lunch from a 30 minutes far-away baker.

[jamespetts]

Freahk - I am not sure that I understand how any of that is a reason to use a distance based system?



Further results:

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 54 minutes
Average journey time: 44 minutes
Average journey time minutes per Simutrans day: 140

Proportion of passengers with a tolerance of >10 hours: 0.6%
Proportion of passengers with a tolerance of <10 minutes: 0.03%
Proportion of passengers with a tolerance of <30 minutes: 49%
Proportion of passengers with a tolerance of <1 hour: 67%
Proportion of passengers with a tolerance of <3 hours: 76%

[Mariculous]

It is reasonable to use a distance based system to restrict the search-space to a much smaller area, which still is a superset (or at least nearly a superset) of the actually reachable area within the journey times limit, to increase the number of successfully selected destinations, especially in cases of short distance preferences. This will increase success rates, which can be compensated by decreasing the number of retries.

The issue of passengers visiting a local supermarket, instead of an antiques shop is a different issue, that does also exist in the current system and needs to be handled by a different system on its own, if we wanted to handle this properly.

Such a system would require a building type system, building type specific journey times and supposedly a locality preference, also specific to building (types).
A passenger will then first decide what to do, which means selecting a building type and a tolerable time and then he would be searching for a building of that type within the tolerable time limit.

Just short thoughts, as I don't think that's a quick and easy thing.

[jamespetts]

It is reasonable to use a distance based system to restrict the search-space to a much smaller area, which still is a superset (or at least nearly a superset) of the actually reachable area within the journey times limit, to increase the number of successfully selected destinations, especially in cases of short distance preferences. This will increase success rates, which can be compensated by decreasing the number of retries.

The issue of passengers visiting a local supermarket, instead of an antiques shop needs to be handled by a different system on its own. Using the restricted search area will handle this issue just as bad, in case of very low distances admittedly even worse, than the current system that does not restrict the search-space.

If we want to increase the success rate, we can increase the number of alternative destinations (indeed, this has already been calibrated extensively). Anything else risks anomalies, of exactly the type that we had when the system was distance based. The fundamental principle must always be that it is time, not geographical distance, that determines whether passengers travel.

[Mariculous]

So it's actually realistic, that passengers are dreaming of transportation that boosts them to far-away destinations within only 10 minutes?
If that's realistic, it's fine and I'm an extremely rare kind of realist.
I never had the desire to visit a far-away bakery and rejected the short journey to the other side of the road, because there was no scifi mode of transport boosting me to a bakery in another town and back in only 10 minutes.

Sure, we can also brute-force more, more and even more "desired" destinations, but that doesn't solve the problem.
It will lead to much increased success rates in case of long journeys, whilst there will still be many unsuccessful short journeys although there would be a suitable destination (that means a destination that will fullfill the desire of the inhabitant, not any destination that offers something completely different than what the inhabitant wanted to do)

[jamespetts]

So it's actually realistic, that passengers are dreaming of transportation that boosts them to far-away destinations within only 10 minutes?
If that's realistic, it's fine and I'm an extremely rare kind of realist.
I never had the desire to visit a far-away bakery and rejected the short journey to the other side of the road, because there was no scifi mode of transport boosting me to a bakery in another town and back in only 10 minutes.

The only reason that you do not think about visiting a bakery in Paris when you have a spare half hour in an afternoon is precisely because of the time that it takes to get from Germany to Paris. You use the distance as a proxy for journey time when the distance gets sufficiently high, and, thus, when you have a low journey time tolerance, you do not even consider things outside a certain distance because it is easier mentally to think about distance than to work out the journey time precisely.

But there would have been a time in the past (and within the time that we simulate in Simutrans-Extended) when it took ~6 hours to get from central London to what are now the northern suburbs of London and when people would have applied the same heuristic and not even considered going anywhere outside their village if they could not spare the whole day for the trip. In modern times, it is entirely reasonable to make a round trip of hundreds of miles within a day. That would have been considered science fiction transport in the 18th century. We need to simulate the 18th century as much as we simulate the 21st. We need a universal mechanism, not a crude proxy that relies on assumptions that are very specific in time and place.

Distance based mechanisms always risk resulting in anomalies. Imagine three towns: town A, a small town on the coast; town B, a large town along the coast, and town C, a small town on an island just off the coast. Town C is much closer to town A than either are to town B, but the only connexion to town C is by a ferry from town B. With a distance based system, passengers in town A are more likely to seek to travel to town C than town B, whereas, in reality, people will be more likely to choose a destination in town B. Precisely this sort of situation in fact occurred regularly when we had distance based mechanisms. This does not occur with the current mechanism.



I have now run a further test, this time using the Bridgewater-Brunel saved game from 1757. Here are the results:

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 58 minutes
Average journey time: 28 minutes
Average journey time minutes per Simutrans day: 78

Proportion of passengers with a tolerance of >10 hours: 0.68%
Proportion of passengers with a tolerance of <10 minutes: 0.4%
Proportion of passengers with a tolerance of <30 minutes: 47%
Proportion of passengers with a tolerance of <1 hour: 65%
Proportion of passengers with a tolerance of <3 hours: 75%

Global passenger success rate: 58% (down from 69% with current settings)

Prominster Shipping & Coaches monthly profit: 10,133c (down from 47,545c)
East Oceanic monthly profit: 12,805c (down from 73,122c)
Azuma Shipping monthly profit: -2,671c (down from 41,667c)
Ves Transport Corp. monthly profit: 534c (down from 11,594c)

[Ranran(retired)]

Azuma Shipping monthly profit: -2,671c (down from 41,667c)

I would have to stop most freight networks as freight is not profitable. (´・ω・｀)

[jamespetts]

I would have to stop most freight networks as freight is not profitable. (´・ω・｀)

Interesting - you are using passenger revenues to subsidise freight operations?
(Incidentally, apologies for accidentally modifying your message instead of replying: I believe that I have put it back to how it was before the error).

[Mariculous]

This does not occur with the current mechanism.

And won't appear with a system restricting the search-space to a distance based area (as we can calculate distances much more easily), that is a superset of the area that can actually be reached within our maximum journey time (which we cannot calculate easily).

To ensure it is a superset, we need to record (global, or per-city) stats about the maximum distance we could reach in a given time, when calculating routes.
Thus, when calculating a new route, we can always definitely say if it might be possible to reach that destination or of it's unrealistic to reach that destination in the given time.

Refering to your example, I don't see the described issue:
An inhabitant attempting to travel from A to anythwere will have a maximum journey time and won't exceed it.
Assuming B could be reached within the journey time limit, C will also be assumed to be within the limit, so destinations in C might get picked, but withdrawn as being to far-away in terms of time, whilst a destination in B might be close enough in terms of time.

As the service gehts improved, the heuristics might be wrong for a while, thus it's important that it is an overestmation to quickly react to such improvements. In a fairly short amount of time, an inhabitant attempting to do a longer journey will notice that there is something in range, at a distance we didn't expect to be in range within a given tolerable time, thus this stat will be updated.
To react on decreasing levels of service, these stats need to be rejected after some time.

I would have to stop most freight networks as freight is not profitable. (´・ω・｀)

I agree, in most cases.
It seems like there are very few profitable cargo lines currently. Coal and iron ore cannot be transported profitably at all using current vehicles.

[Ves]

I agree with James, that we most likely use distance as a proxy for time. I myself live 160km from my work, and take the train every day (when I dont have this Corona-holiday) to go there. From door to door it takes me ca 2,5 hours. 20 years ago, this would have been a much longer travel, but thanks to a new bridge connection, replacing a 45 minute ferry connection with the 10 minute bridge connection, this is now feasable.
However, I also believe that we humans are lazy. Unless we live in Star Trek future, where we can beam ourself around the globe, we still need to spend (some) time and effort to go places. For many things, we just have to accept this fact, like going to work, or visiting friends or special stores. But for other things, we definitively want to spend as little time as possible.

So in Simutrans, this could be simulated that some proportion of the generated passengers will first choose a type of destination (say a building or industry), and then look for a similar destination on the map which has the smallest jurneytime possible.



Well, most of my freightlines are also running negative, but I have two boats that (sometimes) doesnt. Most horses are negative, or in the best part barely breaking even.

[jamespetts]

I am afraid that I still do not understand the purported benefit of trying to use distance as a mechanism, especially in circumstances where the current system was implemented precisely because using distance in this way caused intractable problems. It is not a bad simulation of reality that passengers are being generated all of whose alternative destinations are too far away to be reachable within their journey time tolerance even with modern transportation. If this were not the case, how would it be possible for a transport success percentage system to favour large towns with many amenities within walking distances over isolated settlements without some additional complex proxy that would be difficult to code and potentially prone to its own anomalies?

There is nothing inherently unrealistic about this. The simulation of passengers is not intended to represent peoples' actual explicit thoughts. It is intended to represent (in part) what economists call latent demand: that is, extra journeys that people would make if only there were more interesting or useful things to visit within a reasonable amount of time. What thoughts that actually do or do not go through the minds of people when deciding whether to make these trips is not relevant.




In any event, I have been carrying out further testing, this time with the Bridgewater-Brunel game again, but running for > 1 game year to see the long-term effects, especially the recursive effects of the new mechanism for adjusting journey time tolerances based on actual success rates.

The findings are as follows.

Skew: 6
Minimum visiting tolerance: 12 minutes
Maximum visiting tolerance: 12,000 minutes
Uniform adjustment percentage: 66%

Average tolerance: 63 minutes
Average journey time: 24 minutes
Average journey time minutes per Simutrans day: 71

Proportion of passengers with a tolerance of >10 hours: 0.85%
Proportion of passengers with a tolerance of <10 minutes: 0.22%
Proportion of passengers with a tolerance of <30 minutes: 43%
Proportion of passengers with a tolerance of <1 hour: 63%
Proportion of passengers with a tolerance of <3 hours: 74%

Global passenger success rate: 61%

As we can see, there is a noticeable adjustment of the success rate and the distribution of tolerances in response to the reduced success rate, showing that the negative feedback of the new mechanism does work.

Here are some screenshots of the minimap showing visiting passenger success after running with the new calibration as above for > 1 year, showing separately east and west of the Bridgewater-Brunel game map:





As we see, there is strong patterning: towns with no service or only coasting boats and with few local amenities tend to get very poor visiting success, whereas larger towns, especially those with local amenities, tend to get much higher visiting success. As is realistic in this era, what is needed is for local industries to be well served with freight transport so that they can operate, so that the local market, public house, etc., can absorb the local desired visiting population simply by walking trips to generate a higher rate of visitor success which will in turn, when the new town growth mechanism comes to be implemented, lead to higher town growth, especially in the areas within easy walking distance of the amenities in question.

Longer distance passenger transport, although it may be profitable for the player, is unlikely to have a major impact on local success rates until the era of the steam train, although may make a difference in connecting larger towns or small, cut-off towns with few amenities to neighbouring larger towns with more amenities.

The calibration that we are getting with these settings and the new mechanism seem to be satisfactory and a significant improvement on the existing calibration.

I will now have to make the percentage adjustment for tolerances configurable in simuconf.tab and then consider why freight transport is currently so unprofitable, as, for the reasons given above, freight transport is especially important in this early era.

[Ranran(retired)]

I will now have to make the percentage adjustment for tolerances configurable in simuconf.tab and then consider why freight transport is currently so unprofitable, as, for the reasons given above, freight transport is especially important in this early era.

As I reported in another thread, the shipping volume is limited.
Frequently small carriages wait idle for months or move empty once a month to create a deficit.
It is difficult to recover the fixed cost with such a small amount of transportation. 

Meat and wheat shipments are extremely tightly regulated, while restrictions on fishing appear to be loose.
The port tends to overflow with fish. British people seem to prefer fish than Japanese.

Especially bad is livestock. Despite the vast ranch, they do not ship even one a month.
And the livestock manger demands a large salary every month as they can carry 35 livestock. 
I have to feed them who do very little work with the money I make on the ship!

[jamespetts]

I have now implemented this change on the master branch of both code and pakset. I should be grateful for feedback on passenger generation from to-morrow's nightly build. Please note that it may take a few months for the negative feedback mechanism to produce fully stable behaviour.

I have also reduced considerably the monthly cost of early goods transport with a small volume, including carts, wagons, the skiff wherry, livestock drover and pack horses. These were too great to allow a profit to be made and higher than wage levels of the time (when compared to goods revenue) suggested that they should be.

I should be grateful if people could confirm whether goods transport is now more workable than before in financial terms.