Chill's patchpack v14_7

[jonnie47]

just a little help if possible. i get this message when i try to load that program, any ideas on how to fix it?

[thphwh]

If you had a normal installation of OTTD before you acquired the Bundle:
Look in - The OpenTTD folder in your user account's home directory:
Windows: C:\My Documents\OpenTTD (95, 98, ME)
C:\Documents and Settings\<username>\My Documents\OpenTTD\ (2000, XP)
C:\Users\<username>\Documents\OpenTTD\ (Vista, 7)
Mac OSX: ~/Documents/OpenTTD/
Linux: ~/.openttd/
And delete the .cfg file.
This is what happened to me. In any other scenario, I can't help you...

Close all programs down. Try running your normal OTTD, then see if a .cfg file appears in the OTTD folder in the directory in my previous post, then run the precompiled version of OpenTTD with the PatchPack. Finally, delete the .cfg file if there is one. See if this works.

Sent from my GT-S5830 using Tapatalk

I and another user had this problem;just follow either instructions. I had to work this out myself and I tried everything. If this doesn't work, I'm not sure what I can do. Hope this works!

I've already explained this several times. Hope this helps!

[jonnie47]

great advice thanks. sorry to be a pain but does this bundle not have compatability with newish grf files. the new ukrs released to for 1 example?

[Alberth]

Indeed, it is an old version, not compatible with newer NewGRFs.

It is not likely that this version will get updated. There has been some talk of starting a new patchpack, but it has not happened yet.

[kamnet]

If the set depends on new OpenTTD features, the it's likely this won't work. You can try running it, if it won't work it will give you an error message.

[Valle]

I've already explained this several times. Hope this helps!

That awkward moment when a problem remains despite a fresh .cfg file and savegames... Is there any known history of (and possible solution for) OpenTTD crashes while handling whatever is the second loaded savegame of a single OpenTTD (CPP) session? In particular: saving, quitting, hosting multiplayer games, loading savegame #3

[ChillCore]

just a little help if possible. i get this message when i try to load that program, any ideas on how to fix it?

Deleting your shared config file is a solution, a better one would have been just deleting the line the patchpack complains about.
The best solution is to make the patchpack a seperate installation by adding a config file near the executable.

There is more than one reason for going for the last option.
First is the conflicting settings in my patchpack and recent versions of OpenTTD.
Second reason is that my patchpack expects its files in different directories than recent OpenTTD.
Third is ... well ... you do not mess up your config file that clean versions use.

That awkward moment when a problem remains despite a fresh .cfg file and savegames... Is there any known history of (and possible solution for) OpenTTD crashes while handling whatever is the second loaded savegame of a single OpenTTD (CPP) session? In particular: saving, quitting, hosting multiplayer games, loading savegame #3

That akward moment when the patchpack author has to admit that he has no clue whatsoever.
May I ask what the reason is that you do not load the correct save first? Maybe there is a solution to the reason that "solves" your problem untill I know what goes wrong.
Also may I please have your config file to see if that makes a difference?

[hooiberg]

Dear Chill,

thank you very much for putting much effort into making the patch with many interesting features, although my main interest is the larger maps and the greater amount of height levels. I have a fast computer with a whole lot of memory, so I wish to put maps into a bit more perspective, using your patch pack.

The patching gives a lot of errors, though. Perhaps you could point out to me what I am doing wrong. I have been browsing the documentation and I have lost my way.

What I have done:

From your website: http://bundles.openttdcoop.org/chillpp/releases/LATEST/
I have downloaded the patch: chillpp-full-r22555.diff

Following the wiki: http://wiki.openttd.org/Compiling_on_%28GNU/%29Linux
I downloaded the source: svn checkout svn://svn.openttd.org/trunk openttd
which I reverted to revision 22555 to match the patch: svn update -r 22555

and to make sure everything went well I compiled and played the game in this revision: ./configure; make; sudo make install; openttd

so far all is well.

Next I place the patch file into the openttd directory and run it using: patch -p0 < chillpp-full-r22555.diff

which gives a large amount of errors starting with and continuing in the same spirit as:

