OXPConfig

[GGShinobi]

Indeed your post is so good, I'd even recommend to add it to the wiki or at least place a link there to your post. What do you think??

You are right - the doc is incomplete. I've reworked it now - hopefully it will be more valuable now. Some things are beyond the scope of OXPConfigs documentation though, because they apply to all OXPs in Oolite (e.g. infos about loading order, access to missionVariables, order of fired handlers, Oolites timelimiter and profiling via console).

Thanks for updating the wiki - I'll have a look at it soon!

Muchas gracias for your input, GGShinobi. I'm not so good at explaning and need some reminders to clarify things

You're most welcome! And I disagree, your documentation is very good and your explanation to my question was excellent! This is what I call "premium support"!

Btw: it's normal to skip some info: if you are close to the code, you often think something is obvious, although for an outsider it may be a miracle! It's very funny when you have to look at code you wrote some time ago, and understand nothing, despite the comments you added back then and thought "why comment - it's clear!"

[GGShinobi]

So, I had a look! Nice work on expanding and rearranging the wiki!!

2 points (where the seconds makes the first obsolete):

• Some things are beyond the scope of OXPConfigs documentation though, because they apply to all OXPs in Oolite (e.g. infos about loading order, access to missionVariables, order of fired handlers, Oolites timelimiter and profiling via console).

  I agree, but at the same time I think it's a little sad that you gave me such a great explanation and it will not be "reachable" through the wiki
• I noticed the last link in your linklist is still blank (...) / seems to be a placeholder. It should point to "infos about loading order, access to missionVariables, order of fired handlers, Oolites timelimiter and profiling via console." Does such an article already exist in the wiki? If so, and if the explanation there is as good as yours, forget my first complaint!

[Svengali]

I noticed the last link in your linklist is still blank (...) / seems to be a placeholder. It should point to "infos about loading order, access to missionVariables, order of fired handlers, Oolites timelimiter and profiling via console." Does such an article already exist in the wiki?

Unfortunately no. Parts of it get touched by PhantorGorth [wiki]Handling_OXP_Dependencies_with_JavaScript[/wiki] page, but most of these infos are scattered on the BB. It is a complex field and a explanation which covers all these little problems for OXPers won't be so easy. We have so many different ways of setting up OXPs and we have different ways of starting Oolite with different sets of handlers firing (e.g. https://bb.oolite.space/viewtopic.php?f=4&t=8848&start=2) that it is difficult to catch all these cases in a documentation.

[GGShinobi]

I noticed the last link in your linklist is still blank (...) / seems to be a placeholder. It should point to "infos about loading order, access to missionVariables, order of fired handlers, Oolites timelimiter and profiling via console." Does such an article already exist in the wiki?

Unfortunately no. Parts of it get touched by PhantorGorth [wiki]Handling_OXP_Dependencies_with_JavaScript[/wiki] page, but most of these infos are scattered on the BB. It is a complex field and a explanation which covers all these little problems for OXPers won't be so easy. We have so many different ways of setting up OXPs and we have different ways of starting Oolite with different sets of handlers firing (e.g. https://bb.oolite.space/viewtopic.php?f=4&t=8848&start=2) that it is difficult to catch all these cases in a documentation.

Oh I see... well I guess it's no big deal - the documentation in the wiki is already very good, and when someone needs further info, he can still always ask the friendliest BB this side of Riedquat for help!!

[Svengali]

OXPConfig v2.3.1 is online.

Changes:
- InfoB, InfoS and InfoE are now easily changeable.
- Added Cmd Cheyds "Deep_Horizon_Adv_Nav_Comp".

Special thanks to GGShinobi .-)

[GGShinobi]

OXPConfig v2.3.1 is online.

Changes:
- InfoB, InfoS and InfoE are now easily changeable.
- Added Cmd Cheyds "Deep_Horizon_Adv_Nav_Comp".

Special thanks to GGShinobi .-)

No, thank YOU Svengali for this great OXP and that latest update - I'll use those new features right away!!!

[Lone_Wolf]

On the OxpConfig wiki page, it says this :

List of color supporting OXPs

- none

If that is true, i could remove the code in next version.

Please respond if you know any oxp that uses this.

[Svengali]

On the OxpConfig wiki page, it says this :

List of color supporting OXPs

- none

If that is true, i could remove the code in next version.

Yep. I'm not aware of any released OXP that uses it - although I haven't checked anything after Dec 2013. In the end it's just another 'experiment'.

[Lone_Wolf]

Thank you, svengali.

If no one reports using color support, i'll probably deprecate it for next version.

If it is used, i could log a message to both player console & logfile that color support will be removed soon.
If that doesn't give responses, it can be removed in the version after that.

[Svengali]

I guess you can remove even more. I've added a while ago some functions to dump missionVariables, worldScript properties and sound declarations, namely

this.dumpMVs
this.showWSList
this.dumpWSProps
this.dumpSounds

As I haven't seen anybody posting logs with this kind of stuff it's probably the right time to remove them all together.

[Lone_Wolf]

I've looked at OXPConfig.js and feel several "issues" stem from the way interaction between OxpConfig and it's users (oxps) is setup.

