Cargo Distribution

[Dimme]

Congrats fonso!

I don't know how many failed attempts have been made on cargo destinations, but it has at least been discussed as long as I have been here. I really like your work, and I hope you get it all in

[NekoMaster]

As the cargolist cleanup branch has indeed been merged into trunk (thanks Rubidium ), I'll keep my promise and get the second stage of cargolist performance optimization ready for trunk. It will come in three parts:

• First we need the ability to load and save std::set. This is basically ready, but I'll write some more comments. It's in the branch slset
• Second the vehicle cargo list is split off from the station cargo list via templates and given a std::set instead of a std::list as base. This is the main part of the optimization. I have already identified and moved all the code involved, but I guess it could use some more cleanup and documentation. You can watch this in the new branch cargoset
• Third will be the separate reservation lists for vehicles. I haven't started isolating this one, yet. It's still in the cargomap, together with various other things.

Are you saying this is going to be included in the openttd nightlies? if so that would be wicked just add a option so that you can shut cargo distribution on and off among the other settings for it

[Kogut]

Do you use non-stop orders? If not, you should start using them and it will solve your problem. You can actually enable non-stop orders as a default setting in the Advanced Settings.

What with ships and planes?

[fonso]

What with ships and planes?

Ships and planes can't stop at in-between stations. Their orders are deterministic without non-stop (which isn't available anyway).

Are you saying this is going to be included in the openttd nightlies? if so that would be wicked just add a option so that you can shut cargo distribution on and off among the other settings for it

No, it's not all of cargodist. Part of the optimization I did to solve the performance problems with cargodist has been merged and I have promised to make further optimization of the cargo loading system available to trunk if that happens. That's what I'm doing now. Until now all the optimizations were stuffed into the "cargomap" branch which depends on "flowmapping-vehload" and thus is not very convenient for trunk to pull from. However, a lot of the functionaliy doesn't really depend on cargodist and can be refactored and ported to trunk. Thus I'm splitting cargomap up into several branches some of which only depend on master to ease merging these optimizations into trunk.

[Roujin]

Nevertheless, congratulations on getting this optimization part into trunk, and good luck with the next steps.

[petert]

Then maybe finally we can merge cargodist and IS together.

[Alek_temp]

I have an issue with vechicles loading all cargo of their type instead of just what is destined for them. Same goes for unloading, they just unload all they have, regardles of destination.

I have "Cargo Distribution R17719" for Win32 from the previous page of this thread.

Am I doing something majorly wrong or is badly compiled or something ?

[Kerygma]

Are you using non-stop orders for the vehicles? If not that will (most likely) fix your problem.

[Alek_temp]

Ok, that helped, thanks. The posts can now be deleted

[petert]

Ok, that helped, thanks. The posts can now be deleted

No need to delete them, they may help someone else.

[Zuu]

I don't understand, what has been included into trunk?

I believe this:
http://vcs.openttd.org/svn/log/?limit=7 ... op_on_copy

but possible even more if there are more commits related to it that happened earlier in another rubidium commit-sequence.


Edit: Indeed here are some more older commits that seams to be related:
http://vcs.openttd.org/svn/log/?limit=3 ... op_on_copy


Edit2: Oh! I forgot to check for more pages in the thread. Sorry for not reading the other replies first.

[id10terror]

So i wanted to lower populations without a patch or upper limit so i modified Ammler's early houses grf to keep populations to 1/2 till 2999.

Grf and full description http://www.tt-forums.net/viewtopic.php? ... 15#p824715

[NekoMaster]

So i wanted to lower populations without a patch or upper limit so i modified Ammler's early houses grf to keep populations to 1/2 till 2999.

Grf and full description http://www.tt-forums.net/viewtopic.php? ... 15#p824715

You could have just gone to Advance settings and find the town settings and set the multiplier lower, I find that with it on 1 theres A LOT of >500 pop. towns and such.

[Kogut]

Among many realistic and great things I found something very irritating.

Cargo is very, very stupid. It travel using route with minimal number of stops and tranfers. And nothing else is checked.

There are 4 stations and 3 trains:
stations:
A==B==C==D

trains (all orders are non-stop go to):
1) A, B, C, D, C, B
2) A, C
3) C, D
Passenger prefers travel using trains 2, 3 with transfer during travel, than direct connection!

Another example in attachment.

===
Solution
Finding connections algorithm should check also time of travel (time may be collected in the same way as collecting capacity of line). Maybe it should add penalty for quantify of cargo waiting on station to go on the same way. direction.

[fonso]

Among many realistic and great things I found something very irritating.
Cargo is very, very stupid. It travel using route with minimal number of stops and tranfers. And nothing else is checked.
===
Solution
Finding connections algorithm should check also time of travel (time may be collected in the same way as collecting capacity of line). Maybe it should add penalty for quantify of cargo waiting on station to go on the same way. direction.

This was a design decision. I have to draw the line somewhere. It's not trivial to find out about the "travel time" of a link or route and I don't think considering this adds a lot of gameplay value. Most times the routes with fewer stops and transfers are indeed the faster connnections (think Inter-City versus local train) so most times the additional check would be redundant. I actually can't think of any use for the direct link if it's not faster than the one with in-between stops. You can as well remove it in that case. Of course you can always find artificial counter-examples like in that screenshot but that's not the point. No one builds such a route.

And keep in mind that this is a game. I don't need to recreate the real world in the game; I can make my own. In my world, people hate stopping at many different stations, but don't mind taking large detours or waiting indefinitely at few stations. Sorry, but that's how they do things there ...

[belugas]

And keep in mind that this is a game. I don't need to recreate the real world in the game; I can make my own. In my world, people hate stopping at many different stations, but don't mind taking large detours or waiting indefinitely at few stations. Sorry, but that's how they do things there ...

WOW!!!! At last! There is someone who has the same point of view as I have!!!

[Zuu]

While I do agree that things does not have to be as in the real-world reality, I just want to add that in reality people actually value their time higher when they wait or transfer at stops than when they travel. This difference is quite significant.

So doing the approximation of just counting the number of transfers is not that bad looking from the reality point of view.


And then even in reality (as opposed to games), we make models that also contains approximations. How would you else being able to calculate the route choices for an entire city or an entire country?

[ostlandr]

Playing CargoDist right now- and I like it!

[petert]

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

[bigos]

Then maybe finally we can merge cargodist and IS together.

I use this and IS 2 patch on my server and its working fine