Cargo Distribution

[el koeno]

This looks crazy good Fonso, congratulations on getting it to work.

Except of course I'm too rubbish to get patching to work so I have to wait until it makes trunk.

Same here! Though I'd rather wait until someone posts a binary, than wait untill trunk inclusion.

EDIT: I like the new poll.

[fonso]

MSVC doesn't like it:

Code: Select all

Error	1	error C2668: 'sqrt' : ambiguous call to overloaded function	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\smallmap_gui.cpp	849	openttd
Error	2	error C2668: 'sqrt' : ambiguous call to overloaded function	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\smallmap_gui.cpp	850	openttd
Error	3	error C2668: 'sqrt' : ambiguous call to overloaded function	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\smallmap_gui.cpp	851	openttd
Error	4	error C2668: 'sqrt' : ambiguous call to overloaded function	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\smallmap_gui.cpp	852	openttd

The previous version compiled without problems.

It's because sqrt is available for float and double. I call it with uint as argument, so it doesn't know what to do. Fixed: I cast it to float now.

Also some warnings:

Code: Select all

Warning	5	warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\cargopacket.cpp	210	openttd
Warning	6	warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)	c:\Users\as\Desktop\Uusi kansio (2)\svn.openttd.org\src\cargopacket.cpp	214	openttd

Fixed. Obviously it doesn't like assigning an int to a bool, so it's compared to 0 now. Whatever.

and my mingw (gcc 3.4.2) doesn't like std::vector::data() method. It's not part of some STL implementations.

Code: Select all

