Cargo Distribution

[m00se]

Thanks Eddi, I'll give that a try.

[jackyf]

Hi,

I play OpenTTD with CargoDist patch for more than a (real) year now, I am happy with new game challenges it creates, thank you and all OpenTTD contributors who made this possible.

I have one problems though with "lost" passengers though. Let me explain:

I tend to create two types of passenger connections: local (bus/tram/metro) and intercity (bus/metro/train). Every city at least one intercity station, and all passenger from other sides of the city which want to go to another cities go through intercity station. This works well. Then sometimes as city grows I change the stations' purpose: some another station get "intercity" status and old intercity station becomes a local one. All intercity orders are changed accordingly, so that while in the past the old intercity station had both local and intercity traffic, now it has only local ones. And the problem is: while CargoFlow legend notices this quickly, passengers which were waiting on the old intercity station for intercity connections, are still waiting for them for months/years, not going anywhere.

I have a savegame which illustrates this. In the Tervala city, the station 'Keski-Tervala' was a busy bus/train intercity station with connections to other cities. Recently it got "demoted" to a regular bus-only station while new 'Tervala, metsä' now handles the intercity traffic. Only one local bus is visiting 'Keski-Tervala' nowadays, but there is still, for quite a time already, 136 passengers there who think they can go directly to other cities.

How to reproduce: 1) load the attached save game 2) open the passenger window for 'Keski-Tervala' 3) press Tab for a playyear 4) those 136 passengers are still there.
Version: g6accbf6e-cd

[fonso]

You didn't start the game with version gdb5ad1fb-cd or before, did you? That would explain the problem, but the game log doesn't indicate it. Can you give some more details on the workflow you're employing to change to the other station? And do you have a savegame from before the change? I'm having a hard time reproducing the problem.

[fonso]

OK, I've found it. Tonight's build should fix it. I'm not sure if I'm really happy with the solution, though. I might rewrite that again. Basically the removal of links isn't immediately reflected in all places where flows are created and maintained. That's because the link graph calculation is done in separate threads. The solution before the last big rewrite was to periodically check all cargo for valid next hop. The new solution is checking all new flows when joining the threads. Both are somewhat ugly.

[fabca2]

Hello,
just a question, does your binary build updated with lastest trunk version ?
Regards

[fonso]

Yes, I've also rebased on trunk r25214. There weren't many changes in trunk, though.

[jackyf]

OK, I've found it. Tonight's build should fix it. I'm not sure if I'm really happy with the solution, though. I might rewrite that again. Basically the removal of links isn't immediately reflected in all places where flows are created and maintained. That's because the link graph calculation is done in separate threads. The solution before the last big rewrite was to periodically check all cargo for valid next hop. The new solution is checking all new flows when joining the threads. Both are somewhat ugly.

Ack, thanks for working on this. Do I understood correctly that you reproduced it? I will try the latest version soon; can I continue with current savegame or do I start a new one?

[fonso]

You can continue old games from g6accbf6e-cd or versions compatible with that but already stuck cargo won't be released automatically. The new solution prevents cargo from getting stuck instead of periodically checking for stuck cargo. You can work around that by temporarily recreating the connection and removing it again.

[aantono]