patching file b/.hgignore
Hunk #1 FAILED at 24.
1 out of 1 hunk FAILED -- saving rejects to file b/.hgignore.rej
patching file b/Makefile.msvc
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 27.
2 out of 2 hunks FAILED -- saving rejects to file b/Makefile.msvc.rej
patching file b/Makefile.setting.in
Hunk #1 FAILED at 5.
1 out of 1 hunk FAILED -- saving rejects to file b/Makefile.setting.in.rej
patching file b/Makefile.src.in
Hunk #1 FAILED at 23.
Hunk #2 FAILED at 58.
2 out of 2 hunks FAILED -- saving rejects to file b/Makefile.src.in.rej

not everything fails, though.

The ./bin/nfo and the ./bin.txt files patch properly:

patching file b/bin/chipp_changelog.txt
patching file b/bin/chipp_todo.txt
patching file b/bin/data/Readme.txt
patching file b/bin/data/chipp_grf_sources/copypaste.nfo
patching file b/bin/data/chipp_grf_sources/flat_blacktiles.nfo
patching file b/bin/data/chipp_grf_sources/progsignals.nfo
patching file b/bin/data/chipp_grf_sources/speedsignals.nfo
patching file b/bin/data/chipp_grf_sources/trafficlights_dark.nfo
patching file b/bin/data/chipp_grf_sources/trafficlights_light.nfo
patching file b/bin/data/chipp_grf_sources/trafficlights_wooden.nfo

several header and c files patch properly as well.

The patching goes through a few questions like

The next patch would delete the file b/projects/settings_vs100.vcxproj,
which does not exist! Assume -R? [n]

All about the Visual Studio 10 project files. I agree to proceed, because I compile using make, and not through a visual microsoft compiler.

After 'deleting' these non existent project files, a few hundred more 'Hunk #x FAILED at y'-errors follow, after which the patching processs returns to the command prompt.



If it would help, I can send you the entire list of errors.

Could you tell from this what mistake(s) I may have made?

Thank you very much for your time and best regards!

Lukas

[Eddi]

smells like a problem with dos/unix line endings. try one of the patch options which ignore whitespace changes, or convert the files with dos2unix/unix2dos

[Rubidium]

You need to apply the patch with -p1 and not with -p0.

[ChillCore]

What Rubidium sais.

Or if you have/install Mercurial you can just do this:

Code: Select all

hg clone http://hg.openttdcoop.org/chillpp.mq

which will get you the pre-patched source.

[hooiberg]

Thank for the fast advice! The p0 -> p1 indeed fixed the problem. It is wonderful to have such big and high maps!

And in the near future I will have a lot of fun exploring the functionality of all the other useful patches of the pack.

Best regards and a happy new year

Lukas

[Valle]

That akward moment when the patchpack author has to admit that he has no clue whatsoever.
May I ask what the reason is that you do not load the correct save first? Maybe there is a solution to the reason that "solves" your problem untill I know what goes wrong.
Also may I please have your config file to see if that makes a difference?

I am slightly shocked to have achieved a no-clue status on your side with my first CPP bug report. Well, why do I play with several saves? Sometimes I want to play game #1, then #2 and #1 again, also while hosting (which my small MP gang usually appreciates). In case of the very large map: I believe it uses an excessive number of NewGRFs, forcing me to host something else first to allow people to connect to my server (I don't show up on the tracker with it). The crash doesn't appear to be related to that map, though, it also occurs when only trying to reproduce it in other savegames with a normal amount of NewGRFs, which I have included here as well.

[ChillCore]

Thank for the fast advice! The p0 -> p1 indeed fixed the problem. It is wonderful to have such big and high maps!

And in the near future I will have a lot of fun exploring the functionality of all the other useful patches of the pack.

Best regards and a happy new year

Lukas

Glad you got it to work.
Feel free to post a screenshot from time to time.

Happy new year to you too and best wisches.

I am slightly shocked to have achieved a no-clue status on your side with my first CPP bug report.

There have been previous occasions I have found myself in this situation, sometimes I fix it, sometimes it takes a bit longer.

Thank you for those savegames and the config file, now I can reproduce the crash when saving one of your games while being the second loaded.
I have not yet fixed it but at least I am getting somewhere.
This is the crashreport when trying to save that SETA savegame (still have to look more closely at the reports when crashing with the other saves and with another file).

Code: Select all

Crash reason:
 Signal:  Aborted (6)
 Message: Assertion failed at line 39 of /bamboo/src/rail_map.h: IsTileType(t, MP_RAILWAY)

