OXP Variables

[Thargoid]

This method you have come up with supports enumerated list of options. How could we support numeric values that can be within a fixed range? (I am sure OXP developers would want that.

I would wonder slightly about that. Currently OXPConfig is not so commonly used at all (with due respect to Svengali, although he admits it himself above) - only really three OXP writers have used it, him, me and Eric. For me it's not so clear cut as to whether the wider support would actually make things any more desirable to use. I must admit that for my OXPs I don't see much more I could do with numeric values than I can with the existing four binary flags.

And OXPConfig should already be able to allow ships to be switched on and off via a missionVariable dependent condition setting in shipdata.plist. I must admit I've not tried doing that specifically so I can't confirm if such conditions actually work as expected, but in theory there should be no reason why they wouldn't. But I would be a little careful of taking OSE/RS as too much of an example, as it's quite a specialised and one-off (ok, two-off) case of a meta-OXP. And again care will need to be taken with player ships, as things will go wrong if suddenly the ship you're flying is suppressed. And given in some cases the player ship is a like_ship variant of the NPC one, there is some risk if due care with the conditions isn't taken.

Sorry if I'm sounding quite negative to all this, but I see the risk of a lot of time being spent on something that might not actually be that useful to people beyond what already exists in the already underused OXPConfig.

[PhantorGorth]

I must admit that for my OXPs I don't see much more I could do with numeric values than I can with the existing four binary flags.

Well the example I have in mind is "spawn_number" or "spawn_limit", etc for a OXP that spawns special ships on entry to specific criteria system. For such a requirement a boolean wouldn't cut it.

But I would be a little careful of taking OSE/RS as too much of an example, as it's quite a specialised and one-off (ok, two-off) case of a meta-OXP.

Agreed.

And again care will need to be taken with player ships, as things will go wrong if suddenly the ship you're flying is suppressed. And given in some cases the player ship is a like_ship variant of the NPC one, there is some risk if due care with the conditions isn't taken.

Yes. This I can see would be a concern but not outside the normal development risk zone. But the idea of using any setting for ship removal was just an example that got me thinking not the whole idea. There would be many other things that settings could modify.

Sorry if I'm sounding quite negative to all this, but I see the risk of a lot of time being spent on something that might not actually be that useful to people beyond what already exists in the already underused OXPConfig.

Well I am not twisting anyone's arm to do this. If people feel this is an unnecessary or think that developers should spend their Oolite programing time on something more important I am not going to argue.

Phantor Gorth

[Lestradae]

... allow ships to be switched on and off via a missionVariable dependent condition setting in shipdata.plist. I must admit I've not tried doing that specifically so I can't confirm if such conditions actually work as expected, but in theory there should be no reason why they wouldn't.

This works as intended. I already used it back in RS to ensure that only after completion of the Constrictor mission, NPC (and player) Constrictors start appearing out there. It was Eric's idea to do this with a condition in the shipdata.plist, actually.

To supress player ships for anything makes no sense imo (I mean, prevent them from doing something. It might make perfect sense to keep them from being buyable under certain circumstances, as in the above Constrictor example). That would just introduce incompatibilities that are not nescessary for having fun with the game ...

Cheers

L

[Kaks]

This method you have come up with supports enumerated list of options. How could we support numeric values that can be within a fixed range? (I am sure OXP developers would want that.)

I haven't thought of that yet! To be fair, there's nowhere in Oolite that allows you to enter any numbers...

How would your method allow re-use of the same setting between two scripts in the same OXP without the need to have the user configure two settings?

Any secondary script can access the main oxp script settings! So if we want to know which value myPlanetNum is set at, all we need to do is query

worldScripts.KaksTextOXP.myPlanetNum

Incidentally, any oxp can query any other oxp. So if you have a new oxp that wants to play nice with KaksTestOXP, or needs to change the way it works depending on how many myPlanets there are, all that new oxp needs to do is something like the following:

Code: Select all

    ...
this.myOtherPlanetNum = 1;
if (worldScripts.KaksTextOXP && worldScripts.KaksTextOXP.myPlanetNum)
          this.myOtherPlanetNum = worldScripts.KaksTextOXP.myPlanetNum;
    ...

All you need to do is have that variable defined within the this. hierarchy. You can also call other oxps functions: worldScripts.KaksTextOXP.shipWillExitWitchSpace() will call the exit witchspace event inside KaksTextOXP, if that event was defined. It's always a good idea to test if a variable / event / function we want to use actually exists before using it, though!
Before I forget, in javascript worldScripts.KaksTextOXP and worldScripts['KaksTextOXP'] are two different ways to refer to the same object, the first is easier to read, but the second allows more flexibility...

And finally, when a version change is detected, (of course via worldScripts.KaksTextOXP.version) I'd expect a this still hypothetical new OXPConfig to show 'New version of ThatOXP detected. Settings might need change' and leave it at that. If the number of settings options change from before - like we add a new myNumberOfNebulas option to the mix, I'd go to that oxp settings screen immediately, with maybe an extra line at the top saying - new options detected - or something along those lines.

Anyway, I've got to go! Busy day at the office, as they say!

[Thargoid]

Incidentally, any oxp can query any other oxp. So if you have a new oxp that wants to play nice with KaksTestOXP, or needs to change the way it works depending on how many myPlanets there are, all that new oxp needs to do is something like the following:

Code: Select all

    ...
this.myOtherPlanetNum = 1;
if (worldScripts.KaksTextOXP && worldScripts.KaksTextOXP.myPlanetNum)
          this.myOtherPlanetNum = worldScripts.KaksTextOXP.myPlanetNum;
    ...

All you need to do is have that variable defined within the this. hierarchy. Before I forget, in javascript worldScripts.KaksTextOXP and worldScripts['KaksTextOXP'] are two different ways to refer to the same object, the first is easier to read, but the second allows more flexibility...

If you want to see full OXP examples of that, some of mine do it (look in Lave Academy, Ring Racer and Repair Bots for example, and probably more). LA and RingRacer check for Welcome Mat and if it's present turns it temporarily off (to save unwanted messages as some of the objects defined are buoys which would talk if WM is installed), and Repair Bots checks which version of Rock Hermit Detector is installed (if any) so it can "reboot" it correctly if it has to repair the equipment.

Also for your two ways of accessing the worldScripts above, the second one is the better. The first one doesn't work if the script name has a space in it (which is possible and allowable, if perhaps not good scripting practice) at which point you must use the second method. The quotes therein get around the space breaking the expression problem.

[Thargoid]

To supress player ships for anything makes no sense imo (I mean, prevent them from doing something. It might make perfect sense to keep them from being buyable under certain circumstances, as in the above Constrictor example). That would just introduce incompatibilities that are not nescessary for having fun with the game ...

Some people have stated they don't want certain ship-genre in the game (e.g. Star Wars or Star Trek ships), and via OSE if there are player-ships that are in that genre (either directly or via like_ship) then they would best be suppressed too. But of course if for whatever reason they then tried to load a save-game using one of said suppressed ships...

It's probably an unlikely example, but equivalent things could happen with equipment or NPC ships required for certain OXP roles/missions, where it gets more complicated.

[Svengali]

I must admit that for my OXPs I don't see much more I could do with numeric values than I can with the existing four binary flags.

Second that. For most oxps it will be enough options, but I can imagine cases were numeric values would be very useful. That's why I already thought about an additional handling for special oxps. This wouldn't change the current handling in and for already supported oxps.

And now I'll try to explain myself a bit more: I don't think there's anything wrong with the way OXPConfig does things, but it looks to me that PG was asking for something with a bit more flexibility, and if I ever get enough time I might just be able to do so.

Yupp. You're right. Flexible is another thing. I've had four reasons to choose 4 fixed boolean properties. a.) my limited skills b.) it's a lot easier to handle (for OXPConfig) with only 4 fixed properties c.) it needs only 4 Bits to store them, so 1 string (like oxpConfig_settings = "|235990628|50286";) represents all included oxps d.) the screens have only limited space to display things, so a option like I_REALLY_DONT_WANT_ALL_THESE_DAMNED_STARWARS_SHIPS takes too much space and will possibly cripple the screen.

