Request For Advice - Best Way To Handle Modification In The Layered Ruleset Model

[dulux-oz]

Hi Guys,

I'm after some advice:

I'm creating a new Ruleset based on the CoreRPG Ruleset. I would like to add some extra Slash Commands to the Chat Box. This is done via the onSlashCommand() function from the manager_chat.lua file.

So, my question is this: Do I:
1) Replace the entire manager_chat.lua file,
2) Have a new file with only the original onSlashCommand() function which I modify to include my new Slash Commands,
3) Do something else which I haven't thought of.

If the answer is (2), what extra commands, etc, do I need (and where do/should I put them) to ensure that my new onSlashCommand() function is used instead of the original, or does FG3 take care of that automatically?

Thanks in advance

[Trenloe]

No need to overwrite or add to what is there already (unless you're changing it). Just add a Comm.registerSlashHandler command in the onInit() function of your script where you want to handle the slash command. The Comm package stores all of the registered slash handlers.

See CoreRPG \scripts\characterlist.lua for an example of the "afk" slash handler in a ruleset.

Comm.registerSlashHandler("afk", processAFK);
This will run the processAFK function on \scripts\characterlist.lua when \afk is used.

Also, the language extension uses a bunch of slash commands in \scripts\fontchat.lua: https://www.fantasygrounds.com/forums/showthread.php?20332-Tenians-Language-Chat-Extension-for-select-FG-3-0-rulesets

[dulux-oz]

Still trying to get my head around the Cascading Ruleset Model - could you do me a favour? Check out the script file in my Colour Gizmo Extension and let me know what I've done non-best-practice? The only changes to what the Extension does is:

1) Changes the Background Image in the XML file.
2) Adds the 4 Constant Definitions to the top of the script file.
3) Changes a dozen lines of code to use the Constant Definitions instead of the original numberic values near the bottom of the onInit() function.

However, I included ALL of the other original script code in the Extension - if I'm understanding you I didn't need to do that.

Thanks Trenloe

Cheers

[Trenloe]

Still trying to get my head around the Cascading Ruleset Model - could you do me a favour? Check out the script file in my Colour Gizmo Extension and let me know what I've done non-best-practice? The only changes to what the Extension does is:

1) Changes the Background Image in the XML file.
2) Adds the 4 Constant Definitions to the top of the script file.
3) Changes a dozen lines of code to use the Constant Definitions instead of the original numberic values near the bottom of the onInit() function.
In this case, you are making modifications to a script that is tied to a control, so you can only make changes within that single LUA file, or create a separate "manager" type file that has your customised code - but you'd still need to make changes to the base LUA file attached to the control (via the <script> command) to make calls to your manager file. So, what you have done here looks OK.


However, I included ALL of the other original script code in the Extension - if I'm understanding you I didn't need to do that.
Perhaps I missed the intent of your original question - the manager_chat.lua onSlashCommand() function is essentially a "help" entry that outputs what slashcommands can be used when an unrecognised slash command is entered in the chat window. It is not where you define which slashhanders are actually present in the ruleset. Slash handlers are added using the Comm.registerSlashHandler function and can be done from anywhere - so it is easy to add new handlers in extensions, etc. without impacting other slash handlers.

However, which may have been the original intent of your post, the slash handler "help" provided via the onSlashCommand() function would not be automatically updated to include any new slash handlers. So, it is a case of whether you want to include updated help in your layered ruleset/extension or not. If you want to, you would need to overwrite onSlashCommand which may be overridden by other extensions doing the same...

[Bidmaron]

Sounds like what we need is a RegisterSlashHandler call with an extra parameter that includes the help for a new slash command. Would that work?

[Trenloe]

Sounds like what we need is a RegisterSlashHandler call with an extra parameter that includes the help for a new slash command. Would that work?
That would work to some degree, but it would be very extension specific. e.g. If 2 extensions used /help then the last one to load would overwrite the others.

What is good with the base functionality is that if there is no match the help is shown. No need to know what the help command is etc..

I think what would be great would be if the slash handler help in CoreRPG was moved to a string variable (using /r for new lines) in the manager script with one variable for GMs and one for clients, and then a function added to the LUA file to add extra lines to the help string. This function could be called from other scripts and would allow multiple extensions/layered rulesets to add slash handler help specific to the extension without overwriting other help entries.

[Bidmaron]

That would be great, but what I was thinking was just add a parameter to RegisterSlashHandler where the CoreRPG code just appended the help for a new command onto the end of the system string stored in the campaign database (or perhaps the configuration database, whatever that thing is called again). Alternatively, it could be inserted into the master help string in alphabetical order. As long as the command names were unique, that should work; it wouldn't require a separate call; and its presence in the RegisterSlashHandler should encourage slash commands to provide proper Help.

[Trenloe]

what I was thinking was just add a parameter to RegisterSlashHandler where the CoreRPG code just appended the help for a new command onto the end of the system string stored in the campaign database (or perhaps the configuration database, whatever that thing is called again). Alternatively, it could be inserted into the master help string in alphabetical order. As long as the command names were unique, that should work; it wouldn't require a separate call; and its presence in the RegisterSlashHandler should encourage slash commands to provide proper Help.
That's a much better idea. :)