News:

Want to praise Simutrans?
Your feedback is important for us ;D.

Question: Is waiting time used for cargo as well?

Started by Jando, December 09, 2013, 12:19:26 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Jando

I'm wondering whether waiting time is used for route finding for cargo as well. I wasn't sure thus I thought I'd ask.

It's about bulk freight in my case. I have a route that takes coal from station A to station B and is supposed to take clay on the way back. Now, the coal travels from A to B just fine but the clay doesn't. It travels from B to station C and then with another train from C to A. There are some crazy long waiting times involved, I've seen times of 28 hours, thus about 4 months and I wondered whether that might be the reason for the strange routing.

In any way, the coal takes the direct route, but the clay makes a detour on a longer route with switching trains instead of taking the direct train home. :)

Edit: Odd, it's now an hour later or so and the routing has reversed. It's now the coal that takes the detour and the clay takes the direct way. :)

jamespetts

All types of load take waiting time into account when determining routing; it is difficult for me to comment on this individual case without a saved game, but I hope that this explains things.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Thanks James.

I don't believe it's a bug, prolly just a result of the overcrowded freight stations that leads to very long waiting times. The cargo sees that there's a waiting time of 20+ hours and decides not to take the direct train. Thus the train that could reduce the waiting time travels empty. :)

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Please forgive me for posting another screenshot showing a consequence of this feature.



The line "Monkford Yard-Dock" takes bulk load from Monkford Dock to the steel mill at Monkford Yard and to a number of other destinations from there. For the last year the line carried almost 8.000 units per month between it's two stops (most of it from dock to yard).

Just now the game has instead decided to route the cargo via Oakthorne Bulk Dock (33 kms away from Monkford) and back from there to Monkford Yard, giving 10.000 - 15.000 units of coal and iron a scenic river journey around the map. As a consequence the schooners at Monkford Dock with destination Monkford Yard (where the cargo needs to go!) are empty doing nothing.

I'm aware that it's not a bug but a designed feature, however, that feature can have consequences that can complete wreck a network. I respectfully would like to ask you to reconsider: if there's cargo at A for B and vehicles for that type of cargo are at A going to B the cargo better get on board instead of embarking on a sightseeing trip.

Sorry for my ramblings. :)

jamespetts

Quote from: Jando on December 30, 2013, 02:26:58 PM
I'm aware that it's not a bug but a designed feature, however, that feature can have consequences that can complete wreck a network. I respectfully would like to ask you to reconsider: if there's cargo at A for B and vehicles for that type of cargo are at A going to B the cargo better get on board instead of embarking on a sightseeing trip.

The trouble is, there is not really a way of doing this that is feasible, not least because the game has no way of knowing whether a direct route is actually better or not. Suppose that you have, at A, a short but slow trip by sea to C, and then a fast but long trip by rail to B. Suppose further that there is also an excruciatingly slow trip by sea directly from A to B. If your suggestion was implemented, the cargo would always take the direct route even if it took ten times as long.

Similarly, suppose instead that there is a direct route from A to B by road, with a single horse and cart running at perhaps 1/100th of the capacity needed to keep up with demand. Suppose further that there is a canal between A and C and a coastal ship between C and B with plenty of capacity to take the cargo. Should the cargo nevertheless pile up waiting for the single horse and cart to take it, tiny bit by tiny bit on a grindingly slow journey directly to B? Even if the journey by road was actually faster, the cargo should still go via C in this case because there is insufficient capacity on the road route, whereas there is sufficient capacity by sea. The real issue is that there is no reasonable logic (that is, reasonably easy to implement which does not cause side effects and which does not put too much of a strain on the processor in very large games) that can detect the difference between the last situation that I describe and the situation that you encounter above. Routing is one of the most CPU-intensive parts of the game, so anything that makes this more complicated has the potential to make the game unplayably slow on large maps.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Quote from: jamespetts on December 30, 2013, 04:05:44 PM
The trouble is, there is not really a way of doing this that is feasible, not least because the game has no way of knowing whether a direct route is actually better or not. Suppose that you have, at A, a short but slow trip by sea to C, and then a fast but long trip by rail to B. Suppose further that there is also an excruciatingly slow trip by sea directly from A to B. If your suggestion was implemented, the cargo would always take the direct route even if it took ten times as long.

I would sign up for that in a heartbeat. :) Thanks for the answer, James, it's much appreciated. Personally I'd rather have a slow but predictable route than one that is unpredictable, especially when the game changes routes on the fly with the player not knowing about it.

Quote from: jamespetts on December 30, 2013, 04:05:44 PM
Similarly, suppose instead that there is a direct route from A to B by road, with a single horse and cart running at perhaps 1/100th of the capacity needed to keep up with demand. Suppose further that there is a canal between A and C and a coastal ship between C and B with plenty of capacity to take the cargo. Should the cargo nevertheless pile up waiting for the single horse and cart to take it, tiny bit by tiny bit on a grindingly slow journey directly to B? Even if the journey by road was actually faster, the cargo should still go via C in this case because there is insufficient capacity on the road route, whereas there is sufficient capacity by sea.

