Cargo Distribution

[WWW]

WWW: can u pls update to new fish grf, i deleted my old ver trying to fix a seperate issue and cannot easily locate 0.6.1(its not on ingame content system or forum thread)

I'm updating my server now and changing some stuff.

EDIT: It's back up now.

[id10terror]

thanx, will check it out now.

[Eddi]

[*] Non-stop only orders really doesn't make sense to me... Is there really no way to get around this? You could, for example, only use stations in the orders list for generating the deterministic passengers and other stations the vehicle happens to stop at could add non-deterministic passengers...

yes, that's the main reason i would veto this patch for general inclusion. if i had a veto, that is. but your solution does not sound very useful.

[*] The buttons to select the cargo need to look more like buttons - try lifting the ones from the cargo income graph. Similarly the other graph display options don't really look like buttons.

they are the same as for the industry list in the minimap. if at all, it should be changed for trunk there, not as part of this patch.

[WWW]

I don't see why the patch can't just disregard the setting once the linkgraph is enabled, and force it to enable non-stop orders.

[fonso]

Those are some interesting observations. Thanks for the feedback.

[*] Non-stop only orders really doesn't make sense to me... Is there really no way to get around this? You could, for example, only use stations in the orders list for generating the deterministic passengers and other stations the vehicle happens to stop at could add non-deterministic passengers...

Any way around this either involves ridiculous amount of work or is incredibly fragile. For every scheme of finding the in-between stations of an order I could come with up so far, I could easily construct an example where it totally fails. So I'd say either we keep it as it, or we force all orders to be non-stop when cargodist is switched on, or we just disregard the nondeterminism and load passengers for the next stop in the order list. Those can all be done in a matter of minutes. I don't care about that as I don't think there's too many people using that "stopping" feature with cargodist anyway. I've kept the current behaviour as it enabless that trick of forcing a vehicle to load all available cargo by placing a stopping order after the one where it should load. But that's a hack anyway.

[*] The user interface (on the minimap) seems far too confusing, there is just too much information being shown. Before this patch is suitable for "general consumption" I think you seriously need to think about what information needs to be shown. I would say you need:
-- Link graphs for different cargos. Only one cargo should be shown at once to simplify the view.
-- Capacity of each link (C)
-- Usage of each link (U)
-- Spare capacity of each link (either C-U or C/U)
I would strongly suggest getting rid of the bar charts and numbers and replacing them with colour coding for the link. If you are happy to only display one cargo at once then at any time you would only be showing link capacity OR link usage OR spare capacity. These values could easily be mapped to a green to red scale... This may well also solve the requirement for the minimap zoom. In general I do find the minimap zoom useful though...

Well, the smallmap link stats display is a big fail. At the same time it has been the single greatest time sink of all the branches I'm maintaining. I guess I'll have to get myself to go back to the drawing board there ...

