Cargo Distribution

[audigex]

Kogut - to refer you quickly to the below:

If you don't mind taking a few moments to explain, I'd be interested to know whether the choice of destination is more (and if so, how much more) intelligent than cargodest was. Is it based on the size of town only, or does it base it at all on the used versus potential capacity of the link?

There are three stages in destination selection:

1. The demand function is calculated based on measured monthly supply at connected stations. Supply is the amount of cargo generated at a station by industries and houses. The calculation is done in a way that

• sets a destination for all supplied cargo
• corresponds to the symmetricity, distance and station size parameters. The station size parameter is really a gradual symmetricity parameter. The lower you set it the less demand is assigned from B to A for a given amount of demand from A to B.

2. The planned flows are calculated based on measured capacities of links between stations and the demands calculated before. The algorithm tries to push flow over the existing links in a way that

• satisfies all demands calculated in step 1
• balances routes. If you have two routes from A to B and the sum of their capacities is smaller than the demand from A to B, both will be equally overloaded. On the other hand, if the capacity is greater than the demand, the shorter one will be preferred. That preference can be customized with the "short path saturation" parameter.

3. The plan is enacted. Every cargo packet arriving or being generated at a station is sent over the link where (plan - sent) for that packet's source station is greatest. After each such sending operation the flow stats are updated and some other link may be the most undersupplied.

The algorithm doesn't know about towns or town sizes. It knows about stations and supply at those stations.

My own hope would be that the usage is based on the rating of the route, eg if it has a high capacity and high speed, people are more likely to use it - until the route is full, at which point the overcrowding makes people avoid it. The amount could then slowly increase to encourage the player to increase line capacity.

I don't measure speed. But mind that if you increase the speed of a vehicle the capacity of all links it serves increases as it can serve them more often. There is no "until the route is full". The plan is calculated in advance and in a way that doesn't unnecessarily over- or underload any links. Overcrowding happens if the sum of the capacities of all links to a given destination is lower than the demand for that destination. In that event the overcrowding happens roughly equally on all routes leading to that destination.

Obviously, this is very social rather than technical - so it's a pipe dream I think, but I'd be interested to know if it's based on anything other than the rating of the town and total number of destinations. As much for curiousity as anything else, I prefer cargodest to trunk (haven't played much cargodi yet, I love the ITiM patch too much) and it looks like cargodi is an improvement on that.

Town rating doesn't have anything to do with it and I don't know how it could. The total number of destinations will be factored into the supply. If fewer destinations are connected to a given station you will get less cargo being generated there in the first place. It will be configurable and you will be able to switch it off. Wait for 4. on the roadmap

Well, I said quickly - it's quite a long post - but basically they won't ignore the other route, they'll just only use it when the "1-hop" route is full.

Okay, it's not the fastest, but if you think about it, it's also best for a network. I'd rather my passengers jumped on a direct train until it's full, so they don't clog up the local service.

And remember, it's up to the transport company to build the links. Why would you build an intercity link which is worse than the local route? You may aswell just add capacity to the local route, and increase services to the intermediates.

[Kogut]

@ audigex - thanks

What exactly mean "short path saturation" setting?

[fonso]

What exactly mean "short path saturation" setting?

In stage 2 the demands are satisfied by push flow over paths. The algorithm first considers the shortest paths. The length of a path is the sum of the lengths of its links. In this phase the algorithm stops assigning flow to a path if its saturated to the percentage given in short_path_saturation. In the second phase of stage 2 it considers the paths with most capacity left (or least overload) first. It doesn't care about the length of the paths there.

This setting was added because there are cases where the capacity measurement is inaccurate. This is hard to prevent because a, capacities change all the time and b, the "frozen" states of capacities interfer with the measurement. If short_path_saturation was always 100% stage 2 would thus overload some shortest paths without knowing it because the capacity measured is higher than the actual capacity. Like it is now you can prevent that by making it switch to paths with lots of capacity left before that happens.

[keoz]

Hi,

first of all, thank you for this work. I am really interested about this patch, it makes the game really much more funny and interesting.

But i have a problem. Either there is a point I miss, either the patch isn't working properly by me (or i'm not using it properly).

I try to understand how does cargo pickup and unloading work. So, I have a station at a coal mine (station A), and a network going to two Power Plant, with two trains. One's going to the first Power plant (Station B) and another going to the second Power Plant (Station C). The station GUI at point A (the coal mine) works properly and indicates that a part of the coal has to go to the Power plant A, and that a part of the coal has to go to the Power Plant B.

