[Beta] Release of Station Options 1.0

Discussion and information relevant to creating special missions, new ships, skins etc.

Moderators: another_commander, winston

Post Reply
cag
Dangerous
Dangerous
Posts: 96
Joined: Fri Mar 17, 2017 1:49 am

[Beta] Release of Station Options 1.0

Post by cag »

This oxp allows authors of oxp's with many options to allow easy access when docked at a station. Options can be grouped into pages, ie. screens, with as many as 20/page before the list scrolls (if you keep you spiel short).

Each option has its own screen with unlimited text. Supported are 7 types with range checking and default values (both optional).

Aside from a single function call to register your oxp, everything is driven from the missiontext.plist file, so everything is in one place. Registration has optional callbacks for permission (should you wish to restrict which stations) and notification when options are changed.

Included is a template missiontext which has extensive instructions; the readme does not.

You can see it in action in the new Telescope 2.0. Fps_monitor also has a completed missiontext.plist which was used for testing
(it's not functional but I left is as an example).

(35 kB)
https://www.dropbox.com/s/zpjhpz38dxpb ... .oxz?dl=0

All images from Telescope 2.0

Here is the longest page, scolled to the bottom. Each line is a button that will open up a page for setting the option.

Image

Here is an example of the 'choice' type, where the player choose from a selection.

Image

Here is an example of the 'bitflag' type.

Image
"Better to be thought a fool, boy, than to open your trap and remove all doubt." - Grandma [over time, just "Shut your trap... fool"]
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.

User avatar
Milo
Deadly
Deadly
Posts: 224
Joined: Mon Sep 17, 2018 5:01 pm

Re: [Beta] Release of Station Options 1.0

Post by Milo »

This is really underrated, I think. Best config experience I've had so far with any OXP. I will note however that I did run into a problem (which I don't know how to reproduce) during one play session, where when I tried to type in values at the config prompt, instead of capturing the numbers I was typing, I was switched out of the config interface (for example, I was trying to enter 2 and instead it switched me to the 2 screen - pause menu). That happened a few times during that session, but some time later when I tried again (I think after restarting the game, but not sure) it accepted my inputting a 2 into the same prompt without any problems.

If it helps, I was trying to enter a 2 for the AutoLock option.

dybal
Deadly
Deadly
Posts: 154
Joined: Mon Feb 10, 2020 12:47 pm
Location: São Paulo, Brasil

Re: [Beta] Release of Station Options 1.0

Post by dybal »

Milo wrote:
Thu Jun 18, 2020 9:47 pm
This is really underrated, I think. Best config experience I've had so far with any OXP. I will note however that I did run into a problem (which I don't know how to reproduce) during one play session, where when I tried to type in values at the config prompt, instead of capturing the numbers I was typing, I was switched out of the config interface (for example, I was trying to enter 2 and instead it switched me to the 2 screen - pause menu). That happened a few times during that session, but some time later when I tried again (I think after restarting the game, but not sure) it accepted my inputting a 2 into the same prompt without any problems.

If it helps, I was trying to enter a 2 for the AutoLock option.
I've had similar experiences when moving cargo to/from Equipment Storage: I would start typing the quantity and get back to the Station F4 screen

User avatar
Milo
Deadly
Deadly
Posts: 224
Joined: Mon Sep 17, 2018 5:01 pm

Re: [Beta] Release of Station Options 1.0

Post by Milo »

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.

Because the list of primeable equipment changes, I don't want to create a static missiontext.plist and manually enter all of the primeable equipment that exists in every OXP out there, and then have to maintain that plist any time something changes. Instead, I want to generate the list of options dynamically each time the game starts, using information extracted from the OXPs themselves.

I am thinking to iterate over player.ship.equipment, find all of the items with an attached scriptName.length > 0, collect the .equipmentKey (e.g., EQ_RETRO_ROCKETS), .name (e.g., Retro Rockets) and .description (F3-purchase description of the item), and then use those to construct a dictionary of key-value pairs something like the following, to pass into Station Options somehow:

Code: Select all

  "myOXPprefix_config_options" = "(list of all primeable equipmentKeys, in single quotes, comma separated)"
        (e.g. "   'EQ_RETRO_ROCKETS',  'EQ_TELESCOPE', ... ")
and for each equipmentKey:

Code: Select all

  "myOXPprefix_"+eq.equipmentKey = "(bitflags, 8) Set conditions when " + eq.equipmentKey + " (" + eq.name + ") should be skipped over when cycling";
  "myOXPprefix_"+eq.equipmentKey+"_bitflagStrs" = "'Condition Green, weapons off-line', 'Condition Green, weapons online', 'Condition Yellow, weapons off-line', 'Condition Yellow, weapons online', 'Condition Red, weapons off-line', 'Condition Red, weapons online', 'When a target is selected', 'When no target is selected'";
  "myOXPprefix_"+eq.equipmentKey+"_long" = eq.description;  // usually the purchase description gives a reasonable idea of what the equipment does
Because Station Options uses expandMissionText, which accepts an extra locals parameter, I was thinking that could be used to provide a custom dictionary that either (1) could be passed into Station Options at the time when my OXP calls worldScripts.station_options._initStationOptions() to initialize itself, or (2) could be kept in the world script of my OXP and accessed by Station Options.

I noticed however that in some places in the Station Options code you already use expandMissionText's locals parameter with your own 'keystr' dictionary. I'm also confused by the scoping with the closures and unsure how to refer to my OXP's world script (or any "local" copy thereof) from the various sub-functions, even in the cases where you don't use 'keystr', so how to accomplish either (1) or (2) above is unclear to me. I imagine there is an elegant way to do what I want, but I don't know how.

Post Reply