But, hey. If you'd take this oxp to a new stage I'd be very happy (and I can learn some more things) :-)

Well, this morning I blithely assumed most configurable oxps would check their configurable stuff only inside a shipWillLaunchFromStation event, and that OXPConfig would have had the time to update the internal script variables.

That's why OXPConfig has another approach. In v1.72+v1.73 reset() is the first handler with access to stored settings in savedgames. For v1.74 things have changed (no reset() anymore, a new instance of the script is created), so a new handling has to be done. And the current version has some relics from older versions were I've stored the settings in another format. It's time to get rid of them.

A way to do so is to add a pseudo event inside the main script oxp, to handle the changed variables. It could look something like this: this.configOptionsChanged();

Hehe, it seems we're thinking about the same things. I've thought about a notification when a oxp is changed

Code: Select all

try { worldScripts[this.currentOxp[0]].oxpcNotifyOnChange(); }
catch(e) { if(typeof(e) != 'object') worldScripts[this.currentOxp[0]].oxpcNotifyOnChange(); }

while this.currentOxp[0] contains the changed scriptname.

I personally think that the opt-in idea behind OXPConfig is a pretty sensible one. There might not be too many OXPs compatible with it, but we've got more than this time last year!

Don't get me wrong. I'm not complaining about it. It was just a hint that the whole approach to give players some more options is possibly not necessary for most oxps. A ship-oxp (e.g. Executive Spaceways) won't need it, it only makes sense for oxps with more than one feature (e.g. Thargoids WelcomeMat or my Vector).

