Oolite Bulletins

Hi all.

I have downloaded the new revamped version of Lave with all it's advert ships, ect.....

When I start a new game and I am in Lave to start with, things are fine and Lave works well.
However if I travel to another planet, then come back to Lave, the game crashes and the PC freezes.

If I delete the lave.oxp folder the game is OK, so there must be something wrong with the folder and it's contents.

I would like to keep this new Lave because it looks good.

Is there an updated version anywhere?
If not, could someone who is not having this same problem, please email me their Lave.oxp folder?

Email is [email protected]

Thanks.

Hmm, that OXP has been around for quite some time and I don't know of any other version. I've sent you my copy of the OXP but I don't expect it to be any different, as there isn't anybody else reporting the same problem then it may have something to do with your computer.

Let us know how you get on.

Could be you graphics card or drivers. Lave.oxp seems to be quite demanding. I have a Radeon 9600 Pro and with lave.oxp installed the game is lagging heavily when visiting the Lave system.

If you are on UNIX it could be a case sensitivity bug with the texture for the moon. Check that the case for the texture (ending .png or .PNG) in planetinfo is the same case as the texture in the Texture folder.

Thanks guys.

Thanks for the opx folder Uncle Reno i will try it out.

Stainless Steel... my graphics card shouldn't be the problem as I run much better and more demanding games on this laptop. Plus I would think Lave wouldn't have worked at the start of the game instead of only crashing when traveling back to Lave.

LittleBear... I'll look into the texture file name case too, just in case.

OK this is so weird.

I have tracked the problem down to my planetinfo.plist file.

In the file I have.......

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>universal</key>
<dict>
<!-- Change this value to move the sun closer to or further away from the planet. The game's default
value for this is 20. -->
<key>sun_distance_modifier</key>
<real>100</real>

<!-- Set this to 1 to enable the procedurally generated planet and cloud textures. A value of zero
means use the game's default planet and cloud rendering routines. -->
<key>generate_textures</key>
<integer>1</integer>

<!-- Set this to 1 to draw the cloud textures, 0 to not draw the atmosphere. -->
<key>show_atmosphere</key>
<integer>1</integer>

<!-- The width of the textures generated for planets and clouds. Must be a power of 2. -->
<key>texture_width</key>
<integer>512</integer>

<!-- The height of the textures generated for planets and clouds. Must be a power of 2 and half
of texture_width. Probably take this out later and calculate the value from texture_width. -->
<key>texture_height</key>
<integer>256</integer>

<key>station_roll</key>
<string>0.1</string>

<!-- The ammount of light shed on the dark side of planets and ships. -->
<key>ambient_level</key>
<real>0.5</real>
</dict>
</dict>
</plist>

I have discovered that, for whatever reason, if I have the ambient light setting at 0.5 or higher then the game will crash when going back to Lave.
However with the setting at 0.4 or lower the game is OK.

I know I don't know anything about the programing of this game or it's files but I find this very strange.
I have no idea how the ambient light level setting can affect the Lave.oxp.

Well it works now anyway. Just took a bit of detective work to find the problem.

simple...

not offering an exact explanation to why this is happening, Chrases like this are usually occuring when the code tries to put values that are not within a containers legal parameters..

Example

string example[10]

example[11]= "i love bugs"

result = Crash...

Why, because the program has not allocated memory for example[11] only for example[0-10]

A Good compiler(a program that makes the source code into a program) will certainly catch my example and issue a warning.or depending on the compiler settings, downright refuse to compile the sourcecode..

But where mathematics and numbers are involved multiplication/Division/substraction/addition can create crashpoints not easely caught by a compiler...

All that said, im talking from my exeprience with C++. not Objective C, which i beleive oolite is written in...

anyway, what version of oolite are you running ?, oolite 1.68 has certain problems with planetinfo.plist being altered in the OXPs... something that will not allow assasins. oxp to run on Windows PC.... however it will run fine on mac.

I am using v1.68.

I find it hard to believe that changing the value of ambient_level could cause a crash. Did you test the fix repeatedly? It seems much more likely that this is a sporadic bug and the apparent correlation with the change was spurious.

Yes I tested the 'bug' many times.
I first found it was to do with the planetinfo.plist file by deleting it. The game then worked.

So I reinstalled the file and deleted the lines that deal with the planet textures, and it still crashed.

Then I took the station rotation line out and still it crashed.
Then I took the last line out, the ambient light part and it worked.

I then put all lines back in the file except the ambient light line and it still worked.

I then changed the setting to 0.4 for the ambient light and it still worked.

Anyway, i kept using various settings and found that anything over 0.5 would cause a crash when hyperspacing back to lave.

It works now anyway because I wanted the ambient light turned down anyway.

Very mysterious