### Author Topic: Pax journey times  (Read 2283 times)

0 Members and 1 Guest are viewing this topic.

#### AP

• Devotee
• Posts: 1213
• Languages: EN
##### Pax journey times
« on: March 20, 2014, 08:19:49 PM »
In the current version of experimental, how do pax journey times work?

A railway station seems to know how long the journey takes to each destination, even before a train has run the route. Presumably passengers decide to travel based on this? Where does that number come from, is it an accurate forecast, or does one have to run a route "empty" before the times update and people will travel?

Regarding comfort of vehicles, obviously they will favour the fastest comfortable journey, but if a journey is outside of the maximum time people will travel, based on the comfort factor on offer, will they still travel anyway? If there is only one route on offer, an uncomforable one, will they use it?

What about if there are slow but comfortable routes, and fast but uncomfortable ones on offer. E.g. 20kph in a sailing ship comfort 118, vs 80kph on a train comfort 50.  Would the ship need to be comfort 200 to equal the train (1/4 speed so 4x comfort?) or does it not work like that? And does it change if both are out of comfortable range for the destination port?

« Last Edit: March 20, 2014, 09:05:19 PM by AP »

#### jamespetts

• Simutrans-Extended project coordinator
• Posts: 20776
• Cake baker
• Languages: EN
##### Re: Pax journey times
« Reply #1 on: March 20, 2014, 08:44:33 PM »
Journey times for passengers are calculated in the same way as journey times for all types of load. Initial journey times are based on the distance and the average speed (or, if the average speed is not available, a fraction of the top speed) of the line. When journeys have actually been completed, records of the average times that those journeys have taken are used instead of the initial estimations.

Comfort has no impact at all on whether passengers will travel or which route that they take: it affects only revenue. This is because having a multi-factorial routing system would be too computationally intensive, and it would also be fantastically difficult to get a meaningful balance between different factors. Only total journey time (including walking to and from the origin and destination) is taken into account when routing.

#### AP

• Devotee
• Posts: 1213
• Languages: EN
##### Re: Pax journey times
« Reply #2 on: March 20, 2014, 09:04:28 PM »
So there is nothing which restricts how far passengers will travel, if journeys are on offer to all corners of the map?

#### jamespetts

• Simutrans-Extended project coordinator
• Posts: 20776
• Cake baker
• Languages: EN
##### Re: Pax journey times
« Reply #3 on: March 20, 2014, 09:23:07 PM »
The only thing that restricts how far that passengers will travel is the journey time, although in the current release version, only a certain proportion of passengers will be prepared to make long distance journeys (in the forthcoming major release, the distance ranges are abolished).

#### AP

• Devotee
• Posts: 1213
• Languages: EN
##### Re: Pax journey times
« Reply #4 on: March 20, 2014, 09:35:51 PM »
The only thing that restricts how far that passengers will travel is the journey time, although in the current release version, only a certain proportion of passengers will be prepared to make long distance journeys (in the forthcoming major release, the distance ranges are abolished).
Ah ok. What is the definition of a "long journey" in terms of time in the current version?

#### jamespetts

• Simutrans-Extended project coordinator
• Posts: 20776
• Cake baker
• Languages: EN
##### Re: Pax journey times
« Reply #5 on: March 20, 2014, 10:03:53 PM »
The base data from simuconf.tab are:

Code: [Select]
`# The program will generate three groups of passengers: (1) local;# (2) midrange; and (3) long distance. The program will look for a town within# the specified distance ranges for each class of passenger. If it cannot# find such a town within a certain number of tries, it will pick a random town.# The ranges *may* overlap. These values are in kilometres.# REMOVE in version 12.xlocal_passengers_min_distance = 0local_passengers_max_distance = 16midrange_passengers_min_distance = 16midrange_passengers_max_distance = 80longdistance_passengers_min_distance = 55longdistance_passengers_max_distance = 16384`
These distances are in kilometres. A long journey is thus any journey over 55km.

#### AP

• Devotee
• Posts: 1213
• Languages: EN
##### Re: Pax journey times
« Reply #6 on: March 21, 2014, 08:50:16 PM »
And the ratio of km to tiles is... (I always forget this one...)

Thanks James.

As you've undoubtedly figured, I'm trying to get my head around passenger demand for inter-island travel on the server game, which seems to be very low even when the journey speeds up... which if it's defined by distance would be why.

#### Sarlock

• Devotees (Inactive)
• Posts: 1340
• Languages: EN
##### Re: Pax journey times
« Reply #7 on: March 21, 2014, 11:48:29 PM »
8 tiles to 1 km.

If the cities are properly interconnected on each island, there seems to be a lot of passengers generated that are willing to make a cross-map trip.  Just look at the demand for my Cogsand-Monkington route -- considering that it isn't connected to many cities on the west side, there is a significant amount of demand.  Even though relatively few passengers (and mail) want a cross-map route, with the sheer amount of population we'll have by 1830, there will be sufficient.

#### AP

• Devotee
• Posts: 1213
• Languages: EN
##### Re: Pax journey times
« Reply #8 on: March 22, 2014, 10:34:41 AM »
8 tiles to 1 km.

If the cities are properly interconnected on each island, there seems to be a lot of passengers generated that are willing to make a cross-map trip.  Just look at the demand for my Cogsand-Monkington route -- considering that it isn't connected to many cities on the west side, there is a significant amount of demand.  Even though relatively few passengers (and mail) want a cross-map route, with the sheer amount of population we'll have by 1830, there will be sufficient.

Yeah that was what my gut was telling me, but without building a lot of feeder infrastructure to test it offline, I was having trouble proving it in advance! Hadn't realised you were doing it already by sea!!