Other little bugs and comments:
[*] Calculation mouse position on the minimap for mouse-over information breaks if the title bar is not the default size (try this grf to see this bug http://www.tt-forums.net/viewtopic.php?f=26&t=50095 ). It looks like you are calculating the mouse position/link position from the top right corner of the window not the small map view itself.

Oops. Actually it didn't even work properly for the normal size. It's fixed now.

[*] The buttons to select the cargo need to look more like buttons - try lifting the ones from the cargo income graph. Similarly the other graph display options don't really look like buttons.

I'll go with Eddi here. As long as it's acceptable for the industry map it's also acceptable for the link stats map.

[gian]

Any way around this either involves ridiculous amount of work or is incredibly fragile. For every scheme of finding the in-between stations of an order I could come with up so far, I could easily construct an example where it totally fails. So I'd say either we keep it as it, or we force all orders to be non-stop when cargodist is switched on, or we just disregard the nondeterminism and load passengers for the next stop in the order list. Those can all be done in a matter of minutes. I don't care about that as I don't think there's too many people using that "stopping" feature with cargodist anyway. I've kept the current behaviour as it enabless that trick of forcing a vehicle to load all available cargo by placing a stopping order after the one where it should load. But that's a hack anyway.

A possible solution would be to replace the non-stop switch by a "Add intermediary stops" switch. This switch would cause OpenTTD to determine and add intermediary stops at the creation of the order, and only stop at those stations. This way, the orders would still be deterministic. I can't tell whether this would involve a ridiculous amount of work, however.

[Arie-]

WWW: can u pls update to new fish grf, i deleted my old ver trying to fix a seperate issue and cannot easily locate 0.6.1(its not on ingame content system or forum thread)

I'm updating my server now and changing some stuff.

EDIT: It's back up now.

Hey, nice, I'm playing there now for half an hour, just to relax some. How often do you update binaries? I don't expect the server to be very busy often, so is it continuous playing for like a week then stop the map, update binary and start again?

[Vitus]

A possible solution would be to replace the non-stop switch by a "Add intermediary stops" switch. This switch would cause OpenTTD to determine and add intermediary stops at the creation of the order, and only stop at those stations. This way, the orders would still be deterministic. I can't tell whether this would involve a ridiculous amount of work, however.

This wouldn't work, because the route is never fully deterministic. There are lots of other factors, which might make the path different (signals, station exits/entrances, other trains).

[WWW]

WWW: can u pls update to new fish grf, i deleted my old ver trying to fix a seperate issue and cannot easily locate 0.6.1(its not on ingame content system or forum thread)

I'm updating my server now and changing some stuff.

EDIT: It's back up now.

Hey, nice, I'm playing there now for half an hour, just to relax some. How often do you update binaries? I don't expect the server to be very busy often, so is it continuous playing for like a week then stop the map, update binary and start again?

I'll update whenever time allows, typically this will be on a weekend.

We'll say saturday midnight for a new game and new binaries.

[Arie-]

Well that seems OK, the game is running for a few days now (I think) and we're only hitting the 1980's just now.

[el koeno]

[*] The user interface (on the minimap) seems far too confusing, there is just too much information being shown. Before this patch is suitable for "general consumption" I think you seriously need to think about what information needs to be shown. I would say you need:
-- Link graphs for different cargos. Only one cargo should be shown at once to simplify the view.
-- Capacity of each link (C)
-- Usage of each link (U)
-- Spare capacity of each link (either C-U or C/U)
I would strongly suggest getting rid of the bar charts and numbers and replacing them with colour coding for the link. If you are happy to only display one cargo at once then at any time you would only be showing link capacity OR link usage OR spare capacity. These values could easily be mapped to a green to red scale... This may well also solve the requirement for the minimap zoom. In general I do find the minimap zoom useful though...

Well, the smallmap link stats display is a big fail. At the same time it has been the single greatest time sink of all the branches I'm maintaining. I guess I'll have to get myself to go back to the drawing board there ...

I think the main problem is that too much information is conveyed. All I want to know from looking at the minimap is where to install more capacity. I usually just look at the size of the red and white bars, but even though i've been using this patch for a while, I'm not entirely convinced that this is correct.

I guess the color coding might work: the redder a link is the more capacity is needed? Though is see some problems (e.g. color blind people) it would remove a lot of the clutter that keeps me from looking at it too often right now.

[gian]

A possible solution would be to replace the non-stop switch by a "Add intermediary stops" switch. This switch would cause OpenTTD to determine and add intermediary stops at the creation of the order, and only stop at those stations. This way, the orders would still be deterministic. I can't tell whether this would involve a ridiculous amount of work, however.

This wouldn't work, because the route is never fully deterministic. There are lots of other factors, which might make the path different (signals, station exits/entrances, other trains).

I don't see why it would not work. Of course it isn't fully deterministic, but that's off the point IMHO. The point is that you move the indeterminism to the point in time you create the order list at. At that time, it doesn't interfere with cargodist. If you weren't happy with the order list it creates for you, you could still specify some more (or even all) stations in between yourself and thus influence the route the train takes. Of course, it's not a perfect solution, but better than what we have now, which is basically only non-stop orders.

[fonso]

A possible solution would be to replace the non-stop switch by a "Add intermediary stops" switch. This switch would cause OpenTTD to determine and add intermediary stops at the creation of the order, and only stop at those stations. This way, the orders would still be deterministic. I can't tell whether this would involve a ridiculous amount of work, however.

This is a good idea, but it is out of scope for cargodist. It's basically a new "autofill" mode for the order list, like the one for the timetable. It should be done independently of cargodist and unfortunately it doesn't necessitate the removal of stopping orders. And if it was implemented and the devs accepted it, they probably wouldn't remove the stopping orders in turn - why should they? Another way to do something similar is "shadow autofill orders". The order list would be autofilled in the background but the result wouldn't be shown to the user. The vehicle would follow the now deterministic orders and it would seem to the user like a regular stopping order. However, that would break some funny hacks people have come up with. For example the openttdcoop "self-regulating networks" won't work anymore. So, I'm afraid but I think for the time being cargodist has to handle real stopping orders and as far as I know all funny hacks with stopping orders do work with the current behaviour. I could introduce a setting where you could tune the behaviour of cargodist in case of stopping orders, though.

[Raichase]

For someone who occasionally dabbles in OTTD, and is by no means an expert, does anyone know where there is a concise set of instructions for cargodist? I really enjoy playing it, but flicking through 97 pages seems a bit much, haha!

For example, I'm wondering which setting I need to alter to affect the balance of any raw cargo distribution. Ie, if I take cargo (say coal) from A-B, and at B (Power Station), there is another train waiting to take some coal to a steel mill at C. How does the game determine how much coal to send to B, and how much to C, and is there a way to change this?

I hope I'm making sense!

[fonso]

There is a description of the inner workings and settings for cargodist: http://wiki.openttd.org/Cargodist

Maybe that is a little technical and also the section about demands is lacking the aspect you're asking for ... Asymmetric demand (such as for coal, usually) is influenced by the distance between the producer and the consumer. You can fine-tune the influence of that distance with the patch setting of this name. If you set it to 0 the steel mill and the power plant will receive the same amount of cargo. The higher you set it the more coal the power plant will get and the less the steel mill will get (assuming that the steel mill is further away from the coal mine than the power plant).

[Raichase]

fonso, your description is exactly what I was looking for, thanks heaps mate. Thanks for the link too, I'll have a read

[Dwight_K._Schrute]

Hey,

first of all: I love this patch...

But I have some problems with my trains in bigger cities. If the train is not completely full it sometimes waits forever for new passengers who are coming bit by bit...(I don't have full load order and my platforms are long enough).

I play with timetables and some of my trains are always getting late because of this...

Concerning this issue trunk has been updated in the last weeks (r20506 and r20843)

But AFAIK your code is different in economy.cpp ?! So maybe you can find a solution for this (if I'm not the only one with this problem )

Currently, I have about 15.000 passengers in every station... so the trains are 100 % loaded anyway... but I used tp play with adjusted town cargo factor to have it more realistic and help those poor passengers

[jub]

Hi,

I have been also annoyed by this behaviour. I think it's the standard way OTTD handles small steady stream of incoming passangers (one, two at time). I would also love to know how to prevent this behaviour.

[Arie-]

Hmm concerning the passengers. I've been playing passengers lately, and indeed, stations get crowded with passengers very easy. Maybe an idea to have a more aggressive station rating method for passengers to reduce the numbers a bit.
@Jub Concerning the constant flow of passengers: Try grabbing a binary after the r20834, as (according to Dwight_K._Schrute) after those commits those issues should be solved. r20834 is a so called trunk release, not a 1.*.* branch, but a link can also be found in the top left corner of openttd.org

[fonso]

About the "passenger trickling": I have actually adapted the trunk method of avoiding this, but yesterday I found and fixed a flaw with my adaption. Can you tell me which version of cargodist you're playing and post a savegame demonstrating the behaviour?

About overcrowded stations: Are the stations overcrowded with transfer passengers or with local passengers? ext-rating should take care of that problem, but maybe there's a bug. Also ext-rating only works after some time as it reduces the production of passengers at the source station and doesn't directly get rid of the transferring passengers. Can I see a save game?