OXPConfig

[Svengali]

Note for oxp-developers:

The new OXPConfig version is nearly done and it is time to build the database for supported oxps. Only if included in this database loading and storing will be enabled for this oxp. The pics on the first page are pretty outdated, but will give you a first impression how it looks.

OXPConfig2 will support:
- 4 booleans.
- 4 short unsigned integers (0xff).
- 1 unsigned 24Bit integer (0xffffff) that is used as bitmask e.g. to en/disable appearance of entities.
- Minimum version checks.
- Early calls of oxps startUp function if flag is set.
- Early settings if OXPConfig has collected the data and flag is set.
- Notification for oxps about changed settings if flag is set. Calls oxpcNotifyOnChange().
- Uses a library that PhantorGorth, Cmd.Cheyd and myself are currently testing (lib is requirement then).

If any of your worldScripts should be included in the database I'll need some infos:
- name of worldScript
- display name for OXPConfig2, can be different from the scriptname.

The script will get an ID (stored in OXPConfig) that is internally used then. OXPConfig will look for a specific object (oxpcSettings) and collects the data. If LeaveData flag is not set, OXPConfig deletes the object (oxpcSettings).

Code: Select all

  this.oxpcSettings = {
    Info: {
      Name: "myOXP",
      // required (string), name of the worldScript, can also be simply this.name
      Display: "myOXP",
      // optional (string), if not specified defaults to Name
      MinVersion: "1.0",
      // optional (string), if not specified defaults to "0.0"
      EarlyCall: true,
      // optional (boolean), if not specified defaults to false
      EarlySet: true,
      // optional (boolean), if not specified defaults to false
      Notify: true,
      // optional (boolean), if not specified defaults to false
      LeaveData: true,
      // optional (boolean), if not true OXPConfig deletes oxpcSettings after gathering the infos
      InfoB: "Additional infos for the booleans",
      // optional (string)
      InfoS: "Additional infos for the short unsigned integers",
      // optional (string)
      InfoE: "Additional infos for the unsigned integer."
      // optional (string)
    },
    // Propertyname, e.g. this.logging use "logging" (string), the default value (boolean) and short description (string)
    Bool0: {Name: "propertyname1", Def: false, Desc: "Short description for boolean0"},
    Bool1: {Name: "propertyname2", Def:true, Desc:"Short description for boolean1"},
    Bool2: {Name: "propertyname3", Def:true, Desc:"Short description for boolean2"},
    Bool3: {Name: "proeprtyname4", Def:true, Desc:"Short description for boolean3"},
    // Propertyname, e.g. this.additionalPlanets use "additionalPlanets" (string)
    // the default value (unsigned short integer 0x0-0xff or 0-255)
    // the maximum value (unsigned short integer 0x1-0xff or 1-255)
    // short description (string)
    SInt0: {Name: "propertyname5", Def: 0x2, Max: 0xf, Desc: "Short description for shortint0"},
    SInt1: {Name: "propertyname6", Def: 0xaf, Max: 0xbf, Desc: "Short description for shortint1"},
    SInt2: {Name: "propertyname7", Def: 0xfe, Max: 0xff, Desc: "Short description for shortint2"},
    SInt3: {Name: "propertyname8", Def: 0x10, Max: 0x13, Desc: "Short description for shortint3"},
    // Propertyname, e.g. this.myEntities use "myEntities", default value (unsigned integer 0x0-0xffffff)
    // maximum value (unsigned integer 0x1-0xffffff) and description for every bit (array with strings)
    EInt0: {Name:"propertyname9",Def:0xfff,Max:0xffffff,
      Desc:["desc01","desc02","desc03","desc04","desc05","desc06","desc07","desc08","desc09","desc10","desc11","desc12",
        "desc13","desc14","desc15","desc16","desc17","desc18","desc19","desc20","desc21","desc22","desc23","desc24"]
  };

Short example with 1 boolean property without further schnickschnack:

Code: Select all

  this.oxpcSettings = {
    Info: {Name: this.name},
    Bool0: {Name:"myBooleanProperty", Def:true, Desc:"Do funny things."}
  };

Edit: Changed to reflect the current version.

[Svengali]

You know, christmas, so OXPConfig2 is online.

As posted above it goes a different way, but is much more flexible now. But this means that supported OXPs that were included before won't work with it until they are updated. Internally it has nothing to do anymore with the 1.x versions.

The general handling for players is quite similiar to the older versions, but some things have changed.
- Loading default settings will reset any stored settings and removes the missionVariable for OXPConfigs own settings.
- OXPconfig2 deletes the not used missionVariables from older versions.
- Runs now in 2 cycles to split up the work. One time for early calls and settings and the second one on guiScreenChanged, alertConditionChanged or Timer.

Requirements:
- Oolite v1.74.2
- Cabal_Common_Library

A quick guide for OXP-Developers is available too.

WIKI page - OXPConfig

[Switeck]

Can you recommend a standard style OXP station spawn script to be compatible with OXPConfig2?

1.Like disable/enable default spawn rates/odds.
2.Or set to ALWAYS spawn in every system.
3.Or never spawn, though that's mostly covered in #1.

Hopefully this would also be a good first step to removing OXP stations if they get destroyed, so they don't just reappear on revisiting the system.

[Svengali]

Can you recommend a standard style OXP station spawn script to be compatible with OXPConfig2?

1.Like disable/enable default spawn rates/odds.
2.Or set to ALWAYS spawn in every system.
3.Or never spawn, though that's mostly covered in #1.

He, doesn't sound like 'standard' to spawn a entity in every system and I don't think that there is a 'generic way', because some entities may need special handling and there are so many different ways to do it. But a simple user configurable way to decide if a secondary station with custom role should be spawned on shipWillLaunchFromStation or
shipWillExitWitchspace could look like

Code: Select all

this.name = "TheStationControlScript";
this.author = "Me";
this.copyright = "Public Domain";
this.description = "User configurable station spawn script for 4 secondary stations with custom roles";
this.version = "1.0";

this.startUp = function()
{
  // Delete startUp as per PhantorGorth approach
  delete this.startUp;
  // Declare bitmask - 0xf is decimal 15 (1+2+4+8) like for the weapon_facings
  // In case of loading-order problems, use the EarlyCall flag
  this.myStationBitmask = 0xf;
}

// Settings for OXPConfig
this.oxpcSettings = {
  Info: {Name:this.name,InfoE:"Set entities to 1 to allow spawning or 0 (zero) to disallow."},
  EInt0: {Name:"myStationBitmask",Def:0xf,Max:0xf,Desc:["Station A","Station B","Station C","Station D"]}
};

// Replace the log part with your code to check for interstellar space, existance, government, etc. and place the entity
this.shipWillLaunchFromStation = this.shipWillExitWitchspace = function()
{
  if(!this.myStationBitmask) return;
  if((this.myStationBitmask&1)) log("StationA allowed");
  if((this.myStationBitmask&2)) log("StationB allowed");
  if((this.myStationBitmask&4)) log("StationC allowed");
  if((this.myStationBitmask&8)) log("StationD allowed");
}

When testing you'll need to enable displayAll in OXPConfig.

And if you want to have a adjustable chance for a specific station use the short integers, a switch for spawning a specific station always could be done via boolean or use more than one entry (e.g. "Station A","A Always",...).

Oh, and for entities with standard roles the situation is different, because the populator will add them too. Then you'll have to use the bitmask and a (or more) missionVariable + condition in shipdata.

Hopefully this would also be a good first step to removing OXP stations if they get destroyed, so they don't just reappear on revisiting the system.

Sounds like a good plan, but is not OXPConfigs part. But you are right it would make sense if a script would check (and store these things).

Edit: Changed to reflect current version.

[Switeck]

Seems like this is a consolidation of 4 different stations, which probably all have wildly differing and separate spawn conditions.
That'd require merging of data from different OXPs I gather...
(Incidentally, I haven't made a station of my own. My mod OXP contains no new stations or ships.)

[Svengali]

Seems like this is a consolidation of 4 different stations, which probably all have wildly differing and separate spawn conditions.
That'd require merging of data from different OXPs I gather...

Yes, absoluely right. OXPConfig itself is only the interface between script and player and does nothing with entities.

For your station spawn script it could be helpful to know under what kind of conditions every station should be spawned. Maybe you could make a list and post it in your topic. This way we could see what (and when) a condition has to be checked. And implementing the settings for OXPConfig can be done when the script is done. It's only a few additional lines.

[Svengali]

v2.0.1 is online.

Changes:
Fix for undefined settings if player stores directly after activation.

So if you are using it - it's update time. And if you stumle about a problem it would be really nice if we can sort it before christmas.

[Svengali]

v2.0.2 is online.

Changes:
- Adapted changes in Cabal_Common_Library

[Lone_Wolf]

I'm thinking of using OxpConfig to make several settings userchangeable in the Shield Cycler oxp i'm working on.

The documentation suggests my oxp doesn't have to be known to use OxpConfig, but it's unclear to me how to do that.

This is what i think my oxp needs to do :

- set DisplayAll property
- declare vars to hold the values i want OxpConfig to change

- call oxpcLookup function, declare OxpCSettings

- If user changes a value in the gui, OxpConfig changes the var in my script ?

Now DisplayAll , OxpcLookup , oxpcSettings are all in the OxPConfig,js script , not in mine.
How do i use them ?

Added

Another question :
Some configurable settings will become available later, can OxpcSettings be used multiple times ?

[Svengali]

I'm thinking of using OxpConfig to make several settings userchangeable in the Shield Cycler oxp i'm working on.

The documentation suggests my oxp doesn't have to be known to use OxpConfig, but it's unclear to me how to do that.

For testing things enable displayAll in OXPConfig. This switch changes the behaviour to collect all OXPs with settings. If all is well give me a call and your OXP will get a ID (stored in OXPConfig for the next version). I simply didn't wanted to frickle around with hash-codes, so this is the procedure .-) Maybe I should think about such a mechanism...

All your OXP needs is the oxpcSettings object.

Some configurable settings will become available later, can OxpcSettings be used multiple times ?

For the same worldScript with the same ID? No - i don't think so (at least it was never intended this way).

Edit: Changed to reflect current version.

[Lone_Wolf]

Some configurable settings will become available later, can OxpcSettings be used multiple times ?

For the same worldScript with the same ID? No - i don't think so (at least it was never intended this way).

My oxp will have an upgrade path with 5 devices, and after upgrades more configurable options become available.

I can think of 2 options to achieve this :
A. add a separate bitmask with 9 bits ( the 4 booleans + 4 short integers + the 24-bit bitmask) where each bit determines if that value is shown/configurable by user.
create a function to set the bitmask.

B.
create a destroy method for oxpCsettings

Both ways have advantages / disadvantages, but option B (destroy method) seems the most logical choice to me.

[Svengali]

B.
create a destroy method for oxpCsettings

Both ways have advantages / disadvantages, but option B (destroy method) seems the most logical choice to me.

Yes, should be possible .-)

I think I'll go for a simple way, rebuilding the searchtree. Set the LeaveData flag and pass the object to the function then.
Will do some tests and give you a call.

[Svengali]

OXPConfig2.0.3 is online.

Changes:
- Added Lone_Wolfs Shield Cycler.
- Raised overall length to max 31 em on screens.
- Added .Hide property and searchtree rebuild.

Special thanks to Lone_Wolf.

[Svengali]

OXPConfig2.0.4 is online.

Changes:
- Added Famous Planets (v2.5.1)
- Added System Redux (1.2.1)

[Svengali]

OXPConfig2.0.5 is online.

Changes:
- Added Capt.Murphy's Explorers Club
- Added Disclaimer
- Requires: Cabal_Common_Library1.5
- Screen titles use now OXP .Display property
- StartUp behaviour in v1.76 adapted
- Timer behaviour changed