Short and long distance pax

[prissi]

As some of you may noticed the generation of destinations of passengers and mail (pax) was changed. So some long introduction here:

Before the recent nightlies the chance that a destination (attraction or city) was selected, depended only on its size. Or mathematically speaking:
p=level/total_sum_of_levels.

Recently this formula was changed to incorporate the distance (with minimum distance of 4):
p=1024*level/(total_sum_of_p*distance)

The idea was that on network games, you can start up a network more easily if the destinations are more local, so even people coming a little later could enter into a game. Moreover, this would also make start up of a game easier.

But the above code preferred local destinations quite a lot. To counter this for cities a zone model was invented:

Code Select Expand


# amount of passengers that travel from/to factories or attractions
factory_worker_percentage = 33
tourist_percentage = 16

# the remaining percentage is divided among short-range,
# medium-range and long-range cities trips
# long-range percentage need not be explicitly specified;
# it equals (100% - city_short_range_percentage - city_medium_range_percentage)
# the distance ranges for city trips
# the ranges are the number of tiles from the origin city
city_short_range_percentage = 60
city_medium_range_percentage = 30
city_short_range_radius = 50
city_medium_range_radius = 100


This works nicely on standard 256*256 maps with 16 cities, albeit not for attractions. However, on a 512*512 map no cityis in the first zone and only one on average in the second zone. Thus those zones need to be scaled by map size and number of towns (or mathematically by town density) somehow.


Now to the discussion point:
One could alter the formula to make the influence of distance less prominent. Such a changed formula would be:
p=1024*level/total_sum_of_p*(A+1)/(A+distance)

A is a scaling factor, something like pax_distance_factor. The larger A is the less important the distance becomes. A=10000 will almost revert to the long term stable behaviour. The disadvantage is that such a factor is somehow obsure and difficult to understand. The advantage is, that such a factor is very easy to implement for attractions as well as for cities or that different factors for attractions and towns could be used.

Now the question: What system do you prefer? Do you prefer the system by giving explicit chances and ranges. Or do you rather want to see a simple slider in the new world dialoge to change between local<-> equal? Or rather just another parameter in simuconf.tab (or two for cities and attractions)? Or do you have other suggestions?

I apologize if this reads cryptic or very mathematically. But the passengers generation is at the core of simutrans and thus any big change needs additional input from you, the players.

Personally, currently I favour a single factor for attractions and cities with a slider in new world dialogue. But I am eager to hear your opinions.

[Combuijs]

Hmm, that A factor in the last formula is a bit diffuse, it is quite unclear what it is doing, and very hard to explain to the mathematical impaired.

I like the simplicity and the logic of:
p=1024*level/(total_sum_of_p*distance) with minimum distance 4

but that did not seem to do the trick.

First of all, I think that minimum distance should be higher, say the size of a big city, somewhere between 10 and 20. Second, I think you should not use the distance, but the square root or the natural logarithm of it. In this way local destinations will still be favourite (which is quite natural), but the influence of the distance gets less important when the distance is increasing. I'm very aware that both square root and natural logarithm are time consuming for calculations, but there are integer approximations available (at least for square root). As an alternative you could work with a simple approximation table. This should give better results.

[prissi]

Increasing the A mostly does what a square root would do too, but is more adjustable. See the attachment: 20 emulates the square root and 100 somewhat the logarithm. (Albeit the letter is not very local in the end).

[Combuijs]

Well, I have to say, I like the way the functions 21/(20+x) and 101/(100+x) behave. They are not that steep near 0 and for long distances the difference becomes less but not 0. I really like that result. But the difficulty remains how to explain that parameter A. You should probably fix it, or just give a few possibilities from which the user (or pakset maintainer) can choose.

[prissi]

That was why I though of a slider in the new_world dialoge ...

[Ters]

I think I would prefer a continous scale, but it's hard to say for sure until I have tried it out. Not only are the default values for the zones too small for large maps (I use 1024x1024), but more zones would have been useful as well. Configuring all those zones individually do however sound like a lot of pain. I'm not sure I've got the current configuration right. (I had to retire more than 50 % of my passenger convoys when this change was introduced.)

My wish could be that if I created a map of size 256x256 and a map of size 1024x1024, but with all other settings the same, there should be the same number of passengers going between the cities. This does however mean that the maps are of equal geographic size, with the larger just having a greater resolution (more tiles per kilometer so to speak, although other aspects of the game have other relationships between tiles and kilometers), and this might not be quite what people (including myself) want from a larger map.

One problem with this parameter A is that when A is low, small changes have a huge impact, while the same changes will have little impact when A gets really large. The maximum value of A must also be much greater than the map size to approximate the old behaviour.

[Vonjo]

What is 1024 in the formula above?

I also think that configuring the zones are pain and confusing. Just set the number by default.

Another idea:
p=(level/total_ sum_of _levels) * (0.5*map_diagonal/distance)
It will work in any map size.

Or maybe we should also see how Simutrans Experimental implement this.

[prissi]

The 1024 is to avoid returning zero for attractions with level 1 or so too early.

@Ters
You are right about A has a different sensitivity. But using A=(1000/B) makes the other end difficult. Maybe the slider would use a handcrafted scale. Ideally a player won't touch.

I also though on more zones, but firstly attractions does not use those zone model I think those will be way to many parameters.

@Vonjo

Another idea:
p=(level/total_ sum_of _levels) * (0.5*map_diagonal/distance)
It will work in any map size.

I am not sure this is really desired, since the fixed cost of a pak set does not scale with the map. With this large maps become more difficult than they are already now.

[prissi]

The pax destination selection system was now changed. The probability for a destination is now given by:

(level*locality_factor)/(locality_factor+distance)

where distance>=4. The locality_factor can be change with time. As a consequence you can have very local traffic in 1850 (locality_factor=1) and while in 2050 the probability of a destination is only given by its level.

[Ters]

And because of that I had to bring all my retired trains and some more back into service. At least I got a warning this time, so I was prepared.

It will be interesting to see how this new system works out, but it will take some time for my game to reach a new stable state.

[Vonjo]

Oh nice.
It is great and simple. It can be easily understood.
I think the locality factor should depends on when the player starts the game. For example: first year-->locality=1, tenth year-->locality=10. So we can start the game like in year 2000.

Btw, this system still won't help player who come very late.