Oolite Bulletins

A mirror for  Cabal_Common_Library1.7 is available.

The next version of Cabal_Common_Library will ship another toy for the inflight overlays - a way of combining a custom colored overlays with a decal map. It can be used to show accessoires like helmets etc.

The image is a rough example (graphics not really done yet), but enough to show the possibility.

Wow!
I love that! I want to get a picture of my commander, too...
On further consideration... would it be hard to let you put your own photos into such a tool? A simple template for where the nose/beak/snout and eyes should be etc. .

Rorschachhamster wrote:

Wow! :shock:
I love that! I want to get a picture of my commander, too... :lol:
On further consideration... would it be hard to let you put your own photos into such a tool? A simple template for where the nose/beak/snout and eyes should be etc. :?: .

It isn't that hard to put together a shader that uses multidecals (or a texture atlas), but its nothing for CCLs inflight overlays, because your own Commanders picture would only make sense on standard GUI screens and HUDs (and you can't display models on standard GUI screens). CCL does the shadered overlays inflight (see Overlays and Colored Overlay) to visualize NPCs and notifications. It can display up to 19 overlays - so I'm trying to keep it simple and fast.

But if you really want your picture onscreen and if your box supports shaders - you can.
Just place your pic (png, 128px x 128px) in the Textures folder and add the following line to any OXPs this.shipWillLaunchFromStation function.To make it look better the picture should be a 32bit texture, with the alpha channel set to zero for 'unused' parts. CCL ships a frame for it (ccl_overlay.png) which can be used as template, but you can use it without as well.

We are working on a addition for CCL to generate sentences - CCL_PhraseGen. It has matured already up to a point where it can be shown to other authors and if all is well it will be merged with Cabal_Common_Library.

CCL_PhraseGen0.97_public -> https://app.box.com/s/m7zgdpe7tg0492w9ikxi (38.4 KB) - Requires Oolite v1.77+ and Cabal_Common_Library1.7+.
A first attempt on documentation -> [wiki]Cabal_Common_Library_Doc_PhraseGen[/wiki]

The zip contains 2 parts, a OXP part and a additional tool part to be run in Firefox - just start the htm file (it may fail in other browsers) and play around with it. The tools basics should be selfexplaining. The OXP part spawns a testship on launching which uses generated output from CCL_PhraseGen Samples via .commsMessage() to test the inflight usability. You can use the complete thing as is, Oolite ignores the tool parts.

What is possible with it?
The shipped Samples are showing only a fraction of possibilities, names etc. But the next Snoopers version will sometimes generate complete news stories with it, or it can be used to 'create' ship2ship comms or character profiles. Lots of stuff is possible (and the tool itself is fun to play with ...).

So don't be shy - give it a try .-)

Disembodied and Svengali

<chortles> I've never been so insulted! Very cool!

Cody wrote:

<chortles> I've never been so insulted! Very cool!

Most of the time, nobody will ever have been so insulted ... it's the Dice Waltz of abuse.

(can't get the link to work in the text ...)
(cracked it - it's umlaut-phobic)

When I turned on script.javaScript.call and startup.progress in logcontrol.plist then I found the startup of Cabal_Common_OXPStrength.js need about 1.5s, but after a few optimization  CCL v1.7.1 can start in 0.2s.

For OxpConfig V3 i will need to introduce many (like 15+) new functions.
They fall in 2 categories :
- general functions that deal with objects/arrays mostly
- functions to allow oxps to interface directly with OxpConfig user-input screens.
This should make writing F4-interfaces easier.

Both would be useful for other oxp authors.

I've talked about it with Svengali , and while they could be added to CCL, he indicated CCL has become to massive already and there may be broken parts since 1.80 .

The oxz-manager makes it easy to have dependencies on multiple oxps, maybe we should look into splitting CCL into lots of new small libraries ?

This would make maintaining them much easier, and allow a purge of unused functions.

If others agree, i could start this by introducing 2 new libraries in separate oxps :
- CCL_common_functions
functions from CCL common that are actively used now could be moved there
The new object/array functions i need for OxpConfig v3 would also be put in that one

CCL_interface_functions
This would hold the functionality needed for OxpConfig configuration screens, making them available to all oxps WITHOUT having to install OXpConfig.

Lone_Wolf wrote:

splitting CCL

As I thinked on this I started to feel myself within a minefield. For example, purging a function need to check through all existing oxps to be sure that it is not used anywhere. Furthermore regardless of you make an alternate CCL the original is not removable due to probably we can not remove the dependency within all OXPs need CCL.

I think the best if we leave the current CCL as is and you can make another library with similar and new fuctions, then authors can decide if worth to make updates in the existing works and use only the new one in the future.

Understood, i'll just create new library oxps then and copy functions from CCL 1.7.1 i use in oxps to the new libraries where applicable.

I'd like to keep CCL in the name of those libraries, as i see them as the next step in CCL evolution.
To make the difference between CCL old and new clear, maybe prepending the library name with CCL2 would work ?

Lone_Wolf wrote:

CCL2 would work ?

Sounds good as name. In addition you can start the version number at 2.0 and we should keep the future versions of the original CCL below 2.0 to avoid disturbing clashes.

While I realize CCL is deprecated in favor of Library, and I am not sure if anyone is using the feature, I see that Cabal_Common_SpecialMarkets references some of the commodity aliases that were removed in Oolite 1.82.

I got tired of seeing JavaScript exceptions in the Latest.log whenever some OXP would send a comm message using the Cabal Common Library and looked into it...

This is a fix if anybody is mantaining it (deprecated it might be, but it's still used by a lot of OXPs out there...):

Because I'm a nice guy ( ), version 1.7.2 has been released which incorporates the two issues highlighted above.

More bugs squashed. Onto the next one...