Well this sucks

[Smivs]

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. With OSX 10.5, apple has adopted a syntax that does allow the comma at that place and the plist editor that ships with OSX 10.5 and 10.6 now adds that comma at that location. Very frustrating for me, as I know this will give errors on older mac OS. For my private use I prefer my newer editor, but I always try to make sure I re-save the plists with the old editor to get the syntax work for all OS systems.
My first upload was saved with my normal plist editor. (Changed also all the indentation as you probably noticed).

OK, I'll assume I've got the correct version for now...I'll have a good look through it to check and if there are any problems I'll sort them out later today (I'm supposed to be going out with the family right now ).
My parser is usually very fussy where closing semi-colons are concerned. It finds them all the time
Ho Hum!

[lave]

Thanks for the replies guys.

I will try to track down the oxp/s that may be causing this.

Also, I forgot to say, my laptop does not support shaders, which is why the station entrance was dark.

Another idea I had was that I have 2 save files.
One will be the main file which I use whenever I save at a main station. The other will be for when I have to save at another location.
If I save at another location, then I save and overwrite the second file. I then remember to load that file when I play again. If, again I save at a non main station, I will save to this file again.
However if I save at a main station I will overwrite the first main file, then play from that again next time I play.

Basically one file will be saved at a main station the other will be for saveanywhere.oxp.

If one then messes up, I can then revert back to the earlier version. In other words I have a back up save file.

Of course if both mess up then I am f#@ked again lol.

[Smivs]

Hi Lave,
I've taken to copying a save-file once in a while (week, month) and keeping it to one side somewhere safe. I date them

Code: Select all

16.1.2011smivs.oolite_save

for example, so at any time I can go back to a working save, and choose when to 'pick-up' the game. Very useful if things do go pear-shaped.

P.S. Lots of OXPs (mine included*) have nice lighting effects that do not require shaders. My rig doesn't do shaders, but my Ooniverse still looks beautiful.
*Accessories has been Mac un-friendly as you will have seen...hopefully sorted now.

[lave]

Yeah I will do that. Thankfully I am not too far into the game, with only 2 kills now, but it's all the asteroid mining that I had to do to get my Cobra fully armed that I will have to do again.

I am using Linux too. Never liked Macs lol.

Thanks.

[Eric Walch]

Hi Lave,
I've taken to copying a save-file once in a while (week, month) and keeping it to one side somewhere safe. I date them

Code: Select all

16.1.2011smivs.oolite_save

for example, so at any time I can go back to a working save, and choose when to 'pick-up' the game. Very useful if things do go pear-shaped.

Do you make a copy by "save as.." from within Oolite or make you a copy with your OS. I just ask because in the later situation you can mess up your newest commander. At least it happened to me:

Oolite saves the filename inside the save file. Than when loading a renamed file, it stores that internal commander name as default save name. Than when doing a save, you get the usual question to overwrite the existing file. You say yes, but it is not the renamed filename, but the original filename that is overwritten. And when it happened to me, I explicit used a copy of the file to not mess with my main commander. (At least this is how it works for Oolite on a mac. I have no experience with Oolite on other OS)

I also save my commander regular away with a numbered name to keep copies of several states. But since Mac OSX 10.5 it has a backup system integrated. (The percentage of mac users that makes backups has dramatically increased since than). As long as the backup disk is large enough, it backups a copy of my hard disk with spacings of a week. It makes an incremental backup every 2 hours, but deletes most of it after some time, so for the older files it only keeps a version for every week. It already proofed very useful for files I changed but were I wanted to revert to older versions later on.

To Lave,
I hope you can find the offending OXP. Even when you manage to bypass the bug, finding the real cause is important to fix this problem for future releases. An offending oxp should never crash Oolite, so its an Oolite bug also.

[Smivs]

I do a normal 'quick-save' then take a copy, paste it to a remote folder and rename as described above. It will be 'smivs.oolite_save' after the quick save, so this gets copied and pasted elsewhere, then re-named. If I want to use it, I rename it back to smivs.oolite_save, then copy/paste back into the saves file over-writing the damaged? one in there.
This has worked without trouble the couple of times I've had to do this.

[drew]

Hope you enjoy the pulsar when you get there!

Cheers,

Drew.

[lave]

Thanks.