Oolite Bulletins

OXPConfig

This tool gives you the ability to configure several OXPs. It changes settings to enable (or disable) logging or audio functions and special settings to reckognize errors or to avoid clashes or to adjust numbers of planets/moons, etc. OXPs can use it in a lot of ways and in most cases it only needs a few additional lines of code.

A new feature is "User Definable Colors" - for OXPs which want to give users more configuration options without the need of scripting a own configuration menu.

OXPConfig runs without the debug-console and is primarily meant for non-scripters (and lazy scripters), but if you really need debug-options it is highly recommended to install the Basic-debug.oxp (written by Ahruman) and if necessary the console (written by Ahruman and ported to Windows by Kaks).

As example:
oxpA has declared this.logging = false, but possibly a player gets an error while using it. With the OXPConfig.oxp he can easily change this setting (while playing) to true, so the oxpA will write some status reports to the logfile (Latest.log) and to the debug console (if installed). oxpA is responsible for what kind of infos are logged and OXPConfig doesn't change anything else than the value of this property (and maybe some other specified properties too).

WIKI: OXPConfig
Documentation:  OXPConfig Doc

Maintainer: Lone_Wolf

OXPConfig has reached v1.00. Storing and loading is implemented, so now it's time to join :-)

v1.01 is online

Changes:
- Six oxps included (released or coming): BuoyRepair, Famous_PlanetsA, Hyperradio, Localhero, ScriptTimer and Welcome Information.
- Automatic load of stored value.
- Fixed unavailable choices in some cases
- Introduced second variable to handle database-updates

http://wiki.alioth.net/index.php/OXPConfig

Ok v1.03 is online. OXPConfig is now configurable like any other oxp in the database. It has now all features I have had in mind - currently :-) - and the following versions will only update the database (I hope). So it is not only usable for non-scripters - it's also for lazy scripters :-)

Changes:
- Storing and loading of configurations tweaked
- Internal logging (configurable)
- Default configuration is stored and can be reloaded
- Automatic loading when Oolite is started (configurable)
- Selective loading of changed oxps (configurable)

http://wiki.alioth.net/index.php/OXPConfig

The link to version 1.02 in the wiki d/l version 1.01

tinker wrote:

The link to version 1.02 in the wiki d/l version 1.01

Thanks, I just corrected it.

Thanks a lot (tinker and Eric) for your fast support :-)

Just tweaked it a little bit more to catch one nasty exception when a player loads a savedgame with values from versions before v1.02 and created some pics (3 different sizes) to implement them on the Wiki-Pages with compatible (in the database included) oxps.

So v1.04 is online.
http://wiki.alioth.net/index.php/OXPConfig

EDIT: Fixed also the not executed reset on starting a new career directly after firing up Oolite. Thanks Thargoid for pointing on that.

v1.05 is online.

Just tweaked it a little bit more (grrr) to catch one more exception and removed a consoleMessage (forgot it).
http://wiki.alioth.net/index.php/OXPConfig

v1.06 is online.

Works in v1.72 and updated database.
http://wiki.alioth.net/index.php/OXPConfig

thank you!

I'm currently preparing a new version - so if you think any other oxp should be included (and is prepared with the right properties), please post it here. I'll add it then and the next version will be tested and released after v1.73.

Just to give you 3 reasons:

a) Two (or even more) oxps are doing the same thing (maybe texturing the main planet or playing a musicfile). Only the last thing survives (or both will play their songs at the same time, urgs) and will be noticeable. A simple switch can avoid it.

b) A user has problems with a oxp. By enabling the logging in this oxp we all will get better infos where this problem is and under what kind of conditions it happens. And it will be a lot easier to fix then.

c) Give users a choice for features in your oxp. Lets say 4 oxps are providing features for texturing the main planet, adding secondary planets and moons, giving messages when player enters this system or leaves the station and playing music. Let the user decide what kind of feature he wants from all 4 oxps (e.g. MainPlanet textures from SystemRedux, secondary planets and moons from SystemRedux2, Messages from WelcomeMat and Music from FamousPlanets). Another example is the Hyperradio. The user can choose if she/he wants the automerge, music for launching the escapepod or if the stationlist should be shuffled. Simply by setting or disabling the switches - in the game. No need to frickle around with scripts and easy to use (for scripters and players). The settings in OXPConfig can be stored and will be restored when a savedgame is loaded.

So come on, don't be lazy. If you think that your oxp can collide with other oxps or if you want configurable features give it a try. We are getting more and more oxps and shiny new features from the engine. So clashes will happen. Help to avoid it and give users a vote :-)

I've just tested it with local hero, and it says that local hero needs to be of newer version.. it is 1.05.

I can't seem to find that newer version.. if it exists, that is.

Chaky wrote:

I've just tested it with local hero, and it says that local hero needs to be of newer version.. it is 1.05.
I can't seem to find that newer version.. if it exists, that is.

Yupp. Correct. LH v1.05 is not supported, because it was written long before. OXPConfig needs fixed properties to work (logging,audio,extraA,extraB), so even if the oxp is in the list, but does not provide the right properties, OXPConfig informs you about it. LH2 will have these properties, but
a) it's still far away from being complete
b) it has nothing to do with the old 1.x version, so I'm going to v2.0
c) I won't release anything before v1.73 is there, even if it would be completed before and
d) the feature list is a lot longer now .-)

So take it as a testcase for OXPConfig then.
btw: v1.05 does not work in v1.72.x

I'm using trunk.

Perhaps OXPConfig can be a way through which player can manage the various ship replacement sets.

I don't know if Griff and/or SimonB and/or others are interested, but they could let the user configure this way which of the ships in a collection will be used instead of a generic ship and which will not.

And then if the replacement ships are also given unique names, they can be re-used and modified other OXPs without messing too much with the look and feel that the owner want for his OOlite experience..

Just thinking out loud.

Best wishes,
Oscar