Passenger Destinations

[Patchman]

Just implementing "long distance passengers" wouldn't be too hard. All it needs is a simple callback that determines the revenue at delivery, and sets it to return zero unless the passengers have been transported at least, say, 40 tiles.

[krtaylor]

Yes, but then if the train stopped along the way at an intermediate stop, they'd get off but not pay. It would have to make sure to keep them on the train until they'd travelled at least that far.

Was there a workaround for the max-cargos-per-building problem? I'd proposed a hack, where you'd set a new cargo as behaving "like" an existing cargo, but I don't know if that was accepted.

[Patchman]

My suggestion had nothing to do with passenger destinations, only implementing long distance passengers within the current framework.

The only thing this would break is the accounting of feeder services if the first leg is less than the minimum distance.

[krtaylor]

Right. What I'm saying is, it sounds like that in your scheme, if the train stopped at a station which accepted passengers, all the passengers would get off - but if some of them were long-distance passengers, and they hadn't gone 40 squares, they'd be off the train but NOT pay, because they hadn't gone far enough. There would have to be some way to keep them ON the train until they had gone enough distance. Otherwise it would be very frustrating.

[Patchman]

Actually, that might be good, in fact. Long-distance passengers would prefer express trains that don't stop at every tiny village anyway, so you should put long-distance coaches only on trains that do go the minimum distance between stops.

Local trains will continue to serve regular passengers, of course.

[krtaylor]

The more I think about it, the less I like this particular idea. I think it would be dreadfully awkward to make it work properly, because you would have to make sure every station is served by a long-distance train that never stops closer than 40 squares, or you lose all your money...

I think I prefer the idea of having long-distance passengers as a different cargo that is accepted (and produced?) only by big-city buildings, and is more time-sensitive than normal passengers.

Of course, passenger-destinations would be the ultimate goal, but that's far in the future.

[Patchman]

Since they would be a different cargo type (much like, or replacing, George's tourists), each train can decide which type of passengers it wants to pick up, so the problem you worry about does simply not exist.

[krtaylor]

Then either I don't understand something, or I'm not explaining something properly.

If long-distance passengers were generated and accepted just like normal passengers, with the one exception being that if they hadn't gone far enough, you don't get paid, then you have this problem:

Consider a line with four stations, each of which are 30 squares apart. Long-distance passengers cannot go from any of the stations to the next station on the line and "go far enough." But if they stay on the train one stop further, they're all set.

If the stations at each end were larger cities, then you could have a nonstop express going from one end to the other, and that's fine. But that way you aren't servicing the stations in the middle.

You could have a train hopscotch its way around, but that's weird.

Much better to simply have the long-distance people stay on board if they haven't gone far enough.

[DanMacK]

I actually like Josef's idea. I tend to run my passenger services with locals and expresses. You have 4 towns connected by a rail line as below

Code: Select all

A--------B----------C-----------D

and run your passenger trains as follows:

Express trains run nonstop A-D, locals stop at B and C. Expresses have the top-end locos, such as a Hudson or Northern, Pacifics and such handle the locals.

I don't see what's wrong with this scheme and would definitely use it. Passenger destinations are too difficult, but I can live with a differentiation between Express and local (Maybe for mail too?)

[krtaylor]

Yes, but in your example, what do you do with long-distance travellers from B and C?

[michael blunck]

> (Maybe for mail too?)

Nah. Not for mail.

regards
Michael

[DanMacK]

Yes, but in your example, what do you do with long-distance travellers from B and C?

Run a local from A-B-D and D-C-A

[krtaylor]

Then the long distance travellers between A and B (in the first train) and D and C (for the second) won't pay.

[DanMacK]

Run a terminating train between A-C and B-D? Geez, I dunno. It's much easier to implement this than passenger destinations. Hell, I'd use it.

[krtaylor]

It's much easier to implement this than passenger destinations.

No argument there! My question is just, does this make operations more realistic? And I think, probably not.

[OzTrans]

I can hardly keep up with reading ... but here are another 5 cents worth of ideas ...

... there could be "local passengers" and "express passengers"...

The idea is good, but because we can have only one 'cargo type' per vehicle (wagon/bus/aircraft) it would be difficult. On top of that, every express pax may need to take a local bus, the S-Bahn etc to get to the main station or airport, therefore we would need that pax class on local services as well.

Don't forget, our groups, the info for each group would contain when and where they board, or leave a service, their actual location. The train or bus need not know; the only thing they care is whether there is capacity available or not. The group will know the status; intention, waiting at station, being on a service; and once they have reached their final destination, this group has done its job and disappears. And, if the group is too large to fit on a service it would be split in 2: a) travels, b) waits for the next service.

I would like to call your 'express pax' 'long distance pax', and these would, when it comes to trains, buses and aircrafts travel as 'ordinary' passengers (no distinction); but the way they choose a service would be different. e.g. they would use a local bus to get to the mainstation, but then will only choose express services. If there aren't any, they would not travel at all, but make their intention known.

I do have an idea, that could work, it's just a matter of documenting it, but I haven't got much time ATM.

In DanMacK's example; it does of course depend how far B and C are apart from A and D. In a multi-leg-journey I see the first and last leg on local, short and stopping services quite acceptable for long distance travellers. If they are close, may be even backtracking would be acceptable.

Would a limitation be placed that people travelling within a city are local while leaving the city are express?

The city/town would state the intention what their inhabitants want to do, and it would be the town that makes those known. In the end, all travellers will be just passengers, but the way they choose where to go differentiates them. If some intend to travel to a nearby small town, they would be classed 'commuters'; but if they choose a distant small town, they would be classed 'long distance travellers', some of these will insist on direct services between major cities. I would define 'local' traffic as having start and end destination within the same town and it would also apply to get to the main station or an airport by long distance pax. If an appropriate service does not exist, they would not turn up for travel.

[NukeBuster]

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.

[SuperTycoon]

[OT]

Dijkstra's algorithm)

I had to do an exam on that rubbish the other day Some of the algorithms are useful, but so boring to learn. [/OT]

[krtaylor]

I would love to see this feature, but I wouldn't hold my breath. Unless you'd like to work on the Patching?

[wallyweb]

Typically a station in a larger community acts as a hub to gather passengers from smaller local satelite communities(suburbs?) (even if those communities are coincidentaly on a main line)
Then, at the larger community station, passengers from the local communities switch to an 'express' long distance train.
Conversely, long distance passengers connect to a local train for the return trip to the suburbs.

The implementation is simple:
1. Add a new cargo - long distance passengers where the cargo income rate actually increases up to a minimum distance (eg - 30 tiles) and then remains stable.
2. Add a new industry structure/building to be built near stations in larger communities. This structure could be a ticket agent or some such that would accept passengers to produce long distance passengers and vice versa.
3. This could be implemented for tourists as well and for airports too.