General Scripting comments

If you have got this far, and understand what these routines do and how they do it, then you're ready to study the mIRC FAQ (Sections 7 and 8), look at what other events and identifiers are in there, and let your imagination run riot. If not, don't worry, the concepts introduced here are complicated and varied. There is some other help out there for scripts and so on, but they all tend to use the same examples, which is why I've tried to use some new examples in this tutorial. Study the mIRC FAQ first and then come back to the examples. Experiment with mIRC and have a look at some scripts written by other people.

Try to remember the difference between variables, identifiers, aliases, events and parameters. Be aware of what should be used when. Study the identifiers and event handlers made available to you in mIRC's scripting language, so you don't end up reinventing the wheel. If an identifier exists, use it!

Writing good scripts relies on you having correct knowledge of what each identifier and event handler does. Consult the help file and FAQ for more information, ask questions in the usenet newsgroups, search the internet for mIRC scripting information and above all, persevere.

If you've gotten this far then you obviously have more than a passing interest in writing scripts. You'll learn a little more each day, so don't try to bite off more than you can chew initially. The largest scripts were built up line by line, character by character, and a good script can take months to evolve.

Download scripts from the internet. Study them. Bear in mind that they are all just lots and lots of small routines bundled together in some quite large files. Ignore all the bits you're not interested in - find the menu and popup definitions to see which routines they call, then try to find those routines to see what it is they actually do. Say you've found a popup which calls a routine called $rout1. You can use the advanced section of File Find on Windows Explorer to look for other files which contain the text $rout1. Eventually you'll find the file which contains the identifier definition. You're putting yourself at the mercy of other people's programming abilities, and they may be clever, they may be heavy-handed, but they almost definitely won't have many comments in them. You're on your own there!

I have discovered that it takes time, practice and asking around on the newsgroups to discover exactly what a certain command or identifier will and will not do. This can slow down the scripting process almost to a halt, and you may well find that something you are trying to do simply cannot be done. Don't worry too much about this; it's all part of the learning process. I have been writing programs in various languages to do various things for the last seven years, and I still get a feeling of immense satisfaction when I've 'cracked it' - however, getting one little script to work is a long way away from becoming a master at the scripting language.

Testing code

Code like the examples I have provided in this tutorial are easier to test in that you can go on-line, open up a channel of your own, and try them out. Other scripts which rely on external events (people joining channels, or being opped, or files being sent or received) need to be triggered by these events in order to happen. The best way of testing these types of script is to be on-line at the same time as a friend who is willing to be your script guinea-pig.

The most basic form of a test is called a 'dry-run'. This is where you sit down with a copy of your script and a pen and paper, and run through it line by line, making a note of what each variable should contain at each step of the procedure. The way I've described the scripts above amount to a dry-run, except that I only ran through the loop once, rather than several times. Potential problems might come to light this way.

And finally....

If all this is totally lost on you, don't worry, because although I can do this, I can't cook, knit, fix my car, ride a horse or any one of a huge number of things other people can do. So don't feel left out.

Happy debugging!