1.73.4: Linux - Saves corrupt(?) after dying

[Getafix]

What a panic!
One thousand pidgeons (leaving not only messages ) on my doormat.

Please, stop sending any more of them. I am looking into it...

[DaddyHoggy]

What a panic!
One thousand pidgeons (leaving not only messages ) on my doormat.

Please, stop sending any more of them. I am looking into it...

[shazbut]

Thanks for looking into it. I posted in the build thread (t=4595) before I realised there was a second page on this topic now.

[ferd]

Hi all!

Don't know if someone found the reason/solution to this problem already. I've had the same problem today. I've done a quick diff between a corrupted and a fresh valid save file. Then I copied the regions bit by bit from the affected file to the working one and tried to load the file after each step. I tracked the problem down to a string in the XML file which seemed to contain some characters (the "credits character" in my particular case) which the XML parser probably couldn't cope with properly. In my case it was the string belonging to the long_description of a passenger. I presume this affected the parsing of the rest of the file containing the ship information. Removing the characters from the description string solved this problem.

So if you have this problem open the savefile in a text editor and try to find a description which contains some strange characters and then just remove those.

I think the solution to this could be to make the program enclose affected strings into a <![CDATA[..]]> section or replace the characters with their unicode codes when saving.

Hope this helps.

Regards,
Ferdinand

EDIT: I've just realised that my post might seem a bit rude in assuming that what I identified as the cause of the problem is the right one for all the posts in this thread. But well... I hope it'll help at least some of you

[Getafix]

...I've just realised that my post might seem a bit rude...

Well... to tell you the truth... I am usually quick on the draw on such statements...
...and yours... ... ... ... ...did not seem to be rude at all!

Welcome aboard! Other non-offended offenders will join soon for the welcome party!
Stay tuned.

[DaddyHoggy]

Ferd - As is traditional - "Welcome to the friendliest board this side of Riedquat" (tm)

[jnorichards]

Hi, all.
I might have a different perspective on the same bug, or a different bug. I just posted a report at BerliOS but since it's being talked about here, I'll repeat myself. I have the Big Yellow Query ship, even though I have saved no game since switching to 1.73.4, though I have upgraded the Linux distro.

Upgraded Oolite to v1.73.4 as part of upgrade from Kubuntu 9.10 to 10.04 (Lucid). Started Oolite with shift key down to reload OXPs; Select Commander page says

Ship: Fer-de-Lance - OXP not installed

, and ship representation is a big yellow ?. Earlier Commanders (Cobra, Python) display ships correctly. Selecting Fer-de-Lance commander elicits message:

Could not find ship type "ferdelance-player" Please reinstall the appropriate OXP.

Commander Jameson on Lave is loaded.

Fer-de-Lance is not an OXP ship. Unloading all OXPs does not cure the problem.

Extract of Latest.log follows (/home/jonathan/.Oolite/AddOns is empty):

Code: Select all

[searchPaths.dumpAll]: ---> OXP search paths:
("/usr/lib/GNUstep/Applications/oolite.app/Resources", AddOns, "/home/jonathan/.Oolite/AddOns")
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[shipData.load.begin]: Loading ship data...
[script.load.world.listAll]: Loaded 5 world scripts: "oolite-cloaking-device" 1.73.4, "oolite-constrictor-hunt" 1.73.4, "oolite-nova" 1.73.4, "oolite-thargoid-plans" 1.73.4, "oolite-trumbles" 1.73.4
[dataCache.willWrite]: About to write data cache.
[dataCache.write.success]: Wrote data cache.
[load.failed]: ***** FILE LOADING ERROR!! *****
[script.load.world.listAll]: Loaded 5 world scripts: "oolite-cloaking-device" 1.73.4, "oolite-constrictor-hunt" 1.73.4, "oolite-nova" 1.73.4, "oolite-thargoid-plans" 1.73.4, "oolite-trumbles" 1.73.4
[gameController.exitApp]: .GNUstepDefaults synchronized.

