Cargo Distribution

[fonso]

Not lost, but still "Confused" passengers [...]

I'm confused now, too. You need to provide me with a savegame and tell me the real station names. There's no way for me to find out what's going on in your game like this.

[tts]

Re: Alberth.
1)THX... but the fact the "phenomenon" exists and is known does not satisfy me... but i think it is not cargodist problem - just asked if you did not have some ideas about - how to solve...
2) ok, its good to know some reduction exists... ill try to find out... but - if you know, that your version generates much more traffic (not cargo, of course), it would be nice if you add an option (expert?) which could reduce this a little. I suppose if you can manipulate with cargo by adding a target destination, you are also able to drop some away Just an idea, maybe it fits, maybe not. So - an option "reduce symetrical cargo - 0-100%" and that amount would be dropped instead of assigned to destination - would not it seem useful?

Re: fonso
oh, sorry, i didnot ment to confuse try to read only my normal size letters and ignore the small ones.
Problem is, that after cutting a "trunk" route there are left (many) passengers with old "via" (to now directly non-reachable, already cut) but no final target (is substituted by "to anywhere"). Later it changes to "to anywhere via anywhere" - and so they are delivered to first any station, where they finish) And that is confusing for me, i think it should be opposite, target should remain, but "via" is unknown... (the people know, where they want to, but dont know how to get there)
OK, I´ll try to prepare some saves before and after cut, on small map - but it should take some time...

[fabca2]

Afaik there are passenger reduction NewGRFs that you may want to try.

Hi,
do you have a suggestion, what newGRF would you advice ? what's the one that fits the best ?
Thank you.

[Kraks]

do you have a suggestion, what newGRF would you advice ? what's the one that fits the best ?

Read this topic: http://www.tt-forums.net/viewtopic.php? ... rgo+factor

[tts]

Ok, here is the example
on

Marnway Transport, 16. srp 1951.sav

(13.92 KiB) Downloaded 32 times

all is ok, traffic to marnway goes ... one intercity train and two local bus-lines, crossing in the centre of the Marway town
on

Marnway Transport, 29. srp 1951.sav

(13.77 KiB) Downloaded 24 times

i did rearrangement of local traffic ... intercity train remains, but "main line" - Mines(rail-station) - Central is cut, and substituted with "circle line"
on

Marnway Transport, 7. říj 1951.sav

(13.86 KiB) Downloaded 28 times

passengers in middle of the town (Marnway) are totally confused, and go to nowhere, instead to train
I think they should loose only the "via" information, not their target station - am i wrong?

Interesting is, that passengers on railway station (Marnway mines) aren´t confused... and have found their way through south and/or woods correctly - i suppose that it is due to new line through this station. Marnway (middle) has no new line, and so there is a problem... maybe the same procedure which is used on new line stations may be used even on that stations, where any line is cut?

[Rubidium]

In g1177f9f4-cd the feeder share cache of the cargolist of trains seems to be incorrect. It shows a significant negative feeder share amount.

If you follow train 56 in the attached savegame, you see that when it has unloaded at Dinninghall, the feeder credit amount of said train has become negative.

The modifications in the code are a few added DEBUG statements as SDL was misbehaving in some weird way. Nothing in the game logic was changed.

[Yashio]

So does anyone know whats up with the routing not working? Its like that also on my laptop copy.

[TinyMusic]

That's weird, did you get the actual cargodist build? If you do, you should've got the plus sign after the passengers icons.

[tts]

To Yashio - RU sure all cargodist switches in advanced setting are ok? can you post your save?

[Yashio]

Ok i managed to fix it but am i supposed to have such negative income?

[TinyMusic]

Could be some transfer order problem, can you show some screenshots?

[Yashio]

Alright this kind of stuff is happening.

[Rubidium]

Clicking on the "({CARGO_SHORT} reserved for loading)" opens a subtree in g70821768-cd (and at least g1177f9f4-cd) in the station GUI. This happens even though there is no + after it to indicate there is something, but it also only shows the same information again. So I reckon it should fold open. On the other hand, if it folds open it should probably show the destination/via/source of the cargo that is to be loaded.

[tts]

To Yashio, negative transfer.
Seems to me, that Advanced/Economics/"Percentage of leg profit to pay in feeder systems" is really not 75%, but 750%. try to set about 8-10%, and youll maybe get what you want. I did, it works.

