Extension base.xml question

[Bidmaron]

Ok, I have this in my extension:


<ruleset>
<name>CoreRPG</name>
<minrelease>3</minrelease>
</ruleset>

expecting that anything that was CoreRPG or based off it would allow my extension. Of course, that is not strictly what the documentation here says, extracted below in part:

The <name> element gives the name of a ruleset with which this extension is compatible. The <minrelease> and <maxrelease> elements are optional, and refer to a ruleset release number defined in the base.xml file of the ruleset itself. The number is given in the release attribute to the <root> element in that file:

<root version="2.0" release="12">
You can define multiple rulesets as dependencies, to make the extension compatible with multiple rulesets. If no ruleset dependencies are declared, the extension is usable with all rulesets.

What is the consensus on dependency? Without listing all the known rulesets deriving from CoreRPG, you cannot effectively use this element. So, is the consensus just to leave it out and document its rulesets in the extension posting here?

[Trenloe]

There's really little need to use it, unless there is a very specific bit of functionality you know exists after (or only before) a certain ruleset release version that the extension relies on.

For the Smiteworks released rulesets this will rarely be used, as 99.9% of users will be on the most recent release. There would only be the vast minority who don't update or who have a ruleset unpacked that this would be relevant for.

If you're creating an extension for a community ruleset, it has more relevance, as it relies on the individual user to manually update their rulesets. But this would also rely on the community developer updating the release version of the ruleset, which many don't, especially for minor releases.

[Bidmaron]

Thanks, Trenloe.

[Bidmaron]

Okay, next question related to this:

Can I override the onInit of a manager? That is, can I use:


TableManager.onInit=myOnInit;

in an extension and override the initialization of a particular lua code manager file? Or is the onInit something special that the FG engine always calls for each code file?

If the latter is true, what is the order of onInit? Would the built-in onInt execute before my extension lua script file onInit executes? Specifically, can I set an action manager handler in my extension code file that overrides what is in the table manager onINit routine? The onInit in Table Manager does this:


function onInit()
Comm.registerSlashHandler("rollon", processTableRoll);
ActionsManager.registerResultHandler("table", onTableRoll);
end

and I want to be able to do this in my own extension lua file instead (or after if the above code is called first and my code will override it:)


Comm.registerSlashHandler("rollon",myProcessTableRoll);
ActionsManager.registerResultHandler("table",myOnTableRoll);

I am hoping that the extension onInit executes after the table manager's onInit (if I can't override it) and the most recently registered handler will apply.

[Bidmaron]

Oops, I figured out part of my answer because the order of processing according to the extension documentation here is:



The ruleset files are parsed and processed.
The extension files are parsed and processed, in dependency order.
Templates are processed.
Controls such as desktop elements are created.
Global ruleset script blocks are initialized.
Extension script blocks are initialized, in dependency order.



So, extension scripts are executed after ruleset scripts (and I doubt you can override the onInit routine? Still not clear from above)

[Trenloe]

I don't think that will work reliably. The package isn't available to be accessed (overridden in your case) until it has been initialised, which is when onInit runs. At best you'd get a race condition/no overrides, at worst you'd get errors.

[Bidmaron]

I found additional information by examining the code of the action manager. The most recently registered result handler will override anything previously registered. The Comm.registerSlashHandler code is not available, so I don't know what happens when you reregister a slash handler. I suspect it will override.

[Bidmaron]

I don't think that will work reliably. The package isn't available to be accessed (overridden in your case) until it has been initialised, which is when onInit runs. At best you'd get a race condition/no overrides, at worst you'd get errors.


Based on what I posted, I think I will be okay if I simply re-register the slash and result handlers (although I am not sure in the case of the Comm, since I cannot examine that code).

[Trenloe]

Comm.registerSlashHandler("rollon",myProcessTableRoll);
ActionsManager.registerResultHandler("table",myOnTableRoll);
I'm not sure, but you can probably just override the previous registerSlashHandler - give it a go.

For ActionsManager, unregister the previous result handler with ActionsManager.unregisterResultHandler("table") and then add your own in. Look in the CoreRPG scripts\manager_actions.lua file for the functions you can call in that package.

[Bidmaron]

Great idea. That would be safer in case the FG engine changes to permit cascading handlers.