But when a train arrives (say the one who makes the A-B route), it picks up all the present coal, and unloads it all in the station B. Shuldn't it load only the coal for the station B ?

Thank you

[fonso]

But when a train arrives (say the one who makes the A-B route), it picks up all the present coal, and unloads it all in the station B. Shuldn't it load only the coal for the station B ?

Maybe you're missing the non-stop flag? Otherwise, can we get a savegame? This is about the 121th iteration of this question ... Maybe I'll make that "non-stop by default" setting mandatory and make people specify automatic stopping for each single stop if they want it. Or I'll display a warning dialogue somewhere. This is getting boring.

[keoz]

Hi,

Thank for your reply.

But when a train arrives (say the one who makes the A-B route), it picks up all the present coal, and unloads it all in the station B. Shuldn't it load only the coal for the station B ?

Maybe you're missing the non-stop flag? Otherwise, can we get a savegame? This is about the 121th iteration of this question ... Maybe I'll make that "non-stop by default" setting mandatory and make people specify automatic stopping for each single stop if they want it. Or I'll display a warning dialogue somewhere. This is getting boring.

Yes, it was exactly the problem. I didn't know about the "non-stop" order. Sorry for having asked an already answered question but ... I found the answer just some minutes ago arriving at page 15 of this topic ... Was not so easy to find it.

May I suggest to split this topic into two differents (one about bugs, another about gameplay ?).

Regards

[keoz]

That makes me thing to another question.

Finally, that shows that in fact, there is not any practical reason to build a network in order to dispatch productions and cargos to different destinations (except building a nice network). I mean, even playing with cargodist, i can build an "oldstyle" network, without thinking to destinations dispatching, and that will not affect my game.

Is there not any element in your patch that forces or just rewards the effort to build a more balanced network ? For example, reducing payment for cargos that are delivered to a station which doesnt correspond to the intended destination ?

[Jans]

That makes me thing to another question.

Finally, that shows that in fact, there is not any practical reason to build a network in order to dispatch productions and cargos to different destinations (except building a nice network). I mean, even playing with cargodist, i can build an "oldstyle" network, without thinking to destinations dispatching, and that will not affect my game.

Is there not any element in your patch that forces or just rewards the effort to build a more balanced network ? For example, reducing payment for cargos that are delivered to a station which doesnt correspond to the intended destination ?

You will be paid for any Cargo wich is arriving the goal. The money you can earn depends on the time the cargo need to reach the final destination. So it is up to you to optimize your network!
And pleas check all options of the patch. Are there alredy destinations for all goods or only for passengers and mail?

[tsjook]

Keoz, one shouldn't compare the profitability of a certain linked network with cargodist to the profitability without cargodist. It's just a different way to play, a comparison would be pointless.

For me it's nice to be able to build realistic multi-stop (combined) tram, train and bus networks with many stops without all the passengers travelling just one stop. It's just more fun, differences in profitability just don't count.

[ostlandr]

Don't know- I snagged the latest binary.

Was tearing my hair out trying to patch before I found out that it doesn't work on my WinVista box.

Only "complaint" so far is LOTS of passengers. I need to go back and read this whole thread and the documentation to see if there is a fix for this. There also seems to be a LOT of mail generated relative to the number of passengers- I find myself having to add dedicated mail trains, tack a couple of mail cars onto my hotshot intermodals, etc.

Working fine with PBI so far- no issues detected.

Overall the effect is very realistic (sorry, Belugas.) Passengers want to go places, as does cargo. I can run freight trucks from the rail station (or intermodal yard, depending on how I built) and incoming trains will drop off cargo at the station which the trucks automatically haul where it has to go. I can run crack intermodal freights with strings of container cars (using NARS2) and the cargo is automatically loaded and unloaded at each stop- no elaborate transfer orders needed.

Haven't tested it in your patch yet, but the best feature of these was always Valuables. Run an armored truck in a loop from bank to airport, run some small cargo planes between cities with banks, and now the cash moves easily and automatically.

Playing CargoDist right now- and I like it!

That's great, there was A LOT of effort put into making it.

Also, how long does it usually take other people to download using git?e

[ostlandr]

In this patch, I find myself running unprofitable feeder services, but the overall network is profitable. Only if a truck/bus/rail route is seriously in the red do I think about killing it- and then I very realistically have to analyze its importance to the overall network, and what the consequences will be if I cancel this run.