[fonso]

In g1177f9f4-cd the feeder share cache of the cargolist of trains seems to be incorrect. It shows a significant negative feeder share amount [...]

Yes, the feeder share isn't updated in VehicleCargoList::Stage(). In addition to that the feeder share is added twice: in Stage() and in CargoTransfer::operator(). It should only be added in Stage(). The fix is trivial but I can't push it right now.

[fonso]

The fix is pushed now and g0bd7d484-cd will contain it.

@tts: Your game is perfectly normal. Remember that passengers don't technically have a final destination. Each passenger knows where they're going next and the routing system is created such that a certain number of them will arrive at certain destinations. If you cut the routes while people are waiting for them they're going to be confused. I think this is a small price to pay for the performance benefits of doing the routing this way.

[Rubidium]

There is a desync in cargodist. I've tried figuring out where it comes from, but can't really find the place.

For reproducing desyncs I added some code that stores the commands and random values of a server, so you can replay it exactly the same way. Furthermore savegames are made at regular intervals. You can join with a client to notice when the (first) desync happens. Once you have a desync, you try to find the first savegame that triggers the desync and the last one that doesn't trigger it by "simply" rerunning the commands and letting the random values be checked.

Once you have a way to reproduce an "ok" and "desync" version of the same time line, you enable desync-debugging which enables printing each random call (to autosave/random-out.log). With diff you look for the first differing call, and then you have to backtrace to find the actual desync trigger.

The random-out and commands-out lines usually begin with the date and date_fract in hexadecimal format.


To rerun/reproduce this, follow the following steps (with the files from the attachment):
First apply the replay diff, reconfigure with --enable-desync-debug=2 and make.

Then copy ok.commands.log to the folder of savegames (e.g. .openttd/save).
Start openttd with network server with the ok savegame (openttd -D -g ok.sav).
After a while it says end of commands.log, stop openttd (CTRL+C).
In the autosave folder (e.g. .openttd/save/autosave) is a random-out.log which contains all output of DEBUG(random, ...); copy this file so it's not overwritten.

Do the same for the desync one, however this will crash with a message stating "mismatch expected XY, got AB".

Now you can diff the ok and deync random log. The first bit, up to 000adec0; 00, will be only in the ok log since the desync one starts later. From there, the differences are desyncs. I added some DEBUG(random calls, which shows that at 000adeec; 08 the load/unload has a different amount of cargo in the vehicle in the ok and desync savegame. However, this is caused by something before that, but I haven't figured out what.

It doesn't seem to be the linkgraphjob; the ~LinkGraphJob, SpawnNext and JoinNext happen at the same time and have the same information.


I hope this is clear enough for you to figure out what happens. When looking at the ok and desync runs in-game, the central station has different amounts for different destinations after a while at the same time.

Furthermore, rerunning the ok savegame with valgrind makes it desync as well, but at another time. Sadly enough valgrind doesn't spit out anything useful or suspicious.

[fonso]

Thanks for the report. I'll try to track it down. As my time and internet connection are somewhat limited at the moment I doubt I will be able to find the problem before June, though.

[Rubidium]

Digging further it looks like the order in the FlowStatMap differs in ~LinkGraphJob.

Actually, in the first MCF pass I'm now noticing the first differences. It smells like the paths aren't in the same order. To make the plot thicken... I can reproduce the issue with the ok savegame + run by simply forcing single threadedness (removing the ThreadObject::New call in linkgraphschedule.cpp).

[tts]

Remember that passengers don't technically have a final destination. ... I think this is a small price to pay for the performance benefits of doing the routing this way.

Oh really? If there was talk about cargo packets, I thought each has its own source/destination record, and so the cargo is routed, similar to IP packets. Ok, how the detail information about cargo waiting in station is generated? there is (calculated ?) "amount waiting" with "destination info" - couldnot it be used to recalculate new routing if old route lost?
It seems to me not to be totally marginal problem - I rather often find some "cargo" lost in my stations - usuall if delivering one source to many industries; and I also have many confused passengers in "cyclic" (non-tree) traffic systems
BTW - good job on CargoDist - Iam just hunting some bugs hidden in very dark corners