Cargo Distribution

[YoGz]

Sorry, but Extra Zoom Levels has nothing remotely to do with CargoDist, so I doubt it would be included. Possibly someone with some extra time on their hands can merge it for you.

So does zoom in the minimap but still it was incorporated...

[petert]

Zoom in minimap had to do with interface, and was incorporated because of the stats in the minimap. Extra Zoom Levels deals with graphics.

[Zuu]

Those warnings come for me too, just ignore them.

Reporting of 64bit specific warnings seams quite useful to me. So I would rather not ask 64bit users to ignore warnings they see until I know that fonso use the same compiler in a 64 bit environment.

Keep in mind that this thread is related to development, not some random place for users to hang out.

[fonso]

Reporting of 64bit specific warnings seams quite useful to me. So I would rather not ask 64bit users to ignore warnings they see until I know that fonso use the same compiler in a 64 bit environment.

Keep in mind that this thread is related to development, not some random place for users to hang out.

I think I have fixed the cause this morning. Maybe you can retry with the newest version. It also breaks savegame compatibility as I found out that 16 bits are not enough for the number of flow stats per station.

[Creat]

Yes, most are gone now, you just missed one ^^

Code: Select all

warning C4267: '=' : conversion from 'size_t' to 'uint32', possible loss of data	src\saveload\station_sl.cpp	419

[zedd]

So I built like this

Train A - Airport A - Airport B - Train B

All stations accepts passengers and just default goto orders. Passangers are set to symmetric (all settings are default).
Train capacity is very much higher then the between the airports.
Why do the train A pick up passengers at Airport A that are bound for B stations? The trains seems to clear out the airports every time regardless of where it sais people want to go, basically like OpenTTD normally do when you try to use airports as hubs...

This way I get empty planes going back and forth despite loads of people indicating they want to go from city A to city B

[Jans]

All stations accepts passengers and just DEFAULT goto orders.

Why do the train A pick up passengers at Airport A that are bound for B stations?

If you read more carful you can read you HAVE TO use non stop ordes. All other types will afect this behavior.
Only a few days ago Fonso ask: "Should I show a warning message?"
Fonso you see it seems to be nessesary.

[zedd]

Yes this is pretty useful information ... thanks.
I would recommend pointing it out better on the wiki page.
I did actually read most of it (why I didn't bother reading the first post here carefully enough to see the red text).
But if you happen to skim the vehicle loading section there it is easy to miss.

So planes are always handled as non-stop?

[Jans]

Fonso write yes, because the could not stop beetween two stations.

[Creat]

I was playing a network game today and we had quite a few desyncs (save game attached, 2nd player desynced right before it was saved and multiple times shortly thereafter).

We also both had OpenTTD close due to the following assertion:

assertion_error.jpg (13.26 KiB) Viewed 3946 times

Version reported (for the save game) is: g41f5ec59

EDIT: Unfortunately there was no clear connection to any action taken by us in particular, pointing to the cause of either.

[zedd]

This seems to work better then any destination patch I have tried before.

However there is still issue with hundreds of people wanting to go to oil rigs that are producing almost no passengers. Maybe should make something to reduce the amount of persons that want to go to oil rigs.

[fonso]

I was playing a network game today and we had quite a few desyncs (save game attached, 2nd player desynced right before it was saved and multiple times shortly thereafter).

We also both had OpenTTD close due to the following assertion:

Version reported (for the save game) is: g41f5ec59

EDIT: Unfortunately there was no clear connection to any action taken by us in particular, pointing to the cause of either.

Thanks for the report. Were the desyncs before or after the assertion (maybe you reloaded the game) or both? The assertion is clearly due to some general corruption of the game state, not necessarily related to cargodist. The corruption can have occured much earlier and of course that can easily lead to desyncs, too. With the provided savegame I can neither reproduce the assertion nor the desync, though. So I guess the corruption wasn't saved in the savegame. Are there earlier saves for this game? And how long did the game run after saving that savegame until it hit the assertion?

[Creat]

I'm pretty sure that the first thing that happened was me dropping out of the game due to an assertion. The person who didn't crash saved the game (it was pretty early) which I reloaded and we continued, this obviously could have corrupted the game state. But I know the assertion can occur on it's own/in normal play, since I was playing a new game after I posted this and it happened again. No network game this time and no questionable save games were involved
I've attached the save game, but I just tried to simply fast-forward 3 or 4 years and no assertion, so in some way it has to be related to user interaction (or at least to whatever I've changed after saving the game) and could also always be an error from the used trunk version (speaking of trunk, how can I see which trunk version a git checkout is based on?).

I'll play around a bit later again (this time with a debug version) to see if I can get any more specific...

EDIT: couldn't reproduce the assertion so far, even with that save game (also tried a new game)

[Creat]

[double post due to entirely new topic]

I think I have found a problem with cargo payments/transfers. Let me first say that I think I'm aware how that system works or should work. Not only from reading this thread but also the (few) wiki-article(s) (like this one) and more importantly the source code responsible, which most notably seems to be:

• cargopacket.cpp (functions VehicleCargoList::DeliverPacket and VehicleCargoList::TransferPacket)
• economy.cpp (functions CargoPayment::PayFinalDelivery and CargoPayment::PayTransfer, both are based upon GetTransportedGoodsIncome)

So my understanding is that this works as follows (just to make sure I didn't just misinterpret something):
If a packet is transferred, an estimated transfer reward is displayed (and credited to the vehicle for it's statistics) based on what a payment would be if the transferred cargo had been transported from where the vehicle picked it up to here (where it's just been transferred) assuming days_in_transit as the travel time. This is also saved to the cargo packet as a feeder_share (cumulative, in case of multiple transfers). When a packet gets finally delivered the income/cost displayed is calculated from the actual income (GetTransportedGoodsIncome return this) minus everything payed out for previous transfers (contained in feeder_share), which can of course be negative.

First let me describe the situation in the attached save game so you can find your way around easily: There is a ferry service between a central hub ("Fort Malburgh Station") and a distant city ("St. Proddown Docks"), which has no other connection other than that ferry (ignore the train station there, it has never been used and isn't connected to the dock anyway). At the distant city there are only passengers from "this station" and the ferries aren't accidentally carrying over passengers for other destinations since they never show "transfer" rewards there (and no passengers with a source other than "this station" ever appear there even for the shortest period).
To better illustrate this route, everything that isn't on it has been sent to depots shortly before the game was saved.

Now on to the problem: The mechanics described above imply that if a transport (in this case a ship) is carrying only cargo that has never been transferred before and delivers/transfers this cargo at it's first stop, the income part can't be negative since there is nothing to be subtracted from the income. Unfortunately this is not the case here. Ships are about to arrive at the hub coming from the distant city showing negative income (actually all ships on that route always do when arriving at the hub). Debugging shows that they are delivering and transferring cargo packets which have non-zero feeder_shares, which in my understanding shouldn't happen.
This doesn't just apply to ships but all transports as far as I can tell. To see this just stop all ships and start all road vehicles from the group "Fort Ex E". They also serve as a point-to-point connection between said hub and a dead-end ("Fort Malburgh East") with no other service that has only passengers from "this station". They also often show negative income unloading at the hub (let it run for a while if it doesn't happen straight away, it will eventually).

If I can be of any more help here please just let me know (I've prepared this as well as I could, hope this is helpful or I'm just wrong about something).

[fonso]

I think I have found a problem with cargo payments/transfers...

Thanks a lot. That's a very detailed and well written bug report. And yes, you're probably right. The profit numbers look weird. It might have something to do with the new reservation system. I'll have a look.

Edit: I've found and fixed it. git and patches have been updated. Some cargopackets got transfer payment for the full packet but were only partially transferred then. If in the next unloading round the remaining part was delivered the residual transfer payment was subtracted from the visual profit. Also the flow stats were updated for the full packet in case of partial transfers. This could lead to incorrect transfer/deliver decisions on later packets.

Edit2: There are other funny problems in this area. The decision to keep a cargo packet in a vehicle is not remembered for further unloading rounds. This is the effect you see when vehicles are unloading less and less cargo in each unloading round. The decision to keep or unload is taken in each round for each cargo packet again considering the flow stats in this specific round. Of course the flow stats change a little all the time. So a cargo packet that was kept in one round may be unloaded in the next round. As soon as a single packet is unloaded the unloading continues for another round. In that round the flow stats have changed a little again and so on. I think I'll use the reservation list to store the packets to be kept in the vehicle.

[el koeno]

Fonso; I have a game which is starting to slow down just a bit. It´s with the binary ID10Terror posted october 10, so it´s quite dated. You said you tackled the speed issues now, but if you´re interested let me know.

[fonso]

Fonso; I have a game which is starting to slow down just a bit. It´s with the binary ID10Terror posted october 10, so it´s quite dated. You said you tackled the speed issues now, but if you´re interested let me know.

That binary already has some optimizations. It shouldn't be much slower than trunk. So please post the game and I'll have a look.

[el koeno]

Fonso; I have a game which is starting to slow down just a bit. It´s with the binary ID10Terror posted october 10, so it´s quite dated. You said you tackled the speed issues now, but if you´re interested let me know.

That binary already has some optimizations. It shouldn't be much slower than trunk. So please post the game and I'll have a look.

I´m not sure if it´s slower, obviously I haven´t played this particular savegame with trunk. I´ve built some ships, so at least some slowdown was expected. I was just wondering if you´re still interested in analyzing the performance.

[Zuu]

el koeno: You could try to stop all your ships using the global stop flag in the ships list window. Then you would see how much the ships contribute to the slowness.

[id10terror]

OpenTTD CargoDist compiled with vc2008+dxsdk 31.999 bit

commit 04c1cf6712c6bad5403496be91f862b23f917874
Merge: 41f5ec5... 6f07f41...
Date: Wed Nov 4 01:04:24 2009 +0100