[Beta] Release of Station Options 1.0

[cag]

Oh! And does this mean that your Station Options will itself need options?

Ha, no, I just crippled the function to work on all systems.

1) What are your thoughts on the matter?

I guess it comes down to language and interpretation. I agree with your in-game/out-game dichotomy and most oxp's follow it; look at how many entries are in Ship Systems. Telescope Options belongs there but I don't like the name. Telescope Settings? Telescope Configuration? Telescope Levers & Dials?

If we were starting fresh, Config for AddOns should probably go in the Game category but it's part of the game's lexicon and there's no changing it now.

2) And as regards Wiki pages do you intend the final effort to be just the one .oxp or do your prefer a basic station options .oxp
with add-ons for the various other .oxp's?

There is just the one oxp, Station Options; it's totally generic. Other oxp's can 'register' to use it.

All an oxp needs to create an F4 entry is to create/add to entries in the Config/missiontext.plist file, add a call to _initStationOptions() in their StartUp() or StartUpComplete() function and add Station Options as a required oxp in their manifest. Along with the readme is a missiontext-template.plist file in Station Options with instructions & examples for the entries they will need.

The reason I created the telescope_StationOptions.oxp was to get you a working example for an existing oxp (Telescope 2.0 is currently in many pieces scattered over my workshop). The initial intent was to have an author flesh out the Config/missiontext.plist file and Station Options would do the heavy lifting. I never thought about creating Station Options for someone else's oxp until your offer to help.

