Finally got around to working on this some more. The Vyzor example is really helpful for the overall structure and cleanliness in require()ing all the different .lua files for use in Mudlet. This is definitively beyond my lua skills as of now, so thanks again for the explanations.
While helpful, Vyzor has a different aim. It does not seem to use many triggers, aliases, timers, keys or scripts like my package does. So I was looking into commands to accomplish creating those objects for GUI view directly from the .lua files as well.
For example, I created this template for
permAlias(name, parent, regex, lua code) to build an alias:
code_type = "alias"
code_name = "Test"
code_group = "Testgroup"
code_regex = "test"
code_string = [[--
echo("Test successful!")
]]
if exists(code_name, code_type) == 0 then
permAlias(code_name, code_group, code_regex, code_string)
end
Only downside, I have a few aliases which use the "command" box, so I have to restructure a bit and put send(command) in the code box instead, as the permAlias() won't take input for the command box at all.
However there seem to be a few other limitations with current Mudlet commands' setup.
For example, I can only create groups with permGroup(name, itemtype) on root level, compare
manual. How do I create groups of groups or even deeper levels?
For example, I can either create
permRegexTrigger() or
permSubstringTrigger with either one regex pattern or one substing pattern. But if I want to create one trigger with multiple patterns, maybe even mix regex and substring type, I did not find a command. Vadi suggested tempComplexRegexTrigger() maybe, but this would not be permanent and therefore not be visible for editing by the package's users in Mudlet GUI.
For example, there does not even seem to be a permScript() command to create Scripts objects this way. Which I would need because I sometimes use scripts to respond to events. Again Vadi suggested alternatively to put all scripting inside aliases, triggers, etc. or leave it invisible in GUI, handle all configuration in .lua files directly. Also I could
register events from scripts with
registerAnonymousEventHandler(event name, function name) - However again, this would be invisible in GUI and therefore not viewable nor adjustable by users.
One final issue I faced, but maybe already solved myself: The lua code that Mudlet will put inside the alias (trigger, etc) will have to be a string value like code_string in the example above. In effect, the code will not be as easy to handle by developers who edit the .lua files directly. Like we said in beginning, they want to be able to test and develop directly there without using Mudlet first. Now the solution would be to work with the following
load() command in the .lua file for testing. I have to try it our some more but looks promising enough:
code_string = [[--
echo("Test successful!")
]]
my_test_function = load(code_string)
my_test_function()
-- output happens, or might happen if echo() was replaced with print()
-- another example to give and take arguments from loaded functions:
print(load("return ...")(1,2,3))
-- where 1, 2, 3 are arguments given to the function, which receives them in ...
-- this is called vararg function
Now to keep Vadi & the helpful team to the important work they are doing for the next Mudlet version as well, I want to ask here, is there any other feedback from other users, who considered the same path? Did I miss important functionality? Would you like more information about my findings as I go along? Cheers!