Well, isn't that what we have now as well? Capacity doesn't count, travel time counts, or rather what the game thinks the travel time is. In the above Monkford example the game changed from a high-capacity to a low-capacity route, likely not because of travelling time but because of waiting time. The travelling time on the new route is far longer (factor 10-20 I'd guess, involving another ship-to-ship transfer as well) than on the old route.

It's probably more an effect of waiting time anyway. When a few clippers (or even windjammers) unload their massive cargo at a port there will be waiting times before it's all transported. Can't have 20 trains waiting at all times to pick-up the load. :)

Quote from: jamespetts on December 30, 2013, 04:05:44 PM
The real issue is that there is no reasonable logic (that is, reasonably easy to implement which does not cause side effects and which does not put too much of a strain on the processor in very large games) that can detect the difference between the last situation that I describe and the situation that you encounter above. Routing is one of the most CPU-intensive parts of the game, so anything that makes this more complicated has the potential to make the game unplayably slow on large maps.

That I can understand. Sometimes I would want the game to make no route-finding at all but let the player decide on that. Just dreaming something up here: the game must have an internal representation of what route will be taken, any chance there could be an interface to let the player at least know about the routes, perhaps even change that?

At least a big fat message window telling the player that his routes have been recalculated and 10.000 units of cargo are now going back to where they just came from? :)

jamespetts

#7
Quote from: Jando on December 31, 2013, 12:41:28 AM
I would sign up for that in a heartbeat. :) Thanks for the answer, James, it's much appreciated. Personally I'd rather have a slow but predictable route than one that is unpredictable, especially when the game changes routes on the fly with the player not knowing about it.

The trouble is that this has to work with passengers as well as cargo and that this has to work with multiple players in competition with each other. The player cannot control the route that the goods take (whether indirectly by having it take the most direct route, whether fastest or not, or directly) aside from by providing the best service because anything else is irreconcilably incompatible with the notion of competition between players to provide the best service (where best is defined as the lowest overall journey time). As for passengers, it is realistic that their choice of routes should not be wholly predictable in any event, and certainly not something that could be player controlled.

QuoteWell, isn't that what we have now as well? Capacity doesn't count, travel time counts, or rather what the game thinks the travel time is. In the above Monkford example the game changed from a high-capacity to a low-capacity route, likely not because of travelling time but because of waiting time. The travelling time on the new route is far longer (factor 10-20 I'd guess, involving another ship-to-ship transfer as well) than on the old route.

Waiting time is determined by capacity: if the capacity is too low, waiting time will be high, whereas if the capacity is adequate, waiting time will be lower; this really is the only adequate way of measuring the capacity of a route and including the results in the route finding system.

QuoteIt's probably more an effect of waiting time anyway. When a few clippers (or even windjammers) unload their massive cargo at a port there will be waiting times before it's all transported. Can't have 20 trains waiting at all times to pick-up the load. :)

This is an interesting issue, but not one to which I can see a solution that does not cause more problems than it solves.

QuoteThat I can understand. Sometimes I would want the game to make no route-finding at all but let the player decide on that. Just dreaming something up here: the game must have an internal representation of what route will be taken, any chance there could be an interface to let the player at least know about the routes, perhaps even change that?

At least a big fat message window telling the player that his routes have been recalculated and 10.000 units of cargo are now going back to where they just came from? :)

The trouble with this is that there would in a large game be an extremely great number of these notifications very regularly in more complex networks. Goods, mail and passengers are being re-routed very frequently as travelling and waiting times change dynamically, and this is a necessary and inherent part of the routing system.

It is, however, possible to deduce from information available in the game what route that any load will take: it will always take the route with the lowest overall journey time (comprising a combination of travelling and waiting times, plus transfer times at interchanges and at the beginning and end of journeys). The travelling and waiting times to each directly served destination are all shown in the "details" window for each stop, as are the internal transfer times, and the transfer times at the beginning and end of the journey can be calculated by knowing the transfer speed (5km/h for passengers and mail, 1km/h for freight) and the distance (in tiles, multiplied by the number of meters per tile) from origin to departure station, and arrival station to destination. In simple cases (most bulk goods transport), the transfer times will not make any difference to the routing choices and will not need to be considered.

As to manual routing, see above: the representation of routing is not, incidentally, stored in a format that is easily representable. It is stored simply by each stop having a table of all destinations ultimately reachable from that stop, and the next transfer stop for which goods/mail/passengers of each type should head in order to reach there.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Jando

Thanks for the discussion, James. It is what it is then.

And a happy new year to you!

jamespetts

Likewise to you, too! Thank you for all the feedback - it is appreciated.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.