OXPConfig

[ovvldc]

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

[Svengali]

A way would be to use the four properties (this.logging, this.audio, this.extraA and this.extraB) as bitmask (or a completely new GUI for OXPConfig with integer settings for ship-oxps). The script could check the properties and based on it set a missionVariable. shipdata.plist contains then a conditions-declaration that allows/disallows this ship.

It would be a similiar approach as in OXPShipRegulator with its mechanism to control the strength of ships and to protect new Commanders and the inbuild missions, but there was absolutely no interest and I've discontinued this project.

And. Oolite has already populated the universe before a OXP can do something, so for the first launch after starting Oolite it wouldn't be the right mix of ships. After the first jump everything would be fine.

But as long as we don't have a direction... :-)

[Lestradae]

I would find it problematic if an external oxp "switched off" ships of a collection.

It would be not obviously clear to the average player how much was turned off if the "switching off" oxp wasn't very transparent in its functionality.

Svengali, I for one found your old OxpShipRegulator idea good, actually, and would be perfectly ready to include a new-to-be-defined line into the whole shipdata.plist of i.e. OSE that depicted the "strength" of a given ship with a number.

Then any oxp that has a mission in danger from too-powerful police/pirate/whatever ships could control that under certain conditions, in a certain system, only ships of say strength 2 or below are used etc.

That would lead to a situation where normally players have all the options of a ship-pack, but during certain missions in certain situations part of the pack are switched on standby.

Leaves open the question what about players in carriers, I assume they should still be able to get any mission everyone else can get. Otherwise it would introduce an unnescessary incompatibility.

These would be my 0.2 Cr

L

[Svengali]

It would be not obviously clear to the average player how much was turned off if the "switching off" oxp wasn't very transparent in its functionality.

Making it transparent in its functionality wouldn't be a big task - a well thought GUI could do this.

Svengali, I for one found your old OxpShipRegulator idea good, actually, and would be perfectly ready to include a new-to-be-defined line into the whole shipdata.plist of i.e. OSE that depicted the "strength" of a given ship with a number.

Yes L. You were the only oxper who has stated interest at that time, but we both knew that such a mechanism would need a wider acceptance to be working well.

Leaves open the question what about players in carriers, I assume they should still be able to get any mission everyone else can get. Otherwise it would introduce an unnescessary incompatibility.

I don't think that this is related here, because every strength regulation would only be valid for NPCs.

But I have another headache. Such a mechanism would burn a lot of ressources, leaving a lot of stuff unused. I'm still thinking that OXPConfig and (the already discontinued) OXPShipRegulator are only intermediate oxps and will be trashed in the same moment when Oolite (or a third-party-app) will come up with a solution.

[Svengali]

v1.08 is online.

It contains Thargoids Fuel Station and Lave Academy to catch the current situation.

In the next weeks I'm going for a new version - preparing it for integer values additional to the other properties, playing with some ideas,...

OXPConfig1.08.zip (11KB)

[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.