Oolite Bulletins

I was on my way to Tinave to see the famous palsar.

I was about 5 jumps away from Tinave, can't remember the planet name now.
The main station was in the shadow of the planet and, because I have the ambient lighting down low, I couldn't see the docking entrance.
So rather than trying to dock blind I decided to land on a planet and save there.

However, now when I try to load the 'save anywhere' file, it crashes to desktop.
Is there a way around this or do I have to delete my save file and start the game all over again from the begining?

Thanks.

Obvious question first: You haven't messed with your OXP folder between saving & loading, right? (Checking the "D'oh!" reasons, just in case...)

Nope.
I haven't uploaded anything new or even opened any files since saving the game.

Please send me your saved game.

Ahruman wrote:

Please send me your saved game.

OK I will send the save game file to [email protected]

Thanks.

lave wrote:

However, now when I try to load the 'save anywhere' file, it crashes to desktop.
Is there a way around this or do I have to delete my save file and start the game all over again from the begining?

Thanks.

You could try to load the game after removing the "save anywhere.oxp". In that case "save anywhere.oxp" will not try to launch you from an other station but you launch from the main station.

Not seeing the dock seems a wrong definition of the dock materials. For most stations the dock is still lit when the station is in the dark.

Eric Walch wrote:

Not seeing the dock seems a wrong definition of the dock materials. For most stations the dock is still lit when the station is in the dark.

Yes I have seen that before but in this case it was so dark that I really could not dock.
I do have the ambient lighting turned right down and I prefer it this way because I think it looks more realistic.
However I have always thought that ALL stations should have a red light either side of the docking bay entrance so that you can still align your ship with them.

Luckially most stations are always in the sunlight, but this one was right in the planets shadow.

I will try what you suggested too.

lave wrote:

However I have always thought that ALL stations should have a red light either side of the docking bay entrance so that you can still align your ship with them.

Luckially most stations are always in the sunlight, but this one was right in the planets shadow.

Most stations were designed before Oolite 1.74 and they were always lit as light traveled through the planet before 1.74. With 1.74 these dock details become important.

When you look at the neolite stations, you see that the dock becomes fully black in the shade. But it has flashers that enable finding the dock.

When you look at Griff's stations things are a bit different. There are no flashers and lighting is done with shaders. With shader settings at simple or full, you will see that the dock is always lit, even when the station is in the dark. Also the station itself has lights on its outside.
When switching shaders off, the station becomes totally black when in the shade. But these stations were designed for shaders so that is okay.

Unrelated, but the dock can also become invisible then heating up a station. In ups-courier there is a rescue mission to a sun-station. The station is slowly building up heat. First it becomes red-hot, than slowly white-hot. The hotter it becomes, the more difficult it becomes to recognise the dock. At the end it really becomes impossible to find it. But hey, who wants to dock at a station that is about to explode?

The Accessories stations are all quite well lit, as you can see...

Smivs wrote:

The Accessories stations are all quite well lit, as you can see...

Not on the mac... But that has another reason. In several of the material definitions are semicolons missing as terminator. The mac won't load such a plist with bad syntax, so none of the accessories will appear.

Eric Walch wrote:

Smivs wrote:

The Accessories stations are all quite well lit, as you can see...

Not on the mac... But that has another reason. In several of the material definitions are semicolons missing as terminator. The mac won't load such a plist with bad syntax, so none of the accessories will appear.

I was completely un-aware of this...no-one has mentioned it.
I would like to sort this out, so could you please give me an example?
Cheers,
Smivs.

Edit:- Yes, I've just had a look at the shipdata.plist and (of course) Eric is right. There were missing quotes (") and a missing semi-colon (;) on the line for the arc-detail of the Coriolis station. My (Ubuntu) computer had always parsed this plist as OK. I only found the one problem...if there are others, please let me know.
I have fixed this and uploaded v1.2 for download, so Mac users, really sorry it didn't work for you...I hope it will now.
If anyone cares to have a look and confirm it is now OK, I'd be very grateful.
Edit removed as it has been superceded. See the posts below.

Smivs wrote:

I was completely un-aware of this...no-one has mentioned it.
I would like to sort this out, so could you please give me an example?
Cheers,
Smivs.

I downloaded it just a few days back and was wondering why I never saw the bright buoys you advertised Only now when I wanted to open the shipdata file, I noticed my plist editor refuged to open it. I think I found 4 or 5 missing semicolons. It is probably easier when I give you the corrected version of the .plist file.
And yes, it is sometimes a bit frustrating if things work on one OS but not on the other. You think you had tested it perfect...

I can’t reproduce the crash. Given the large number of OXPs you were using, it’s possible that some combination of OXPs triggered the problem.

Please try loading the file with only Save Anywhere installed. If that works, try to track down which combination of OXPs triggers it. (The efficient way to do this is to add half the OXPs, and if that works, swap for the other half. If it still works, try adding half of the remaining OXPs; if it crashes, try removing half the installed OXPs to narrow it down.) If you can find a combination of OXPs that triggers a crash, please post a list of them including versions (or, better, provide a zip file of all of them since getting hold of specific versions can be a problem).

Thanks Eric,
I can believe I missed some more on the quick scan I gave it. I've taken the liberty of copying your corrected version into the OXP and re-uploaded it, so the v1.2 now available should be OK.
As a Linux user I spend half my time sorting out case-sensitive issues, but a dodgy plist that parsed as OK is a new one on me. Ain't life full of surprises.
Thanks for the help...much appreciated.

Smivs wrote:

Thanks Eric,
I can believe I missed some more on the quick scan I gave it. I've taken the liberty of copying your corrected version into the OXP and re-uploaded it, so the v1.2 now available should be OK.
As a Linux user I spend half my time sorting out case-sensitive issues, but a dodgy plist that parsed as OK is a new one on me. Ain't life full of surprises.
Thanks for the help...much appreciated.

I uploaded it twice. I don't know if you have the most correct version now. The windows parser was always very forgiving with syntax errors. And there were two definitions for some syntaxes. e.g. for windows is was always allowed to terminate the last item in an array with a comma. Under the Mac OSX 10.4 this resulted in errors. A comma was not allowed as terminator of the last array entry because it was only a divider for the entries. With OSX 10.5, apple has adopted the syntax that does allow the comma as terminator and the plist editor that ships with OSX 10.5 and 10.6 now even always adds that comma at that last location. Very frustrating for me, as I know this will give errors on older mac OS (Tiger). For my private use I prefer the newer editor, but I always try to make sure I re-save the plists with the old editor for Tiger, to get the syntax accepted by all OS systems.

My first upload was saved with my normal plist editor. (That editor also changed all the indentation as you probably noticed).