Keoz, one shouldn't compare the profitability of a certain linked network with cargodist to the profitability without cargodist. It's just a different way to play, a comparison would be pointless.

For me it's nice to be able to build realistic multi-stop (combined) tram, train and bus networks with many stops without all the passengers travelling just one stop. It's just more fun, differences in profitability just don't count.

[petert]

@fonso, why is this diff completely empty? I'm trying to set up my own cargodist for trunk, but I can't.

[fonso]

@fonso, why is this diff completely empty? I'm trying to set up my own cargodist for trunk, but I can't.

You have to use this one: http://fickzoo.com/fonsinchen/patches/c ... odist.diff
The other one shows what the cargodist branch adds on top of station-gui and smallmap-stats. That's nothing as station-gui and smallmap-stats combined pull from all other branches.

Don't know- I snagged the latest binary.
Was tearing my hair out trying to patch before I found out that it doesn't work on my WinVista box.

What does that mean? Which binary is that and what happens if you try to run it?

[bokkie]

Only "complaint" so far is LOTS of passengers. I need to go back and read this whole thread and the documentation to see if there is a fix for this. There also seems to be a LOT of mail generated relative to the number of passengers- I find myself having to add dedicated mail trains, tack a couple of mail cars onto my hotshot intermodals, etc.

Try the .grf from http://www.tt-forums.net/viewtopic.php? ... 2&p=824738 bij id10terror (14th of october). Might help Haven't tried it myself yet. I'm curious whether mail generation is lowered as well in the grf, isn't mentioned so I guess not.

Fonso: congratz on having some patches included in trunk Must give some motivation to get Cargodist into trunk

[keoz]

Keoz, one shouldn't compare the profitability of a certain linked network with cargodist to the profitability without cargodist. It's just a different way to play, a comparison would be pointless.

For me it's nice to be able to build realistic multi-stop (combined) tram, train and bus networks with many stops without all the passengers travelling just one stop. It's just more fun, differences in profitability just don't count.

I'm not thinking just about profitability, but about gameplaying. I think that the cargodist patch-serie could be an excellent basis for some other improvements. Particularly, the problem of the incoherence resulting by the fact that actually, we can send a lot of cargos always to the same destination with not any limitation resulting by a realistic industry-demand. I can concentrate all the coal of a map to the same power plant, and always be payed the same. I think that it would be a great improvement to find a way to limiting cargo payment in order to force some dispatching.

I have to admit, that this idea goes beyond the scope of cargodist, and could (should ?) be implemented independently. Because anyway, the distribution algorithm of cargodist always just considers existing connections to calculate its transport-demand. But ... if some patch is created in order to limit payments for excessives unloading on a single place (based on some industry-demand algorithm), it could be interesting to link it to the "transport-demand" algorithm of cargodist, in order to make this last take in count the demand of an industry.

Just dreaming, i know.

Anyway, once more, thanks to fonso. It's really great.

[rbn2903]

Particularly, the problem of the incoherence resulting by the fact that actually, we can send a lot of cargos always to the same destination with not any limitation resulting by a realistic industry-demand.

Then why don't you use Industry-NewGRFs with stockpiling?

[Jans]

Particularly, the problem of the incoherence resulting by the fact that actually, we can send a lot of cargos always to the same destination with not any limitation resulting by a realistic industry-demand. I can concentrate all the coal of a map to the same power plant, and always be payed the same. I think that it would be a great improvement to find a way to limiting cargo payment in order to force some dispatching.

Try to use ECS Vectors. This is a Newgrf wich can help you to solve your problem.
Cargodist only choose reachable destinations for the goods. So if you only build routes to one powerplant all coal would go there.
What can the patch do for you? I think you be able to let goods change the vehicle although the good maybe accepted at these station! And you dont need special orders!

[jungle]

Is there not any element in your patch that forces or just rewards the effort to build a more balanced network ? For example, reducing payment for cargos that are delivered to a station which doesnt correspond to the intended destination ?

I think the final element in fonso's list of things to do in the first post of this thread (the only one listed as not being started yet) will address this, basically by linking station ratings to the reach of the network they are connected to, instead of just frequency of service. This will probably be awkward to calibrate initially (it could result in all stations having very low ratings early in the game, raising the difficulty level by miles) - but will bring in a good incentive to link things together.

[Kogut]

It is really needed thing - big red warning at the beginning of game without automatic non-stop.

[petert]

Check out my work on http://wiki.openttd.org/Template:Forums . The reason I'm mentioning this is because I linked to cargodist.