Cargo Distribution

[fonso]

Firstly I had a few crashes, that I've been unable to reproduce. It happend two times while clicking the + in the station GUI, right when a train was in there. But as said, I haven't reproduced it yet.

I'll play around with your savegame a bit and see if I can catch it.

Secondly, the station GUI doesn't remember my choices: I'd like it to stay Via-Destination-Source. Is this possible?

I can implement that. It won't be very difficult.

Thirdly, I've got the same problem reylas reported; I've build a goods line from Bienne Factory to Friburg Sawmill (see save game). From the train stations, truck transport the goods into town. Then I decided to add Zug to the network, in march 1941. It's '43 now, and the goods still want to take the direct train between Bienne and Fribourg, which doesn't exist anymore. Meanwhile, my goods trains are running empty.

For games this small you need to set average unit to 1 and average length to something between 32 and 64 (you can set the unit higher and the length lower if you like, the important number is their product). Then the capacity of the old route will disappear much more quickly. The default values are probably not so well chosen. I'll change that.

Hmm.
I have build it again and had a few warnings on compiling.
It compiled, and I had some visitors... I did not notice, sorry.
Here are the warnings.

The second and third block of warnings are easy to understand and fix. If someone knows what the first block means, please tell me. It might also be a hint for the crash.

[Eddi]

[OT](BTW, I was expecting snow from the Alpine climate, but there is none, anyone know why?)[/OT]

snow only appears in snowy climate... this also applies to alpine, which is inactive in temperate climate. Alpine is an arctic replacement, not a snow-in-temperate grf.

you notice you have done something right if stolentrees stops working. (which is only active in temperate)

[el koeno]

Thirdly, I've got the same problem reylas reported; I've build a goods line from Bienne Factory to Friburg Sawmill (see save game). From the train stations, truck transport the goods into town. Then I decided to add Zug to the network, in march 1941. It's '43 now, and the goods still want to take the direct train between Bienne and Fribourg, which doesn't exist anymore. Meanwhile, my goods trains are running empty.

For games this small you need to set average unit to 1 and average length to something between 32 and 64 (you can set the unit higher and the length lower if you like, the important number is their product). Then the capacity of the old route will disappear much more quickly. The default values are probably not so well chosen. I'll change that.

After a couple of months it started working (for the factory), thanks. The only problem is that neither the factory nor the sawmill sends any goods to Fribourg. There is a connection, the station does accept goods. Well, it's only one truck, no worries, I'll keep on testing. Tomorrow.

[fonso]

After a couple of months it started working (for the factory), thanks. The only problem is that neither the factory nor the sawmill sends any goods to Fribourg. There is a connection, the station does accept goods. Well, it's only one truck, no worries, I'll keep on testing. Tomorrow.

Remove the full load order. The truck goes into a vicious circle of waiting for cargo while its link is decreasing ever more which leads to less cargo supplied and more waiting time. In the end the link disappears and no cargo is sent that way.

This could at least partially be solved by making full load an overriding order which takes any cargo waiting there, not only cargo going over the link the vehicle is serving. However in your game the truck from Gossau Woods to Zug shows that this won't work in any case. As long as there is no link between Gossau Woods and Zug the goods trains won't unload anything in Gossau Woods and the truck still has nothing to pick up. I'll think of a solution for this problem. Perhaps I should somehow detect that "is serving" relation between a vehicle and a link. Then I'd be able to find out if a link is really dead or if it should be kept alive.

[el koeno]

After a couple of months it started working (for the factory), thanks. The only problem is that neither the factory nor the sawmill sends any goods to Fribourg. There is a connection, the station does accept goods. Well, it's only one truck, no worries, I'll keep on testing. Tomorrow.

Remove the full load order. The truck goes into a vicious circle of waiting for cargo while its link is decreasing ever more which leads to less cargo supplied and more waiting time. In the end the link disappears and no cargo is sent that way.

This could at least partially be solved by making full load an overriding order which takes any cargo waiting there, not only cargo going over the link the vehicle is serving. However in your game the truck from Gossau Woods to Zug shows that this won't work in any case. As long as there is no link between Gossau Woods and Zug the goods trains won't unload anything in Gossau Woods and the truck still has nothing to pick up. I'll think of a solution for this problem. Perhaps I should somehow detect that "is serving" relation between a vehicle and a link. Then I'd be able to find out if a link is really dead or if it should be kept alive.

Ahaaa... I see. It all makes perfect sense. Thanks for checking.

[fonso]

I have updated the git repository:

• when a vehicle is passing via a station with a stopping but no-unloading order the flows are calculated correctly now.
• while a vehicle is loading the link capacity to its next stop is locked and cannot fall below the vehicle's capacity. This should prevent the vicous circle with full load orders. (It also breaks savegame compatibility)
• The compile warnings on windows are partially resolved.

Now please help me find that crash. When that is resolved, I will merge up with trunk and post a new patch.

[jub]

I've got assert when playing with the new version from git:
mcf.cpp:57

