Cargo Distribution

[Dwight_K._Schrute]

In this example it makes really no sense. I just constructed a simple example to show that it is going wrong.

in my game it looks like this:

MacDonald & Co., 7th Sep 2176.png

(291.85 KiB) Downloaded 1 time

The IC train is arriving, unloading and then waiting at the side track so that it is not blocking the station for a long time. The city "Marktheidfelden" is still very small so it is not in the catchment area of the side-track-station. But maybe this will change someday...

[Zuu]

From what I can see, all it does is that it detects that there is a connection between your main station and your train yard station. It calculates the capacity of this connection, but the usage remains at zero.

[Dwight_K._Schrute]

From what I can see, all it does is that it detects that there is a connection between your main station and your train yard station. It calculates the capacity of this connection, but the usage remains at zero.

Yes! It remains zero, because no houses are in the catchment area of the train yard station.

That is why I constructed the example where are houses in the catchment area... and the usage is not zero anymore.

[Arie-]

Code: Select all

{network}>-A-B

So while it is impossible for passengers to get onto a train between A and B (B is a terminal station) in a network because of "unload and leave empty" and "no loading" orders, still a capacity for that link is calculated.

[fonso]

... unload and leave empty ... no loading ...

The behaviour you are seeing is expected. As stated on the Wiki page you shouldn't use any order modifications except for "full load" unless you know what you are doing. Cargodist can't see those order modifications. My general position on that is: Either let cargodist handle the distribution or do it yourself. You can't mix those. So, either push your side track far enough out of town, or make it a waypoint or provide a service from the terminal station to the side track. You can remove the "leave empty" clause and keep the "no loading". Then the side track will still not generate any passengers. This in turn means that only very few passengers will be sent there (if pax distribution is symmetric). Think of those as the workers needed there.

[fonso]

... patch ...

thanks for the patch. I've had a look at it. It consists of several parts:

• You send all packets to "any station" to nirvana instead. Basically: no. There are a couple of very good reasons for having those around.
• A modification of the mcf solver which prevents it from assigning additional flow to certain links. It's actually a good idea to stop generating additional flow when all links are saturated. Basically we can drop the second pass of the MCF solver. It doesn't change the ratios of flows to each other in a meaningful way. This in turn means it doesn't have any meaningful effect on the actual routing. Thanks for pointing that out. I must have been drunk when writing the MCF code. Somehow I had the idea that all demand must be assigned at any cost. Btw, your change around mcf.cpp:380 disables the second pass in a crude way. You probably didn't notice, though.
  Edit: The point about the second pass was that the nodes are processed in a certain order and thus for links with very low capacity some flow may be inherently preferred if you don't assign all demand. Flow from node 1 could fully saturate a certain link leaving no capacity for other nodes which might want to use the same link. This means cargo from the other nodes will have to take detours or cannot be routed at all. This can be interpreted as the problem of choosing the right accuracy, though. I guess I'll just remove the second pass and see if anyone complains ...
• A change to the cargo generation code which prevents it from generating cargo under certain conditions. This should be done either by lowering the rating more aggressively if too much cargo is around or by generating even less cargo for low ratings. In any case it's not a part of cargodist and should be done in a separate patch.

Another hint: Special cases for certain cargos (passengers and mail in your example) won't be accepted. With newgrfs there may be other cargos with the same properties as those. My solution to that problem is the symmetricity of distribution. Symmetric distribution roughly means "like passengers and mail" and asymmetric distribution means "like other cargos".

[Eddi]

tricky brain twister: there could be a "bipartite" distribution, so tourists can go from cities to tourist centers, and from tourist centers to cities.

and i'm of the opinion that "force unload" and "no loading" behaviour should be fixed. cargodest did handle these cases correctly. also, there should be a "no unloading and no loading" option for waypoint-like behaviour but with timetabling.

[7even]

Hello again,

I just want to tell you that the patches EZ and CargoDist are compatible.

Based on trunk revision 20868 I applied the patches "CD r20868" and "EZ r20861" into separate branches and merged them afterwards back to my trunk.

Anyone that wants to play with EZ and CD can checkout the already patched source files from svn://server7even.homeip.net/openttd/trunk - you just have to "./configure" and "make" afterwards...

Currently my trunk is on revision 46 but I will do some experimenting with other patches as well, so when in doubt checkout revision 46 explicitely. I have copied this revision to svn://server7even.homeip.net/openttd/tags/x001 also, but since this tag is untested I cannot guarantee that it will work (but it should).

[Zuu]

IIRC there was a call for help with interesting scenarios for a test game. Well, I've made a scenario called "Communication" which might be interesting for that purpose. Due to not having much left on my monthly data limit, I had didn't update my grfs before making the scenario so if there is a few weeks newer version of some of the NewGRFs, I apologize for that.

[fonso]

Nice map, I like it. Thanks. Now we need enough people, a date to start the game and some rules.

About the order modifications: I can probably support the order modifications with a deterministic outcome. For example "unload all and leave empty" has the outcome of the vehicle being empty. It's clear that no cargo can travel on the following link. However "no loading" without "unload all" means that cargo from other stations can pass the current station and can be unloaded there, but cargo sitting there can't be loaded. Supporting things like that would break the current model of the link graph. We'd need a multigraph or something similar which in turn would have a huge impact on the MCF solver. So I cannot support all combinations. I can maybe fall back to non-cargodist loading for all those, like with stopping or conditional orders, but you don't seem to like that behaviour, either.

