Chill's patchpack v14_7

[ChillCore]

With enerency save you mean scrash.sav?
Ifso that is a bad idea. IIRC when it crashes again there will be no crash.sav, no crashlog and no crash.png ... because it crashed already before. Unless that has chanched since I read that somewhere.
Better is to enable autosave and continue your game from the last one if you have a crash. Yes, you lose a little, depending on the interval, but at least that game has not yet crashed.

[ostlandr]

Here you go. Started a fresh game to be sure. Save pre-crash, emergency save, log and .png. Also a .png showing the newGRF list.

I done broke it:

Can I see a savegame please. I can not reproduce it.

[ChillCore]

This is where it crashes:
assertion failed at line 2260 of window.cpp: IsGeneratingWorld() || IsLocalCompany()

Strangely enough if I load your crash.sav in my linux build it does not crash.
When loaded in the windows binary you linked to before it crashes in a matter of seconds.
So it is either the MinGW build that is buggy or a grf that is no longer working in current trunk. Windows builds and linux builds do not use the same grf folder on my computer and they are not in sync.

These are the grfs I am missing:
North american Roads set v1.0
tramdpw
North American road city v0.1c

Only tramdpw.grf is not replaced by another.
I will see if I can find the missing grf somewhere. In the meantime your savegame from before the crash is running in the windows build to see if it crashes also.

Also IIRC if have been looking at a savegame with the same assert a few pages back. At the time I did not have a replacement for the NACity.grf and the game did not crash on my computer. I have not yet tried running your savegame while the patchpack can not see the replacement ... will try that in a bit.

[ostlandr]

Found the problem- an obsolete GRF preset picked up an obsolete GRF version. Time to weed out the GRF folder that I keep copying to new installs. . .

This is where it crashes:
assertion failed at line 2260 of window.cpp: IsGeneratingWorld() || IsLocalCompany()

Strangely enough if I load your crash.sav in my linux build it does not crash.
When loaded in the windows binary you linked to before it crashes in a matter of seconds.
So it is either the MinGW build that is buggy or a grf that is no longer working in current trunk. Windows builds and linux builds do not use the same grf folder on my computer and they are not in sync.

These are the grfs I am missing:
North american Roads set v1.0
tramdpw
North American road city v0.1c

Only tramdpw.grf is not replaced by another.
I will see if I can find the missing grf somewhere. In the meantime your savegame from before the crash is running in the windows build to see if it crashes also.

Also IIRC if have been looking at a savegame with the same assert a few pages back. At the time I did not have a replacement for the NACity.grf and the game did not crash on my computer. I have not yet tried running your savegame while the patchpack can not see the replacement ... will try that in a bit.

[Melfice]

With enerency save you mean scrash.sav?
Ifso that is a bad idea. IIRC when it crashes again there will be no crash.sav, no crashlog and no crash.png ... because it crashed already before. Unless that has chanched since I read that somewhere.
Better is to enable autosave and continue your game from the last one if you have a crash. Yes, you lose a little, depending on the interval, but at least that game has not yet crashed.

It's been going strong ever since, and even if it does crash and won't produce an emergency save... that's okay with me. I understand the lack of a crashlog is... potentially annoying to you.
So, sorry for that then.

[ChillCore]

@Ostlander:
Mind sharing what grf that was so other people can avoid it?

@Melfice:
If it crashes again and you know how to reproduce it, it might be fixable. However there is no way of knowing then if the crash is something new or if it is related to the previous crash as the crash save is already broken when produced. eg. Ostlander's crash.sav did not produce a crashlog neither but the wine debugger showed me the assert.
It is more annoying for you as you may come to a point where your savegame will no longer be playable. eg the crash save keeps crashing after loading it.
Anyway glad you are able to continue your game, somtimes the patchpack may crash on something that is not saved and I guess that is what happened in your game.

[Melfice]

@Melfice:
If it crashes again and you know how to reproduce it, it might be fixable. However there is no way of knowing then if the crash is something new or if it is related to the previous crash as the crash save is already broken when produced. eg. Ostlander's crash.sav did not produce a crashlog neither but the wine debugger showed me the assert.
It is more annoying for you as you may come to a point where your savegame will no longer be playable. eg the crash save keeps crashing after loading it.
Anyway glad you are able to continue your game, somtimes the patchpack may crash on something that is not saved and I guess that is what happened in your game.

I've never been too attached to my saves, since I keep starting new ones to test new stuff or because it's all gone lopsided anyway, so I'm not too worried there.

If I hadn't accidentally deleted the crashlog, I would have posted it here for you to peruse, though.

[Wasila]

I have a very weird problem - whenever I add a newGRF electrified railway becomes greyed out. Everything works fine with current newGRFs, but adding new ones stops me from building elecrified rail. Running same version as before (r20768).

[ChillCore]

Good thing that you do not have many grfs defined in your game.

I have copied the grfpreset and did some quick testing.
What you are experiencing is caused by the 2cc trainset.
If I start a new game without it I can add grfs while the electrified track remains available. Also adding a grf to GlobalTrans.sav disables it as you say, removing the 2cc trainset enables it again.
I woud advise against this approach as train 12 will have an invalid lenght and I am pretty sure your game will crash afterwards. I did not unpause ...

You could maybe try to see what the resetengines command in the console does after adding grfs. I have not yet tried as my keyboard is not yet configured properly and I have no acces to the console for the moment. I could change my hotkeys.cfg but I would rather fix my keyboard settings, I hope you understand.
BEFORE trying, disable autosaving and make a backup of your savegame just in case.

[Wasila]

I added a bridge set and typed 'resetengines', but e-rails were still greyed out.

[ChillCore]

