Cargo Distribution

[Valle]

I don't know if the following error is related to the one Alluke experienced, but every time I try to turn around a (non-articulated, of course) locomotive I get an error message claiming "vehicle cannot be turned around". Subsequently, turning around fails.
gba921979 and also g40fd3900 with OS X 10.6.5

[Alberth]

Nope, this was changed in trunk recently, NewGRFs now explicitly have to enable rotation.
You need a different/newer version of your vehicle NewGRF file.

[BlueEagle_nl]

I think this is a great patch. I only miss one small thing...

Imagine:
- One train going from A to D, via B and C.
- One train going from C to G, via E and F.

When opening up station A while there are passengers waiting, it'll show "200 passengers to B"
When unfolding the details of the line "200 passengers to B", it'll show the final destination of those 200 passengers. Eg. 20 to B, 5 to C, 20 to D, 55 to E, 75 to F and 25 to G. But, it does not show how many people are actually unboarding at C (would be 160).

In CargoDest I had an option to view the next hop my cargo packages/passengers made, so I could see via which station/link the people would go. Which would give something like:

Code: Select all

200 passengers via B
- 20 passengers to B
+ 160 passengers via C
  - 5 passengers to C
  - 55 passengers to E
  - 75 passengers to F
  - 25 passengers to G
- 20 passengers to D

Is it possible to bring the next hop-feature to CargoDist?

Further, great patch!

[Eddi]

[edit]sorry, i misread your post. ignore this[/edit]

[fonso]

BlueEagle_nl: It's possible to implement that, but I won't do it anytime soon. Anyone is free to provide further patches on top of cargodist, though.

[zde-nek]

hi, as my old laptop falls apart to small plastic pieces, i consider to buy new one. because i have only few money, i want something really cheap. will 2gb ram be enough for really big map with cargo distribution to run smoothly or should i take 3? what i mean really big? i recently discovered England and Wales scenario, 2048x2048 map with many cities (1000?) and 1700 000 residents.

[Eddi]

2GB is really plenty for openttd, you should more ask the question whether it's enough for your operating system.

[Zuu]

Additionally, unless you run a 64bit OS, you can't use more than 2 GB for OpenTTD in the case it would actually have need for more than that.

[JacobD88]

Additionally, unless you run a 64bit OS, you can't use more than 2 GB for OpenTTD in the case it would actually have need for more than that.

Very OT question... Does the /3GB switch work with OTTD, i know that although it does free up to the full 3.2GB available to windows in a 32-bit environment, not all programs can use above the 2GB limit even with it on... Is OTTD one of the few programs that will recognise that the extra RAM has been freed up (minus what windows takes of course)?

[zde-nek]

thank you for answer. meanwhile i made some testing, tried run big map and computer was really slow - but i had enough free ram - so more important is obviously cpu

[ChillCore]

Hello fonso,

I did some testing with the latest version of CargoDist (r22250) as I noticed a problem when bumping to r22258. This is a problem that I created myself by bumping and I was going to wait and test with your next version ... you would most likely have noticed yourself and reporting problems that do not yet exist ... (*)

However while I was checking to see where it came from and if I could fix it I noticed another problem with your current version.

There is a segmentation fault in the distribution of cargo ...
The most reliable way to reproduce is open a station gui and mess with the sorting and grouping order.
As you can see in the screenshot the game crashed when I clicked "station:planned" but most of the times I am able to click that without a crash. It also crashed one time when resizing the gui and once while just leaving some station guis open while doing nothing.
Finally it seems to happen more often if I select "...: planned" and "via-...-..." but it happens at different occasions each time ...
The game seemed to crash each time at the same point in the code. (also with other test-games than the one posted)

I have attached a backtrace of a debug build and I pasted the crashlog to the end of the file because I forgot to type continue before quit...
Anyway, note that the backtrace is produced on Ubuntu 9.04 and the crashlog, -save and -screenshot on Ubuntu 10.10 due to me not being able to build debug builds on Ubuntu 10.10 and not having lzma on 9.04.


(*)
Future bugreport:

Everybody wants to go to the same place they came from via the same other place even if networks are not connected in any way after bumping.
eg. Create three not connected lines A->B and C->D and E->F and everybody comes from eg. A over C to B also when you open station F's gui. (some cargos do display correctly but most will be messed up.)
Also if you save such a game and reload it the source, destinations and via places change but still in the same way for everybody.
In other words the station gui's strings are messed up in r22258 and later.

[ChillCore]

Double post for the good cause ...

I think I solved the crashy thinghy.
station_gui.cpp line 1636:

