Configuring oxps

[spara]

I would like to let some of my oxps to have some user configurable options and the means to achieve that are user changeable variables in the script, oxpConfig oxp or f4-interfaces screen. I don't fancy using f4 as these options are sort of an under the hood types of things and they need to be set only once or at most very rarely. OxpConfig is an impressive and ambitious oxp, but it needs to be updated for every oxp that want to use it. So for now I have used user changeable variables.

With 1.79, the script is hidden inside an oxz-file and using variables for this sort of thing is not really an option any more.

So I have an idea. There could an entry in the f2 menu that would open an interfaces type of screen that could be used by oxps for configuration purposes. It would work exactly like the interfaces screen, so that an oxp could put an entry there that would open up a mission screen. The oxp would handle the mission screen and saving/loading of the configuration.

[Norby]

Great idea!

[Diziet Sma]

Having read the rest of the recent posts in the OXPConfig thread, I agree.. Oolite provides the interface for OXPs to do what they do.. it only makes sense that it also provides the interface to make it possible to configure OXP options.

Hands up everyone who thinks that, as the OXPConfig maintainer, Lone_Wolf should be the one to work with the devs to make it happen..

[Lone_Wolf]

OxpConfig is an impressive and ambitious oxp, but it needs to be updated for every oxp that want to use it.

This can be worked around by using worldScripts["OxpConfig"].displayAll = true; in your script
(along with an oxpcSettings declaration).
Note that this workaround is intended for testing purposes and has many drawbacks if it were used on a large scale.

-----------------------------------

I do agree with the previous posters that it makes sense for Oolite to have configure options for oxps in the core game.
For oxp gamerelated options, an interface with the F2 screen is the logical place.

Some oxps use OxpConfig to set ship-related options, those could be put in an interface for the F3 equipment screen.

However I do see several reasons why i don't think that will happen anytime soon.

- OxpConfig currently doesn't have a good mechanism that will work for all oxps without requiring code changes in OxPConfig
Such a mechanism will be desgined for OxpConfig v3, but that has just entered idea stage.