Closing log at 2010-05-24 20:55:09 +0100.

[Micha]

Hi jnorichards,

How did you install Oolite? We've just found a nasty little bug in the version of GNUstep which comes with Ubuntu 10.04, so any copies of Oolite compiled natively for that version of Ubuntu are subject to that bug. It affects loading of XML property lists.

If you got Oolite from the repository (via APT), then please uninstall and try the autopackage version of Oolite which ships with a different version of the GNUstep libraries.

[jnorichards]

How did you install Oolite?

I installed originally from the Karmic repository, and upgraded with the move to Lucid.

We've just found a nasty little bug in the version of GNUstep which comes with Ubuntu 10.04, so any copies of Oolite compiled natively for that version of Ubuntu are subject to that bug. It affects loading of XML property lists.

Ah, that would do it, I guess. I have packages for game and data installed labelled 1.73.4-1~getdeb4.

If you got Oolite from the repository (via APT), then please uninstall and try the autopackage version of Oolite which ships with a different version of the GNUstep libraries.

Will do; not certain where to find the autopackage version, but I'll work that out. Thanks for the help.

Jonathan

[Micha]

Will do; not certain where to find the autopackage version, but I'll work that out. Thanks for the help.
Jonathan

http://www.oolite.org/download.shtml

[jnorichards]

OK, here's the steps I've followed:
Used adept to remove oolite and oolite-data deb packages.
Then at a command prompt:

Code: Select all

$ sudo apt-get autoremove

Downloaded oolite-1.73.4-test.x86.package by following the link Micha gives above

Code: Select all

$ cd /usr/local/downloads #this is my download folder
$ chmod u+x oolite-1.73.4-test.x86.package
$./oolite-1.73.4-test.x86.package

I was prompted for the root password twice, once for autopackage and once for oolite itself.

Run Oolite from the KDE menu, and my Fer-de-Lance is back!
Thanks Micha for the diagnosis, and the fix.

Jonathan

[Micha]

Glad to hear you're up and running

And since no-one else has done so yet, Welcome to the Friendliest Board this side of Riedquat™!

[jnorichards]

Glad to hear you're up and running

And since no-one else has done so yet, Welcome to the Friendliest Board this side of Riedquat™!

Thank you kindly.
While Oolite seems to be running fine, I though to look back in the log file. I have 24 repeats of lines like these:

Code: Select all

[gnustep]: 2010-05-26 17:49:28.704 oolite[3245] unable to find GNUstep DTD - +++
[gnustep]: 2010-05-26 17:49:28.921 oolite[3245] don't know how to load entity +++

The +++ represents DTD specifications that won't pass this board's spam filter
Since everything seems to work I'm not worrying, but thought it might be useful to mention.

Riedquat. I remember Riedquat, the nasty anarchy not far from Lave? I first flew Cdr Jameson into that mess with Elite on a Commodore 64, coming on for 'bout thirty years ago, now!

[Getafix]

Welcome jnorichards.

The "DTD not found" has been addressed in the trunk, therefore, the next release will be OK with DTDs.
In the meantime, do not worry. It has no implications with your gaming.

[Micha]

Ok, update on this problem.

The root cause is yet another GNUstep bug.

It looks like -any- unicode characters anywhere in the save file somehow or other prevents the lookup of the ship from the ship registry from succeeding. (stepping through with the debugger, I am completely baffled - everything looks ok in the relevant parts of the code and all data returned seems ok -whether using a broken gnustep or a good one).

Affected gnustep versions seem to be at least from gnustep-base1.19.3 up to the current release of gnustep-base1.20. ie. 1.20 is already fixed as regards this particular issue.

Unfortunately a lot of the current Linux distros are shipping with the broken gnustep-base1.19.x (x > 1). If you are wanting to just play Oolite on these distros, use the autopackaged version of Oolite which includes a known good version of GNUstep (1.18, old but functional).

If you want to compile Oolite yourself, you should first upgrade the version of GNUstep on your system.