Code: Select all

EDIT: adjusted to reflect fonso's correct code.

	/**
	 * Invalidate the cache for the given cargo.
	 * @param cargo ID of the cargo.
+	 * @param gui_scope Whether the call is done from GUI scope. You may not do everything when not in GUI scope. See #InvalidateWindowData() for details.
	 */
-	virtual void OnInvalidateData(int cargo)
-	{
+	virtual void OnInvalidateData(int cargo, bool gui_scope = true)
+	{
+		if (!gui_scope) return;
		this->cached_destinations.Remove((CargoID)cargo);
-		this->SetDirty();
	}

I am not sure if my fix is correct but it does not crash anymore after trying to do all sorts of things with the gui.

The messed up strings is an unrelated issue caused by r22258 that I have not yet been able to fix.

[fonso]

Thanks for the report. The crash is due to StationViewWindow::OnInvalidateData not having been converted to the new system with GUI/non-GUI scope, yet. I have fixed that, but not uploaded yet. The other bug is http://bugs.openttd.org/task/4562 . I'll upload a full version when this is resolved. The patch for the crash is quite simple, I'll attach it in case you want to build something based on < r22258.

edit: ... seems I was slower

[ChillCore]

Thanks for the report. The crash is due to StationViewWindow::OnInvalidateData not having been converted to the new system with GUI/non-GUI scope, yet. I have fixed that, but not uploaded yet.
...
The patch for the crash is quite simple, I'll attach it in case you want to build something based on < r22258.
...
edit: ... seems I was slower

Hehe.
I tried that fix before but I did it with source after r22258 and I at that point I still assumed that both the issues were the same so I reverted it.
After posting my bugreport it hit me that I did not try that with r22250 ... I had two other patches crashing for the same reason in my patchpack so it was not that hard to find after checking the code the backtrace mentioned a bit better -> everything pointed at drawing code ...

So this->SetDirty() is not needed anymore? I will need to check the other patches I fixed to see if I removed it there also, if present that is ... thank you for the patch.
I will adjust my codeblock posted above to reflect your patch to not confuse people.

The other bug is http://bugs.openttd.org/task/4562 . I'll upload a full version when this is resolved.

I checked trunk but apparently not good enough cause I thought it was fine.

[ChillCore]

Thank you for the updated patch fonso, but I'm afraid it still does not work as it should after updating my source.

I could reproduce in clean r22271 and have requested the re-opening of FS#4562.
I attached a screenshot there that shows the issue still in trunk.


EDIT:
Issue fixed in r22273 by Yexo.
Just bumping your source will solve it, no additional codechanges needed.

[donchatryit]

Just wanted to post this to thank fonso for this excellent patch and also for working on a fix for the crash issue, which I was about to report.

fonso, this is really great work. I would love to see it in trunk somehow, maybe as an "Enable Cargo Distribution Tracking" option in Advance settings.

[SketchyGalore]

I would love to see it in trunk somehow, maybe as an "Enable Cargo Distribution Tracking" option in Advance settings.

That was my first reaction when I first started testing it out the other day. No need to hide something so wonderfully-made!

[Eddi]

i skimmed the code a little, and stumbled across this line in linkgraph/mcf.cpp:300

Code: Select all

		cycles_found = this->EliminateCycles(path, node, node) || cycles_found;

i think it can be shortened to

Code: Select all

		cycles_found |= this->EliminateCycles(path, node, node);

according to SmatZ, the function is still guaranteed to execute in this case.


anyway, what i really was searching for, but didn't find was the place where i can tell it to not establish links for orders "no loading and no unloading", which should be treated like waypoints for the linkgraph...

[fonso]

i skimmed the code a little, and stumbled across this line in linkgraph/mcf.cpp:300

Code: Select all

		cycles_found = this->EliminateCycles(path, node, node) || cycles_found;

i think it can be shortened to

Code: Select all

		cycles_found |= this->EliminateCycles(path, node, node);

according to SmatZ, the function is still guaranteed to execute in this case.

OK, no big deal. Thanks.

anyway, what i really was searching for, but didn't find was the place where i can tell it to not establish links for orders "no loading and no unloading", which should be treated like waypoints for the linkgraph...

It shouldn't establish links there. If you have an example where it does, please post it here. I don't know the place from the top of my head, but there is all that logic with last_loading_station and last_station_visited and somewhere along those lines I made it ignore stops with "no loading and no unloading" - at least I think that's what I did.

[Leanden]

How long can we expect till we see this as an optional extra in trunk, this has been running as a branch for literally ages!