src/saveload/linkgraph_sl.cpp: In function `const SaveLoad* GetComponentDesc()':
src/saveload/linkgraph_sl.cpp:60: error: 'class GetComponentDesc()::SaveLoadVector' has no member named 'data'

Fixed. &vector[0] does the same job. It only looks a little ugly.

You can get a new all-in-one patch with the problems fixed in the first post. Thanks for reporting.

[MJS]

If anyone has compiled a Windows binary, whould s/he care to post it here?

[fonso]

I've found another bug. Removing stations might crash the game. I'll post yet another version of the all-in-one patch in the first post ...

[Eddi]

It's because sqrt is available for float and double. I call it with uint as argument, so it doesn't know what to do. Fixed: I cast it to float now.

you do know that floating point operations cause desyncs, right?

[fonso]

It's because sqrt is available for float and double. I call it with uint as argument, so it doesn't know what to do. Fixed: I cast it to float now.

you do know that floating point operations cause desyncs, right?

Ouch. Why? Luckily I only use float operations when calculating the sizes of the bars in the smallmap (sqrt) and for the MCF algorithm. Square roots of integers should be easy to calculate with an own method. And the MCF algorithm will be replaced anyway. I already have an idea on how to calculate that without floats. (And yes, those rounding errors you see in the station GUI sometimes are caused by float to integer casts, too ...)

[Eddi]

It's because sqrt is available for float and double. I call it with uint as argument, so it doesn't know what to do. Fixed: I cast it to float now.

you do know that floating point operations cause desyncs, right?

Ouch. Why? [...]

because different processors are not guaranteed to round the same way. e.g. a processor that does all operations on 80 bit internally, and then round to 64 bit, will behave differently than a processor that does all operations on 64 bit, also, different compilers or libraries may shuffle around the floating point operations, which can yield different rounding results

[fonso]

because different processors are not guaranteed to round the same way. e.g. a processor that does all operations on 80 bit internally, and then round to 64 bit, will behave differently than a processor that does all operations on 64 bit, also, different compilers or libraries may shuffle around the floating point operations, which can yield different rounding results

I see ... one more reason to ditch the MCF algorithm then. It's only causing problems anyway - numeric instability, failure to effectively balance routes, higher flows than capacities and failure to allocate all possible demands namely.

[-3s-]

I am new member, but a long-time lurker.

I love cargodest and I am glad that you (Fonso) are taking efforts to develop cargo destinations further.

I just compiled your patch (cargodist_r16003_2.diff) with trunk (r16003) and stationsgui (latest version) for windows. It compiles fine, just like OpenTTD.

When I start a game and start to run a two buslines (to A->B and A->C) the game freezes after a while. I never had this before. I was watching the station gui, where it states that passengers were waiting for a destination unknown.

I don't get a real error, I just have to "end task" and thus end OpenTTD.

Don't know if this is really a helpful explanation for you, I am no programmer and can't look into the source or something like that.

[fonso]

I am new member, but a long-time lurker.

I love cargodest and I am glad that you (Fonso) are taking efforts to develop cargo destinations further.

I just compiled your patch (cargodist_r16003_2.diff) with trunk (r16003) and stationsgui (latest version) for windows. It compiles fine, just like OpenTTD.

When I start a game and start to run a two buslines (to A->B and A->C) the game freezes after a while. I never had this before. I was watching the station gui, where it states that passengers were waiting for a destination unknown.

I don't get a real error, I just have to "end task" and thus end OpenTTD.

Don't know if this is really a helpful explanation for you, I am no programmer and can't look into the source or something like that.

Which "stationsgui" is that? You shouldn't apply any patches on top of cargodist. It should work with unrelated things like diagonal leveling ot similar, but don't count on it. Patching a different stations gui on top of cargodist is sure to cause problems. The "rudimentary GUI" I mention above is already included.

If you still see that behaviour with plain cargodist, could you run the game from a command line and post me the messages you see there?

[-3s-]

Which "stationsgui" is that? ?

It is the Improved Build Station GUI (IBS GUI) (v3-imp-station-build-gui-r15948.diff, http://www.tt-forums.net/viewtopic.php?f=33&t=41222)

You shouldn't apply any patches on top of cargodist. It should work with unrelated things like diagonal leveling ot similar, but don't count on it. Patching a different stations gui on top of cargodist is sure to cause problems. The "rudimentary GUI" I mention above is already included.

If you still see that behaviour with plain cargodist, could you run the game from a command line and post me the messages you see there

I first patched the trunk with your patch, then the IBS GUI. I will compile this weekend another version based on trunk and your latest patch, without any other patches. If I encounter any problems I will run the game from the command line. To be continued

[jub]

I experience the same problem as -3s-. I have applied only the patch with cargo-distribution (16003_2) and the game behaves exactly as was described. With two routes A-B and B-C, the game freezes in about a month.

Compiled: mingw
System: windows xp

[Toni Babelony]

I've just tried compiling this patch on my eMac G4, but after a while I get this error:

Code: Select all

[SRC] Compiling dedicated.cpp
[SRC] Compiling demands.cpp
/Users/albohelm/Desktop/OpenTTD/src/linkgraph.h:55: error: using typedef-name 'Component' after 'class'
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Components.h:184: error: 'Component' has a previous declaration here
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp: In member function 'void DemandCalculator::PrintDemandMatrix(ComponentRecord**)':
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:20: error: request for member 'GetSize' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:21: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:22: error: request for member 'GetSize' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:24: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:26: error: request for member 'GetEdge' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp: In member function 'void DemandCalculator::CalcSymmetric(ComponentRecord**)':
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:36: error: request for member 'GetSize' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:37: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:52: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:56: error: request for member 'GetEdge' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:57: error: request for member 'GetEdge' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:59: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp: In member function 'void DemandCalculator::CalcAntiSymmetric(ComponentRecord**)':
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:98: error: request for member 'GetSize' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:99: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:120: error: request for member 'GetNode' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:129: error: request for member 'GetEdge' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp: In member function 'virtual void DemandCalculator::Run(ComponentRecord**)':
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:145: error: request for member 'GetCargo' in '* graph', which is of non-class type 'ComponentRecord*'
/Users/albohelm/Desktop/OpenTTD/src/demands.cpp:146: error: request for member 'GetSettings' in '* graph', which is of non-class type 'ComponentRecord*'
make[1]: *** [demands.o] Error 1
make: *** [all] Error 2

It's quite frustrating, but it seems I'm missing something in my frameworks. Is there a way to compile this on mac, or do I have to wait until the patch is finished or in a more stable state?

Thanks in advance

P.s. I'm quite noobish on this as I only know the very basics on compiling (from the OTTD wiki).

[Rubidium]

That's a classical redefinition of a class. OSX's API headers also contain classes called Component and that clashes. Easiest way to fix is just renaming the class.

[Toni Babelony]

That's a classical redefinition of a class. OSX's API headers also contain classes called Component and that clashes. Easiest way to fix is just renaming the class.

As I'm more of an artist then a coder, could you please explain how to do this and what to do exactly? Maybe it's offtopic, but it'd be nice to play OTTD with destinations again. However, it's not urgent so I can also wait until this is fixed in some way, just to keep this topic clean.

[Rubidium]

As I'm more of an artist then a coder, could you please explain how to do this and what to do exactly?

That's the tricky part. To tell you what to exactly do I have to do it myself too (I don't know where the name is referenced and such). It's better when fonso fixes his patch so it works on OSX than to let you fix up his patch each time you want to play with it.

[fonso]

Thanks for testing - I'm sorry it's a little frustrating, but when coding C++ you always have those incompatibilities between platforms popping up and I think that's the problem we are facing now. So, I need some more information to solve them ...

About the freezing:

• Did you "make clean" before building the patched version? The build system is broken and won't find all the dependencies between the various source files. This leads to a seemingly correct build which behaves strangely afterwards. This could be the reason it actually builds with a second station GUI patch. If all the dependencies are resolved correctly in a clean build chances are very low that it will build together with another modification of the station GUI.
• Could you post a savegame of shortly before the freeze?
• Is the behaviour deterministic? Does it happen with every A-B, B-C configuration you try?
• What platform are you using?

About the "Component" thing:
I have defined a class called "Component" which unfortunately redefines a system-supplied class on Mac OS. You can't do anything on your own, but I will rename it.

I won't be available over the weekend, so you have plenty of time to answer all the questions

[jub]

1) yes, i did build everything with clear sources, only applied the cargo dist. patch and compiled
2) the save is one day before freeze (on 23rd)
3) it seems so, I tried two buses and combination of one bus and one train
4) windows xp, compiled with mingw (gcc3.4.2)

[-3s-]

1) I tried it again today with the latest trunk r16025 and your latest patch cargodist_r16003_2.diff, without any other patches.
2) The save is around the tiem it freezes, it is actually the autosave.
3) It happens the moment I let drive two buses
4) Windows XPxp, compiled with mingw that came with BuildOTTD.

In addition I have my compile log, autosave and a screenshot of the moment with the taskmanagement in fron included.

Hopefully things are more clear for you.

[TrueBrain]

Ever considered using a Mercurial or Git repository for your code? Easier to track, and easier for us to follow