OpenTTD version:
 Version:    h4f8131fc (0)
 NewGRF ver: 1200581b
 Bits:       64
 Endian:     little
 Dedicated:  no
 Build date: Feb 19 2012 03:07:20

Stacktrace:
 [00] ~/openttd(_ZNK12CrashLogUnix13LogStacktraceEPcPKc+0x39) [0x7214f9]
 [01] ~/openttd(_ZNK8CrashLog12FillCrashLogEPcPKc+0xf0) [0x5d8710]
 [02] ~/openttd(_ZNK8CrashLog12MakeCrashLogEv+0x7c) [0x5d880c]
 [03] ~/openttd() [0x72145d]
 [04] /lib/x86_64-linux-gnu/libc.so.6(+0x36460) [0x7f64ca34c460]
 [05] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x7f64ca34c3e5]
 [06] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x7f64ca34fb4b]
 [07] ~/openttd() [0x70d675]
 [08] ~/openttd() [0x74ffc2]
 [09] ~/openttd(_ZN20SignalStateConditionD0Ev+0x10) [0x750130]
 [10] ~/openttd(_ZN8SignalIf6RemoveEv+0x16) [0x74e7e6]
 [11] ~/openttd(_ZN13SignalSpecial6RemoveEv+0x1e) [0x74e21e]
 [12] ~/openttd(_ZN13SignalProgramD1Ev+0x18) [0x74ec38]
 [13] ~/openttd(_Z17FreeSignalProgram15SignalReference+0x8a) [0x74f01a]
 [14] ~/openttd() [0x7a34cd]
 [15] ~/openttd() [0x7a0e7a]
 [16] ~/openttd(_Z10SaveOrLoadPKci12Subdirectoryb+0x319) [0x7a1bd9]
 [17] ~/openttd(_Z12SwitchToMode10SwitchMode+0x259) [0x70db09]
 [18] ~/openttd(_Z8GameLoopv+0x1d5) [0x70fe75]
 [19] ~/openttd(_ZN15VideoDriver_SDL8MainLoopEv+0x1e2) [0x878f62]
 [20] ~/openttd(_Z8ttd_mainiPPc+0xe59) [0x70f979]
 [21] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f64ca33730d]
 [22] ~/openttd() [0x4f6459]

The nasty thing is that when it crashes on saving the resulting savegame is left in an unreadable state.
The strange thing is that it does not happen when I switch between one of your games and a savegame someone posted earlier on.
Now where did I put my debug build again ...

One more question though, Valle.
Might be unrelated as it would be strange happening in all three your savegames at the same time ...
Did a company go bankrupt while owning rails with programmable signals on them?
I just ask because the crashlog mentions those signals and I remember them not being properly cleared in the case of bankrupty.
I remember fixing someones savegame but I just can not remember if I fixed that properly in the patch itself too or not. Will have to do a little diggy diggy code.
Also it may be best if you backed up your savegames at this point in time.

As for the problem with the server not showing up when you load the big game ... I know there are settings in the config file to allow clients more time to join and download the map. I am however not aware of any settings that limit the filesize limit.
Anyone knows if any such limits exist?

[Valle]

The nasty thing is that when it crashes on saving the resulting savegame is left in an unreadable state.
The strange thing is that it does not happen when I switch between one of your games and a savegame someone posted earlier on.
Now where did I put my debug build again ...

One more question though, Valle.
Might be unrelated as it would be strange happening in all three your savegames at the same time ...
Did a company go bankrupt while owning rails with programmable signals on them?
I just ask because the crashlog mentions those signals and I remember them not being properly cleared in the case of bankrupty.
I remember fixing someones savegame but I just can not remember if I fixed that properly in the patch itself too or not. Will have to do a little diggy diggy code.
Also it may be best if you backed up your savegames at this point in time.

As for the problem with the server not showing up when you load the big game ... I know there are settings in the config file to allow clients more time to join and download the map. I am however not aware of any settings that limit the filesize limit.
Anyone knows if any such limits exist?

