I know what the mIRC help file says about it (which is not much), but I still don't get it's use. Could someone explain a bit more or something to help me understand why the signal events even exsist because at this point I think it was a waste of time implementing this into mIRC.

A signal is simply a script-generated event. I assume you think it's a 'waste of time' because if you trigger a signal and then some commands get run, you could've just run those commands in the first place? If so, you're not thinking it through. By using signals you can add signal handlers at any point throughout your script, enabling you to place code in a logical manner if you have several different files to your script, and also allows you (or anyone else who knows what signals a script uses) to create 'addons' for another script without having to edit the original code.

Signals also provide a more mIRC-like interface for certain things happening in scripts. For instance I've written several DLLs which catch and send certain Windows events to mIRC by SendMessage()'ing signal commands so that anyone wanting to handle, for example, the PrintScreen key being pressed can use an event handler such as on *:signal:keydown:if ($1 == PrtScrn) { ...code... } instead of having to register some kind of hook or callback mechanism when the DLL is loaded, which is a very 'un-mIRC' method.

For an example of how signals can be used in a way that really wouldn't be practical without them, see this post (yes, it's by me, I'm spamming my own post ).

To be honest, I don't fully see the use for mIRC scripting, apart from maybe the more "native" feel of triggering an event.

For signal with -n switch, is like calling a custom alias immediately.
For signal without n flag is like issuing a .timer 1 0 myalias

I suppose people might find it useful that the signal name can have wildcards, though for me personally, this isn't a benefit in any way.

Of course, I'm only 1 person, and many different people might have very different needs.

EDIT: After thinking about it for a bit, it is an advantage that you indeed don't need to change the code from 1 alias, you can add another on signal event in another script file, which also gets called. For now that looks like the only useful extra it has over calling a custom alias.

But then I get to thinking: what good is it if you make a second on signal event for the same signal name, wouldn't that mean you want it to be different than the first on signal event? But since that one also gets triggered, what is really the purpose then?

I suppose only if you have complementary tasks, then it is useful for having multiple on signal events with the same name, which do different things that don't need to replace each other. Though you might as well just add these complementary things in one single on signal event, which completely defeats the purpose, since it's reduced to being a "custom alias" type of construct. I would actually prefer to see all these different commands grouped in 1 signal event, since then you know exactly what happens on the signal, without having to look for it in multiple script files where you might have coded yet another version of the signal.

Btw even though I reply to you, I'm just saying this as a general reply, if you find good purposes for signals then that's great. I'm also not downtalking signals, even if it's very similar to calling a custom alias in the ways described, I really like variety, and some people are gonna prefer to have code triggered in "event" form, so that's great too

Thanks for replying, I can see why someone would use a signal now...