This method you have come up with supports enumerated list of options. How could we support numeric values that can be within a fixed range? (I am sure OXP developers would want that.)

This would mean to add some more optional options (like stepping and range) and a lot more work on the GUI handling.

BTW: I'm not sure that adding a version handling is such a good idea. It will blow up the whole thing, but maybe you have already an idea to avoid it? OXPConfig (or whatever it will be called then) was meant to be a small tool with some basic options, easy to handle/understand for the end-user (not for the scripters). Adding too much stuff will need a lot more screens and it will be complicated to step through all levels then.

One way to avoid unnecessary screens would be to use the cursorcoords and declaring clickable fields, but unfortunately we don't have these options yet (the coords are only valid for the star charts). I think Ahruman has already thought about it (as always :-)) and maybe someday we'll get this option???

As I've said above - if we'll get a new quality for a configuration tool it would be a dream :-)

[Svengali]

Oh, and to complete this.

The choices (in missiontext.plist) are fixed and not changeable via script and have to be named then in a more common way (like increase, decrease, but not WelcomeMat, Hyperradio,... anymore) and any settings for ship-oxps are not taken directly after starting Oolite, because the populator has already done the setup before any oxp can do something. This would mean to add a mechanism to remove entities like in OXPShipRegulator to get around it. )-:

Edit: @PhantorGorth: It is already possible to make ship-oxps configurable. Take a look in OXPShipRegulator. There I've implemented an example - used to show a strength-regulation, but the mechanism is the same. And the current 4 properties in OXPConfig can be used to get 16 different values if they are treated as bitmask.
The oxps are already responsible what they are doing with these settings, so it doesn't make a difference if the processing is done in OXPConfig or the particular oxps. I understand that you want a more flexible way and yes, you're right - limitTheSpawnedShips is more clear than extraA, but I also think that we need then a lot more code, maybe even a error handling for invalid options/settings.

So I'm currently a bit unsure what to do.

Oh, and if a ship-oxp needs such a mechanism - nothing hinders the oxper to implement something - completely independent from any tool. So if you think that OSE should do something your first adress is Lestradae. OXPConfig would only be a GUI, so any processing of settings would (in all cases) have to be done in OSE.

[PhantorGorth]

d.) the screens have only limited space to display things, so a option like I_REALLY_DONT_WANT_ALL_THESE_DAMNED_STARWARS_SHIPS takes too much space and will possibly cripple the screen.

I am aware that the GUI has it limitations so that would be a factor. I have ideas on the GUI which I am personally willing to tackle myself as I have trawled through the GUI code and seen that is a mess. Adequate mess but a mess all the same. Also it has very limited features. I will leave that topic for another thread.

This method you have come up with supports enumerated list of options. How could we support numeric values that can be within a fixed range? (I am sure OXP developers would want that.)

This would mean to add some more optional options (like stepping and range) and a lot more work on the GUI handling.

Range I understand and agree that would be needed. By stepping do you mean whether the setting is integer to some other level of accuracy as stepping to me implies things such as every even number or every third number etc.? Wouldn't see much use for stepping if the later is what you mean by that term.

I am of a similar opinion on version handling. This is why I suggested that setting values in a save game file that aren't used by the current version of the OXP (or if the OXP no longer exists) would be ignored and new ones would get the default value. When the game is saved next time the redundant ones would not be recorded and the new ones would be. It would be the responsibility of the OXP developer to manage backward compatibility. Maybe there should be a way to remap the old ones if required but that seems to be going too far in my opinion.

One way to avoid unnecessary screens would be to use the cursorcoords and declaring clickable fields, but unfortunately we don't have these options yet (the coords are only valid for the star charts). I think Ahruman has already thought about it (as always ) and maybe someday we'll get this option???

That's more stuff to think about for a GUI system re-vamp.

The choices (in missiontext.plist) are fixed and not changeable via script and have to be named then in a more common way (like increase, decrease, but not WelcomeMat, Hyperradio,... anymore) and any settings for ship-oxps are not taken directly after starting Oolite, because the populator has already done the setup before any oxp can do something. This would mean to add a mechanism to remove entities like in OXPShipRegulator to get around it. )-:

