Passenger Destinations

[eis_os]

As I said earlier, I don't think currently any Patchdev is very interested in it (could be wrong however). Other stuff are planed for the next alpha phase which will need a lot work A* is already on my todo list for better train/road pathfinding since ages... (doing it right however is not easy) (and it will be in 100% assembler)

[wallyweb]

As I said earlier, I don't think currently any Patchdev is very interested in it (could be wrong however). Other stuff are planed for the next alpha phase which will need a lot work A* is already on my todo list for better train/road pathfinding since ages... (doing it right however is not easy) (and it will be in 100% assembler)

Your work is always good and well worth waiting for.
Meanwhile, the passenger to long distance passenger conversion can still be implemented as an ECS type vector. That would just leave the distance thing to be done at a later time when dev time is available.

[Dave]

Remember that the reason most companies stop their trains at the "smaller" stations (rather than just the terminii) is because they would be putting their longest trains on services that may not be well used. For example they could have a 10-car Pendolino for Euston to Glasgow, but I won't be able to use that - and many others won't - so it'll be empty, thus making a loss.

This is why putting it into TTD would completely alter the passenger system, I think.

[SpComb]

I think the best way to implement such a thing is to look to how internet routers handle packages using link-state routing protocols. Which provide shortest path first methodes(based on Dijkstra's algorithm) and take bandwith in line aswell. Like EIGRP perhaps.

Al stations would then be a router, trains and busses would be the transfer medium (like a modem or t1 line) and passengers would be packets.

EIGRP keeps a database of the complete network to choose which route is the best way to go based upon the availeble bandwith. This way when the shortest path bus line is already filled up, they would take another line which would take them there faster.

In a situaton where I got 3 stations: A, B and C.
2 Lines: A-B-C, C-B-A and A-C, C-A

Code: Select all

A-B-C
\__/

If A-C busline is full it would probably be faster to take A-B-C instead of A-C even though this route has more stops underway.

Also EIGRP allows for a succesor, so if a line gets full it doesnt have to recalculate the whole table immidiately.

The EIGRP is probably more extensive but there's likely to be a Wiki entry about it.

I don't think that's the problem here. The issue is a bit deeper.

It's a nice analogy, but only works if you figure out how to implement a routing protocol in a network that uses packets that store no header data at all. So no source/destination address, just the data (how much of what cargo). Each node assumes that each packet is exactly, say, 2 bytes long, and the transfer medium reserved exactly 2 bytes for that data.

My analogy probably isn't perfect, but the idea is there. Each vehicle only stores what cargo it has, and how much of the given cargo. Then there are a million places that work on that structure, and to implement a new feature, you have to go find all those milliions of places and change each and every one.

That's what's holding up features in the patch. That's the reason OpenTTD exists...

[Caelan]

This feature is indeed already in simutrans and also in transport giant. It greatly enhances realism and makes the game all the more interesting.

There are literally thousands options to create such a scheme, but i consider a couple of variations:

-intra city transport (25% of population)

-local transport to the nearest towns (any population) within eg 20 tiles taking 25% of population divided over the towns/cities within the local zone

-regional transport to the nearest cities (eg 2500 and up) eg 50 tiles taking 25% of population divided over the amount of cities close by.
*note that a city can fall within a local zone effectively doubling the passengers traveling to that city

-intercity transport to the largest cities (eg from 7500 and up) on map (regardless of distance) taking 25% of popultion divided over the amount of large cities.
* note that a large city can fall within a local zone and region effectively doubling or tripling the passengers traveling to that city

It is in this system not needed to adjust any payrate system. It would be interesting to see if subsidies can be adjusted to cover the 'demand' of cities but in my opinion to have only the feature of passenger demanding to travel to various cities is a huge step forward!

[Villem]

Thats not true passenger destinations, thats just arrbitrary handing out a percent for who goes where. Thats almost as good as what we have now, anybody with big cities will make huge chunks of profit even after that kind of implementation for passenger destinations.

[Sorcerer]

I thought about the passengers destination algorithm below. Sorry for my english please.

1. Suppose that it is the time to create passengers in an "atomic" region A. Suppose that the region is a part of a town. Suppose that there are M stations cover the region (all the M stations listed in M_list);
2. Let N is total number of passengers that could run somewhere. N is _not_ number of passengers that will run;
3. Len L = N*80% is the number of passengers that could run to the local town, and R = N*20% is the number of passengers that could run to the other towns;
4. Suppose that we have prepared lists of passenger regions in each town. Let L_list is randomly generated list of regions in the local town where L passengers want to get to (with number of passengers on each region). Let R_list is randomly generated list of the other _towns_ where R passengers want to get to (with number of passengers on each town);
5. For each node in R_list let Re_list is randomly generated list of regions in the current town as it was made for L (in 4).

So, now we know where all the passengers want to get to.

6. Suppose that for each region we have prepared list of stations which cover the region;
7. Suppose that for each station we have prepared list (dictionary) of stations from those the station could be accessible via any kind of transport (assuming transport changes). Each node contains list of stations on the way and total cost for passenger;
8. For each region in L_list and Re_list we can quickly determine whether the region accessible from A (considering each station in M_list) or not. If the region is not accessible then delete it from L_list or Re_list (passengers will not run there);

For each region in L_list and Re_list:
9. Let Route_list is the list of different optimal (by money) routes from A to the region by each transport company;
10. Let Opt_money is the money passenger would pay if there is direct route from A to the region (without transport changes);
11. Using Transport company selection mechanism and the probability of selection richer then Opt_money routes (say, -Route_money / (2 * Opt_money) + 1.5) put the passengers on the selected stations.

There is a moment: cancelling transport routes. If a passenger has been already going to the destination, and there are no more routes to reach the destination region, then the transport company pays 3 times more money to the passenger than the passenger could pay to the thansport company. If there still is a route to the destination region, then the passenger will not pay the transport company more money than it was calculated in 9. But the passenger may pay less money if the new route is cheaper.

[Pookey]

For the percentage of people wanting to go to a town, it would be best to base it on game years, so in 1921, no passengers will want to go farther than the closest three to four towns to them. However, in 1940, for example, they may start to want to travel to towns halfway accross the map. In 1921 (in real life) no one wanted to travel further than close towns unless they had to or they were filthy rich. Back then, rail or car travel cost a fortune for the average family.

[athanasios]

...in 1921, no passengers will want to go farther than the closest three to four towns to them. However, in 1940, for example, they may start to want to travel to towns halfway accross the map. In 1921 (in real life) no one wanted to travel further than close towns unless they had to or they were filthy rich...

No passengers is not correct then. A small percentage would be more appropriate. And don't forget the immigrants who traveled by ship from Europe to USA.

By the way: Are still fish around the harbor? My father used to take me fishing next to the harbor bridge a few decades ago... (I don't stay in Australia now. Left in 1970!!!)

[Pookey]

No passengers is not correct then. A small percentage would be more appropriate. And don't forget the immigrants who traveled by ship from Europe to USA.

By the way: Are still fish around the harbor? My father used to take me fishing next to the harbor bridge a few decades ago... (I don't stay in Australia now. Left in 1970!!!)

A small percentage is right (OT)Fish are still in the harbour, however you can't eat them cause they have some toxin from homebush bay that causes cancer.(/OT)

[Caelan]

Am i correct in assuming that OTTD already works on such a feature? Perhaps we can learn from them?

[Redirect Left]

Am i correct in assuming that OTTD already works on such a feature? Perhaps we can learn from them?

As far as I know OTTD does not have this, only Simutrans (?) and Transport Giant.

[CMircea]

There's a user working on this for OTTD.

[Sleepie]

Here's the link to the thread in the OTTD development forum.

[Pookey]

So is this not possible in the Patch at the moment then?