Cargo Distribution

[keoz]

The issue with conditional orders is fixed now. I was comparing orders, not their destination stations for equality to find out about determinism. So if you had several orders for the same station it didn't work.

Thank you.

I've thought to another question. This is not a bug but a suggestion (maybee this has been discussed also ?). What do you think about the possibility of taking in count special orders like "no loading", "transfer" and so on, when determining the links ?

I thought about this because I've been confronted to an unexpected behaviour. Let me show it with an example: I have tree station. At station A, I have a brewery, producing goods, which are sent to station B. At station C, I have a sawmill, also producing goods, and those are also sent to station B. Until here, all is fine. But the brewery and the sawmill are near to a city. So, when those two citites expanded, the stations which were sending goods (A and C), started accepting goods themselves. The result is that, the goods of A are sent to B, but a part is resent to C (from B), because the train between B and C established a link coming back to the sawmill.

This is normal in regard to the mechanism of cargodist, but I think it could be interesting if we could have more control about that kind of question. I thought to several possible solutions.
1) Having the possibility to better define which cargos are accepted in a station. Let's say I have an industrial station near to a city, and some setting in the station gives the possibility to block passenger, mail, goods acceptance for this station. That's not unrealistic. But I know that this suggestion falls partially out of the domain of cargodist.
2) Another possibility to better check the game-behaviour would be that cargodist considers "no loading orders" in determining the capacity of a link and hence, the links themselves. When it finds a "no loading" order, it assumes it and don't consider this link/capacity as available. That would mean, add some complexity to the code which "builts" the existing and available links, but it would mean also giving a far better control to the player. In the previous example, I could put "no loading orders" for the trains coming back, from B to A, and from B to C, and avoid the goods dispatching.

What do you think about that ?

[Eddi]

2) Another possibility to better check the game-behaviour would be that cargodist considers "no loading orders" in determining the capacity of a link and hence, the links themselves.

it should already do that.

[keoz]

2) Another possibility to better check the game-behaviour would be that cargodist considers "no loading orders" in determining the capacity of a link and hence, the links themselves.

it should already do that.

Mmmhhh.

Not according with the wiki, which states that:

Order modifications such as "no unloading", "unload all", "transfer", "no loading", etc generally do what they are supposed to when using cargo distribution. However, as the link graph doesn't know about orders it assumes it can use any link with a capacity. It will thus also plan cargo to be sent with those vehicles that decline loading cargo.

If this statement is still right, it'd mean that even if my train (B->A) coming back doesn't load goods, goods are planned to be sent with, and then, transferred at station B, when coming from C, not just delivered.

But maybee that have been changed since ? I'll check.

[fonso]

The problem is that you don't know where the currently loaded cargo has come from when it arrives at some station. So you don't know which order you have to check for modifications. Example:

1. Train loads goods at A and goes to B.
2. Order for B says "no loading", but allows unloading. Train doesn't have anything to unload at B, so it goes on to C.
3. Train unloads goods at C.

In this case the "no loading" order for B doesn't tell us you can't use the B->C link for goods. It just says you cannot use it for goods that are currently waiting at B. Goods from A are perfectly fine if they are already aboard. Getting things like that into the link graph opens a whole new can of worms. You need a multigraph for that and then the MCF solver gets much more complicated.

Now consider another train going A->B->D. You can't have that train load the goods from A to C as they'll be stuck at B. Even though the orders for B may be completely equal. So you also need a pretty complicated lookahead for future orders to get the loading right.

In short: I won't do that. It's overly complicated. Either you trust cargodist to do the distribution for you or you have to do it manually. If you want it both ways you need to know very well what you are doing. And I don't see anything wrong with the behaviour you're describing. Why not just let the trains carry those goods?

[erikvanvelzen]

yes, "supply scaling" has been replaced by "external station ratings". The Wiki was outdated.

So, as it stands now, a station won't generate more cargo if you connect more places to it?

[fonso]

So, as it stands now, a station won't generate more cargo if you connect more places to it?

No, it won't. It's too complicated to measure "more places" and to find a clean way to reduce cargo generation for less connections without having industries closing down all the time.

[keoz]

In short: I won't do that. It's overly complicated.

Ok, I see the point.

And I don't see anything wrong with the behaviour you're describing. Why not just let the trains carry those goods?

Actually, there is nothing technically wrong. It perfectly works as it is designed to. In my specific case, the question is that stations A and C are really close, so a part of goods was resent with a little income. But that is not the main point.
More generally, the question is about how we build our networks. Until now, I builded passenger/mail networks on the basis of cargodist dispatching, since that implies to completely re-think our way to build links, connections, networks. I haven't really do that with industrial cargos. Sending mostly my trains from a station A to an only other station B, hence, without the possibility of dispatching. The result is that industrial trains have (in my games) a behaviour more similar to traditional gameplay, unless some conditions, like the ones which I described over, are present.

So, my idea was to find a way to have a better control over possible/non possible routes, even if working globally inside the frame of cargodisted dispatching. Maybee an interesting and simpler solution could be my idea 1: blocking some cargos acceptance for some stations.

[fonso]

I haven't really do that with industrial cargos. Sending mostly my trains from a station A to an only other station B, hence, without the possibility of dispatching. The result is that industrial trains have (in my games) a behaviour more similar to traditional gameplay, unless some conditions, like the ones which I described over, are present.

If you send all your goods to one station, ie distribute them manually, what do you need cargodist for? Just switch the distribution type to "manual" for those goods. You can also do tricks like removing non-stop from some order to force a train to load everything at the previous order if you want different behaviours for one cargo in different places.

[keoz]

