Transport Tycoon Forums

sometimes when generating a new map:
settings were:

Dante123 wrote: sometimes when generating a new map:

That one is reproducable and makes it easier to find the cause, I hope.
Thank you.

Hi, Here is the grf list and the last autosave.

I did some more testing of may save game and found the error did not happen when I used the 2nd newest autosave.

ChillCore wrote:

Dante123 wrote: sometimes when generating a new map:

That one is reproducable and makes it easier to find the cause, I hope.
Thank you.

This one seems to be solved after bumping to r20522.
Thank you Rubidium.

phillipabbott wrote: I did some more testing of may save game and found the error did not happen when I used the 2nd newest autosave.

I can make it crash by crashing two trains and waiting for them to be removed. It does not seem to matter if I cloned them or not.
I do not yet know what patch causes it though.(If it is a patch at all and not something I have changed somewhere.)
I will need to test some more to see if it is a problem with the code in the patchpack or with a GRF as I have not yet tested without grf or with a new game using your grf list.
Thank you for the savegames as they showed me the difference.

Note:
Before someone tries to bump the patchpack to trunk himself, remove the Panorama patch as that one is in trunk since r20508.
Congratulations Eddi and thank you Michi_cc.


EDIT:
@ phillipabbott:

I did some more testing and could not reproduce the crash with newgames made with the same grf setup as in your savegame.
Also when removing crashed trains the game did not crash.
However when looking at the bottom of the crashlog, produced from crashing your savegame. You have removed NuTracks in tick 0 and added fish in tick 10761. It is very likely that the crash is caused by doing this.
May I remind you that removing and or adding GRF in a running game is not recommended.
Usually adding GRFs will not cause much trouble but removing some or even re-arranging the order is a big NONO ... as that will mess things up beyond repair.

On as side note what version of NuTraks have you removed? When I removed NuTracks r86, while trying to reproduce this in a new savegame, the option to select electrical rail was also removed. In your savegame you still have electrical rails available after doing so ...

As for your savegame ... you can continue maybe from autosave 12 if you do not crash trains in the future but it will be no guarantee to be crash free.
I suggest you start a new game and select the GRFs you want to use before starting a game and not during.
Sorry but there is nothing I can do about this and the same could happen if you do this in clean trunk.
Also in the future please provide the crashlog as I would have noticed he GRF changing a lot sooner. Thank you in advance.

I have been playing with r19891 with Chillpak's patches and i LOVE it! This is one of the best patchpack's around. Although i never use the copy-paste feature, i can't live without the updated station GUI, the underwater tunnels, and so many of the other features i've come to take for granted. I just DL'd v 9.3, so i'm looking forward to not only your additions, but the new features/fixes in the most OTTD release.

Keep up the good work Chill.

Once you go Chillpak, you can't go back!!

Thank you for the kind words SirXavius. Glad you like it.

You can always express your gratitude by sending some money. My account number is 123-456789-lol.
I shall put it aside for my detox-clinic that I will open after I stopped updating the patchpack. (Not yet but at some point I may get tired of it or all patches are merged in trunk, who knows.)

All jokes aside, this would not be possible without the efforts of other patchwriters and the efforts made by the Devs to keep trunk bugfree and a stable as possible.
The next version will come soon but I'd rather take a little more time reviewing the code.

ChillCore wrote:

Hayia-Dragon wrote: I'm currently hosting a MP game with a time delay factor of 15. Everything is rock stable without any desyncs or crashes whatsoever. We're currently in 2008, and started in 1890, so that's quite a lot of playing time

Unfortunately my internet connection is not stable enough to play online. If it was I would defenately swing by.
I would love to see the savegame when you are done.
Would you mind making one before the server is reset? Please.

Here you go.
I believe the only non-banana's GRF used in the game is found here.

Two players left the game early, so they still have steam engines running

Before extracting, rename the Snow2.rar to Snow.r00.
The forum wouldn't let me upload the .r00 extension so I had to work around it, as this savegame barely breaks their 4MB limit.

Hey, know what would be fun? Being able to share your competitors rails. If its possible CHill, maybe you could see if you can bump Infrastructure sharing to a recent openttd?

