Cargo Distribution

[id10terror]

CargoDist built with VC++ 2008 + directx sdk

Code: Select all

git show
commit 502f4c583bafa9687a0eaac2f08aa814b93dcb96
Merge: 47c8975... 4f8768e... 6e67e56...
Date:   Wed Sep 9 21:15:59 2009 +0200

[Irwe]

I thought I should give this Cargo Distribution thing a try and I found it very amusing. The only thing I noticed is that most of my vehicles got a negative income after a few years. I play as I usually do so is this suppose to happen or do I play it the wrong way?

[fonso]

id10terror's last build contains a partial fix for the desyncs and a full fix for huss' problem. Desyncs shouldn't happen anymore if all clients are using the same standard C++ library. Thanks a lot for posting the build.

The full fix for the desyncs is a little more complicated. I think I'll have to extend the saveload system to enable saving and loading several kinds of possibly nested containers. In fact I also need that for saving and loading the link stats, flow stats and the link graph components. Until now I have been using some hackish workarounds, but I think it's time to clean that up. I'm still pondering how to do that.

Irwe: It's quite normal that some vehicles create losses. This is because every vehicle gets virtually paid for transfers and those transfer payments have to sum up to the total profit you get in the end. Now if you have passengers going one of those long links by plane the plane will get a big transfer credit because it is so fast. Then the passengers board some bus which takes ages to move them a few tiles. Then the total profit you get for taking the passengers from their original source to their final destination is lower than the transfer credit the plane got. The passengers aren't far from the airport, possibly they even moved back towards their original source a little. Yet it took them a long time to get there which immensely lowers your profit. This is why the bus at the last leg of the journey gets a negative income to have the transfers sum up. However, your total income over all legs of the journey is still positive.

[Irwe]

Irwe: It's quite normal that some vehicles create losses. This is because every vehicle gets virtually paid for transfers and those transfer payments have to sum up to the total profit you get in the end. Now if you have passengers going one of those long links by plane the plane will get a big transfer credit because it is so fast. Then the passengers board some bus which takes ages to move them a few tiles. Then the total profit you get for taking the passengers from their original source to their final destination is lower than the transfer credit the plane got. The passengers aren't far from the airport, possibly they even moved back towards their original source a little. Yet it took them a long time to get there which immensely lowers your profit. This is why the bus at the last leg of the journey gets a negative income to have the transfers sum up. However, your total income over all legs of the journey is still positive.

Thanks for clearing that out for me!

[audigex]

That also helps it to be more realistic - the buses lose money in order for the planes to make money. Subsidising of services etc

[dbkblk]

About my previous bug report post:
The link had gone. So it effectively works, BUT it took 20 years to disappears. Isn't it too much ?

[fonso]

About my previous bug report post:
The link had gone. So it effectively works, BUT it took 20 years to disappears. Isn't it too much ?

You have set the moving average dimensions to 4*256. This is 16 times the default setting (default is 1*64). This means it takes about 16 times longer than usual for dead links to time out. Fix that in "advanced settings"->"economy". The other issue is a real bug, I'm investigating that.

Edit: The other one is a bug in trunk. I reported it, see http://bugs.openttd.org/task/3201.

[dbkblk]

Okay, thank you !

Is there anywhere to get informations about theses parameters ?

[St256]

Related to the topic of negative income of vehicles only transferring cargo (see some posts above):

The concept of the negative income is clear to me. However, there is an inconsistency/bug regarding the income calculation. If the sum of the annual profit of each vehicle a company owns is calculated, the result should be the same as the sum of the income values of the finance window minus the sum of running costs. Maybe not exactly as there might be transfer credits taken into account in the per-vehicle profit which is not reflected in the finance window, but the difference should not be very high.

In a recent game, I noticed, however, that this difference was really huge. Summing up the income of all vehicles I had, resulted in a negative number which was about as high as the positive total income which was shown in the finances window. I think this difference cannot be caused by the cargo still waiting for delivery at transfer stations.

I tried to verify the behaviour by starting a new mini-game, and again weird (in my opinion) numbers occured. In the screenshot below, my point should be obvious. The savegame for producing the numbers is also attached. The savegame was produced using the cargodist branch from fonso's git repository at revision a29e6da... from 09/15/2009 12:32:09 PM.

TranferMoneyBug.png (14.42 KiB) Viewed 2823 times

[John]

I don't know if any devs can shed more light on the above, but I believe it is a result of how transfer credits are worked out.

It is also not specific problem to Cargo Dist, more a problem in trunk.

The finance window is the truth, and calculates the amount earned by distance travelled. I believe the default TTD way is to give all the credit to the last vehicle in the chain of transfers and this has been used in OTTD. As such, if all your trains transfer all their cargo to buses, and never deliver to the cargos final destination, then the finance window will show a profit of 0 for trains.

