Passengers/Mail with Specific Destinations

[Villem]

I think the thing should extend only to Passengers, Mail, Valuables. Other services should be balanced by the player(that way player will still have some overall control in how to make his network so trains won't get stuck etc, and has control over flow of the materials and goods)

[Magic_Pixel]

In this context maybe goods should be added too.

(Although it could be acceptable that some processing industry owns a raw material facility and that facility only sells the cargo to the owner processing industry. For example a specific food processing plant could own/have an exclusive contract with one/several farms)

[lucaspiller]

That looks brilliant TolgaAbaci. Can we have a patch now to try it out? Please?

[Villem]

In this context maybe goods should be added too.

(Although it could be acceptable that some processing industry owns a raw material facility and that facility only sells the cargo to the owner processing industry. For example a specific food processing plant could own/have an exclusive contract with one/several farms)

Then people would have no control whatsoever where to take the goods.(i.e to the that need most, not just every city connected in the network that can take it). There are profits to be consindered..

[Magic_Pixel]

Yeah, true, but this is a transport management game and a transport company has to move according to the market demand. Or, if you control both the market and the transportation system there is no challenge involved. I don't think this game is mostly about huge profit numbers as it is about the challenge of achieving a nice transportation network across a country/map. That's why we're always using random maps, so we can face new challenges. Isn't this right? (Besides, one industry could own a supplier which at the other end of the map, and that involves both the challenge and the huge profits you were talking about)

Anyhow, this was just a suggestion to top up the current version as I would gladly accept even a rudimentary passenger destination approach (which luckily is not the case here)

[Magic_Pixel]

Also, NOT ALL industries would need to own a supplier. Just some (maybe only a small percentage: 30-40% or less (custom?)), as in real life.

[Celestar]

What about transferring passengers?

Example:

A ==== B ==== (C,D,E,F)

A is a bus station, B is an airport in the same city, and C-F are airports in distant cities. So if there is a bus going from A to B with to drop off passengers, they'd like to go to C-F.

Celestar

[Darkvater]

I have split this topic, continue the idiocy here: http://www.tt-forums.net/viewtopic.php?t=9252

[TolgaAbaci]

What about transferring passengers?

Example:

A ==== B ==== (C,D,E,F)

A is a bus station, B is an airport in the same city, and C-F are airports in distant cities. So if there is a bus going from A to B with to drop off passengers, they'd like to go to C-F.

Celestar

What I've implemented yesterday should work in this scenario. In fact, this is the point of the second screenshot I've posted. You can simply replace the second bus with an airplane, there is no difference.

As soon as I can hack something to enable saving, I'll post a first patch/binary for testing, then you'll be able to see it for yourself. I hoped I could do it earlier, but time constraints...

[TolgaAbaci]

As long as it can completely be disabled by a switch, and I mean COMPLETELY, I have no problems of adding this to the code.

This is something we'll have to test. So far, I have taken quite a bit of care to keep the original behaviour of the game if the switch is off.

[Celestar]

I'd be very nice if the transfer stuff works as well. I've done quite some work on transferring cargo/passengers (currently trying to find out how to balance the profit), so I could be of some assistance if you wish. Contact me with the IMs or find me in the chat room if you wish to

Celestar

[dominik81]

@TolgaAbaci: I have a couple of questions regarding your current implementation. How do you handle a setup like this, where some passengers from B want to go to A and some want to go to C?

Code: Select all

             TrainX                         TrainY
Town A <----------------> Town B <-------------------------->Town C

TrainX should only pick up the correct passengers, does it check its schedule when it tries to pick up passengers?

And how will the station GUI handle different passengers? Will you have an extra window that displays the destinations? Because it already gets crowded when many different cargo types are at a station.

[TolgaAbaci]

TrainX should only pick up the correct passengers, does it check its schedule when it tries to pick up passengers?

Yes. It works like this: We keep a graph of all available passenger routes, constructed from orders of vehicles with passenger carrying capability. This graph is used to query the shortest paths (currently paths with smallest number of stops) from one station to all others, by using Dijkstra's shortest path algorithm (basic computer science stuff). This is very fast.

Once a vehicle arrives at a station, we find the shortest paths to all possible destinations. Then, for each possible destination, we check whether this train goes in the same direction (same next stop) as the shortest-path. If so, passengers board it. We do the same for the passengers already on board, to decide whether they should get off, or stay on the vehicle.

Right now I still have one more bug in the graph-generation from vehicle orders, seems I am not handling one case properly, but it should not be too difficult to fix. Tomorrow evening...

And how will the station GUI handle different passengers? Will you have an extra window that displays the destinations? Because it already gets crowded when many different cargo types are at a station.

Good question/point. So far I have not worked so much on the GUIs, very basic stuff as you have seen from the screenshots. Once I manage to get the groundwork done, I'd like to have a look at this issue. I am open to any suggestions on this issue.

And another update: It looks like I'll be able to get the save functionality done, after some more inspection of the saving mechanism.

-Tolga

[ChrisCF]

And another update: It looks like I'll be able to get the save functionality done, after some more inspection of the saving mechanism.

You're very brave to do this

Nice to see that this feature is coming along.

[Magic_Pixel]

[Yes. It works like this: We keep a graph of all available passenger routes, constructed from orders of vehicles with passenger carrying capability. This graph is used to query the shortest paths (currently paths with smallest number of stops)

Situation:

route 1
A<--->B<--->C
\___________/
route 2

So this means that if we have a straight route with 3 towns and a curvy route only connecting A to C, the passengers going from A to C will choose route #2 even if technically it is not the shortest? If so, I assume the pathfinding algorithm within the game could be more useful. Or maybe something between your Djikstra and the one in the game (to calculate the fastest route (including times spent in stations - but I guess it is too complex to be done now. I CAN wait )

good luck and thanks for your work

[dominik81]

Once a vehicle arrives at a station, we find the shortest paths to all possible destinations. Then, for each possible destination, we check whether this train goes in the same direction (same next stop) as the shortest-path.

I'm sure this works pretty nice, but I'm not too sure if it is efficent enough. The Dijkstra algorithm has a theoretical running time of O(m + n), where n are the vertices and m as the edges. Implementing it with priority queues gives you O( (n+m) log n), a simpler implementation O(n^2). Even though n is fairly small here, this might still consume too many computations, because it requires O(n^2) each time a train arrives at a station.
Keep in mind that we try to still make it possible to run OpenTTD on low-CPU devices such as PDAs.

So far I have not worked so much on the GUIs, very basic stuff as you have seen from the screenshots.

I was just wondering if you had planned it already. GUI won't be a problem, but destinations would need a new one.

[NCarlson]

I think that it's time to admit that to implement everything that people want to will mean cpu requirement increases, and go ahead and let that happen. As for this, I don't really knwo how much of a hit this will cause but frankly if it's reasonable for the mojority of PC owners I don't think theres a reason to worry (for those working of PDA versions, the featurecan always be turned off).

[TolgaAbaci]

Implementing it with priority queues gives you O( (n+m) log n), a simpler implementation O(n^2).

The current implementation is the simpler, O(n^2) implementation. I am not sure if a priority queue implementation is worth the effort, since n is quite small here.

Even though n is fairly small here, this might still consume too many computations, because it requires O(n^2) each time a train arrives at a station.

Keep in mind that we try to still make it possible to run OpenTTD on low-CPU devices such as PDAs.

Yes, n is rather small for modern hardware, and furthermore the frequency of trains arriving at stations is relatively low (even when you have a lot of them).

I believe even PDAs should be able to handle this part of the solution. Even if it's a problem, this feature can be turned off, then the CPU usage will be the same as the original. So it will still be possible to run OTTD on any hardware it can run on today.

I am not sure if a more efficient solution exists for this problem. If you know about it, or if you have some other suggestion, I'd like to hear about it.

The bigger problem is probably within the MoveGoods function, whose load increases quite a bit for passenger-generating tiles if the switch is turned on. This function is called far more frequently, so this is a bigger problem. However, I have to point out that even the original implementation of this function seems very inefficient to me (it has to scan neighbouring tiles for nearby stations and so on).

[TolgaAbaci]

the pathfinding algorithm within the game could be more useful.

This would probably require far more CPU time than what I've implemented so far.

[TolgaAbaci]

the passengers going from A to C will choose route #2 even if technically it is not the shortest?

Only if there is a passenger train serving A-C, otherwise they'll take A-B-C. So, it's still somewhat manageable by the user.