Re: OXPConfig
Posted: Wed Nov 26, 2014 12:34 pm
I think it should.Lone_Wolf wrote:I see OxpConfig as a library/framework that allows PLAYERS to configure oxp options.
Oolite core code doesn't offer this functionality.
I think it should.Lone_Wolf wrote:I see OxpConfig as a library/framework that allows PLAYERS to configure oxp options.
Oolite core code doesn't offer this functionality.
OXPConfig was up to v1.77.1 a pretty fast OXP (see this post). I guess this is something that needs to be investigated.Lone_Wolf wrote:Basically, OxpConfig tries to make things as easy as possible for oxps, but this comes with a rather steep price (complex code, slow performance) for OxPConfig itself.
Ah, ok .-)Lone_Wolf wrote:that message is displayed by this.doOxpCTimer , and that's what gives the impression of slowness.
guiScreenChanged
not being fired for the game options screen in older Oolite versions. You could remove it and trigger instead via guiScreenChanged
.Doing it via literal will be faster - instantiating walks along the prototype chain. And the template would need to be adjusted by OXPs anyway.Lone_Wolf wrote:Oxps would then create a new instance of that template and pass that to OxpConfig on initialisation.
Yep, sounds good. It would even open the option to handle more settings.Lone_Wolf wrote:loading / storing the settings would then be a job for the oxp, not for OxpConfig.
looking into thatSvengali wrote:Ah, ok .-)Lone_Wolf wrote:that message is displayed by this.doOxpCTimer , and that's what gives the impression of slowness.
The trigger via timer stems fromguiScreenChanged
not being fired for the game options screen in older Oolite versions. You could remove it and trigger instead viaguiScreenChanged
.
understood, initialization will look something like this then :Svengali wrote:Doing it via literal will be faster - instantiating walks along the prototype chain. And the template would need to be adjusted by OXPs anyway.Lone_Wolf wrote:Oxps would then create a new instance of that template and pass that to OxpConfig on initialisation.
Glad you like it.Svengali wrote:Yep, sounds good. It would even open the option to handle more settings.Lone_Wolf wrote:loading / storing the settings would then be a job for the oxp, not for OxpConfig.
Most of the complexity has to do with loading/storing functionality. The consequence was that OXPConfig had to care for loading- and script execution- order, order of fired handlers, possible changes in OXPs, Oolites timelimiter, etc. Ok, sometimes it was the attempt to see how much complexity I can handle. But with a little bit distance now I really don't think that you need to explore the code beyond the point of screen functionality for the new approach.Lone_Wolf wrote:Although i do understand OxpConfig high-level functionality many of the implementation details are still beyond me.
Sounds good. I guessLone_Wolf wrote:worldScripts["OxpConfig"].activate_oxp(this.name,this.my_object_for_opxc_settings,this.my_oxpc_notify_handler)
.activate_oxp()
is a simple registering method which pushes into an array?The internal list of supported OXPs was only necessary to avoid startUp chains and I doubt that you'd still need it .-) The currently supported OXPs should degrade nicely to their default functionality, none registers. It shouldn't be necessary to keep v2.x alive and the required changes for OXPs would be - based on your approach above - minimal.Lone_Wolf wrote:Since the new interaction method is incompatible with the current method, it will become version 3.
I will look into adding version numbers to the list of supported oxps to help with the transition and making it possible for players to have both OxpConfig v2 & v3 installed at the same time.
Bring it to the next stage then! :-)Lone_Wolf wrote:Using this method does feel like a 'natural' evolution of OxpConfig,<snip>
OxpConfig version 2.x is now officially put in "Maintenance Mode" .Svengali wrote:The internal list of supported OXPs was only necessary to avoid startUp chains and I doubt that you'd still need it .-) The currently supported OXPs should degrade nicely to their default functionality, none registers. It shouldn't be necessary to keep v2.x alive and the required changes for OXPs would be - based on your approach above - minimal.
Bring it to the next stage then!Lone_Wolf wrote:Using this method does feel like a 'natural' evolution of OxpConfig,<snip>
Code: Select all
Methods
worldScripts["OxpConfig Server"]._register(pointer_to_my_object)
// add oxp to list of oxps oxpconfig does handle
worldScripts["OxpConfig Server"]._unregister(pointer_to_my_object)
// remove from list
worldScripts["OxpConfig Server"]._changed(pointer_to_my_object)
// notify OxpConfig_Server that oxp has changed values
/* my_object is a wrapper object to hold all data that is needed for OxpConfig_Server.
properties
name type optional meaning
General object
Script_name string oxp worldscript name, normally equal to this.name of calling script
Display_name string the name you want OxpConfig to display to the user
Display_on string used to determine where OxpConfig will show the values.
"Game options" = show on F2 - F7 screen
"Ship/Station Interface" = show on F4 screen through interface OxpConfig
Notify_type string tells OxpConfig when to send notifications
"Dynamic" = at every change
"Dynamic_group" = when user leaves group page
"Changes_completed" = when user leaves oxp configuration pages
Notify_handler pointer points to a function that will be called by OxpConfig_Server when user has changed values
Bool_info string y description shown when user goes to "change booleans" page, defaults to empty
Number_info string y shown when user goes to "change numbers" page, defaults to empty
Bitmask_info string y shown when user goes to "change bitmasks" page, defaults to empty
Booleans array y
Parent pointer
Child string Parent & Child are combined to access variable
Hide boolean false = variable will be shown to user
Default boolean used for "set to default" option
Description string user-visible description
Numbers array y
Parent pointer
Child string Parent & Child are combined to access variable
Hide boolean false = variable will be shown to user
Default integer used for "set to default" option
Max integer highest value allowed for number
Description string user-visible description
Bitmasks array y
Parent pointer
Child string Parent & Child are combined to access variable
Hide boolean false = variable will be shown to user
Default integer used for "set to default" option
Max integer highest value allowed for bitmask, should be a (power of 2) -1
Description string array user-visible descriptions
examples
this._sc_oxpconfig =
{
General:
{
Script_name: "Shield Cycler",
Display_name: "Shield Cycler",
Display_on: "Ship/Station Interface"
Notify_type: "Dynamic",
Notify_handler: this._sc_user_changed_values,
Bool_info: "enable / disable Shield Cycler oxp functionality & the devices it manages",
Number_info: "Threshold % determines when adjusting is done. 100 = always, 0 = never. Start configuration is the configuration that will be set upon launch (3 = equal, 2 = fwd, 1= aft, 0 = disabled).",
Bitmask_info: "enable / disable the availability of the settings for manual cycling. Note : if you disable all, Shield Cycler oxp will enable the disabled setting"
},
Booleans:
[
{ Parent:this._sc_settings.general, Child:"disabled", Default:false, Hide:false, Description:"disable SC OXP." },
{ Parent:this._sc_settings.general, Child:"sc_disabled", Default:false, Hide:false, Description:"disable cycler devices." }
],
Numbers:
[
{ Parent:this._sc_settings.sc, Child:"threshold", Default:100, Max:100, Hide:true, Description:"threshold %" },
{ Parent:this._sc_settings.sc, Child:"start_configuration", Default:3, Max:3, Hide:true, Description:"launch setting" }
},
Bitmasks:
[
{ Parent: this._sc_settings.sc, Child:"cycler_mask", Default:0x001, Max:0x00f, Hide:true, Description:["Disabled","Aft","Forward","Equal"] }
]
};
worldScripts["OxpConfig Server"]._register(this._sc_oxpconfig)
worldScripts["OxpConfig Server"]._unregister(this._sc_oxpconfig)
worldScripts["OxpConfig Server"]._changed(this._sc_oxpconfig)
this._sc_user_changed_values = function(bitmask)
{
// process user changes to variables
};
The flag is not related to OXPConfig. I'm using it to flag OXPs which have deleted their properties (either because requirements are not fulfilled or if the OXP has nothing to do anymore). OXPConfig has only checked this flag (like a few other scripts).Lone_Wolf wrote:this.deactivated (calling oxp property)
I think it's purpose was to allow oxps to disable configuration through OpxConfig.