Can MUSHclient support sub-group definition?

Posted by Zhenzh on Thu 05 Sep 2019 06:30 AM — 2 posts, 12,576 views.

China #0
Too many triggers under one group and too many groups get the trigger difficult to be read and managed.

If sub-group can be supported, triggers can be managed as file trees which will be helpful for understanding and controlling the trigger relationships.
Australia Forum Administrator #1
No it doesn't.

However if you have many triggers there are ways of dealing with them.

Filter the trigger view


In the filter dialog there is a checkbox "Filter by" and a button labelled "...".

If you click on the "..." button you can make a filter script, for example:


local wanted_group = utils.inputbox ("Choose group", "Group", "")

function filter (name, trigger)
  if not wanted_group or wanted_group == "" then
    return true
  end -- if no response

  return trigger.group == wanted_group
end -- filter


The first line prompts you for a group you are interested in, and then for each triggger line item the function "filter" is called which returns true if you want to see that line and false if you don't.

Now you can click on the checkbox and you will be prompted for a group, and then only items in the group will be shown. You could make a partial match by using string.match rather than compare-equal in the filter function.

This can be useful for cutting down large lists in a way of your choosing. A more sophisticated function could query for things like enabled triggers, triggers which have never fired, triggers which send-to-script and so on.

Move the triggers into plugins


Instead of doing everthing in the GUI interface you can make one or more plugins which lets you move batches of triggers which do related things, into a plugin. Whilst you cannot edit the triggers in a GUI dialog any more, the text version is quite easy to follow. For example:



<triggers>
  <trigger
   enabled="y"
   match="Affects * by *."
   name="affects"
   send_to="12"
   sequence="100"
  >
    <send>

objectStats ["%1"] = "%2"
EnableTrigger ("end_of_affects", true)

    </send>
  </trigger>
</triggers>


It is pretty obvious what is going on in this trigger. You can see the match text, the trigger name, and what it is sending to script.

In a plugin XML file you can add comments to make it obvious what groups of triggers do, for example:


<!--  Triggers for getting my inventory  -->


If you were keen you could make your own program (eg. in Python or C++) to edit these XML files, find the triggers and display them in a tree view. The plugin files can be parsed by any standard XML parser.