This tutorial intends to show you some basic guidelines to follow when creating your addon. They are by no means the only way to do it, and comments and suggestions are welcome.

Scripting: Files

When creating addons, it is encouraged to use a single file for the code, a ".mrc" file. When you use this format, you must remember to prefix aliases with the "alias" keyword and when you make popup menus, you must do "menu <area>", like "menu nicklist".

Scripting: On Load/Unload

Your addon should include an on *:load: event, if to do nothing more than to simply inform the user that the addon has loaded correctly. Ideally, however, in this event, you want to check the version of mIRC, to make sure it is compatible with the addon. If you know it only works in a certain version on up, you could do something like:

if ($version < 5.71) {
  echo -a You must use mIRC v5.71 or higher for this addon to work.
  echo -a Please upgrade to mIRC v5.71, and try again.
  .timer 1 3 unload -rs $script
  halt
}

We encourage you to make sure the addon always works with at least the latest version of mIRC. Also, if you do if ($version < [current version]), the addon doesn't need any changes to work with newer versions of mIRC...so if the user upgrades mIRC without upgrading the addon (or if there is no upgrade of the addon available), the addon will still be functional.

Also important to the on load event is setting initial settings, if they are needed. This could be setting variables or creating files (ini, txt, etc..). On the same note, it is also nice to check if the user already had the addon loaded previously, and you could import the old settings.

When the addon is unloaded, any necessary files and variables should be cleaned up.

Scripting: Aliases

When creating aliases for your addon, you should use local aliases whenever possible. Local aliases are aliases that take the -l parameter when created:

alias -l als1 echo -a This is a local alias
alias als2 echo -a This is a global alias

Local aliases have two main benefits, they are local to the specific files, so you can avoid naming conflicts, and they cannot be called from the command line, so you prevent the user from inadvertently calling an alias they are not supposed to.

Remember, all aliases created in remote files must be prefixed with "alias".

Scripting: Menus

If you want your addon to have popup menus, you do not use the popup editor, but you define a menu definition. For example, if you want to have an op command in the nicklist, you would put this in your addon:

menu nicklist {
  op: mode # +o $1
}

You can use status, channel, nicklist, menubar, and query. Otherwise, the popups work exactly like normal popups.

Scripting: Remote Events

Unless your addon is supposed to specifically change the output of remote events, then you must use halt and haltdef (and the ^ modifier) carefully, as to not change the user's current script.

When considering to use those, you can check the identifier $halted, to see if the default output has already been halted. $halted returns $true if it was halted and $false if it wasn't. Also, if you prefix the event with "&", and the event has been halted, the event will not be executed at all.

Scripting: Variables

It is ideal that your addon not keep too many permanent %variables. Too many variables could make mIRC become slow and/or use a lot of memory. The best way to do this is to store long-term settings in an external file, and only use temporary variables when doing methods. To achieve this, you can use "unset" or you can prefix the variables with the "var" keyword. Var variables are automatically cleaned up whenever the calling procedure is finished.

When naming your variables, make sure they all use unique names, since you never know what the host script will be using as variables. For example, if you are making an addon called "MyScript", you might use names such as %myscript.ver. Then when the addon is uninstalled, you simply have to do unset %myscript.* to clean up all of your variables.

Misc Notes

USE the $scriptdir identifier! Do NOT assume the user has installed the addon to the mIRC directory, or some hard-coded subdirectory. Also, make any files you include, such as bitmaps, belong in the same directory as the addon. It makes it a lot easier when uninstalling or removing the addon.
Update: carbstah says use $shortfn($scriptdir) or " $+ $scriptdir $+ " incase the directory has spaces in it.

We the introduction of dialogs a while back, making an addon customizable has become easier, and allows for a great deal. Using customization allows your addon to appeal to a wide audience.

Use unique ideas. If you have a lot of information to display, don't just /echo it to the user, display it in a picture window with colored text and graphics. Using picture windows, you can give your addon a lot of style.

With these tips, you should be able to put together a successful addon. If you have any tips or ideas, you can email them to me (email at the top), I would like to make this a good "guideline" to go by.