[Patch] Daylength, Cargodist with sprinkles

[petert]

Dear petert.
Could you please post a new fixed patch or upload those 12 files, to complete the source for the binaries you have posted as the liscence requires.
Thank you.

How do I create such a "fixed" patch? I usually use "svn diff > <filename>.diff" as that is what I just did.

[Terkhen]

The patch command does not know about version control systems: if there is a patch that includes new files, patch will create these files but they will not be added to the repository. As a result, these files will not appear when using svn diff. After applying a patch, you must use svn add <file_name> to manually add all missing files to the repository before creating any diff files.

[petert]

It would be easier to just not upload a patch. Is there another way to add files to the repo?

[ChillCore]

Unfortunatly that is not an option when providing binaries.(Unless you are going to post the actaul source folder.)
Either copy the source from the patch you have used when patching yourself and paste it in the new patch.
Or do as Terkhen said It's only twelve files.

Thank you Terkhen. I have learned something new.(Again )

[Terkhen]

The patch command does not know about version control systems: if there is a patch that includes new files, patch will create these files but they will not be added to the repository. As a result, these files will not appear when using svn diff. After applying a patch, you must use svn add <file_name> to manually add all missing files to the repository before creating any diff files.

I found a small gem: a bash script that will add automatically all unversioned files created by patch to the subversion repository. You can find it here:

http://mail-archives.apache.org/mod_mbo ... ail.com%3E

I'll try to replicate it on windows later.

[petert]

That looks really useful, Terkhen, thanks. I'll test it with MSVC soon.

[Terkhen]

That version was only compatible with subversion patches. I have coded a windows version that works with git patches, you can find it at my signature. If you have any problems, send me a PM or use the project site's issue tracker.

[Jimbow]

I found a new bug.

This time i saved the files for you. Here is a .rar file.

However, it's not clear to me what action triggered the bug.
I just made a new line, added a train, added orders, and started the game. Then it crashed.

I hope this can help you with the further development

[petert]

Can't make a new build yet, I need to get those scripts working.

Terkhen, see your issues page.

[SpComb]

This time i saved the files for you. Here is a .rar file.

However, it's not clear to me what action triggered the bug.
I just made a new line, added a train, added orders, and started the game. Then it crashed.

I managed to load the .dmp, and while I can't really make complete sense out of it, based on the partial stack trace that I did see, this almost certainly isn't from my patches.

There's some kind of std::Tree + DistanceAnnotation data structure involved, so I suspect it's from cargodist, but I can't know for sure, since the stack trace is presumably corrupted.

But if you're playing with r18625M, I suggest you try the newer-ish r18678 build from this thread and see if it crashes the same way.

[fonso]

Jimbow, please post a savegame. The only thing I can see from your crash report is that the MCF solver tried to get 84MB or RAM at once for a set of paths. That's a lot and if it was doing that several times you may well have run out of RAM. However, for a really big game it might be necessary. It could also be that the memory management was already corrupted at this point and the game was crashing anyway. Both theories would explain the broken stacktrace.

The only way to find out more about it is with a savegame. Especially the first case should be well reproducible from a save game of shortly before it happened. I'd just have to watch memory usage. So please post a save game of before the crash.

[Jimbow]

Jimbow, please post a savegame. The only thing I can see from your crash report is that the MCF solver tried to get 84MB or RAM at once for a set of paths. That's a lot and if it was doing that several times you may well have run out of RAM. However, for a really big game it might be necessary. It could also be that the memory management was already corrupted at this point and the game was crashing anyway. Both theories would explain the broken stacktrace.

The only way to find out more about it is with a savegame. Especially the first case should be well reproducible from a save game of shortly before it happened. I'd just have to watch memory usage. So please post a save game of before the crash.

I will post a savegame during the weekend.

I do not have a savegame of just before the crash. I expanded my network between the savegame and the crash. However, i only added one new ship (to an existing route) and one new train to a new route.
The setting for autosave was 6 months, but because i play with a daylenght factor of 3, it equals 18 months.

I think you are right about it could be a memory problem. It's a big map with many trains and links, and my computer only has 512mb RAM. My settings for days between calculations of the link graphs may also be too high.

