Cargo Distribution

[fonso]

The hotkeys.cfg seems normal and "r" shouldn't actually trigger the road building tool. That's either "1" (build_x), "2" (build_y) or "3" (autoroad). What OS do you use and can you check if the same thing also happens with trunk?

[zlatos]

So, I got a bus running between station A and station B.
When I add station C to the orders window and remove station B everything still works, but after deleting the actual station B the game freezes.

This error appeared in only once, unfortunately I don't know what I did differently.

[fonso]

Can you please post the crash files? There should be a crash.sav, crash.dmp, crash.png and crash.log somewhere in your openttd folder. Those are very helpful when tracking down problems.

[zlatos]

ok, I found the files except the .sav, hope that still helps.

edit: It looks like g414696bb fixed my problem.

[Dewin]

On the most recent Win32 build (openttd-cargodist-g414696bb-cd-windows-win32), I'm getting a reproducible hard lockup at August 7th 1907 in the attached set of autosaves, feels like an infinite loop (OpenTTD jumps to 100% CPU and halts.) Not sure if it's patch related, but figured I'd toss it here.

GRFs in use:

FIRS 0.10.0
2CC Trainset v2.0.0 Beta 5
2cc Chimera
2cc Subways from the 2cc Set
eGRVTS v2.0 - r181
World Cities Town Names GRF
Longer Girder, Steel Bridge.

[fonso]

Thanks for the reports. I've fixed the bugs. zlatos' bug is most likely fixed in g414696bb-cd. I'm not 100% sure about that, but I'm assuming the bug I've fixed there was the cause of the assertion. Next time, try to find a savegame, please. Dewin's bug is fixed in g1fdc43d8-cd which will be compiled tonight. That was a very good bug report. The last save showed the bug but not the cause. The additional previous saves allowed me to easily track down exactly what was happening.

Both new versions are savegame compatible with gdc70fe71-cd and each other. Dewin, if you want to continue your game, load autosave9, not autosave10 or autosave0.

[dasy2k1]

Ive been looking into the hotkeys issue, its not the R key that is selecting stuff but the numbers keys,

I cant seem to reproduce it in trunk but it is sporadic at the best of times
unless I play a game in trunk for a while I cant be sure that it repoduces.

Given i rename all my road stops with RX,Y,Z at the end which corrispond to the vehicle groups using them as a basic way of keeping track of what the hell is going on when there are 10 differnat bus routes serving the same station! it can cause some problems,

prehaps if i modify my hotkeys.cfg to remove the numbers to build tools connection it may solve the problem for now

[fonso]

dasy2k1: Are you using the numbers row above the letters or the keypad on the right of your keyboard to type in the numbers? Or do you have a laptop where the keypad is mixed into the letters and you have to press a special button to activate it? Can you take special note of the state of the numlock key next time you try to reproduce it? And what operating system are you using? Windows? Mac OS? Something else?

[fonso]

I just tried it: If you're typing the numbers with numlock off on the keypad, the build tools are indeed selected. If you're doing the same with numlock on, the numbers are typed. That behavior, though weird, to say the least, is perfectly reproducible in trunk. I've posted a bug report for that: http://bugs.openttd.org/task/5504

[dasy2k1]

Not 100% sure,

i use both the numberpad keys and the row above the letters depending on mood,
I have removed the hotkeys and it still dosent work all the time. for whatever reason it will stop accepting any keyboard input in text boxes at all
its as if the box wasent focused... will try toggling numlock to see what happens, (not easy as i dont have a LED for numlock as its a laptop)

using linux (mint) x86_64

[fonso]

There's another big update today. The changes are mostly syntactical, though. I've refactored the linkgraph API again for better readability and more intuitive usage. Still, watch out for bugs, please.