I think I get what you mean in that the system populator adds ships to the system when you first enter the system or leave a station before the code in any OXP is called so you have to go through and delete the unwanted ships from the system that have already been created. That is an issue. I have to say that my original suggestion was brought to my attention by the OSE/RS unwanted ships issue but wasn't the only reason for me to suggest it. I do what I always do which is see any issue and see if there is a solution that is general enough to be more useful that just solving the original solution. It has become very obvious that I really should have played with OXPConfig first before starting this thread.

Edit: @PhantorGorth: It is already possible to make ship-oxps configurable. Take a look in OXPShipRegulator. There I've implemented an example - used to show a strength-regulation, but the mechanism is the same. And the current 4 properties in OXPConfig can be used to get 16 different values if they are treated as bitmask.
The oxps are already responsible what they are doing with these settings, so it doesn't make a difference if the processing is done in OXPConfig or the particular oxps. I understand that you want a more flexible way and yes, you're right - limitTheSpawnedShips is more clear than extraA, but I also think that we need then a lot more code, maybe even a error handling for invalid options/settings.

So I'm currently a bit unsure what to do.

Oh, and if a ship-oxp needs such a mechanism - nothing hinders the oxper to implement something - completely independent from any tool. So if you think that OSE should do something your first address is Lestradae. OXPConfig would only be a GUI, so any processing of settings would (in all cases) have to be done in OSE.

Well it seems to be a case that my suggestion has some merits but as you say it is either covered by the existing OXPConfig or could be done internally by the OXP itself. So all I can say is that this suggestion be considered low priority and if someone feels there is need for it in an OXP they are writing or there is a re-vamp of the GUI then it could be revisited.

Phantor Gorth

[another_commander]

I have trawled through the GUI code and seen that is a mess. Adequate mess but a mess all the same.

This has to be the understatement of the centrury.

[Commander McLane]

Sorry if I'm interfering, and I don't want to say anything negative about the whole idea, but I am asking myself whether it is really worth the while.

As far as my own OXPs are concerned I cannot think of a single thing that should be switchable by the player. For instance, either you want qbombs to behave like in Status Quo, or you don't. You achieve that by either installing or de-installing the OXP. Same for total_patrol.oxp. And for the others. Cataclysm is a mission, why would you want to let's say disable a certain station, if it also will make the mission impossible to finish. Anarchies does some more things, but I still don't see why you would want to disable one of them (okay, I admit, I have thought about splitting the legal-status handling and the flavour station into two different OXPs, so that you could get Hacker Outposts, but stay with the vanilla fast decay of your bounty. The Hackers won't offer a Multipass either, in that case. But then what would they be all about? So in the end the two aspects seemed to be too closely related to each other.).

And as far as other folks' OXPs are concerned, I came up with two things which could/should be switchable: Certain ship groups in RS/OSE, and the number of additional moons and planets which are created by System_Redux. In both cases you can sensibly change something which cannot be achieved by simply installing/de-installing the OXP. (And both OXPs come with a guide on how to do it already.)

Thus, is it worth the effort to produce a big options.oxp or something of the like? Just asking.

[PhantorGorth]

@Commander McLane:

Well as you can see that pretty much most people's view and I am starting to see that myself. My idea has merit for very large/meta OXPs but there aren't that many and 4 boolean options is fine for those at the moment. It may be be adequate in the future but we can worry about that then.

Phantor Gorth

[Kaks]

This has to be the understatement of the centrury.

Guys, you wouldn't believe the cruft I had to sift through to just get the equipment purchase screen to work semi-reasonably in trunk!

And I'm still not done! I found 2 more - minor - glitches this morning, I wonder what I'll find when I sort those two out!

It's now personal! After the MNSR that GUI goes!:P

[Svengali]

@PhantorGorth: First of all - thank you for spending time and thoughts about it. It's not that bad to think about ways to handle these things, even if we don't have such a big need currently. But we'll get more and more oxps with multiple features, so it would be cool to have a solution ready before a problem starts to be annoying. Muchas gracias.

@Kaks: R'n'R! A shiny new one?

[PhantorGorth]

This has to be the understatement of the centrury.

Guys, you wouldn't believe the cruft I had to sift through to just get the equipment purchase screen to work semi-reasonably in trunk!

And I'm still not done! I found 2 more - minor - glitches this morning, I wonder what I'll find when I sort those two out!

It's now personal! After the MNSR that GUI goes!:P

I can which is why I am about to start another thread in the discussions area on GUI issues and what is needed to be done.