Oolite Bulletins

Diziet Sma wrote:

pagroove wrote:

As a co-author of BGS (A lot of sounds I made for it) ... Anyway I can maintain the sound side of it but I need to be paired with a strong programmer for the scripting side of BGS.

Did you grab a copy of the BGS Female Comms Chatter patch yet? And would you like a copy of the original audio files it was made from?

Not yet. But will download it soon.

Diziet Sma wrote:

Well, at this point the ships and stations probably won't need a lot in the way of work, other than roles, etc.. so mostly plist type stuff.. and if it comes down to the point where the docking ports need attention, there's lots of help available here.

If you're agreeable then, I'll put all the 'orphans' under your care.

That's probably true. OK, you've talked me into it

OK, I'll set up a new orphanage then.
"Come along little ones..."

Fantastic! Your blood's worth bottling, as my stepfather used to say..

List has been updated.

Diziet Sma wrote:

Fantastic! Your blood's worth bottling, as my stepfather used to say..

Er, thanks

For my shieldcycler oxp i needed additions to OxpConfig, and functioned as a tester to get them working.
This gave me a basic understanding of how OxpConfig works internally.
If needed I am willing to take on OxpConfig .

I'm also interested in LocalHero, but have no experience with mission oxps.
Also all i can find is the old code for Localhero 1.05, maybe Svengali has WIP-code ?

Lone_Wolf wrote:

If needed I am willing to take on OxpConfig .

That would be fantastic! Much appreciated!

Lone_Wolf wrote:

I'm also interested in LocalHero, but have no experience with mission oxps.
Also all i can find is the old code for Localhero 1.05, maybe Svengali has WIP-code ?

I'll ask him if he has anything..

I've added your name for both OXPs.

Something that might save you a bit of maintenance work on OXPConfig: now that Oolite 1.80 has separate startUp and startUpComplete it might be more practical to let OXPs use OXPConfig without OXPConfig itself needing updating first.

cim wrote:

Something that might save you a bit of maintenance work on OXPConfig: now that Oolite 1.80 has separate startUp and startUpComplete it might be more practical to let OXPs use OXPConfig without OXPConfig itself needing updating first.

I do understand the difference between those 2, but am not clear yet who should start first.

I THINK you mean calling oxps should use startUp, then OxpConfig should use startUpComplete instead of startUp ?

Lone_Wolf wrote:

cim wrote:

Something that might save you a bit of maintenance work on OXPConfig: now that Oolite 1.80 has separate startUp and startUpComplete it might be more practical to let OXPs use OXPConfig without OXPConfig itself needing updating first.

I do understand the difference between those 2, but am not clear yet who should start first.

I THINK you mean calling oxps should use startUp, then OxpConfig should use startUpComplete instead of startUp ?

Yes. This is what cim means. Currently OXPConfig needs to call the OXPs startUp for OXPs which are using the EarlyCall flag. Otherwise properties would be undefined. The loading order is a beast .-) If OXPConfig uses startUpComplete instead then all OXPs have done their own startUp already.

Edit: But systemWillPopulate runs before startUpComplete gets called! So it might be too late for some OXPs. I would leave it as it is .-)

Svengali wrote:

Yes. This is what cim means. Currently OXPConfig needs to call the OXPs startUp for OXPs which are using the EarlyCall flag. Otherwise properties would be undefined. The loading order is a beast .-) If OXPConfig uses startUpComplete instead then all OXPs have done their own startUp already.

Edit: But systemWillPopulate runs before startUpComplete gets called! So it might be too late for some OXPs. I would leave it as it is .-)

Thanks for the clarification, maybe EarlyCall should be taken out of oxpcSettings and be added as a flag to the list of supported oxps.

My ShieldCycler for example has no need for EarlyCall , there may be other oxps that know in advance they don't require EarlyCall.

Lone_Wolf wrote:

Thanks for the clarification, maybe EarlyCall should be taken out of oxpcSettings and be added as a flag to the list of supported oxps.

I'm not sure about this change - you'd have to check these OXPs then every time a new version gets released.

Svengali wrote:

Lone_Wolf wrote:

Thanks for the clarification, maybe EarlyCall should be taken out of oxpcSettings and be added as a flag to the list of supported oxps.

I'm not sure about this change - you'd have to check these OXPs then every time a new version gets released.

That is correct, but i do feel the oxp authors that use OxpConfig should be more involved in OxpConfig development.
Not sure yet how to achieve that though.

Lone_Wolf wrote:

<snip>, but i do feel the oxp authors that use OxpConfig should be more involved in OxpConfig development.
Not sure yet how to achieve that though.

*grins* Sounds like a good plan, but don't hold your breath. Usually it takes some time before OXPers are starting to dig in other projects, regardless of announcements or documentation. Probably I should have been chattier...

Tricky has agreed to take on BGS..

Diziet Sma wrote:

Tricky has agreed to take on BGS..

Excellent!