In order to present this in a more useful fashion for players, the concept of transfer credits was born. This allocates a credit to the vehicle after it has delivered its cargo based on how quickly the vehicle travelled. The final train then banks the full credit as it used to in TTD, but then all the transfer credits get deducted from it. This is how vehicles can end up with incomes far more negative then the trains running cost.
Transfer credits only exist in the world of the individual trains profit, and do not show up at all in the finance window.

I assume this is what causes the difference in final figures, with the vehicle list including more additions and subtractions from across the whole range of vehicles. Also, possibly, the transfer credit method doesn't take into account the time cargo waits at intermediate stations, which the finance page does.

I can only assume that is why the totals don't add up, is that something doesn't get taken into account one side, and it does the other. As intuition suggests they should be the same...

[bluebottle]

A bug regarding income on r17268 with the CargoDist patch (the devs closed it since I didn't know the policy about reporting bugs on patched versions, but FWIW here it is anyway):
http://bugs.openttd.org/task/3221

Basically, I get a sudden, massive negative income on my aircraft, some -941 billion yen, in 1956. I only have five planes, all of which show positive income. The bug only shows up in the finances window: and of course I can't build anything ever again. The only workaround I've found so far is to ground all my aircraft permanently, after loading from an autosave before the bug hits, which cuts off a large portion of the game.

Is there any console var or something I can set to correct my bank balance, so that I can use aircraft?

Screenshot, saves and newgrf window attached.

[John]

That looks like a stack overflow - a common problem in the original TTD. However, all of these (should) have been fixed - some time ago as well.

Just before the big debt occurs, switch the currency to GBP or USD and see if it still occurs...

[St256]

It (weird transfer credit numbers) is also not specific problem to Cargo Dist, more a problem in trunk.

I tend to disagree on this statement. Consider the following experiment I tried:

Due to the enhanced traffic handling of cargodist, it is not possible to rebuild a cargodist network in a plain trunk game. So, in order to find out, where the bug occurs, I created three transfer scenarios:
1.: Trunk:

Code: Select all

A --- bus (transfer) --> B <-- train (normal transport) --> C <-- bus (transfer) --- D

(no loading of the bus at B and C (transfer and leave empty))

2.: Cargodist:

Code: Select all

A --- bus (transfer) --> B <-- train (normal transport) --> C <-- bus (transfer) --- D

(the same orders as in scenario Trunk)

3.: CargodistFull:

Code: Select all

A <-- bus --> B <-- train --> C <-- bus --> D

(no transfer orders were used, so the full cargodist features are used)

The scenarios were created from single trunk savegame, resulting in the same topology for all of them. The results, however, do suggest that the weird numbers are caused by cargodist. In the attached image, the exact numbers can be found.
The following list shows the difference between the per-vehicle-total and the finance window total (finance window - per-vehicle):

Code: Select all

  Scenario     Difference    % of total profit
Trunk:           -   5.636       1
Cargodist:       -  52.698      19
CargodistFull:     280.392      72

The difference for the Trunk scenario might be explained by cargo which is still moving. For the other scenarios, especially for CargodistFull, I do not have an explanation. If someone wants to verify, all four savegames (base + three scenarios) are attached in a zipfile. Trunk version was r17596, Cargodist version was a29e6da.

[bluebottle]

Just before the big debt occurs, switch the currency to GBP or USD and see if it still occurs...

Yes, it still happens. In late May 1956 I get saddled with a debt of around 4.2 billion GBP.

If I ground all aircraft I can avoid it altogether. Could it be related to the problem of income not adding up to the correct amount?

[Rubidium]

Differences in trunk are likely just due to 'time lag' between the intermediate payments to the vehicles and the final payment. If, in this scenario, a bus (or two) gets paid for the passengers on in late december 2041 and the final delivery takes place in 2042, the 'all vehicle total' does not include the cargo for which it was already paid in 2041, whereas that piece of cargo is actually paid for in 2042.

Therefor to properly test it you should do a few runs within the same year and then stop all vehicles. This would make the figure more accurate and likely reduce the trunk difference.

However, there is other, probably minor in this case, cause for the difference. It is the fact that if your rating is too low or the amount of waiting cargo is too high cargo vanishes from stations. This will cause the partial payments to be made, but it might not undo the partial payments. See it as people who have requested their money back due to delays. If there were (in the real world) people counting whether they took a specific train they would have made the trip, they would actually have paid for it. Later on they would have gotten their money back, which is 'already' deducted from the vehicle income.

[John]

It (weird transfer credit numbers) is also not specific problem to Cargo Dist, more a problem in trunk.

I tend to disagree on this statement. Consider the following experiment I tried:

1) "It" was referring to the calculation of transfer credits in general, not the differences in vehicles individual profits compared with the finance window.