- The F4 interfaces use missontext.plist & JS Mission object in a way close to what it was designed for (atleast that's my impression).
Those methods however are not designed to display values and allow changes.
A lot of the code in OxpConfig deals with working around that limitation.
Making those parts of OxpConfig usable by other oxps will not be easy, though i do see that as one of the design goals for OxpConfig v3.

- The amount of changes intended for 1.82 is already large, adding OxpConfig functionality would delay the 1.82 release further.
It does seem likely Oolite devs would postpone it for the next version.

- If OxpConfig v3 would be developed in core Oolite, testing would be limited to people using nightly builds.
Oxp authors would only be able to use the new OxpConfig options IF their oxps are kept uptodate to trunk changes.
Imo this may slowdown development and acceptance a lot.

Personally i feel that at some point OxpConfig v3 will be suitable for inclusion in Oolite core, but it needs a stable API and a mature implementation before that happens.

TL;DR : great idea, and i hope to see it happen, but imo it's too early for this.

Added

OxpConfig v2 does have a stable API, is mature and Svengali did a great job with it.
In my opinion it's design is just not suited for Oolite core inclusion.

[spara]

I'm not advocating for OXPConfig to be included into the core. I'm simply suggesting an option in the F2 screen that opens an interfaces (f4) type of screen for configuring oxps. And of course a suitable setOXPInterface method to do that. Then it's up to oxps to write their own configuration screens.

A CCL type of library (OXPConfigLib?) helping to make these screens would be great, but not necessary.

[spara]

One more thought here. A single configuration file in addition to the normal save files would be really cool so that configurable oxps could save their settings and they would be preserved over different save files. Currently the only way to achieve that is to use user editable configuration variables in scripts.

[Norby]

preserved over different save files

Similar with missionVariables but called to globalVariables, yes, I would like it.

[Lone_Wolf]

I'm not advocating for OXPConfig to be included into the core. I'm simply suggesting an option in the F2 screen that opens an interfaces (f4) type of screen for configuring oxps. And of course a suitable setOXPInterface method to do that. Then it's up to oxps to write their own configuration screens.

A CCL type of library (OXPConfigLib?) helping to make these screens would be great, but not necessary.

Upon thinking about this, i do feel you're right.

preserved over different save files

Similar with missionVariables but called to globalVariables, yes, I would like it.

I'm not sure adding a separate file is needed, a new section in the savefile might be enough.
Keep in mind however that we need tools to use those vars ingame.
The current mission / runscreen objects only use missionvars and can't handle any other variable type.
Enabling the user to see / change them will be hard.

[spara]

preserved over different save files

Similar with missionVariables but called to globalVariables, yes, I would like it.

I'm not sure adding a separate file is needed, a new section in the savefile might be enough.
Keep in mind however that we need tools to use those vars ingame.
The current mission / runscreen objects only use missionvars and can't handle any other variable type.
Enabling the user to see / change them will be hard.

I was thinking OXPs like Moar Rocks that by default multiplies the number of asteroids by 5. Someone might want that to be lower, let's say 3. It would be nice to be able to do a one time configuration from the game itself instead of setting it for every different commander.

[cim]

Adding an interfaces-like config screen for OXPs to F2 should be reasonably straightforward.

The current mission / runscreen objects only use missionvars and can't handle any other variable type.

That's technically true, but you can use title, message and choices rather than titleKey, messageKey and choicesKey to assemble the text strings on the JS side with access to any variable JS can see.

However, regarding the specific request that this is about...

A single configuration file in addition to the normal save files would be really cool so that configurable oxps could save their settings and they would be preserved over different save files.

...I'm going to say no, not from me. There are two reasons for this:

1. Directly, I think the global configuration should only be for hardware-specific settings. Size of game window, joystick curves, gamma correction, shader level, etc. There are a few things currently in there which don't meet that, and should probably be moved out of it at some point. Yes, in theory, OXP settings could be hardware-specific, but in most cases that relates to things like shader support and texture size - or widescreeniness for HUDs - for which providing two separate OXPs is probably the better approach. Otherwise you get a situation where two people can't play on the same computer with different numbers of asteroids and/or if you take your Oolite savegame to another computer the number of asteroids changes.
   
   If you do regularly start new commanders and have a lot of configurable OXPs installed, you might find it useful to set the OXP settings up, save your game as "template", and then next time you start a new commander, do it by loading "template" and saving as something else.
   
   (People with basic OXPing skills could also make the "template" save into a scenario file, or write a short OXP which writes the settings itself on startup of a new game)
2. In terms of wider implications of the change, allowing arbitrary dictionaries to be transferred between different save games - or between different instances of the same save game ... change setting, die, setting still exists on reload ... is huge, and using it to share config settings between commanders is the least of the uses to which it cwould be put.
   
   You can think that's a good idea or not, but I hope either way you agree it's fundamental enough of a change that it shouldn't be done accidentally!

[spara]

You're right, cim. Potential problems outweight the gain, so better forget globalVars. That menu entry will be useful.

[Norby]

config screen for OXPs to F2

Then go with this, which is good to shorten the Interfaces list also. For example my HUD and MFD selector should go to the config screen instead of Interfaces. Another which is likely a config is the Ship registration imho.

[cim]

For example my HUD and MFD selector should go to the config screen instead of Interfaces. Another which is likely a config is the Ship registration imho.

I would have thought all of those were in-game actions. You could reasonably have a system on your ship which set up HUD projections or default MFDs - I'd view an F2 screen as for settings which the player character has no logical means of influencing - for example whether main stations require docking clearance (for a core setting that's there) or Spara's example of asteroid field density.

This would be a disadvantage of having two separate lists, of course, that different people would come to entirely reasonable and completely contradictory expectations of which settings should go in which list.