Accessings Aliases, Triggers, Variables...in Plugins

Okay Nick, it's time for me to cause another headache. ;)

How possible would it be to allow the GUI screens that access the Aliases, Triggers, Variables, Timers, etc(?) for the primary MushClient data file to also pull data from currently loaded Plugin files.

Also allow editting, automatic(?) saving of the plugin(with the plugin wizard, I figure this should be possible to rewrite the xml file, although extra formatting may be lost if you do it this way) after any changes are made.

I figure a dropdown box that would list the current MushClient file you have loaded and each plugin you have loaded, although it would always default to the primary file when the GUI is initially opened(although if you move around between screens without closing it, it should stay on the current selection, which makes somewhat easier to jump between sections for plugins if you really need to).

In addition to this, possibly another option on the header of the file for a 'readonly' attribute that basically would not allow the name to show up for it to be altered. This would allow for less casual changing of data for distributed files if the author wanted to implement it.


(Take 2 aspirins and ignore me for a week and you should be all better :} *muah*)

What you could do as a workaround is to copy the entire plugin to the clipboard, excepting the <plugin> section, and then "import" it into MUSHclient (preferably a session with no other triggers, aliases etc.)

That way they can be accessed from the GUI interface, and then either remake the plugin, or copy and paste the relevant parts (eg. all triggers) back into the plugin file.

My thought was that you would debug a plugin before making it a plugin, so to speak, ie. using the GUI interface.

Any last-minute tweaking of flags, triggers etc. isn't that tedious in the plugin text file.

Or in a smaller case, say you want to fix up one trigger, copy its definition from the plugin file, paste it into the trigger dialog, edit it, and copy and paste it back.

Heh. This was something I mentioned way back, when there was heavy disussion on how to evolve MUSHclient to use plugins. :)

I had the same idea... A pulldown box at the top of the GUI settings window, that would let you select witch 'space' your were working with.

It would probably require some re-organization of the Configuration window... But once it's done, MUSHclient would use the same engine for both root/core data and plugin data.

I suspect Nick may want to leave this as something for next spring-ish, when perhaps he will consider working on the next major-ish update. :)

I would have to agree here. It is not reasonable to assume that a plugin will be bug free when created or that it is even a good idea to develope it inside the existing world first. I have two that fall into this category.

The first is my druid potion plugin. I have made changes to it wuite a few times since its first release and in at least one case, I had to do a major rewite. There was no way to effectively drop the whole thing back into the main world file and script, then turn around and re-export it back into the script. Doing so would have been harder than continually reinstalling is was.

The second was my little spell status tracker. The problem here was that the same set of triggers are used by it and some of the core functions of my main script. To avoid making debugging 10 times harder I chose to duplicate the triggers and build a completely new plugin to house the needed code. It would have nearly doubled the size of my main script to have it in there and made fixing either one overly complex.

In both cases I missed a few things that would have helped testing a great deal.

1. There was no way to check the world variables used by the plugins, or even if they where created.

2. If I thought I had fixed something and closed the editor, then found something else was wrong, I had to reopen the editor, stumble through directories to get to the file, fix the problem, and finally reinstall it all over again.

3. If I forgot a command to call the plugin, there was no list of aliases, triggers or anything else I could check to see what I needed.

While plugins work really nicely, once created they work too much like a black box imho. You can't really look at any of what makes it tick, edit it to fix bugs or check the aliases to remind yourself of the correct aliases. All of it gets hidden like the plugin was some sort of runtime library and I have to say that this sometimes creates more drawbacks than benefits.

This is also compounded even more by those cases where the core function the the plugin is dependent on some of those OnPlugin... subs that the normal script can't access. In such a case, you can't 'build' all the interfaces and test the complete set of subs in the GUI. It simply won't work.

1. Try: /world.debug "plugins"

2. Press Shift+Ctrl+P to open the plugins window. Select the plugin. Click Edit.

3. /world.debug "plugins"


I didn't want to make a GUI interface to change plugin contents because plugins are read-only files (include files) that may well be shared by multiple worlds. What if you change a plugin that is used by more than one world?

It's not that hard.

Edit the plugin, as described above. Select all. Copy. Go to the File menu -> Import -> Clipboard.

All the GUI things are now imported back into the world file. You can now play with them, and then either copy and paste them back into the plugin file, or make a new plugin.

As for the script, just copy between <script> and </script> into your script file.

>1. Try: /world.debug "plugins"

>2. Press Shift+Ctrl+P to open the plugins window. Select the plugin. Click Edit.

>3. /world.debug "plugins"

Hmm. Ok.. Will try to remember that. As to the second message about copying the stuff back in.. As I said, in most cases I put stuff in plugins because they would either interfere with code in the main script or use things that are not supported in the main world, such and the OnPlugin... stuff, so it is not that terribly helpful. lol However the rest is helpful. But maybe a new icon added to the configuration bar for plugins would be helpful. ;)