Currently oxps declare a this.oxpcSettings object in THEIR code.
At runtime, OxpConfig startup searches for those objects.
As OxpConfig has no idea what the oxps have put in there, a lot of verification/translation is needed.
The search/verification/translation can (and often does) happen multiple times during play.

http://wiki.alioth.net/index.php/OXPCon ... pcSettings


Another (minor) drawback : The Name field for Boolx, SIntx, EInt0 is limited to top-level properties of the oxp.
example :
Code:
Bool0: {Name:"logging", Def:false, Desc:"Logging functions."},
Bool1: {Name:"sound.activated",Def:false, Desc:"sound on/off."},

Bool0 will be linked to worldScripts["someoxp"]logging, linking Bool1 to worldScripts["someoxp"].sound.activated will fail.
---------------------------------
Basically, OxpConfig tries to make things as easy as possible for oxps, but this comes with a rather steep price (complex code, slow performance) for OxPConfig itself.

I think changing the interaction between OxpConfig & oxps can solve the issues.

An example of what i have in mind :

Create a new helper-oxp, called OxpConfigData .
It will hold an oxpcSettings2.oxpname object for every supported oxp with default values, flagged as inactive.
The oxpcSettings2.oxpname objects will be stored in the savegame and only initialised/loaded on request
OxpConfigData will also keep track of which oxpcSettings2.oxpname object have been activated.

Before using any values from worldScripts["OxpConfigData"].oxpcSettings2.oxpname, oxps will have to call an initialisation method.
methods to store changed settings and activate "notify handlers" will also have to be created.

This eliminates the use of searches to locate oxpcSettings objects in oxps.
It should also make verification much simpler and make several flags obsolete :
EarlyCall
EarlySet
LeaveData (Once loaded, they will be kept)

oxpcSettings2.oxpname would likely have these members :
info (similar to oxpcSettings.info )
nr_of_booleans_used
nr_of_integers_used
Nr_of_Bitmasks_used
// array objects to store vars
Booleans
Integers
Bitmasks (EInt )

A change like this will offcourse only work if oxp authors agree on it.

Please comment on this idea.

[Wildeblood]

Serious question: why would you/how many OPs do bother with OPConfig? This is from a time before the interfaces screen on F4; is it any more work to set up your own interface than to negotiate with OPConfig?

(Ever since they fixed my new computer the X key doesn't work properly, I have to really bash it.)

[Diziet Sma]

Serious question: why would you/how many OPs do bother with OPConfig? This is from a time before the interfaces screen on F4; is it any more work to set up your own interface than to negotiate with OPConfig?

Interesting idea.. even though I can see this causing the F4 page to balloon out of control.. and to be honest, I see it as being outside of the intended scope of the interface screen.. this is supposed to be a ship/station interface, not a game options interface. It would totally spoil the illusion that you're operating a space ship.

(Ever since they fixed my new computer the X key doesn't work properly, I have to really bash it.)

Time to either open up the keyboard and fix/clean it, or replace it, by the sound of things.

[cim]

Before using any values from worldScripts["OxpConfigData"].oxpcSettings2.oxpname, oxps will have to call an initialisation method.

If you're going to do that, you can probably drop the requirement that OXPConfig has to know which OXPs use it at all, which should significantly reduce the number of times a new version needs releasing.

[Lone_Wolf]

Serious question: why would you/how many OPs do bother with OPConfig? This is from a time before the interfaces screen on F4; is it any more work to set up your own interface than to negotiate with OPConfig?

Interesting idea.. even though I can see this causing the F4 page to balloon out of control.. and to be honest, I see it as being outside of the intended scope of the interface screen.. this is supposed to be a ship/station interface, not a game options interface. It would totally spoil the illusion that you're operating a space ship.

I have considered adjusting OxpConfig to use the F4 screen instead of F2 - F7 , but didn't see any real benefit of it.
Also I do feel the same as Dizziet Sma, the values OxpConfig deals with are kindalike game options and shouldn't be put in a ship/station interface.

I see OxpConfig as a library/framework that allows PLAYERS to configure oxp options.
Oolite core code doesn't offer this functionality.
Currently 24 oxps use OxpConfig, so there IS a demand for such a framework.

Before using any values from worldScripts["OxpConfigData"].oxpcSettings2.oxpname, oxps will have to call an initialisation method.

If you're going to do that, you can probably drop the requirement that OXPConfig has to know which OXPs use it at all, which should significantly reduce the number of times a new version needs releasing.

Part of the reason for splitting the data into a separate oxp was indeed to reduce the number of OxpConfig releases.
After making the previous post, i realised that changing the interaction can be done without moving oxpcSettings from oxps to OxpConfigData .
I do think this would reduce the performance issues a lot and remove the need for OxpConfig to keep a list of supported oxps.

The amount of verification needed could be reduced by providing a template oxpcSettings object (pointers to notification handlers would also be part of the template) .
Oxps would then create a new instance of that template and pass that to OxpConfig on initialisation.
loading / storing the settings would then be a job for the oxp, not for OxpConfig.

Using this method does feel like a 'natural' evolution of OxpConfig, moving oxpcSettings to OxpConfigData feels like a revolutionary change.