The International Simutrans Forum

 

Author Topic: Prevent Interchange at Specific Stops  (Read 2652 times)

0 Members and 1 Guest are viewing this topic.

Offline fhaag

  • *
  • Posts: 7
  • Languages: EN, DE, ES, FR
Prevent Interchange at Specific Stops
« on: October 20, 2017, 09:13:05 PM »
I have been playing Simutrans for quite a while, although not with a focus on making in-game profit, but rather with a focus on fulfilling the transportation needs of a population and its industry in a realistic manner. This works well for the most part, but I keep running into an issue that I have recently asked about in the Simutrans Help Center forum.

In short, under certain circumstances, my high-capacity cargo transport channel is ignored by a given set of goods, while some tiny factory yard ends up getting used as a major transfer stop for these goods. As a result, the high-capacity cargo transport channel remains unused (or at least less used than it could), while the factory yard (which was never designed as an interchange hub, neither by its size, nor by its road connection, nor by the number and frequency of vehicles serving it) is hopelessly overcrowded in no time.

In terms of a somewhat realistic transport simulation, the situation feels to me as if said factory (let's call it A) allowed another factory (let's call it B) to store products on their cargo ramp. A helps to facilitate the delivery of goods by their direct competitor, B, to their common customer. For me, this kind of breaks immersion.

Therefore, I humbly suggest the following feature: Could stops have a flag (a checkbox in the options dialog box) to disallow transfers? A stop with that flag set could only emit or receive goods from directly connected buildings. The simple variant would be one such flag per stop, the luxury variant would be one such flag per stop per cargo type.

My (admittedly absolutely uneducated, in terms of the concrete implementation in Simutrans) idea about the ramifications of such a feature is as follows:

  • From a user interaction perspective, it should not be too difficult to use. In fact, I would argue it can make using the game easier, as it becomes easier to direct goods where you want them. Also, it is a direct way of controlling what happens, rather the indirect methods suggested to me in the other thread. For instance, while the same effect may be achievable by making vehicles stop several times on their way back, it is neither realistic for those vehicles to stop for no reason, nor does it feel like a "valid part" of network design - rather, it feels close to cheating by taking advantage of a specific implementation detail of the path finding cost calculation.
  • From a performance perspective, this should be a lot less critical than other suggestions I have read on the forum for improving the choice of routes. After all, there would be no need to determine a large additional number of routes that have to be compared by some newly considered factors. Instead, it is basically just an exclusion of certain stops as possible transfer stops when searching for a route, not unlike excluding stops as transfer stops if they are not designed to store a given type of goods at all (e.g. cargo at a passenger stop).
  • From a realism perspective, this seems valid. While customers will indeed choose the route (for themselves, or for their cargo) that is best for them among the choices offered, that does not necessarily imply a transfer at any given stop is offered in the first place. Likewise, your delivery vehicles could very well be ordered to only ever unload cargo at a given location if that cargo is going to be consumed right there.

Maybe this idea cannot be mplemented as (relatively) easily as I would hope, in case some complex look-behind/look-ahead would be needed for goods to "know" that a given stop during the route finding is directly linked to their origin/destination. And of course, maybe there are better, yet non-workaroundy ways to cope with the described issue. Nonetheless, I hope it is worthwhile to have this idea "on record" here in the forum, if only as a starting point for a later discussion.

Offline Leartin

  • Devotee
  • *
  • Posts: 1041
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Prevent Interchange at Specific Stops
« Reply #1 on: October 21, 2017, 07:40:57 AM »
A more immersed approach would be to allow trains to load and unload directly from and into an industries internal storage. This would mean you could build stops with 0 storage capacity. Add some "no routing over overcrowded" logic and you are pretty much set - stations without storage capacity could not be used as hubs.

This also get's rid of these annoying "overcrowded" messeges, because the producer pushes more in the station than the consumer actually needs, and if the goods stations have no capacity, hubs would actually need some storage buildings - a nice side effect.
« Last Edit: October 21, 2017, 07:53:19 AM by Leartin »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9185
  • Languages: De,EN,JP
Re: Prevent Interchange at Specific Stops
« Reply #2 on: October 21, 2017, 07:54:31 AM »
Disallowing transfers is not easily possible without a lot of changes (albeit doable). Much easier would be an unload and leave empty flag in a schedule. That would create one way connections, but that should not pose a big issue for programming. (I think this has done before as a patch, one of the many to be considered that had been lost with the old forum.)

Offline fhaag

  • *
  • Posts: 7
  • Languages: EN, DE, ES, FR
Re: Prevent Interchange at Specific Stops
« Reply #3 on: October 23, 2017, 10:50:36 PM »
Disallowing transfers is not easily possible without a lot of changes (albeit doable). Much easier would be an unload and leave empty flag in a schedule. That would create one way connections, but that should not pose a big issue for programming. (I think this has done before as a patch, one of the many to be considered that had been lost with the old forum.)
For simple cases, this would be a viable solution. It could disrupt some legitimate connections, though - think, for example, about a triangular course A - B - C, where A is a tree plantation, B is a sawmill, and C is a cargo hub. A wood transporter could be meant to bring lumber from A to B, planks from B to C, and return empty from C to A. With the unload and leave empty flag set on B, no planks could be transported.

