Trunk nightly

[Cody]

<applauds> Thanks... and white tea is preferable.

[Getafix]

Due to an in progress dispute with Google,
windows nightly binaries are temporarily moved back to terrastorage.
This means you will experience very low d/l speeds.
An alternative to accelerate your existing nightly installation update,
is the use of an rsync client, as per this post.

EDIT 2017.04.19
It seems like a bandwidth issue (e.g. number of file downloads) with personal Google Drive accounts.
No answer from Google yet; I do not think that they will ever revert to me, though.
New nightly is uploaded in Google Drive.
The windows nightly page download link has been redirected to Google Drive again.
(as long as we do not violate the unknown bandwidth limitation )

[Cody]

Went atmosphere-diving to check Griff's station update, and deep in the red some strange gfx stuff appeared.

[another_commander]

Went atmosphere-diving to check Griff's station update, and deep in the red some strange gfx stuff appeared.

This seems to be issue #84 and the culrpit seems to be the nebulae textures in Zygo's skies. Try the Textures folder from here and see if it gets resolved: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

[Cody]

That fixes the blocky stuff - thanks - but blobby, blobby!

[another_commander]

Thanks for confirming fixed. As for the blobby, yep, that's something we currently live with. This happens also with the core nebula textures, but it's not that visible because by default nebula density is limited.

Edit: And because the core textures format is correct (8-bit grayscale).

[another_commander]

Updated the fixed package for Zygo's skies with correct format nebula textures. Please test inside atmosphere if you want: https://drive.google.com/file/d/0BwG6R5 ... sp=sharing

[Cody]

Thanks - will test tonight.

[Cody]

Sorry to report another crash, again when loading a commander (via F2).

[Cody]

The blobbiness seems much improved - thanks again!

[Cody]

I doubt this will help, but I spent about an hour this evening looking for that crash (sheer monotony), and forced it four times.
As above: from F5, F2 Load Commander, select Commander, hit enter - game gone!

[another_commander]

Please post Latest.log, if possible from a crash after starting Oolite with Shfit (or just set the always-flush-cache to true in .GNUstepDefaults). Reason for asking a shift-start crash log is that there could be messages from the ship registry load that we would not see when the cache is used. Also, please post the save game that is causing it. I am completely unable to reproduce it and I just can't see why it would continue to crash following the fix of issue #204.

I wonder if your organized OXP folder could have something to do with it. Although nested OXP folders do work, they are not officially supported and I am not sure if there is something going on with that. Also, the frequency at which you are receiving crashes makes me wonder if there is something physically wrong in the system like memory or HD problem, or the antivirus shutting down Ooltie for some reason. The thing is, if we can't reproduce it here, it can't be fixed, so please provide as much info as possible in order to attempt tp recreate it. Worst case scenario: Zip up your entire Oolite installation and upload it somewhere so that we can download it exactly as you have it.

[Cody]

I'll disorganise my OXPs and run like that for a while (having first made a .zip of my current Oolite installation*). Not today though, as I'm plagued by a persistent headache. As regards my system: oodles of RAM, oodles of HDD space, no AV - and all running smoothly.



*Minus Griff's shipset and Povray (to keep the size below my Box account limit).

[another_commander]

Quick q, just to get the obvious easy stuff out of the way: Which trunk version are you running? Check your log's first line where it reports the git commit revision.

[Cody]

As reported above, 1.85.0.6907-170327-31394c5