If you send all your goods to one station, ie distribute them manually, what do you need cargodist for? Just switch the distribution type to "manual" for those goods.

Hell, my bad. I didn't see that it was possible, I was sure the choice was only between symetric/asymetric ...

[Creat]

The problem is that you don't know where the currently loaded cargo has come from when it arrives at some station.

Actually that poses a Question... Let's assume the same scenario as above, A and C generate goods, and all three stations accept them. Could it happen, that cargo from A ist transported to B (via train going A->B->C) and returned to A (via train C->B->A)? That wouldn't be good
I always assumed that this wouldn't happen, as those goods would probably only generate negative income (no revenue as the distance ist 0, but it took time to get there)?

[keoz]

The problem is that you don't know where the currently loaded cargo has come from when it arrives at some station.

Actually that poses a Question... Let's assume the same scenario as above, A and C generate goods, and all three stations accept them. Could it happen, that cargo from A ist transported to B (via train going A->B->C) and returned to A (via train C->B->A)? That wouldn't be good
I always assumed that this wouldn't happen, as those goods would probably only generate negative income (no revenue as the distance ist 0, but it took time to get there)?

I don't remember from my above game, but I suppose no, since the passenger cargos are always in that situation but aren't sent back to their original city.

[keoz]

Hi,

I've found a strange behaviour, I suppose it is a bug.

The other day, I moved all cargo-class trains from asymetric to manual. But the dispatching didn't stop, and trains were still receiving destinations. As I could observe in a test game, when the "manual" mode is enabled, vehicles shouldn't receive destinations, but should be show "to any station" in red, in the station gui).

So, to change the behaviour, I had to stop all the trains until the links in the linkgraph disappeared. Only after that, I could relaunch my trains, and the manual management could be effective for cargo-class trains.

Here a savegame where I've seen that behaviour:

SwissTrans, 18_06_1949.sav

(351.27 KiB) Downloaded 91 times

Note: I think I'm probably not running the last revision, but one downloaded about two weeks ago (g0e2b4fba), because I want continue on the same game. So, I don't know if that has been solved since.

[AppeL]

First game I use cargodist in and there is a problem

I have a line with several stations. Since the line is quite long I have added a Depot in the middle (one for each direction).. I send the Trains there using a conditional order (if reliability is more than 70 carry on to next station) (see first screen)
Now at the last station before the Depot the trains completely unload all cargo and load new cargo only from that station.. Then they carry on (or go into Depot for Service - the above behaviour does not depend on if a train actually goes for Service) like normal.. Same for the other direction

Southeastern Train, 29th Oct 1952#2.JPG

screen 1

(331.3 KiB) Downloaded 1 time

The same happens at a Depot at the end of the the line (see 2nd screen).. Trains coming from Broadstairs completely unload at Broadstairs and then load new passengers from Broadstairs.. Then they go to Ramsgate (or go to service before - again, it does not matter if they actually go for Service, they still unload at Broadstairs)

Southeastern Train, 29th Oct 1952#3.JPG

screen 2

(324.05 KiB) Downloaded 1 time

Also it does not matter if I put "nearest Depot" instead of the actual Depot place or if I put "Service" etc. If I remove the condition and always send trains into the Depot the full unload still occurs. Only if i remove the "go to Depot" order, trains behave properly, only unloading passengers for that station..

the savegame is too big to upload or something.. tell me if u need it. I use cargodist g17340e3e

[Creat]

This is the same problem that was reported by keoz just one page back. I can't tell by looking at the version string from what date the version is, but since fonso said he fixed it, I assume it's older than about a week (or he missed something, if it's newer). Anyway, he'll know from when that version is and if it should be fixed in it...

In the meantime: You do know that the game has a built-in mechanism to do exactly what you're doing, just without having to use conditional orders? You can use a "Maintenance" order (either by selecting maintain in the dropdown menu in the lower right for any depot order, or by holding Ctrl when clicking (with 'go to' active) on a depot to create it directly like that). It only sends the train to the depot in case maintenance is actually needed. And have I mentioned the huge advantage over not having to use conditional orders?

[AppeL]

does not help.. train still completely unloads at the last station before the depot and only loads passengers from that station

[Creat]

does not help.. train still completely unloads at the last station before the depot and only loads passengers from that station

You did remove the conditional order though, right? If so, that's extremely strange, most likely a savegame would either solve the mystery or at least make it clearer (putting it in a .zip, .7z or .rar file doesn't make it small enough to post here?)...

To clear up, weather the conditional-order-fix is already in your build: did you build the game yourself? Or did you use a pre-built binary? If so, where did you get it or do you know the time/date it was build? you can also check the "modified" date of the executable, if you don't know, it should be the build time and date...

[AppeL]

well, now it works, i had to let the trains run for some time until they behaved properly

[fonso]

AppeL: I'd still like to get a savegame of your problem. The behaviour is indeed very strange and I suspect a bug. And what version are you playing? You can see the version string in the title of the main menu.

keoz: The behaviour your describing is quite an obvious flaw. When you set the distribution type to "manual" the planned flows won't be updated anymore - so they won't be removed either, except if their link disappears. I just didn't think of that situation when I wrote the code. I'll fix it.

[Creat]

AppeL mentioned his verstion at the end of his first post:

I use cargodist g17340e3e

[fonso]

OK, I see. The problem with AppeL's first screenshot is rather obvious: The depot order isn't nonstop, so the condition is indeed nondeterministic. The expected behaviour for this is "like without cargodist": unload everything, load everything. I don't know what's wrong in the second screenshot. However, order 1 is invisible there so I don't know what it does. If order 1 is nondeterministic the condition at order 29 is nondeterministic, too.