[Dwight_K._Schrute]

no overload-patch

Just tried this patch in a small game (unfortunately it was not compatible to my old savegame) and I like it a lot... Much better than the town-cargo-factor-approach

order modifications

If it is too complicated just leave it as it is. I think it's no big deal. Most important thing for me is, that no passengers are created in the "waiting-station". If some "workers" want to there... so be it

[supermop]

The Unload and leave Empty order is one that I would really like to use, the other non-supported orders are not ones I commonly find myself wanting.

Best,

[fonso]

some changes:

1. all sorts of "leave empty" orders, optionally with subsequent "no loading" orders, are supported now. No links will be created between those. Also "go via" doesn't show up in the link graph anymore even if the next order is a stopping one.

2. The second pass of the MCF solver has been restored. This is mainly so that you can see where the problems in your network are. The overloading of links is more intelligent now. It overloads by ratio of load to capacity instead of by difference between those. Links with more capacity get overloaded more than links with less capacity. It seems like this leads to fewer bottlenecks as the cargo is distributed more evenly. It probably doesn't lead to less overall cargo piling up. Now you clearly see that you have the option of upgrading your backbone to resolve the situation as the MCF solver will rebalance the network in whatever way it can. Before it did that too but sometimes it might have seemed that it liked some specific and very narrow links most.

[Kogut]

* It may be good to explain in Big Red Box that playing with non-stop orders by default is good idea and add ", because cargo routing requires non-stop orders".
* Maybe replace ling graph by cargo routing in advanced settings etc?

[MagicBuzz]

IMHO, the warning message at the begining about non-stop order should be removed for another feature.

With default settings, error message are just displayed for 5 seconds. For most people this is too short to 1/ understand the message 2/ memorize the affected parameter 3/ understand what they must do with the parameter. At my first attempt, I needed to load 5 or 6 times OTTD to understand which setting was producing the message, and what to do. I think several people got the same problem.

For those reasons, I suggest when you switch on the cargodest feature, the patch automatically switch on the non-stop order feature, and vice-versa.
At this time, you may display a message "to avoid compatibility problems, the non-stop paramater was switched on" (and when switch off the non-stop order, a message "to avoir compatibility problems, the cargodest parameter was switched off").

When loading config file or savegame, you may do this check and switch off cargodest if non-stop order if off, as non-stop order is an older feature already in trunk.

I'm sure it would be very much clear than the current message.

[7even]

I aggree to that, it took me the same time and restarts to figure out what this message means and then where this parameter is located in advanced settings..

[Eddi]

May i also suggest an addendum to the "check schedules" feature, that warns you when a vehicle with "managed" cargos has non-non-stop orders?

[Kogut]

May i also suggest an addendum to the "check schedules" feature, that warns you when a vehicle with "managed" cargos has non-non-stop orders?

Only if it will be possible to disable it. Sometimes I deliberately leave no non-stop orders.

[Kimby]

I'm hoping this is the right place to point out a bug in Cargodist. If I should go elsewhere with it, please point me to the correct forum/whatever.

The problem happened for me in ge85d6871 (28/10/2010) and stayed when I upgraded to g7e9b5cdd (01/11/2010). More recent versions broke my savegame. I'm using the precompiled Win32 files from http://bundles.openttdcoop.org/cargodist/

I've noticed the problem with pax+mail planes since that's what I was mainly using in my game. If anyone is actually going to look into it, I'm available to check out a few more things like figuring out if it happens with other vehicles too. The situation was not limited to a single spot in the game but seemed to happen everywhere I had this kind of setup.

Basic situation: 3 airports A, B and C. Planes are going between A and B and between B and C.

In airport B, there's a plane headed for A busy with a full load any order. No cargo pax or mail to A is present in the airport B, but here's some going to airport C. A second plane with destination A lands, unloads and then loads the cargo meant for destination C (which is actually also accepted in A).

Since the plane loads cargo for C while it's never going there (it's simply going back to A) I consider this a bug. At first I thought this was caused by there being a route available from A to C, but I've seen it happen also with a case where A didn't have any other connections then back to B.

Reasons this is a bug for me:
1) you get money from transporting cargo to a place it's not meant to go
2) the cargo is loaded on a plane going to a destination for which there's already a plane busy loading

Point 2 is very bad for me, since my 2 planes have (shared) orders like this:
1. Go to Airport B
2. If load percentage is below 20, jump to step 5
3. Go to hanger Airport B
4. Go to Airport B, Full load any cargo, no unloading
5. Go to Airport A

This should cause only 1 plane to remain at B to full load cargo, while the other makes sure the amount of cargo headed from A to B is still being served. However, due to the bug, my second plane now often gets above 20% from cargo actually headed to C and starts waiting for a full load too!

If so desired, I can supply a savegame, but it'll work with only the versions I mentioned above and also has quite a few newgrf's it's using.

[Kogut]

Is it still happening without conditional orders?