And I've done some profiling. The surprising result is that the slow thing when opening the smallmap or switching on the viewport overlay is actually GfxDrawLine. Basically it iterates over every pixel on the line and draws them all separately, checking for each pixel if it's really visible (which most of them aren't, in our case). There's some potential for optimization I'd say. All the other cargodist stuff is totally negligible if you're playing a "normal" game. I have an example for one of those massive Cindini games which actually push the MCF algorithm to its limits. However, it's more than 3 years old and a lot has changed since then. Does anyone have a more recent example of a really big game? Could I have that for testing? The openttdcoop games are mostly unsuitable because the graph topologies are either star-shaped or heavily restricted in their orders, with lots of "transfer and leave empty". Both kinds of topologies are really easy for the MCF algorithm.

[aantono]

Got a crash of the game with the message - "Assertion failed at line 451 of /bamboo/src/cargopacket.cpp: (cargo_next != next_station || cargo_next == INVALID_STATION) && cargo_next != current_station"

Logs and save attached.

[fonso]

Thanks a lot aantono, that was very helpful. I've found the bug and fixed it. I can build a savegame-compatible version for you now if you want. Unfortunately I don't have a Mac. You can choose between 32bit-Windows and 64bit-Linux. If you want to build yourself you can apply the following patch to fix the bug:

Code: Select all

diff --git a/src/station_cmd.cpp b/src/station_cmd.cpp
index e491d36..398a207 100644
--- a/src/station_cmd.cpp
+++ b/src/station_cmd.cpp
@@ -4067,10 +4067,11 @@ StationID FlowStat::GetVia(StationID excluded, StationID excluded2) const
        uint begin2 = (it2 == this->shares.begin() ? 0 : (--it2)->first);
        uint interval2 = end2 - begin2;
        if (interval2 > new_max) return INVALID_STATION; // Only the two excluded stations in the map.
-       new_max = new_max - interval;
+       new_max -= interval2;
        if (begin > begin2) {
                Swap(begin, begin2);
                Swap(end, end2);
+               Swap(interval, interval2);
        }
        rand = RandomRange(new_max);
        if (rand < begin) {

[aantono]

Thanks a lot aantono, that was very helpful. I've found the bug and fixed it. I can build a savegame-compatible version for you now if you want. Unfortunately I don't have a Mac. You can choose between 32bit-Windows and 64bit-Linux. If you want to build yourself you can apply the following patch to fix the bug:

Thanks a lot for the patch. I think I'll try building out a version myself. Is this fix already in the trunk and available with the latest nightly? If so, I might as well update to that and start from scratch (this was a prototype game to begin with)

[fonso]

Is this fix already in the trunk and available with the latest nightly? If so, I might as well update to that and start from scratch (this was a prototype game to begin with)

The fix is not about trunk, but specific to cargodist. The compile farm will build it tonight and the version will be g2fd6a1a7-cd. It will be savegame-compatible with the previous version of cargodist, but not with the one you were playing.

[aantono]

Is this fix already in the trunk and available with the latest nightly? If so, I might as well update to that and start from scratch (this was a prototype game to begin with)

The fix is not about trunk, but specific to cargodist. The compile farm will build it tonight and the version will be g2fd6a1a7-cd. It will be savegame-compatible with the previous version of cargodist, but not with the one you were playing.

That's what I was referring to, when saying trunk (meaning trunk of cargodist branch)
I'll wait till tonight and will get the final binary. Wanted to check out the new additions anyways. So good reason to start over...

[Kevo00]

Hello - got a possible bug, but I may have screwed up somewhere. I have tried gfa7cddf9 on the Mac, but while my station window for cargo stations (e.g. coal) shows the usual drop-down cargodist information, there is none displaying for passengers. I have tried this with both a railway station and a multiple stop tram route. I don't know if this is a graphical error or if passengers are genuinely not cargodisting. See screenshot.

Is this me or a bug?

[Eddi]

have you checked the settings under advanced settings->linkgraph? for passengers this setting should be set to "symmetric" (you are usually transporting them back and forth both ways) and for other cargos "asysmmetric" (you are usually transporting them from a source to a destination). if set to "manual", cargodist will not apply to this type of cargo.

[Kevo00]

Yup, that works. Had a feeling it would be a setting I hadn't found. Many thanks.

[fonso]

Since r25119 trunk has an improved clipping and visibility check for line drawing and today's cargodist geef1f48f-cd inherits that. The improvement makes the link graph overlay for smallmap and viewport about 10 times faster. The exact performance numbers depend heavily on screen resolution and zoom factor. Let me know about your experiences.