Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Plugins
➜ Dynamically created triggers are not persisted?
Dynamically created triggers are not persisted?
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Sergii
(2 posts) Bio
|
Date
| Thu 16 Mar 2023 08:37 PM (UTC) Amended on Fri 17 Mar 2023 04:44 AM (UTC) by Nick Gammon
|
Message
| Hi.
So I have a plugin.
It contains a simple alias which just passes parameters to lua function:
<alias
name="my_channel_set_pattern"
match="__channel_set_pattern * *"
enabled="y"
group="my_channels"
omit_from_log="y"
send_to="12"
omit_from_output="y"
sequence="100"
>
<send>channel_set_pattern("%1", "%2")</send>
</alias>
channel_set_pattern function just creates a trigger (details probably are irrelevant to the problem, but I'm posting code here just in case):
function channel_set_pattern(name, pattern)
local trigname = "my_channels_"..name.."_pattern"
local replacement = 'channel_add("'..name..'", "%1", "%2")'
check(AddTriggerEx(trigname, pattern, replacement, 1065, -1, 0, "", "", 12, 100))
check(SetTriggerOption(trigname, "group", "my_channels"))
Note("Name pattern for ", name, " set: ", pattern)
end
I add this plugin in global preferences, so that it's automatically installed in all worlds.
I create new world and type '__channel_set_pattern something something' to create trigger.
Everything works, trigger is added.
Then I save my world and close the client, and newly added trigger is not saved, neither in world file nor in plugin state.
Setting save_state="y" in the plugin header does not help.
So the main question here is: how to persist triggers created by plugins?
Thank you in advance!
[EDIT] Code tags added. | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #1 on Fri 17 Mar 2023 04:52 AM (UTC) |
Message
| Dynamically added triggers/aliases/timers are not saved to the plugin file because plugins are read-only. They may be shared between multiple worlds.
They are also not saved to the “state” file because, although that is written to, and is per-world, it is for variables and not triggers/aliases/timers.
There are a few ways you could achieve what you seem to be trying to do:
Save the information you get passed in the alias into a variable, suitably named (eg. my_trigger1, my_trigger2 and so on). Then when the plugin starts next time simply re-add the triggers from these variables.
If appropriate, make a catch-all trigger (eg. matching “*“) and then run all lines through the saved patterns (using Lua pattern matching) which would have a similar effect except that you are not actually adding triggers.
Save the newly-added triggers into a table (see http://www.gammon.com.au/scripts/doc.php?function=ExportXML) and then use http://www.gammon.com.au/scripts/doc.php?function=ImportXML to load them next time.
Serializing this table of triggers may simplify things: http://www.gammon.com.au/forum/?id=4960
If this is for chat channels you may be able to simplify this a bit, by simply saving a list of things you are trying to match, and then using that list to process all chat messages. I don’t have enough detail in your original post to know whether this would help or not.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Sergii
(2 posts) Bio
|
Date
| Reply #2 on Fri 17 Mar 2023 12:34 PM (UTC) |
Message
| Hi Nick,
Thank you for fast response and for the awesome client :)
Matching on * is not an option, because these triggers should be first-class citizens (i.e. I want to be able to enable/disable their groups etc); so I'll have to reimplement most of trigger machinery from scratch.
Serializing them to variables certainly will solve my problem, but it also looks kinda awkward.
Would you be willing to accept a PR on github if I implement saving triggers to plugin state? Or you deliberately chose to save only variables there? | Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #3 on Sun 19 Mar 2023 10:35 PM (UTC) Amended on Sun 19 Mar 2023 10:38 PM (UTC) by Fiendish
|
Message
| For what it's worth, I also ran into this in one of my plugins. I store the parameters for the triggers in a Lua table that gets serialized during save and then deserialized into triggers during plugin load.
Quote: Would you be willing to accept a PR on github if I implement saving triggers to plugin state? Or you deliberately chose to save only variables there?
This seems like the sort of thing that has the potential to break an existing plugin, so I'd personally only accept it if it were gated behind a new plugin-level setting like e.g. save_state_includes_triggers_and_aliases="y" or something. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| Nick Gammon
Australia (23,070 posts) Bio
Forum Administrator |
Date
| Reply #4 on Mon 20 Mar 2023 05:37 AM (UTC) Amended on Mon 20 Mar 2023 05:38 AM (UTC) by Nick Gammon
|
Message
| I am very reluctant to make this sort of change because of the compatibility issues, and that if your plugin was ever distributed, people would need the latest client version to support it.
I think it would be comparatively simple to make a generic “dynamic trigger adding” function. It would do something like:
On plugin load, read in (and de-serialize) any existing triggers from a specially named variable (which is a table of triggers). Such triggers would then be added to the plugin’s trigger space.
When wanting to add a new trigger, pass it through a function that both adds the trigger (in XML format) and adds it to the table of triggers to be added next invocation.
Have some provision, if desired, for removing existing triggers. It would likewise delete the existing trigger and remove it from the aforementioned table.
At plugin save time, serialize the table of current triggers so that can be used in step 1 next time.
The amount of work needed to do this would almost certainly be less than the amount needed to change the client, and would have less compatibility issues.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #5 on Mon 20 Mar 2023 06:02 PM (UTC) |
Message
|
Quote: The amount of work needed to do this would almost certainly be less than the amount needed to change the client, and would have less compatibility issues.
Oh, 100%. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
6,527 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top