Scautura wrote:And again, one fresh new binary and diff (this one doesn't crash on the station dialog).

http://www.scautura.com/bg/openttd-cust ... -MINGW.zip

This binary does not support freetypes. Only people who uses not default font would see a different. Freetype is here http://www.freetype.org/

Once you go Chillpak, you can't go back!!

Yeh, do not retreat !!! Otherwise community will find you and ....

I like this patchpack. Still forget some bits are there, but I'm working on it.
So as thanks, I bring this offering.
This is a Linux binary, made using 'make bundle', then compressed into a 7z because zip was over the forum's limit.
This was compiled on Arch Linux up to date as of the time I post this. Please bear in mind that this may not work correctly on other distributions, or for that matter any other Arch Linux - I cannot guarantee it will run on any Linux, but in theory it should run anywhere. Linux binaries are somewhat touchy, I've discovered first hand.

Enjoy all.

And traditional: REPORT ALL CRASHES IN THAT THREAD AND ONLY IN THAT THREAD

i get this on ubuntu 10.04:

Try installing Allegro, then try again. It may be that where I compiled it with support for both Allegro and SDL, it wants Allegro around even if you don't want to use it.
I blame Linux being strange in that regard.

*i think* i've now installed it, but still doesn't work (doesn't actually matter, i'm just telling you)

Gremnon wrote:I blame Linux being strange in that regard.

There's nothing strange about it. Allegro and SDL are linked directly to the binary which means they must be resolved before OpenTTD is started. It can be written so it will only try to load the library when there is a demand for it, i.e. when a driver is autodetected, but that needs to be written and is basically more work. In any case, Allegro has always been inferior w.r.t. video speed in my experience and it is much less likely to be installed.

Even so, Allegro 4.4 doesn't seem to be common in the major Linux distributions yet.

I call it strange in that to me, it seems more logical to call it only if it's needed. Since SDL appears to be default, I would expect it to use that first, and only if the respective parameters are passed to it should it call for Allegro.
However, since I've no idea why it is or isn't the case and so on, I'm not going to worry about it. I'll compile a build without Allegro and upload it too.

And for the record, I find that on a widescreen monitor, Allegro handles running in a window far better than SDL does.

Edit: Updated binary posted. Exactly the same as the previous one, but without Allegro support.

now i get:
i looked it up and i believe it's something to do with arch linux
i won't bother trying these anymore since it's obvious arch linux builds aren't compatible with ubuntu
if i really want it i'll compile it myself
thanks for trying anyway

Gremnon wrote:I call it strange in that to me, it seems more logical to call it only if it's needed.

It does not happen while calling the library, it happens while loading openttd.

If you have a large library used by many programs, it is a waste of disk space and memory to load it seperately for each program that you run. To solve this, shared object files are invented at Linux, and DLLs at Windows.
Instead of loading the library with each application, it gets loaded once, before starting the first application. Each next application then uses the same block of code, sharing it with the other applications.

So with openttd, you specified to need the shared libraries Allegro and SDL, so they get loaded for OpenTTD (if you don't have another program using them, otherwise you'd re-use that).
The information what the application needs is inside the application. Type 'ldd openttd' to get a list. If you keep binaries at the same system, shared libraries work without you noticing, as you never compile against a library that you don't have installed.

However if you move a program to another system, that system also needs the exact same libraries, or it will fail.
Apparently, arch linux and Ubuntu are different in that respect.

One solution is to compile against static libraries, which means you will include the whole library code in the application, so you don't need the libraries installed at the other computer. It does make the executable (potentially a lot) bigger however.
Another solution is to reduce the problem by not loading all libraries at startup (as is done now), but only if you need to call them, as suggested by Rubidium. That however needs additional programming, as the code that decides whether or not to load the library does not exist at this time.

That makes sense now. Thanks! I guess it's true what they say, learn something new every day.
Lord Aro, it does seem like it's an Arch/Ubuntu incompatibility, I hauled an older tower back into service running Ubuntu and found exactly the same issues. I'd provide a compiled version from that old box, but it'd probably have a heart attack (CPU attack? ) if I even thought about asking it to.
I had hoped it would be a bit like Java - compile once, run anywhere - but apparently when distributions make different changes to, or choices in, versions of packages, you get a few problems.

It was worth a try though.