2)Unless fonso has changed any code on how payments are calculated (which I suspect he hasn't), then all the problems are in trunk. As Rubidium has pointed out, the issues of cargo vanishing and the time lag in the calculations contribute towards it.
The thing you have to remember though, is that in a standard game very few vehicles will be transferring along their routes. Possibly some station feeder services or airport feeder services and that's it. In a cargodist game suddenly EVERY vehicle is transferring across the whole map. This means that any minor differences in a normal trunk game suddenly grow exponentially to be very noticeable in a CargoDist game.
And accordingly, the trunk can cope with these minor differences as they are hardly noticeable.


[edit]
Bluebottle, just tried your game in my cargodist build and get nought. Probably a different version. Anyway, the point is I couldn't find a match for the av8 set you are using (is it older then 1.3?), which let me to notice that according to your newgrf window, av8 is loading with errors. What are those errors?

[bluebottle]

[edit]
Bluebottle, just tried your game in my cargodist build and get nought. Probably a different version. Anyway, the point is I couldn't find a match for the av8 set you are using (is it older then 1.3?), which let me to notice that according to your newgrf window, av8 is loading with errors. What are those errors?

That's right: some of the GRFs specified by the scenario creator, such as av8 and the freight harbour, aren't on my system (either outdated or unobtainable). This is the result in my Linux console:

Code: Select all

dbg: [grf] NewGRF 42650104 (NewGrf\newtown_415.grf) not found; checksum B185F8AF636620BE01F4020C630E81BC
dbg: [grf] NewGRF 56430001 (ottdc_grfpack\def\ttrs3\ttrs3w.GRF) not found; checksum AF3E0A1E6EF0B98DB966594578D1775B
dbg: [grf] NewGRF 535A0C00 (ottdc_grfpack\jp\japanset\japansetw.grf) not found; checksum D7479D7A3A1FEAD64A43492708B801C6
dbg: [grf] NewGRF 44440A01 (ottdc_grfpack\def\pb_av8\pb_av8w.grf) not found; checksum 3722E7AE510BF0126BD99CB8EF1E0E93
dbg: [grf] NewGRF 6D620601 (ottdc_grfpack\def\newstats\newstatsw.grf) not found; checksum 44EB2F155862E4D4F0AB671D7021AF54
dbg: [grf] NewGRF 54570604 (ottdc_grfpack\def\harbour\harbourw_456.grf) not found; checksum 09E2627CACBE087959BCD2B86A07DB4E
dbg: [grf] NewGRF 4A430000 (ottdc_grfpack\def\jcindsta\jcindstaw.grf) not found; checksum A8B0E3328517AF70653FBDF7CDAFE005
dbg: [grf] NewGRF 52453C00 (ottdc_grfpack\def\stolentrees\stolentreesw_162_108.grf) not found; checksum C5B4EC240B33E2DB8D1EA64C97898B5E
dbg: [grf] NewGRF 45520B00 (ottdc_grfpack\jp\jpset_lnd\jpset_lndw.GRF) not found; checksum 366E931C70E3858578F172054924A049
dbg: [grf] NewGRF 44440201 (ottdc_grfpack\def\pb_viaduct\pb_viaduct.grf) not found; checksum DBEE7FED4B51E27E53FB7A14E283BE38
dbg: [grf] NewGRF 44470000 (NewGrf\dep2.1w.GRF) not found; checksum 840B1A2DDDE83A56C3F65C601C8C4C6F

Just for kicks, I tried again and explicitly removed all the red-light GRFs. The big debt still hit me in May.

Edit by Yexo: when you see <line>, the next line should continue on the same line. One big lines breaks the table too much.

Code: Select all

~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs <line>
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext <line>
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug <line>
--enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu <line>
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)

That's what I built it with. Are there any other relevant bits of info I can provide? I might give a fresh git build a go tomorrow.

[John]

Just had another look and managed to recreate the bug. Some more info from the above for Fonso or anyone else:

Disable the AV8 grf, if you have the file. Unpause the game.
Sit back, and watch aircraft number 5.
When it returns to Nagoya and unloads its passengers on the 10th May, the following appears above it: "Cost: Y0 Transfer: Y5,099,820" where Y = Yen.
It looks like that Cost: Y0 is what causes the negative cash amount.

To avoid the bug, just make aircraft 5 go to a hanger or do something to prolong the route in the air.

[bluebottle]

Just had another look and managed to recreate the bug.

Wow, well spotted! I guess a function isn't checking its input.

[huss]

a sudden, massive negative income on my aircraft

That sounds exactly like the problem I had, which I reported to fonso and (according to him and as far as I can tell) has been fixed since then. Have you tried the latest version or the binary supplied by id10terror?