Just tried the latest (today's build) and the game just freezes up (but without crashing). Attaching the autosave. When started, wait till the 16th of Feb and then the game just locks up. Same save works just fine in openttd-cargodist-g77abb4d3-cd-macosx-universal build, successfully passing beyond that date.

[ffpp]

Just tried the latest (today's build) and the game just freezes up (but without crashing). Attaching the autosave. When started, wait till the 16th of Feb and then the game just locks up. Same save works just fine in openttd-cargodist-g77abb4d3-cd-macosx-universal build, successfully passing beyond that date.

Same problem for me with gb83fe363M-cd.

• sources via git
• compiled with mingw
• had to remove the option -mno-cygwin from config.lib or otherwise I would get a linker error
• no other patches

The game seems to hang the moment when the cargo is choosing a 'real' destination. At least it runs, when the station still says 'any destination', then shortly afterwards (at the time I would suspect it to compute a destination) it freezes.

[fonso]

Thanks for the reports.

aantono: It seems you're actually using gb83fe363-cd, too. At least your game log says so.

Obviously I didn't have enough time to test my bugfix on Wednesday and so I created a new bug by fixing the old one. g1177f9f4-cd which will be built tonight should really and finally fix that now.

[ffpp]

Thanks for the reports.

aantono: It seems you're actually using gb83fe363-cd, too. At least your game log says so.

Obviously I didn't have enough time to test my bugfix on Wednesday and so I created a new bug by fixing the old one. g1177f9f4-cd which will be built tonight should really and finally fix that now.

Thanks, I fetched and merged the newest sources and recompiled it and the problem seems to have disappeared.

[aantono]

The latest version seemed to not exhibit the issue, but I did got a crash during a train refit, so not sure if the issue is related to cargo dist, or not, but am attaching the crash and save, just in case it is related.

To reproduce the problem just try to add the Multiple Unit Wagon to thetrain that is in Alexandria Train Depot, and you get a crash error saying "Assertion failed at line 102 of /bamboo/src/autoreplace_cmd.cpp: src->cargo.TotalCount() == src->cargo.ActionCount(VehicleCargoList::MTA_KEEP)"

[fonso]

Thanks for the report. The crash.log is not from the game in the crash.sav. However, as evident from the crash.sav you changed your newGRFs around quite a bit while the game was running. I don't believe that's the reason for the crash, though. Can you give some more details on what you did with that train's engine (the one with the 16 passengers) before you ran into the problem? Did you replace it manually? Was it autoreplaced? Was it autorenewed? Did you refit it? Those passengers are marked as "to be unloaded" which of course is wrong as the train is not in a station. I'm wondering how that happened.

[fonso]

I found a possible cause for the problem. See http://bugs.openttd.org/task/5543 . I can't be 100% sure if that's the actual cause until I know more details about what happened to that train before, though.

[aantono]

Not sure what GRF changes you are referring to, I don't actually recall making any after the game has started. (but could have forgotten).
The train was a new purchase, it was running the route for a few months, until I've decided to increase capacity, so I told the train to go to the depot (the train might have been at the station at the time), once in the depot, I have attempted to add a few more multi-vagon cars to it, and that's when I got the exception.

The way around it was to change the order to unload and load nothing, then send the empty train to the depot, and that allowed me to add the cars without crashing.
What is weird is that it only happens with passenger/mail trains, never had it happen with cargos like coal, etc. (though could be just the draw of the luck).

[jackyf]

I built the last version from Git and passengers don't get lost anymore when route disappears. Thanks!

[tts]

Not lost, but still "Confused" passengers
Passengers want to go form A to B. Found route A->C->D->B; passengers waiting in C.
Now i cut off the route C->D, but another routes A->B and C->B still exists. What happens? Pasengers waiting in C, having status "via D to B", get new status "via D to anywhere".
Isn´t it wrong? Shouldn´t it be "via anywhere to B" ?
And i try to suggest even "next behaviour" of these passengers (but many others are possible, i´ve just tried to describe human crowd solution):
1) if recalculation is done and new route to B is found, let them all get via from this route (An infocentre tells us where to find our lost way - we believe them)
2) if recalculation is done and route is lost, or recalculation not done
2a) if there is a post-neighbour X (next to C), possibly even X=A or X=B, which has non saturated route C->X and X->Y, where Y<>C is first step on existing route X->B; then many of waiting should get status via X to B - maybe 10-20% daily? (look - there is a not full bus i can go with - hooorah (and the bus is overfilled )
2b) if there is a "hub" neighbour X (sum planned (X)> 3*(sum planed(C)), some of passengers will try status via each such X to D - small amount, 2-5% daily. BUT - Planned route in X "via C to D" must be dropped first... (we´ll try our best, maybe in such a big place there is a bus of any use...)
2c) small amount 2-5% daily should dissapear without any payment. (oh no, better go by taxi!)
2d) some people should even resign and not patiently ask to be taken home to A... without payment... may be... but that is only optional )

And B - wrong calculation of transit - transit payment to first vehicle is too high... non considering neither the length of "voyage" taken /is payed even for A->A!/ nor the waiting times in transit stations... and the next vehicles get red numbers.... is any possibility to balance this?
TT

[tts]

And one more... maybe stupid.. but - if symetrical mode used, shouldnot be the amount of newly generated cargo/passengers in each station divided by 2? "We are too many... and we must die!" (some sci-fi novel citation, forgot the name)

[Alberth]

And B - wrong calculation of transit - transit payment to first vehicle is too high

This is a known phenomenon with feeder systems, also in trunk OpenTTD. See http://wiki.openttd.org/Feeder_service , in particular the page about negative income.

shouldnot be the amount of newly generated cargo/passengers in each station divided by 2?

Cargo distribution is about transporting passengers, not about creating them.

Houses create passengers. The generation problem is just more visible with cargo distribution since you have more work to move them.
Afaik there are passenger reduction NewGRFs that you may want to try.