If I may suggest a plan of attack, examine telescope_StationOptions.oxp to see how it was done. There are only a handful of code lines (you can ignore both _loadSavedOptions() & playerWillSaveGame() as that's specific to Telescope) and the missiontext was mostly cut/paste from the readme. As you're new to coding, you are well suited to find the places I skip relevant details. The missiontext-template.plist can be a template for the wiki; you're job is to make it comprehensible. The more questions you ask the better!

[Cholmondely]

... a decent cup of first flush darjeeling in the station café...

<sips organic Colombian arabica - ponders the mysteries of the universe>

Why is it that tea never smells as good as it tastes, whereas coffee never tastes as good as it smells?

You need cag's Station Options - than you can opt for the coffee or tea of your choice! If you will insist in shopping at Tescoo's....

So you select the Distinguished Digebitian Tea Maker, and using cag's all-singing all-dancing addon, then decide if you want service with white gloves or mandibles, select either Chinese or Indian, choose black, white or green, select the tea of your choice, then go for sugar, sweetener or unadulterated, then milk or lemon, then jersey milk or guernsey milk, et cetera, et cetera...
Quite simple, really.

[Cody]

And to quote the great DNA: you end up with a liquid that is almost, but not quite, entirely unlike tea!

[Cholmondely]

And to quote the great DNA: you end up with a liquid that is almost, but not quite, entirely unlike tea!

So you're selecting the mandibles option, then?

[cag]

new version 1.01 with bug fixes (same link as initial post)
<link removed>
latest version:
https://www.dropbox.com/s/dzz9ayq1e0jhv ... s.oxz?dl=0
(same as 1st post)

- fixed bug with unprintable characters on MacOS
- fixed missing F4 entry on a subsequently loaded game

[Cholmondely]

Wiki page now up: http://wiki.alioth.net/index.php/Station_Options

[Cholmondely]

Buggy!

Full of Bugs!

In fact, this marvellous oxp infests my AppleMac with bugs! Oodles and Ooodles and Oooodles of them.

When I launch from the station! When I jump! When I arrive at a new station!

Everywhere is Thargoid-riddled!

I removed all my oxp's but Telescope. No problems. I added these two (Station Options & Telescope Options) and bingo! Bugs galore!

What next?

Update: Only get the infestation when start game from a saved neophyte Jameson (have tried 5 so far!). But not when starting from a more experienced Jameson (even one who did not buy Telescope) - have tried 3 so far of varying vintages. Odd.

[cag]

Wiki page now up: http://wiki.alioth.net/index.php/Station_Options

"It currently only works with Telescope."

Players will also need to download the oxp I created for you in order to use Station Options with the version of Telescope (1.15) currently in the manager:

https://www.dropbox.com/s/vusqo0pwx3ck ... .oxz?dl=0

It contains stuff specific to Telescope, namely, the missiontext.plist and a small script.js to register Telescope for use as a station option 'user' and to load/save these options.

...
Update: Only get the infestation when start game from a saved neophyte Jameson (have tried 5 so far!). But not when starting from a more experienced Jameson (even one who did not buy Telescope) - have tried 3 so far of varying vintages. Odd.

Lacking further details, I can only guess. Did you alter the TelescopeThargoids option for that Jameson? Its description reads

Code: Select all

"you will get some aliens right after undock to test Telescope"

Search the save file for TelescopeThargoids. Otherwise, send me links to download the save file & Latest.log.

[Cholmondely]

Wiki page now up: http://wiki.alioth.net/index.php/Station_Options

"It currently only works with Telescope."

Players will also need to download the oxp I created for you in order to use Station Options with the version of Telescope (1.15) currently in the manager:

https://www.dropbox.com/s/vusqo0pwx3ck ... .oxz?dl=0

It contains stuff specific to Telescope, namely, the missiontext.plist and a small script.js to register Telescope for use as a station option 'user' and to load/save these options.

...
Update: Only get the infestation when start game from a saved neophyte Jameson (have tried 5 so far!). But not when starting from a more experienced Jameson (even one who did not buy Telescope) - have tried 3 so far of varying vintages. Odd.

Lacking further details, I can only guess. Did you alter the TelescopeThargoids option for that Jameson? Its description reads

Code: Select all

"you will get some aliens right after undock to test Telescope"

Search the save file for TelescopeThargoids. Otherwise, send me links to download the save file & Latest.log.

Hah! I never even realised that the option existed!

Now that I know, I can sort myself out - and the wiki page!

But I was getting the Thargoids without having bought Telescope and getting access to Telescope Options...
And I never knowingly altered that option either.

[cag]

new version here:
https://www.dropbox.com/s/dzz9ayq1e0jhv ... s.oxz?dl=0

[I've updated the 1st post to have the same link but do not have credentials to update the wiki. Cholmondely, would you mind?]

new features:

'missionKeys' is a new parmameter added to $O_initStationOptions() (Milo)

• it is a map (key, value pair) like {'name1': value1, 'name2': value2, ... }
• these are sent along with station_options' own set to every expandMissionText() call
• enables dynamic text, especially in combination with a descriptions.plist
  • e.g. in Telescope 2.0 station_options, before getting access to the new/expiremental options,
    you have to accept a licence agreement. There are unique responses to your reply.
    Once you accept, an entire new page is added (for those options) and later on, the licence
    page will be removed. This is all done by updating a few missionKeys.
• all of the oxp's missiontext keys may be overridden (except keyPrefix & hostVarPrefix of course)
• all of station_options own set may be overridden (see its missiontext.plist)
  • e.g. change inherent button text, colors
• other functions to support this are:
  • $O_getMissionKeys()
  • $O_setMissionKeys()
  • $O_updateMissionKeys()
• this is laid out in the missiontext-template.plist file included in station_options oxp
  (it's a stand-in until the wiki page is written)
• added get/set functions for all the other $O_initStationOptions() arguments
  (allows one to alter the behavior as conditions change)

NB: function name prefix changed from '_' to '$O_' for all station_options functions
to facilitate '_execute' key (see below)


'_condition' is a new option's key in a missiontext.plist that is evaluated to determine if option is available

• can be based on other options and/or oxp vars
  • e.g. in telescope, the option 'SniperRingSize' controls its size, 0 turns it off
    while 'SniperRingColor' sets the ring's color

    Code: Select all

    telescope_SniperRingColor_condition = "SniperRingSize > 0"

  • 'SniperRingColor' will appear as a sub-option of 'SniperRingColor' and
    will not appear if SniperRingSize == 0 (turned off)
• there is NO inheritance! it's easy to implement but too restrictive (and debugging is harder)
  
  • e.g.

    Code: Select all

    telescope_SniperRingSize_condition = "$FixedTel == 0"

  • option becomes unavailable if player opts for the 'cheap' repair
    but what about 'SniperRingColor'?
  • with inheritance, it would also disappear, which may be unwanted
  • if it IS wanted, just use

    Code: Select all

    telescope_SniperRingColor_condition = "SniperRingSize > 0 && $FixedTel == 0"

    as its '_condition' statement

all option closed (i.e. off)


all option open (i.e. on)


'_assign' is a new option's key that is executed immediately after changing an option. (Milo)
While there is a callback when all option changes are committed ('Apply changes and exit' button),
this allow more flexibility

• e.g. changing an option can instantly alter results of '_condition' values
• e.g. changing an option can change which option pages are available (see Telescope 2.0's BetaLicence)
• e.g. from Telescope 2.0 BetaLicence

  Code: Select all

  "telescope_BetaLicence_assign" = "$BetaLicence = $BetaLicence ? $BetaLicence : BetaLicence; $BetaLicenceTimestamp = BetaLicence === 'Accept' ? '[stn_optns_clockString]' : ''; $BetaLicenceSystem = BetaLicence === 'Accept' ? '%H' : ''";
  

  The first only assigns worldScripts.telescope.$BetaLicence if it's null. The next 2 save the time and system (Telescope only sets the missionVariables if they're null, so it preserves the original values).

'_execute' is a new option's key that is executed immediately after '_assign'

• allow option specific callbacks
• e.g. from Telescope 2.0 BetaLicence

  Code: Select all

  "telescope_BetaLicence_execute" = "_BetaLicenceAnswered( BetaLicence );";

  calls worldScripts.telescope._BetaLicenceAnswered with the option's current value

coercion is performed during substitution. This improves readability for choice & bitstrs options,
making it easier to change/re-order (vs. just numeric indices)

• e.g. say you have a choice option, 'myView', for 'Forward', 'Aft', 'Port', 'Starboard' then you can use
  ".._condition = myView == 'Aft'" instead of ".._condition = myView == 1"
• works for '_condition', '_assign' & '_execute'

tweaks
------

• choice can now be list of numbers (before had to use string: {'0', '1',..}, now {0, 1,...})
  NB: if a default is specified as a number, it is ASSUMED to be an index!
• hostVarPrefix can be > 1 char

[Cholmondely]

[I've updated the 1st post to have the same link but do not have credentials to update the wiki. Cholmondely, would you mind?]

With the greatest of pleasure! It's the one thing that I can do...

Link updated!

... and there is a PM awaiting your perusal ...

[cag]

Updated with a few bug fixes, one a memory corruption bug! (thanks arquebus)

https://www.dropbox.com/s/dzz9ayq1e0jhv ... s.oxz?dl=0
(same link as 1st post)

[cag]

cag, would you be willing to add support for OXPs to provide dynamically-generated options at runtime, or give me pointers on how to do it?

I want to generate options for each primeable equipment that the player has.

I've added a missionKey paramater when you registers which will allow you to pass through your keys and getter/setter/update functions which will allow you alter them whenever you like. I've also added some extra key types that may be helpful ('_assign', '_execute'). All the gory detail are in the wiki:  Adopting Station Options (script functions are the last section)

The latest version of Telescope 2.0 has a demonstration, a 'licence agreement' page that, once the player signs away his soul, loads the 'experimental' options page. The licence page gets remove a short time later.

[Cholmondely]

And what is the current status of Station Options vis-a-vis Telescope Options?

I do feel that Telescope is really the only .oxp that needs this. And the only .oxp for which it can be done in an immersive manner, as you demonstrated. The other oxp options handled by Telescope are really not the sort of thing which a pilot would expect to control in-game (how many Academies there are, or how many asteroids there are, or how the customs find contraband... I think that Phkb's option for an amber GUI for his XenonUI is probably the only real pilot-controlled choice I would expect to find in-game.

At some stage, heavens willing, we will have some other complex oxp's which will deserve your tender treatment...

As it stands, Station Options does all I need for Telescope and then some. I threw in the licence agreement page to test dynamic page loading (yah, I know, you didn't notice; few would. But the 'experimental' options page does not load until you accept and later, the licence page gets removed.)

Any oxp with a handful of options could use it, esp. those with expansive readme files which require the player to read the wiki or crack open the oxz. Having the info available at the station is more immersive. Station Options is driven entirely from the missiontext.plist file, so there's minimal coding involved.


I always had in mind that it could also function as a mission builder. Especially useful is the 'choice' option type, where in a given situation, the player could be presented with options/questions and the mission would proceed base on his input. If missions were structured like a tree (not linear), then they could be replayed yielding different results.


Milo had an idea for an oxp to help with the primeable equipment issue and I've implemented some 'advanced' keys in addition to the dynamic options he wanted.
(see  Adopting Station Options)

cag, would you be willing to add support for OXPs to provide dynamically-generated options at runtime, or give me pointers on how to do it?

I want to generate options for each primeable equipment that the player has.

...

Wondering about Station Options and Weapon Laws.

In the current version of Oolite, Weapon Laws causes better lasers to be confiscated when they are tampered with in better political systems.

(ie using Combat Simulator OXP - lasers are confiscated if the system prohibits their sale
Laser Arrangement - lasers are confiscated if the system prohibits their sale
Ship Storage Helper - ditto
Hyperspace Hangar - ditto)

So: theoretically speaking, would it be possible to use Station Options to buy a license to rearrange my lasers, or use them in the combat simulator, etc (and disable Weapon Laws at the same time...). This would be a superb solution to the problem, which also enhances immersion...

Would it involve tampering with Weapon Laws?

[Redspear]

Would it involve tampering with Weapon Laws?

OK, so here's the issue as I see it.

Weapon laws is supposed to prevent the sale of certain equipment in certain systems.
Weapon laws is not supposed to prevent the moving, awarding or swapping of pre-owned or non-GalCop/Station market weapons.

Unfortunately, it seems to be doing both.

The solution relates to the cause, namely the use of the condition script allowAwardEquipment being a blanket restriction.
The good news is that I can add context such as purchase or new ship limiting when the restictions are in place.

So this.allowAwardEquipment = function(purchase) might do it.
I'll give it a try and if all goes well provide an update soon.

Thanks for raising the issue.