Maybe the unload and leave empty flag could be complemented with an approach empty flag. In that case, a company at risk of being unintentionally misused as an interchange hub could be designed with two cargo stops, one for incoming goods and one for outgoing goods. Depending on how thoroughly goods "plan ahead" in Simutrans's routing logic, difficulty of implementing the approach empty option might, however, be asymmetrical to the unload and leave empty option.

A more immersed approach would be to allow trains to load and unload directly from and into an industries internal storage. This would mean you could build stops with 0 storage capacity. Add some "no routing over overcrowded" logic and you are pretty much set - stations without storage capacity could not be used as hubs.
From a user perspective, this sounds like a promising approach, as well; it would actually mitigate the aforementioned issue with triangular routes.

Offline Leartin

  • Devotee
  • *
  • Posts: 1041
  • PAK-DEV P192C
  • Languages: DE, EN
Re: Prevent Interchange at Specific Stops
« Reply #4 on: October 24, 2017, 06:15:19 AM »
Maybe the unload and leave empty flag could be complemented with an approach empty flag. In that case, a company at risk of being unintentionally misused as an interchange hub could be designed with two cargo stops, one for incoming goods and one for outgoing goods. Depending on how thoroughly goods "plan ahead" in Simutrans's routing logic, difficulty of implementing the approach empty option might, however, be asymmetrical to the unload and leave empty option.

The flag would be in the schedule. Hence "approach empty" would be the same as "unload and leave empty" flag the previous stop. Technically, "unload and leave empty" would not cause trains to get there with any kind of load and lose it*, rather, the connection between the stop where "unload and leave empty" and the next stop in the schedule would not be considered in routing at all. Normally, when we talk about an A-B Connection, we imply that there is also a B-A Connection on the way back. If you would go A-B(unload)-C-A, the routing would only see "C-A-B" but no connection B-C. If you split B, you can go A-B1(unload)-B2-C(unload). There won't be any lumber transferred from B1 to B2, so it can never be loaded at this station.

*except possibly for schedule changes in vehicles on the road.

Note that it is dependent on the schedule, so you still have to tell every vehicle, NOT the station. Hence a station where all wood-trucks need to unload and can't get anything from could still be used as a hub for coal if coal trucks don't have the same restriction.

Offline wlindley

  • Devotee
  • *
  • Posts: 938
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Prevent Interchange at Specific Stops
« Reply #5 on: October 24, 2017, 01:28:59 PM »
Suppose you have a schedule like:



What if we could add orders like this:




Where the skip and restart flags would be handled at the same code, after calling at each station, where the mirror happens now; and where "Leave empty" would be handled by the routing logic (effectively considering that as ending one schedule and beginning another).


Further, the "Mirror schedule" check-box could go at the bottom to indicate its function.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5275
  • Languages: EN, NO
Re: Prevent Interchange at Specific Stops
« Reply #6 on: October 24, 2017, 02:57:33 PM »
This is approaching the scriptable schedule I described years ago.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9185
  • Languages: De,EN,JP
Re: Prevent Interchange at Specific Stops
« Reply #7 on: October 25, 2017, 07:12:37 AM »
"Approach empty" is the same as setting "unload and leave empty" at the previous station.

Further things like jump schedule when the vehicle is empty, I would rather leave out of standard. I also doubt there wil be much use for such a feature, at least for freight. Jumping schedule when station is empty is quite unrealistic. The driver would need to go there to see it first ...

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2308
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Prevent Interchange at Specific Stops
« Reply #8 on: October 25, 2017, 03:28:18 PM »
"Approach empty" is the same as setting "unload and leave empty" at the previous station.

Further things like jump schedule when the vehicle is empty, I would rather leave out of standard. I also doubt there wil be much use for such a feature, at least for freight. Jumping schedule when station is empty is quite unrealistic. The driver would need to go there to see it first ...
Well I have often had a line where a train has loaded coal for two powerplants, dropping part of the load at one and continuing half-empty to the other. It would be very helpful to let the train return if all the cargo was for the first plant.




Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5275
  • Languages: EN, NO
Re: Prevent Interchange at Specific Stops
« Reply #9 on: October 25, 2017, 05:02:13 PM »
"Approach empty" is the same as setting "unload and leave empty" at the previous station.

But neither is really the same as the title of this topic. When there are many types of goods able to use the same vehicles, such as the different kinds of boxed goods in pak64, you may want the train to go to a station with goods x, but you do not want it to approach the station with goods y.

Offline wlindley

  • Devotee
  • *
  • Posts: 938
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: Prevent Interchange at Specific Stops
« Reply #10 on: October 25, 2017, 06:11:39 PM »
prissi -- Vladki is correct; my example would mean, skip the next station if the *train* is empty (which the engineer would know) not the station (which he generally could not).