Cargo Distribution

[keoz]

Ok, thanks for all answers and idea. I didnt know about those different GRF's, will try it.

[ostlandr]

Ok, thanks for all answers and idea. I didnt know about those different GRF's, will try it.

I prefer Pikka's Basic Industries (PBI) to ECS, but that's just a matter of personal preference. PBI is basically the original industries with stockpiling and a few changes such as steel mills requiring both coal and iron ore, the addition of breweries (accept grain, produce goods) etc.

[petert]

I prefer Pikka's Basic Industries (PBI) to ECS, but that's just a matter of personal preference. PBI is basically the original industries with stockpiling and a few changes such as steel mills requiring both coal and iron ore, the addition of breweries (accept grain, produce goods) etc.

I absolutely agree, without getting too OT, I think PBI looks much more realistic in an 8bpp game.

[bigos]

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

Hehe free advertise

As I see some code from your patch appear in trunk. How far You are in rewrite to current trunk because there is a lot of differences... and I don't know if I should make it by myself or wait?

[fonso]

As I see some code from your patch appear in trunk. How far You are in rewrite to current trunk because there is a lot of differences... and I don't know if I should make it by myself or wait?

I'm waiting for Rubidium to finish merging the cargoset branch ... and I hope he'll actually do that and not something entirely different. But anyway, as soon as he gives the impression to have finished his work on cargopacket.{h|cpp} I'll merge his changes into cargodist and publish the result. In my local repository I have also split up the cargomap branch further to make the separate reservation lists available to trunk. This provides further potential for merge conflicts. I don't want to go through the hassle of resolving all those conflicts several times so I wait until trunk is relatively stable in that area.

[keoz]

A little question more.

I only played one map with cargodist until now. It seems to me that there is a problem in my game: cities dont grow as fast as usual. Maybee is it only an impression, but this impression is really strong. To check this out, I compared two games

- one game was done using the official branch of the game (0.7.3); a game started in 1920. One of my big cities (i always start the game connecting together two great cities) grows quite fast. After 10 years, one of this big cities (Lille) contains more than 4200 people, and was at 1500 at the start of the game. Files: 1921: http://keikoz.free.fr/var/KaboumTransport-5Mar1921.sav and 1931: http://keikoz.free.fr/var/KaboumTransport-17Dec1931.sav

- another game using the cargodist patch and the development version of the game (using the git procedure explained in the wiki). Cities grow, but just a little bit. I started the game connecting Bordeaux to LeMans. In 1921, Bordeaux was at 1300 people. In 1953 (more than 30 years later), it is just at about 1800-1900 people ! Files: 1921: http://keikoz.free.fr/var/BordeauxTrans ... an1921.sav and 1953: http://keikoz.free.fr/var/BordeauxTrans ... ul1953.sav

I have to say that i used exactly the same settings about town/cities growth, in both game. Their passenger supply was about the same on both game, and even bigger in the second game after some time. So, i'm quite sure something's happening with city growth. Either related to recent trunk versions, either I miss something important ... either something in the cargodist patches compromises city growth based on passenger transfer.

What do you think about that ?

Note: i use the GRF UK Renewal Train set, but I used it for both games.

[Dimme]

I don't know the answer to your question, but some information: the total passenger supply is not relevant, only the number of working stations, up to five stations. Did you have at least five stations in both games?

[fonso]

... either something in the cargodist patches compromises city growth based on passenger transfer.
What do you think about that ?

Isn't city growth related to station rating? It's harder to keep a good station rating with cargodist than with trunk as the passengers are travelling further and you need higher capacity in your network. Just a stab in the dark, though. I'll have a look at your savegames later.

[tsjook]

I support your view because my cities (you can even call them agglomerations as more than one town is involved) still grow like crazy. But they have many many stations connected with very good+ station ratings, connected by many many trams.

[keoz]

I don't know the answer to your question, but some information: the total passenger supply is not relevant, only the number of working stations, up to five stations. Did you have at least five stations in both games?

Not anyone has, for the moment, more than 5 stations. Anyway there are more stations in the cities of game number 2 (the one where cities grow so slow). Anyway:

... either something in the cargodist patches compromises city growth based on passenger transfer.
What do you think about that ?