I have just created randomly bus stops and buses. Then I added bus to a new stop and the assert have appeared.

[fonso]

I've got assert when playing with the new version from git:
mcf.cpp:57

I have just created randomly bus stops and buses. Then I added bus to a new stop and the assert have appeared.

Thanks. I found and corrected this one. It has been introduced by the frozen capacities change. If a vehicle was loading a short time, the linkstat's frozen value was updated but the capacity value stayed at 0. Yet, the MCF algorithm doesn't like edges with 0 capacity and asserts on them.

It's nice to have found this problem, but unfortunately it's not the crash I was looking for ...

[jub]

Hello,

I have got crash with given savegame on 31 dec/1 jan. It's the same savegame as above, only fast forwarded for 2 years.

Regards

[el koeno]

Done testing for now. My game starts having trouble (going really slowly), and then simply stops. Train 73, which I had just built at the time of the autosave, and you can see it exiting the depot, seems to be responsible: reversing and selling it before it reaches its first station "solves" the problem.

[fonso]

I have got crash with given savegame on 31 dec/1 jan. It's the same savegame as above, only fast forwarded for 2 years.

This problem, I think, has nothing to do with my code. Obviously it happens when it tries to start an AI but none is available. Then it says:

Code: Select all

dbg: [ai] No suitable AI found, loading 'dummy' AI.
dbg: [ai] The AI died unexpectedly.

Then it crashes. The backtrace looks as follows:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
0x00733fc2 in ScriptFileInfo::GetURL (this=0x0)
    at c:/openttd-svn/src/ai/../script/script_info.hpp:63
63              const char *GetURL() const { return this->url; }
(gdb) bt
#0  0x00733fc2 in ScriptFileInfo::GetURL (this=0x0)
    at c:/openttd-svn/src/ai/../script/script_info.hpp:63
#1  0x00443a29 in AIInstance::Died (this=0x4ab0fc8)
    at c:/openttd-svn/src/ai/ai_instance.cpp:264
#2  0x00443cc1 in AIInstance::GameLoop (this=0x4ab0fc8)
    at c:/openttd-svn/src/ai/ai_instance.cpp:309
#3  0x0042d51e in AI::GameLoop () at c:/openttd-svn/src/ai/ai_core.cpp:68
#4  0x0052dcd6 in StateGameLoop () at c:/openttd-svn/src/openttd.cpp:1113
#5  0x0052df47 in GameLoop () at c:/openttd-svn/src/openttd.cpp:1193
#6  0x005fce31 in VideoDriver_Win32::MainLoop (this=0x3ed7d20)
    at c:/openttd-svn/src/video/win32_v.cpp:874
#7  0x0052ceb3 in ttd_main (argc=1, argv=0x22fde0)
    at c:/openttd-svn/src/openttd.cpp:692
#8  0x0061633b in WinMain (hInstance=0x400000, hPrevInstance=0x0, 
    lpCmdLine=0x241eff "", nCmdShow=10) at c:/openttd-svn/src/win32.cpp:1012
#9  0x0065184a in main ()

Clearly someone is trying to dereference an invalid AI info there. This only happens if there is no AI available. If I download for example AdmiralAI and TownCars before loading the game, it doesn't happen anymore. The behaviour is the same on Linux and Windows. I will file a bug report for it.

[XeryusTC]

I've been playing with this patch for a bit and there are are a couple of things I would really like to see. First of is that the station window remembers what display option you selected last like el koeno suggested before. This was one of the first things that annoyed me with this patch. Maybe it could be configurable via the patch window as the cargodest patch from Celestar does.
Second is to make the destinations/sources/vias etc ctrl-clickable like in the orders window so you can ctrl-click them and the main window moves to that location. This would surely make it very easy to identify routes and most targets etc.
Last I would suggest to make the flow stuff in the map overview a bit easier to understand, right now I've seen 4 bars popping up and even though I've read the wiki I still can't make soup of the graph, maybe some easier representation would be better but I can't currently think up a better one.

Edit: Maybe you shouldn't ditch the view in the map window but you should make it possible to view a normal list of all connections or maybe just the connections a certain station has. That way you can see all the information without it being tiny or overlapping each other. I recon that having a list in the station window of all of the station's connections would be best.

[pasteur]

Compiling on VC++ 2008 EE, I got an error.

Code: Select all

1>------ Rebuild All started: Project: strgen, Configuration: Debug Win32 ------
1>Deleting intermediate and output files for project 'strgen', configuration 'Debug|Win32'
2>------ Rebuild All started: Project: version, Configuration: Debug Win32 ------
2>Deleting intermediate and output files for project 'version', configuration 'Debug|Win32'
2>Determining version number
1>Compiling...
2>Microsoft (R) Windows Script Host 버전 5.8
2>Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
1>string.cpp
1>strgen.cpp
1>..\src\string.cpp(8) : fatal error C1083: Cannot open include file: 'core/math_func.hpp': No such file or directory
1>alloc_func.cpp
1>Build log was saved at "file://d:\compilee\svn.openttd.org2\objs\strgen\BuildLog.htm"
1>strgen - 1 error(s), 0 warning(s)
3>------ Rebuild All started: Project: langs, Configuration: Debug Win32 ------
3>Deleting intermediate and output files for project 'langs', configuration 'Debug|Win32'
3>Generating strings.h
3>'..\objs\strgen\strgen.exe'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는
3>배치 파일이 아닙니다.
3>Project : error PRJ0019: A tool returned an error code from "Generating strings.h"
3>Build log was saved at "file://d:\compilee\svn.openttd.org2\objs\langs\BuildLog.htm"
3>langs - 1 error(s), 0 warning(s)