I hope it's possible to locate the crash then you see the savegame

[TheVirus]

Testing the town cargo factor patch with cargodist at the moment. It's a big relief, as cargodist gives too much passengers compared to trunk. So with the setting at -2, it somewhat comes close to trunk, although it seems to be a bit less. But unfortunately, you can't specify it more in detail. Maybe it's better to divide given factor at least by 4, so -8 would be the same as the current -2. This gives 4 times less sensitive options, maintaining the fact that you actually see some difference (a factor 10 would be too much for example, I think) but you get the option of more subtle changes. I would like to set it for example to -7 or -6 to get close to what it used to be. So my suggestion is to divide the cf by 4 to get more out of the patch.

[fonso]

I will post a savegame during the weekend.

I do not have a savegame of just before the crash. I expanded my network between the savegame and the crash. However, i only added one new ship (to an existing route) and one new train to a new route.
The setting for autosave was 6 months, but because i play with a daylenght factor of 3, it equals 18 months.

I think you are right about it could be a memory problem. It's a big map with many trains and links, and my computer only has 512mb RAM. My settings for days between calculations of the link graphs may also be too high.

I hope it's possible to locate the crash then you see the savegame

Just post that last savegame you have. There is a chance I can make sense of it. Have you seen your OS swapping out memory (slowdown, lots of disk activity) while playing that game?

I don't think the recalculation interval is a problem. It shouldn't have an effect on memory consumtion. If you increase the interval the jobs will be started less frequently, but they will be kept around for a longer time. The best way to reduce resource consumtion is reducing the accuracy of link graph calculations.

[Jimbow]

Just post that last savegame you have. There is a chance I can make sense of it. Have you seen your OS swapping out memory (slowdown, lots of disk activity) while playing that game?

I don't think the recalculation interval is a problem. It shouldn't have an effect on memory consumtion. If you increase the interval the jobs will be started less frequently, but they will be kept around for a longer time. The best way to reduce resource consumtion is reducing the accuracy of link graph calculations.

Here is my savegame and newgrf list.

I do not remember if my computer was slowing down just before the crash, but when i loaded this savegame that day, it took like 20 seconds from i unpaused the game to the game speed was normal. But i do not think that this is because of cargodist, as i can experience these problems with the trunk too.

[SpComb]

But unfortunately, you can't specify it more in detail. Maybe it's better to divide given factor at least by 4, so -8 would be the same as the current -2. This gives 4 times less sensitive options, maintaining the fact that you actually see some difference (a factor 10 would be too much for example, I think) but you get the option of more subtle changes. I would like to set it for example to -7 or -6 to get close to what it used to be. So my suggestion is to divide the cf by 4 to get more out of the patch.

A valid point, and there's not really any particular reason this couldn't be changed to a linear factor - as long as the integer math is worked out correctly. I'll take a look.


On an unrelated note, I've added a second trivial variable-daylength tweak for timetable autofill, bringing the number of patches up to four. Refer to the first post for details. PeterT, remember to update the link in your post for your new build

[michielh]

I'm still getting crashes with this version of OpenTTD, but as I use the autosave it isn't a big issue.

I usually get the error's when I'm placing an PBS-signal, and as mentioned before in this topic: I've set the wait_for_pbs_path at 255, which makes the trains much more obedient

[Eddi]

r18764 looks like it should be a fix for an issue like this

[petert]

Hi guys,
I didn't have the best-of-luck compiling this binary, I had some trouble patching. But, I fixed the failed hunks and now we have a binary! MSVC, r18750.

Disclaimer:
If CargoDist crashes, do not report it to the OpenTTD developers. Report it to this thread. When making your post about the crash, please upload the crash.dmp, crash.log, crash.sav, and crash.png (only available as of r18184, so if you are using a build older than that, don't bother). These files are vital to finding what happened during the crash. For developers, you can find the PDB file and other files at this site: http://users.tt-forums.net/petert/dev/

Peter

[fonso]

Jimbow, you have changed the grf config during the game. This can easily lead to crashes. Even though I can't quite tell the origin of this crash it might well be that it's related to the grf config change.