Oolite Bulletins

And my question is: Capt Murphy, how did you get a main planet without atmosphere?

Edit: and are shaders on at all?

No, those png files not being there shouldn't cause any major trouble. Oolite should simply ignore the missing files, and carry on as normal... :? Anyway, it looks like you've got a setting somewhere - either inside a planetinfo.plist or a js file - that says you need those pngs. Have you tried to g...

mandoman, I'm also confused... can you confirm that the files Oolite says are missing are actually inside your Oxp folder?

If you have access to the source code and can compile it, you can do whatever you like with it. That's the major point of open source. Therefore: it's very feasible to maintain a source tree with energy bombs enabled, and most of your questions don't compute: it's impossible to give 'definitive stat...

Hmm, strange. Both 1.76 & maintenance did have the same wrong bits, and I haven't ported my previous tentative fix... I've ported cim's fix to maintenance now, so there shouldn't be any of those errors in maintenance for real. That there weren't any when you tested looks like it was more of a happy ...

We're getting there! :) The underlying code is a lot less flakey now, and we should have rock solid(!) materials & shaders via plists in the not-too distant future: possibly a couple of weeks, even! Mind you, I can see a lump of RL approaching quickly, so it might be 'a bit' longer. However, conside...

In the meantime... err, I mean a couple of months later: New planets are live-ish! I don't think there are many major problems left with the new planets code - (well, there's an annoying memleak which I left in for the moment to avoid a more annoying CTD) but we're getting there. I've enabled them i...

All's well that ends well! Thanks cim for the great work!

@Gimi: aha, so it was you who submitted a trunk bug!
Trunk - by definition - is expected to have bugs...
Anyway, I'm curious about the Kaks maintenance bugfix you mentioned. Which one were you referring to?

Bugbear, are you testing using the nightly build? What you're describing sounds a lot like a bug that should have been eliminated in rev 4830

Confusing, that stack trace seems to say oolite didn't even get a chance to start... it looks like you found another bug, possibly triggered by a 'wrong' plist setting, and totally unrelated to wildships...

Just to let you know, the oolite.org site is still safe and sound, and temporarily accessible via http://oolite-linux.berlios.de And there's always some truth in dumb pilots' words! ( maybe not always easy to find, though! :P ) Anyway, it seems berlios moved a few servers & settings around, meaning ...

Cool, looks like my tentative fix actually worked! To be 100% sure, do you get the occasional Ignoring Timer Exception: line in the log when testing? If that's the case, I don't know about you, but I'm planning to say 'yeah, in your face, bug!' for a while... :mrgreen: Ahem, I suppose there's always...

Hmm, I'd start from rev4761: the shader synthesiser is still not-quite tested properly (the pink cobra3 will revert to blue once we're sure the synthesiser is working ok) and with hindsight, the problems you're having sound exactly the kind of problems an unfinished shader synthesiser would create.....

Well, it's definitely possible for an oxp to place any targetted object a couple of inches in front of the scoop - different ships can have different scoop positions, though! :) Actually, I seem to remember someone releasing a tractor beam oxp. Hopefully someone else will have better memories than m...

Hmm, I'd be more inclined to use already existing mechanisms ( I'm thinking OXPConfig ) to change oxp equipment settings... a dedicated 'change primable equipment settings' key seems to me to just increase interface complexity in exchange for little extra functionality. Sorry timer, I totally misund...