Isn't city growth related to station rating? It's harder to keep a good station rating with cargodist than with trunk as the passengers are travelling further and you need higher capacity in your network. Just a stab in the dark, though. I'll have a look at your savegames later.

Maybee it depends from station rating, but I did read, in the manual, that "In short, the growth of a town is heavily dependent on the number of passengers picked up and delivered, regardless of origin." (http://wiki.openttd.org/Town#Growth). That's why I considered, the important thing, is just quantity. Anyway, regardless of what actually makes cities growing, something is weird, i guess (but I still dont know if the problem is coming from recent trunks, from cargodist, or from me ?).

Another word: I tried to make a test in game number 2: i tried to run it for 7 years in two different ways. Once, using "non-stop" orders (in order to use cargodist/dispatching effectively). Then I relaunched the game, but I changed all orders to "normal" orders (non "non-stop" orders). The scope was to run it with the cargodist patch-set installed, but not using really cargodist and letting it run with classical behaviour. The result, in terms of growth, was quite the same. So, when i say, that maybee in the recent trunks *or* in the cargodist patch-set somebody could be blocking city growth, if the hypothesis is correct, this is independent from effective use of cargodist dispatching or not.

[Jans]

keoz don´t forget ther ist a patch where you can choose every 4th or 5th city grow faster then other. Maybe in game one your lucky because one of youre town belong to these group. In the second game annother city grow faster. So i Think it isn´t possible to compare the games.

[Roujin]

You can enter the same seed upon generating the map, this way you'll have the same map to play on.

[keoz]

You can enter the same seed upon generating the map, this way you'll have the same map to play on.

Good idea. I'll make a more clean test to compare if there is really any difference and give results here.

[acabin]

in smallmap_gui.cpp:

Code: Select all

uint line = (pt.y - wi->top - 2) / 6;
int rows_per_column = (wi->bottom - wi->top) / 6;

should be:

Code: Select all

uint line = (pt.y - wi->top - 2) / SD_LEGEND_ROW_HEIGHT;
int rows_per_column = (wi->bottom - wi->top) / SD_LEGEND_ROW_HEIGHT;

其实我想知道还有哪位说汉语的在玩这个游戏……

[Creat]

I've only recently re-discovered OpenTTD and shortly afterwards I found this incredibly awesome Patch. Thank you so much for investing so much time into this
I've been playing it for about a week now, so I do have a few suggestions (and one bug and question each ) for you, so this post might get a bit long, please bear with me
They're all intended in the best possible way to make Cargodist the best it could be, just thought I'd mention this in case this doesn't become clear from my post...

The non-stop issue:
The most important suggestion (more like a plea, actually) would be: PLEASE make it somehow obvious (for example with big red letters in the first post of this thread) for new users that non-stop orders are mandatory when using Cargodist. It took me (like many others) hours to figure it out since it first appears on page 15 of this thread, which is quite a lot of reading to reach such a fundamental piece of information! By now I've read the entire thread and there seem to be quite a lot of people who took a while to get that too. This can only be like a band aid in my understanding though, giving similar warnings in game when a tuck/train uses default (nondeterministic) orders like those for a train being lost or a vehicle getting old would be a minimal amount of feedback required I think. At least some way to somehow see that this vehicle uses the fallback.

Expanding on this, I'd suggest a much more useful fallback for nondeterministic orders for quite a lot of reasons, like:

• those orders are the default
• with the current fallback method adding buses (for example) can make a traffic situation worse instead of better (I'll try to create an example game that demonstrates this, had one but don't have the save game anymore )
• I don't know how others use these orders, but at least for me 95% of the time the next stop in the order list actually is the next stop.
• For this to be merged into trunk (*fingers crossed*) these normal orders would obviously have to work, and I just love to see that happen

The easiest approach to this would probably be to ignore the stops in between, if there are any. Just reload the passengers you've just unloaded and continue as if the stop wasn't there. This would probably be the best solution if these stops don't always occur but only sometimes (for example due to buses taking different routes through a city, passing different unplanned stops). If the unplanned stops are always the same (like a train passing through stations) this can obviously be detected and the detected route used as the deterministic one.
As a compromise solution that requires less effort you could just pick up as many passengers that have the next stop as their final destination (or if this information is easily accessible: as a waypoint they have to pass to reach it, like a station with the only connection to the destination). This would also work with unexpected stops in between, even though it may no longer be the best travel-option to the destination (might take longer than a direct connection without unplanned stops and so forth), but you don't accidentally transport people/goods to where they came from or otherwise further away from their destination.
Finally the fallback could actually be a fallback to the old system (simplest solution of them all, also probably the least appealing): cargo's/passengers are delivered wherever they are dropped of (if accepted there) regardless of their destination.

(Automatic & Manual) Link-Management
Quite often (especially in the beginning of a game) I switch the routes of vehicles, effectively changing the links in the graph. As far as I know there currently is no way to tell Cargodist, that a certain connection is no longer valid. Depending on the map size the moving average/size could be set quite unfavorably (and changing this around constantly to get a link to disappear is somewhat backwards I think). I have attached a save game [order_switch_example] to illustrate (cause I know you really like em ^^) even though you probably know what I mean.
I've switched the shared order of all the buses to not go A<->B but A->B->C to include that stop, now I know that the previously existing connection B->A is now gone and the new detour should be used, but it will take quite a while for that link to disappear (the game already ran a while in fast forward since the switch). The buses currently aren't even used to capacity, and there are already 84 passengers in Bundton heading for Bundton Central that are planned for the no longer existing direct connection, and I can't do anything about it except wait :/
How about allowing to Ctrl-Click a link in the minimap-graph to delete a connection? Maybe use the node closer to the click position as the source and then ask if the link should be deleted (i.e. cap set to 0), the latter could be an advanced option: "ask for deletion after ctrl-clicking a link".
Example: I have a connection A <-> B and Ctrl-Click that link close(r) to A, then I get asked if I want to delete the connection from A to B with capacity [x], clicking yes it's gone (and the proper new route via C in my example above will be used immediately). This can also come in very handy if you completely reorder the bus lines in a city allowing you to just delete all links, after all repopulating them is very fast (completing the orders of each vehicle once), timing out might take ages causing huge buildups in medium to large cities!

I have another suggestion where I really don't know if this is feasible, but would be possible to correlate the moving average unit/length with the link-length (in tiles or something similar, i.e. physical distance on the map) since travel time can't easily be determined as you've stated numerous times (and in addition might not even be consistent for a link served with planes and trains for example)? This would make the setting superfluous and allow it to be replaced with good defaults instead. Imagine the problem directly above with a moving average designed to allow plane connections on a 1024x1024 sized map. Maybe it's already later in the game and there actually are plane connections. Now I start in a new town somewhere and have to expand my bus network, the passenger ratings are gonna drop right through the floor until the link disappears after quite a long while. I could add another group of buses and a new line instead of rerouting those already there, but to know this requires pretty in-depth knowledge about how those goods are transported - at least far more than can be expected from the average player just wanting to have a little fun game every one in a while

I'll continue this a bit later, right now I have to leave, but there is still more stuff to come (if you want it, anyways...)
Still once again thank you for this already quite playable patch adding much fun!

EDIT: sorry, forgot to post version the save game applies to: Title of OpenTTD says g90f47d3cM-(no branch)

[Creat]

Ok, back at a computer with OpenTTD on it... Continuing post from above

Passenger Numbers

Super short version: this is about the current impossibility to connect two networks to each other with anything else than a powerful backbone.

There currently is a serious problem with passenger numbers and destinations in some specific cases. In not just talking about the initial passenger (or is it all cargo?) boost you said you added because 'someone requested it' (but please make that boot configurable via advanced settings or similar), but adding a low-capacity link between two traffic networks (I'll elaborate further on this a few lines down). Low capacity meaning low compared to the passengers generated in the two traffic networks connected by the link. Generally speaking most problems with passengers and traffic load on the network can be attributed to the destination selection. I propose two changes here, possibly one of them would suffice though.
First back to a concrete example. I've seen this happen many times over the last couple of days. I'll create a save game to illustrate this problem if so desired (will take some time to do that so I'm not putting the effort in unless it's actually needed), but this should already be pretty clear without one.
Lets say that we have six cities: [A,B,C] and [X,Y,Z]. Both triplets are connected in a triangle within the group, but not to each other yet. Also lets assume those networks are sufficiently sized to carry the traffic generated. Now we add an Airport connecting A and X (obviously not creating a new station but joining with existing ones) with only a couple of planes, now all of a sudden everything goes down the drain. Small graphic to illustrate:

Code: Select all

B                    Y
| \                 /|
|  \               / |
|   \    bottle   /  |
|     A}--------{X   |
|   /     neck    \  |
|  /               \ |
| /                 \|
C                   Z

Just to throw some numbers around: Even if none of the cities are above 5k inhabitants, and at none of the stations are generally more than 300-500 passengers waiting, adding this link will generate at least 3000 passengers at both A and X trying to go over the new bottle neck link. I don't know weather those are passengers that were only generated because there are more and/or more distant destinations available or if they would've gone to some local destination instead (actually generating income, and not killing the station ratings of A and X). The link graph also shows this pretty clearly, while the new link may have a capacity of about 20, it shows 200 as it's planned value.

Now for the two actual suggestions on how to solve this (as mentioned using just one might be enough, but both would be more adaptable to capacity changes in the network):

• Select a destination and take into account how easy it can be reached. I.e. include capacities of the links going there in this decision.
• Allow passengers to change their minds if they've been waiting for so many ticks at a station, switch their destination to something reachable (again possibly according to link capacities)

Well, maybe it's just one suggestion since both versions include taking the link capacities into account at some point. Combining the two would have the advantage that a decrease in link capacity wouldn't cause (at least the already generated) passengers to pile up at the bottleneck nodes (lets say due to a signaling error two of three trains collide with no money to replace them at the moment). They'd simply change destination/route after an amount of time one could correlate (to some degree, to avoid oscillation) to the distance of the next travel node.
This obviously shouldn't morph into an algorithm trying to maximize utilization on all links in the network and not generate more passengers than that. But it shouldn't hopelessly overload tiny links either.

A similar problem occurs when one or more small town(s) is connected with bigger cities. There should be a limit of how many passengers can be accepted by a town, just like there's a hard limit on how many it can generate (at least as long as there are other possible destinations that haven't exhausted their limit). Possibly just use that value multiplied by some either adjustable or carefully tuned number. I think I've had a somewhat unrealistic situation a couple of times where the town population was delivered to a town about ever two months or so (unfortunately I don't have a save game of that anymore, sorry).