Bancrupcy of a company with programmable signals? That possibility can be ruled out, programmable signals were only recently implemented in the EIG game I posted here before (maybe 5 game-years before the date of the savegame), and with no infrastructure companies having gone bancrupt at all in either of those games (which is hard enough anyway with my sandbox-like settings). The non-appearance on the tracker isn't a big deal for me since I believe to have caused it by adding an excessive number of NewGRFs to the running game. I'll look into the join time settings again, but I had already altered those to fight the timeout that happened quite often by that point. By the way, the crash scenarios seem easier to reproduce in Multiplayer, the saving crash always causes a 0 KB file.

[vtk]

Went looking for binaries of newer builds, http://dev.openttdcoop.org seems to be down.

[kamnet]

Went looking for binaries of newer builds, http://dev.openttdcoop.org seems to be down.

It was up at the time of this post.

[vtk]

Hmm, downforeveryoneorjustme.com reports the site is up too, but when I try to visit, the connection is reset before any page loads. This happens both in Firefox and in Chrome, but it seems to work fine on my phone with the home wifi.

I guess that means the problem is with my desktop machine, but not a specific browser on it. I don't run firewall software (firewall is in res gateway, phone behind that too), and Avast isn't reporting blocking anything. Weird.

Browsing on my phone seems to indicate there isn't anything new there anyway.

[ChillCore]

Hmm ... down for me too ...

Code: Select all

Internal error

An error occurred on the page you were trying to access.
If you continue to experience problems please contact your Redmine administrator for assistance.

If you are the Redmine administrator, check your log files for details about the error.

Using firefox 17.0.1 at he moment; I will check with internet explorer in a bit ...



vtk, if you have a version with a build date later then "Feb 19 2012 03:07:20" then you are already playing with the newest version; a few binaries have been compiled there after too but no changes were made to the code and they should all be the same except for the revision tag (which needs only to be the same for all clients in multiplayer games, savegames can still be passed around as for singleplayer games the code only checks for the savegameversion).



EDIT:
Some further testing with firefox reveals that only the devzone is unreachable on the openttdcoop site, the main page loads fine and clicking "home" or "blog" or any other link seem to work fine too.
Also Internet explorer 8.0.6001.18702 opens the devzone as it should.

EDIT 2:
Some more testing with strange results.
The devzone loads fine with firefox 17.0.1 in combination with linux Mint (testing above was with windows XP).
At first I thought it was a simple browser issue but now I am confused as the same(*) version works on one OS but not on the other.

Anyone else having this issues? I will report in a bit and the more info there is available the easier it will be to solve the issue by the powers that be, I hope.


(*) Relative same as Clem and his team do like to rebrand many apps as "Mint" versions, after making modifications (at least, I hope he does not rebrand without making modifications), and the plugins installed on my different OSs may not be the same neither.

[ChillCore]

I am slightly shocked to have achieved a no-clue status on your side with my first CPP bug report.

There have been previous occasions I have found myself in this situation, sometimes I fix it, sometimes it takes a bit longer.

Not yet fixed but I do have found the problem.

A reproducable way to make the crash happen is loading the "lathi" savegame, loading the SETA savegame and then trying to save; the other way round does not crash the game.
Part of the debug build reveals this:

Code: Select all

dbg: [sl] Programmable signal information for (3a2c, 1) has been leaked!
openttd: ~/chillpp_debug/trunk/src/rail_map.h:39: RailTileType GetRailTileType(TileIndex): Assertion `IsTileType(t, MP_RAILWAY)' failed.

Which is confusing as you stated no progsigs are used in that savegame
A bit further we find this ...

Code: Select all

#12 0x0000000000904e0d in Save_SPRG ()
    at ~/chillpp_debug/trunk/src/saveload/signal_sl.cpp:110
        ref = {tile = 14892, track = TRACK_Y}
...

Indeed there is no progsig on tile 14982 or anywhere near it but then I had a better look at your "lathi" savegame and what do we find there, if we type "scrollto 14892" in the console, indeed ... near "Lapinsalo West".
So the crash is caused by the previous loaded savegame (at least its behaviour when replaced with another one) and not the currently loaded.

In short ... information exists that should no longer exist and messes up saving the current game.
I was not even aware this being possible between loading games and as a result ... I am not sure how I have to fix that, yet.


Sorry for the delay Valle, RL and all ...



-------------------------------------------
Edit:
Quiz of the day number two:
A progsig can depend on itself.
Except for the signal state, if programmed right, going into an infintite loop of red/green (if it were not for the max number of evaluations setting) there is absolutely no use for this option and it should be removed?