Without applying patch, there was no error.

[fonso]

New version, some problems resolved ...

First the most probable cause of the mysterious crash we had a few posts ago was that the MCF algo was still building circles. After some playing around I could reproduce it. Now I have ditched the idea with increasing lengths and implemented an explicit circle check in pass 1. This should resolve the bug. Also the problem with amounts of entries in the station GUI not adding up has been resolved (even if no one noticed ). Then there were some other problems you reported:

Compiling on VC++ 2008 EE, I got an error.
...
Without applying patch, there was no error.

Somehow you deleted core/math_func.hpp. I don't think my patch does that. Try again please.

I've been playing with this patch for a bit and there are are a couple of things I would really like to see. First of is that the station window remembers what display option you selected last like el koeno suggested before. This was one of the first things that annoyed me with this patch. Maybe it could be configurable via the patch window as the cargodest patch from Celestar does.

It remembers the last setting now.

Second is to make the destinations/sources/vias etc ctrl-clickable like in the orders window so you can ctrl-click them and the main window moves to that location. This would surely make it very easy to identify routes and most targets etc.

Good idea. Has been noted.

Edit: Maybe you shouldn't ditch the view in the map window but you should make it possible to view a normal list of all connections or maybe just the connections a certain station has. That way you can see all the information without it being tiny or overlapping each other. I recon that having a list in the station window of all of the station's connections would be best.

Also a good idea.

Done testing for now. My game starts having trouble (going really slowly), and then simply stops. Train 73, which I had just built at the time of the autosave, and you can see it exiting the depot, seems to be responsible: reversing and selling it before it reaches its first station "solves" the problem.

Oh, I missed that one. Sorry. Does it still happen with the new version?

I've got assert when playing with the new version from git:
mcf.cpp:57

resolved. Thanks for all the feedback.

I'll be busy with other things for the next two weeks, so I won't do any functional improvements to the patch during that time.

[fonso]

Done testing for now. My game starts having trouble (going really slowly), and then simply stops. Train 73, which I had just built at the time of the autosave, and you can see it exiting the depot, seems to be responsible: reversing and selling it before it reaches its first station "solves" the problem.

Found and fixed. I've posted a new version. The problem was that the antisymmetric demand function you use for mail (thanks for testing strange corner cases ) didn't like graphs with only one node that has demand as well as supply.

[Toni Babelony]

Something strange in my games when compiling with the latest patch... Numbers seem to be missing. I have attached a screenshot of a game and you'll see. The towns, map-size, etc. also don't have numbers, but zeroes. In previous compilations this wasn't the case.

[fonso]

Something strange in my games when compiling with the latest patch... Numbers seem to be missing. I have attached a screenshot of a game and you'll see. The towns, map-size, etc. also don't have numbers, but zeroes. In previous compilations this wasn't the case.

Savegame please.

[Toni Babelony]

Here's a savegame, though it already starts in the main menu. The map size and years aren't displayed properly as well.

[el koeno]

Done testing for now. My game starts having trouble (going really slowly), and then simply stops. Train 73, which I had just built at the time of the autosave, and you can see it exiting the depot, seems to be responsible: reversing and selling it before it reaches its first station "solves" the problem.

Found and fixed. I've posted a new version. The problem was that the antisymmetric demand function you use for mail (thanks for testing strange corner cases ) didn't like graphs with only one node that has demand as well as supply.

I didn't intend to use mail, and I didn't even notice I attached mail wagons to the train. Silly me.

I simply sold the train and continued playing. I'm having some problems with my valuables transport and some stations seem to have passengers waiting that actually have that very station as their destination... I don't have the time right now, but the behaviour (both of the problems) can probably be seen in the previous savegame I posted.

[ftk]

Getting the following crash with latest (cargodist_r16157.diff). It occurs as soon as the train leaves the station.

Code: Select all

openttd: /home/ftk/openttd/src/vehicle.cpp:1537: void Vehicle::LeaveStation(): Assertion `ls.frozen >= v->cargo_cap' failed.
Aborted

On occasion I want to get quick positive cash flow and will create a coal route right off the bat. Create coal mine station, a little bit of track, create train, and set to full load any cargo. I start the train and have it load while I finish the rest of the line and build the power plant station. Next, I modify train orders to append the power station.

Once the train is done loading I get the crash. Savegame attached.