Well, that's it for me, gotta go to bed.

[fonso]

Thanks for the feedback, Creat. I'll give you some answers:

The non-stop issue
I see the problem. The default fallback at the moment is indeed the old behaviour: Unload, deliver if possible, load anything. This behaviour causes problems when cargodist is involved. "Remembering" the frequent unplanned stops would probably involve changing the order system to somehow record those. This would be a lot of work for not much benefit as most people don't really need the nondeterministic behaviour; it's just the default. I'd rather change the default non-stop flag when enabling cargodist or display a warning in-game. And yes I'll put a warning in the first post right now.

Passenger Numbers
First there is no boost in passenger numbers. There is a boost to the initial capacity of a link. It is applied whenever a vehicle chooses an order and the capacity of the link to that order's destination is smaller than the vehicle's capacity. This doesn't influence the passenger numbers.
Yet, I also see your problem here, but I don't quite know if it should be solved. Of course it's a challenge to fulfill the transport demands especially if you connect two networks. However, making the demand function independent of the capacities was a design decision especially create that challenge. I'm very reluctant to give up this principle. What could be done is setting a certain cap on how many passengers are allowed to wait for a certain next stop at a station. Then, if more arrive, they get "to any station" instead. This would sort of implement the "mind change".
About connecting small towns: If you have symmetric demands a station will only attract as many passengers as it generates. So a town will only attract as many as it generates, too. Of course, if you have multiple stations in a small town you will reach that limit more easily than if you have few stations in a large town.

Link-Management
Making the averages depend on link length is actually a very good idea. I'll think about that. Maybe I'll also find a way to manually delete links, but I'm not sure if the smallmap is the right place for this.

[NekoMaster]

If Possible, could someone post the latest openttd nightly with this patch (win32 bin)

[petert]

You are extremely lucky NekoMaster, as I am only posting this binary because I want my 600th post. For no other reason, if it were any other post, I wouldn't have posted at all. So, your welcome.

[NekoMaster]

You are extremely lucky NekoMaster, as I am only posting this binary because I want my 600th post. For no other reason, if it were any other post, I wouldn't have posted at all. So, your welcome.

Lol, thanks and I guess I could say your welcome for giving you a reson to post something