Sladekraven is incorrect when he says you can only have one on text event in an mIRC script file (wink@andy).
In fact you can have as many as you want in 1, but you need to organise them in a way, that each on text event only captures as much as it should.
Fex if you have 5 on text events, and the first one is one where the matchtext is *, this one will capture everything, thus making the other ones useless.
To show how you can use multiple, consider this test case.
on *:text:this is a test:*: { do things }
on *:text:this is a *:*: { do things }
on *:text:this is*:*: { do things }
on *:text:this*:*: { do things }
on *:text:*:*: { do things }
If someone says 'this is a test', the first one will trigger, and not the other ones. Had the order of on text events been different, for example the other way round, then it would have never triggered the right on text event. Instead the one with matchtext * would have captured it.
So far we only talked about differences in matchtext of the on text event. As you know, there is also a way to specify on what window the on text event should trigger.
We can choose out of:
? = for any private message
# = for any channel message
#mirc = for any messages on channel #mirc
* = for any private or channel messages
This also makes an important difference.
Consider the following 3 on text events:
on *:text:this*:#: { msg # triggered from a channel }
on *:text:this is a test:?: { msg $nick triggered from a query }
on *:text:*:*: { msg $iif($chan,$chan,$nick) triggered from either a channel or query }
So if I say 'this is a test' in a query, even though the first on text event matches on this*, it is not triggered, because it's for a channel. So the second on text gets triggered, because that is the one that reacts on a query window. (So does the third, but since the second is before the third, this one captures it instead.)
If I say 'this is" in the channel, the first one is triggered. The last one doesn't get triggered, even though it matches the text (*) and it is on a channel (* means channel or query in the location part of the event)
If i say "booo", in a pm or a channel, then the 3rd on text is triggered.
So far we discussed differences in matchtext and matchlocation in on text events. There is still something left to complicate things. As you may or may not know, we can use the ^ event prefix for certain events. This prefix is used so you can prevent the default text for an event from being shown, when used along with halt/haltdef.
Consider the following two on text events:
on *:text:*:#: msg # nr 1
on *:text:*:#: msg # nr 2
When you say anything in a channel, only the first will trigger and msg "nr 1". However, let's add a very small modification to the second on text event.
on *:text:*:#: msg # nr 1
on ^*:text:*:#: msg # nr 2
Now when you say something the script will message, in this order:
nr 2
nr 1
Putting a halt/haltdef after the second one, will prevent the text from being displayed, but will not prevent the first on text event there to trigger. If we would want that our first event does not trigger, after another event used a halt/haltdef, we need to modify it a bit. In particular, we need to prefix it with the & event prefix.
on &*:text:*:#: msg # nr 1
on ^*:text:*:#: msg # nr 2
Now what happens when we say something on the channel? It messages again first nr 2, then nr 1. When we add a halt/haltdef to the second on text event like this:
on &*:text:*:#: msg # nr 1
on ^*:text:*:#: msg # nr 2 | haltdef
The second on text event is now the only one triggered when something is said on a channel, whilst the first one is ignored. Btw, instead of using the & event prefix, one could also use the $halted identifier, which returns $true if a user has used /halt or /haltdef in a ^ event which was triggered prior to the current one, and $false if not.
on *:text:*:#:if !$halted { msg # nr 1 }
on ^*:text:*:#: msg # nr 2 | haltdef
The result is the exact same as the above with the & event prefix. The second on text with the ^ event prefix is triggered. Then the first on text event (without ^) is triggered, however, there is an if check to see if $halted is $true or $false (if !$halted means only proceed is $halted is $false). Since we did indeed use a haltdef or halt in the ^ event, the if condition fails, and stops processing. Therefore, it also only msges to the channel "nr 2".
Be very careful! Even though the result of using & and $halted were the same, they work inherently different. When you use the & event prefix, the event is never even triggered. In the case of $halted, the event is triggered but stops processing after the if condition that checks $halted, is $false. This can be an important difference in certain situations. For example:
on *:text:*:*:{
echo -a triggered first event
if !$halted { echo -a No halt/haltdef used in an on text event with ^ prior to this event }
}
on ^*:text:mirc:*: echo -a triggered second event | haltdefIf I say on a channel "mirc", then the second event with the ^ is triggered. Then the first event is also triggered and echo's "triggered first event"'. Then follows the if check for $halted, and since I did use a haltdef in the event with the ^, the if condition is false, thus the remote stops.
However if I say "this is a test", the first event is the only one triggered, and echo's 2 times since $halted is false now, thus making the if condition $true. The second event does not trigger because of the matchtext.
Phew, we're almost there. You didn't think that was it, did ya? There's more...
You can have multiple on text events in one remote file, even if they have the same matchtext, and without the use of ^,&, and halt/haltdef. It's with the use of #groups.
Consider the following example:
#group1 on
on *:text:*:?: msg $nick 1st group triggered | enable #group2 | disable #group1
#group1 end
#group2 off
on *:text:*:?: msg $nick 2nd group triggered | enable #group1 | disable #group2
#group2 end
The use of groups here like this can be handy in certain situations, as it can be scripted to act in a dynamic way.
Well, there might very well be still some things left to be said, but I'm writing this in the middle of working on my thesis, it wouldn't surprise me at all if I forgot some important parts here and there :tongue:
Btw just for clarification, to anyone that is trying the examples provided. You cannot trigger your own on text events. If you want to test on text events, it is best to have one client with the code (preferably a clean mIRC with no scripts installed as they may corrupt the results), and one mIRC to test. You could also use the multiserver ability of mIRC but for testing on text events, it is sometimes a bit too confusing.
Greets
