There is not a huge amount you can do in plugins that can't be done with ordinary scripting - excepting plugin callbacks, which I will discuss in a minute - however they have a big advantage of encapsulating everything needed to implement a particular idea, in one file.
That Chat plugin is an example of that, quite a few aliases, triggers, and scripts, all needed to make it work. Without the plugin concept everyone that wanted to install it would have to:
- Add triggers as instructed
- Add aliases
- Add variables
- Copy and paste the script portion into their script file
- Enable scripting, and set it to the language the author wrote it in
And then things get ugly if you want to remove it.
However with plugins something like installing chat is as simple as "install this file in the plugins dialog". To remove it "remove the chat plugin from the plugins dialog".
Plugins have these advantages:
- Encapsulating all required triggers, aliases, timers, and variables (for a particular purpose, such as the chat system) into a single file.
- Any scripting needed is also in the same file.
- Each plugin script runs in its own address space, so there is no clash between variable names that different plugin authors may choose.
- Also, for the same reason, each plugin can be written in a different language.
- If required, plugins automatically load and save a "state" file on a per-plugin/per-world basis, so that each plugin can save its variables independently of each other plugin, and once for each world. This means that a plugin can save its state, even if the user chooses not to save their main world file. It also saves mucking around reading and writing files, and wondering where to put them, just to remember something like "what port to use for the chat plugin".
- Certain script actions are only supported via plugin callbacks.
- They can be easily installed and removed.
Plugin callbacks
Certain functionality in MUSHclient is only supported by setting up a plugin, and having a function inside that plugin that matches a predefined name. See this page for a list:
http://www.gammon.com.au/scripts/doc.php?general=plugin_callbacks
Basically when the plugin is installed, MUSHclient sees if those functions exist, and if so makes a note to call them at the appropriate time.
Some are designed for plugin housekeeping (like OnPluginInstall and OnPluginClose) and others are called more frequently, such as OnPluginLineReceived.
Quote:
I understand that triggers and aliases (etc) can fire off to the scripting engine, so what does this mean?
When matching triggers and aliases (and timers firing) if that trigger is in a plugin, then the script in that plugin is called (same for aliases and timers). This is part of the process of keeping everything related to that plugin private to the plugin.
How to write plugins
MUSHclient has a "plugin wizard" which helps to do the infrastructure required in writing a plugin. My suggestion is to tackle a single idea at a time (eg. a health bar), get it working in the normal non-plugin script space, as far as possible, and then use the plugin wizard to migrate all related triggers, aliases, timers, and script routines into that plugin.
Once the plugin file has been created you have to manually edit it to make changes, there is no GUI "plugin editor". However to add things like more triggers, simply use the "copy" button on the trigger list to get the trigger on the clipboard in XML format, and paste into the appropriate part of the plugin file, it isn't hard.
If you are going to write plugins completely from scratch (eg. by basing on an existing one) be aware that each plugin you develop should have a unique "plugin ID" which is used to identify one from another. You can use this script line to generate a new one:
/Note (GetUniqueID ())
This gets placed in the initial part of the plugin, like this:
<plugin
name="SomeName"
author="Nick Gammon"
id="ef2989ef263b3ff47d662556"
language="Lua"
purpose="Whatever it does"
date_written="2006-05-16"
requires="3.23"
version="1.0"
>
|