Then I am afraid you're stuck with your grf list untill you finish your game.
Changing the order after adding a grf does not help and replacing the 2cc trainset with an older version is no good either, I tried -> trains are stuck thinking they are electric while they are not.
I would not know how you can add grfs without breaking your game, sorry.

I think changing grfs ingame should be disabled by default as many people have problems with it and it causes a lot of bug reports, also in clean trunk.
Instead it should maybe be possible to enable doing so by a switch in the configfile for people that do know what they are doing, as has been suggested before somewhere else on the forums.

[ChillCore]

I have a very weird problem - whenever I add a newGRF electrified railway becomes greyed out.

Hi Wasila,
While having a break from my own game I had another look at this to see if I could find a solution and I did.

I added a few eyecandy and some station grfs and the electrified tracks were disabled. I then added another trainset grf and the electrified track was working again.
I have used NARS to test this but it might also work when adding another trainset.
Do make another backup of your game and test if everything still works before continuing your game.

Also I found a possible deadlock in your game. In the screenshot it is not deadlocked, and electrification is already fixed, but I have seen it locked at some point before so I know it is possible. I forgot to take a screenshot.

Disclaimers:
I have not playtested your game after changing the grfs.
Removing grfs is strongly discouraged and will give problems! Adding some should not give too many problems unless you add grfs that conflict with those already there. If you made a misstake while adding one or more load your backup and try again.

[Muzzly]

I think changing grfs ingame should be disabled by default as many people have problems with it and it causes a lot of bug reports, also in clean trunk.
Instead it should maybe be possible to enable doing so by a switch in the configfile for people that do know what they are doing, as has been suggested before somewhere else on the forums.

I used ingame grf changing to test what GRF are doing, kind of previewer, because loading it to list, then starting game,then quitting was to annoying especially having many new GRF, which I was willing to test. TTDPreview is also to slow ( because of JAVA, I think).

I added feature request to http://bugs.openttd.org/task/4149?project=1
If this will be implemented one day, then in my opinion (at least for me) there will be no need for ingame grf changing.

[Wasila]

I added a few eyecandy and some station grfs and the electrified tracks were disabled. I then added another trainset grf and the electrified track was working again.
I have used NARS to test this but it might also work when adding another trainset.
Do make another backup of your game and test if everything still works before continuing your game.

Thanks for having another look at this. So what exactly are you suggesting? That I add another trainset after the other GRFs? I also considered the possibility of adding GRFs just before a new electric train comes out - do you think that might help? The problem is, I don't particularly want to add a trainset; would removing and then re-adding 2cc be alright?

Also I found a possible deadlock in your game. In the screenshot it is not deadlocked, and electrification is already fixed, but I have seen it locked at some point before so I know it is possible. I forgot to take a screenshot.

Yeah - I noticed this problem; but only after half the queue stretched back half the line! Thanks for the heads-up anyway.

[bluebottle]

I can build debug builds me, yay.
The only odd thing I noticed was this: (just before building the package)

Code: Select all

   dh_shlibdeps
dpkg-shlibdeps: warning: dependency on libicui18n.so.42 could be avoided
if "debian/openttd/usr/games/openttd" were not uselessly linked against it (they use none of its symbols).

Yeah, I wouldn't worry about that. I've seen it too and it's just because of a dependency mentioned in the build script, which covers all the possibilities that people might choose.
It's good that the process is working for you!

[ChillCore]

I added a few eyecandy and some station grfs and the electrified tracks were disabled. I then added another trainset grf and the electrified track was working again.
I have used NARS to test this but it might also work when adding another trainset.
Do make another backup of your game and test if everything still works before continuing your game.

Thanks for having another look at this. So what exactly are you suggesting? That I add another trainset after the other GRFs? I also considered the possibility of adding GRFs just before a new electric train comes out - do you think that might help? The problem is, I don't particularly want to add a trainset; would removing and then re-adding 2cc be alright?

Removing and adding the 2cc trainset will not help as it involves removing the grf first. I tried that before -> train 12 having invalid lengt above.

Regardles of which grf you add it is always added to the end of the list.
eg. If you add 3 grfs with 10 sprites each they will use respectively slots 0-9, 10-19 and 20-29. If you remove the middle one and then re-add it it will use slots 30-39. OpenTTD does not know how handle this change so when you try to use the midle one later on it will either use slot 30-39 or go beserk while trying to use sprites from slots 10-19 that are now invalid because of removing the grf.

What you can do is add an (old) 2cc trainset at the end that is incompatible with the (newer) one you have already (read has a different grf-id). The downside is that many trains will be double in the available train list and the same trains will have different running costs (or whatever changed between the two versions).

In regards to the above I have found a few FIRS grfs that I can load simultanously and the industrie legend is massive, one of them still had the waste chain
I did not yet have a play with more then one enabled but I am planning on doing so after my current game to see what happens.



Also, I will be updating the patchpack soon but I have not yet found why the savegames become corrupt when saving manually with increased daylenght.

[ostlandr]

It was the North American city set. Upgraded it to version 0.1c.

@Ostlander:
Mind sharing what grf that was so other people can avoid it?

[Dwight_K._Schrute]

Hey,

maybe you can think about including this very nice and small patch:

http://www.tt-forums.net/viewtopic.php? ... 74&start=0

Very useful for all who are playing with timetables

[ChillCore]

Can do, no conflicts, but quick testing shows that it will not work with automated timetables as the times that you set will be overwritten.
Also, I am busy splitting up some code in the moreheightlevels patch to post on flyspray. When I'm done I'll update some patches and post a new version.

[Eddi]

someone should look into automatted timetables, i have heard several reports of people who couldn't disable the automation.