Oolite Bulletins

Kaks wrote:

Oops, I think that the previous Black Baron update was done & uploaded by me via a now dead computer, so we'll need a completely new location for the new version of this OXP...

Before I forget, I suppose I'll have to reopen the OXP orphanage... do we have a list of orphaned OXPs anywhere?

The one I just updated was your one for v1.70 - it was uploaded on the wiki itself (on aloth.net). If the update is ok for Rxke, then perhaps he can upload it there. That's the one linked to from the wiki OXP page.

There was a bug in the old version too - if you took the mnission in G1 but then jumped to G2 (or beyond) without visiting the relevant planet, if you go to the same numbered ones in G2 etc then the mission will trigger then (no galaxy check is done except for the first offering).

Eric Walch wrote:

Kaks wrote:

do we have a list of orphaned OXPs anywhere?

What about this sticky a few topics higher. Its has had no new posts for a good year now. Is that good or bad?

It does not contain many oxp's, so nobody sees orphaned stuff around.

That's the very orphanage I was thinking of reopening!
This probably means there's no current list... drats.

Thargoid, good to know you've got everything sussed out!

I uploaded the new BlackB version to a Box.net account, made a stub page on the wiki, but left the old version in the list where it was. (As I said, not so much free time at the moment) here it is: http://wiki.alioth.net/index.php/Scourg ... lack_Baron

So to do (for me): change that entry in the alphabetical list, maybe keep the old version for people who still use 1.65?


EDIT: cleaned up stuff, everything now redirects correctly to the page dedicated to the mission. Both versions available there. Page needs wikification etc but the bare bones are in place.


Again: thanks for your work guys!

Ahruman wrote:

Quietly? The old approach to mission screens is – for JavaScript – explicitly deprecated. Scripts that use it will not work in the stable release. This is, again, what we mean by “unstable”.

I thought that to be clear on what will still work and what not oxp-wise would not be too bad, and I had noticed that I even read all that stuff on oxps and deprecations etc. and still didn't know.

Reading through the thread I am still content that I asked the question - though you are technically completely correct that your answer was already given before, of course

Right On, all your work much appreciated here as always

L

Well, the wiki is usually pretty clear on what will work and what will not in upcoming releases. That's what for instance a category like Updated JavaScript features in Oolite 1.74.2 is for. And that's why you will find on top of for instance the SystemInfo-page the sentence "This class was added in Oolite test release 1.74.", which simply means that SystemInfo didn't exist in Oolite 1.73.n, so you couldn't use it. And further down on that page, at the systemsInRange-method, you find the sentence "This method is planned for Oolite test release 1.74.2. The design and functionality presented is not final." And in other places you will find a sentence like "This property/method is deprecated in Oolite 1.nn.", which means that from this version onwards it will give a warning message. And if you don't find the method anymore on any page, it was removed and has stopped working, so it will give an error if still used.

Thanks for the systemsInRange reminder, I've updated the documentation now. Hopefully what I wrote there makes some sense!

I've been playing with the mission screen and have been using recursion for a persistent menu with a quit option. This works well but is there a recommended limit on recursive calls? At the moment selecting an option which isn't possible simply leaves you in the same menu (or another call of the same menu), I can imagine someone pressing the button fifty times and overloading their stack. Oh, the humanity.

Call me strange, but I'd definitely avoid providing choices that don't do anything...

As for the stack limit, good idea. I'd limit it to 16 nested screens, myself.
Anything that takes more than 3-4 screens, I tend to press F1, but others might be more patient than me...

docwild wrote:

I've been playing with the mission screen and have been using recursion for a persistent menu with a quit option. This works well but is there a recommended limit on recursive calls?

Calling runScreen() from the completion callback isn’t actually recursion, since the callback is called in a later event cycle, like a timer.