This tutorial assumes working knowledge of basic mIRC event scripting, aliases, and basic scripting concepts such as wildcards.

So just what is /signal? Signals are simply another level of event handling to prevent conflicts between scripts.

The mIRC help file explains signals as:

"Signals are simple way of triggering signal events in multiple scripts at the same time."

/signal [-n]  [parameters]

The signal command allows you to trigger signal events in all scripts that listen for signals.

By default the signal is triggered after all current scripts have finished executing. You can however use -n to make the script trigger immediately.

on *:SIGNAL:name:command

The on signal event triggers if a script has used the /signal command to send a signal to all scripts.

The signal name can contain wildcards.

The $signal identifier returns the signal name that caused the signal event to trigger.

The $1- identifier returns the parameters that were specified in the /signal command.

Note: The script that called /signal is triggered first, and then all other scripts are triggered."

In other words you can create custom events based on existing events/situations.

Standard mIRC event handling creates conflicts in a modular environment. For example, let's say that you have a channel flood protection script:

on ^@*:TEXT:*:#: {

  if ($+(%flood.,#,$nick) >= 5) { 
    kick # $nick Quit Flooding Queer 
    unset $+(%flood.,#,$nick)
  }
  else { inc -u10 $+(%flood.,#,$nick) }

  echo # $+(<,$nick,>) $1- 
  haltdef
}

This example kicks the $nick from the channel when the variable reaches a certain value in a certain period of time. In a situation such as this, the speed of the script is essential to it's function. What good is a flood protection if it's slow?

So now lets say that you want to add some features to your flood protection script. Maybe some logging and counter functions. Normally you would just add them to the event:

on ^@*:TEXT:*:#: {

  if ($+(%flood.,#,$nick) >= 5) { 
    kick # $nick Quit Flooding Queer 
    write kick.log $timestamp $nick #
    inc %kick counter
    unset $+(%flood.,#,$nick)
  }
  else { inc -u10 $+(%flood.,#,$nick) }

  echo # $+(<,$nick,>) $1- 
  haltdef
}

This creates a problem however. The extra lines of code now slow down the rest of the event. mIRC script is executed IN ORDER before following lines can be processed.

Using /signal you can set off multiple triggers at the same time, without slowing down the event:

on ^@*:TEXT:*:#: {

  if ($+(%flood.,#,$nick) >= 5) { 
    kick # $nick Quit Flooding Queer 
    signal flood.kick $nick #
    unset $+(%flood.,#,$nick)
  }
  else { inc -u10 $+(%flood.,#,$nick) }

  echo # $+(<,$nick,>) $1- 
  haltdef
}


on *:SIGNAL:flood.kick: {
    write kick.log $timestamp $nick #
    inc %kick counter
}

While this example might seem trivial, it illustrates an important concept. The less one event has to do, the faster it will do it. Let's move on to a more beneficial example: a theme engine.

MTS takes over all visual event handling, and often causes conflicts within scripts. Instead of having:

on *:TEXT:*:#: { MTS parse }

seperate file...

on *:TEXT:*:#: { 

   Flood protection
   Fserv Triggers
   Shitlist
   etc...
}

and then having to run script after the parse in another file, you can simply create a signal based engine and pass along the event handling without any conflicts:

on *:TEXT:*:#: { 

   signal $+(mts.,$event,chan) $nick # $1-
   Flood protection
   Fserv Triggers
   Shitlist
   etc...

 }

on *:SIGNAL:mts.*: {

    goto $signal

    :mts.text.chan
    text parse.... | halt

    :mts.join
    join parse... | halt

    and so on..

}

In this example we introduce both a wildcard signal definition, and the $signal identifier. $signal works in the same way as $event. It returns the value of the calling signal. The above example shows how one could handle a range of signals dynamicly.

In closing, there isn't much to the syntax of Signal Event handling, but there is a wealth of potential for a creative scripter.

As well as the above MTS example, possible uses for signals could include:

Bot Event handling

Multiple Userlist triggers

Faster Protection/Revenge Response
and much more...

Hopefully this has shed some light on the concept of Signals and mIRC event handling. Questions, comments, flames can be sent to [email protected].

(NOTE: The code examples above are strictly conceptual and are in no way meant to be copied and pasted as working script. In other words, don't complain to me about why it's lame to use inc -u for flood protection etc. The code is just there to give you an idea of the environment in which signals work.)