Forums Feature Suggestions generic channel message event

Currently if you want to have a remote be triggered by any kind of channel message (e.g. if you're making an auto-kick on swear script, but people keep getting around it with /me, /notice, /ctcp because plain TEXT dosen't catch them) you need 4 seperate triggers:


It's annoying that you need all 4 of them, especially if the code for them is very long. So I think there should be another kind of event, that will catch all 4, called CHANMSG, so all you need is "on *:CHANMSG:*:#:"

You can do something like:

I would use signal so that you could trigger more than just one script


Event = $1, Full Address = $2, Channel Name = $3 & Text = $4-

Sending first the event, so you can respond in same format if you wish .. $fulladdress of course .. channel name .. and than text

Edit: Just an addition since this is in the feature suggestion section, I thought it would be cool to have local signal like you can with alias, so SIGNAL events of the same name in different scripts won't be triggered.

The -l switch in the command would make it signal only to the same script.

The & on the event would make it only listen for signal from the same script.

Anyway, just an idea I've always thought would be cool.

I actually think that an on *:CHANMSG:#:{ } event would be brilliant.

Using signals and so forth is fine enough, but I would have to say, having an on CHANMSG event is brilliant :P

of course, it should only take actions, notices, text messages, and ctcp events that affect the whole channel :P

Well that's what he meant .. any messages sent to the channel .. I didn't mean the event wasn't needed .. because it would be great to have as long as the $event identifier is filled with the appropriate event .. I was just showing a better way (imo) to do it than with an alias, that's why my reply was to MonoSex and not Ashkrynt.

What about a "fall through" mechanism? For example:

ON *:ACTION:*:#:
ON *:TEXT:*:#:{
.echo this triggers on both action and text, this one was a $event
}

Meaning if there is nothing specified for the particular event, and the next line is the definition of another event, it would use that event's code. I'm sure something like that could be useful in other situations where you don't want to duplicate code.

Maybe that's not such a bad thought, except with a suffix (similar to !), rather than nothing.

ON *:ACTION:*:#:&
ON *:TEXT:*:#:{
.echo this triggers on both action and text, this one was a $event
}

Wouldn't an or suffix be better in this case?

on *:ACTION || TEXT:#:{ } (would make it on an action or text.)

Well, the "!" suffix halts processing and is used at the end of the line, (e.g. "on *:text:*:#:!"), not halfway through it.
"&" was just a thought inspired by $&

Thats why I was suggesting an "or" switch to join them into the one on statement to process both of them.


ie,

on *:ACTION || TEXT:#:{
do stuff
}

would run for either text or action.

But that doesn't work as well as putting it at the end. What if I want it to trigger on an action that matches *foo* and on a text that matches *bar*, with your || method, I can't do that, with what Nimue suggested, I can.

on *:ACTION || TEXT:*foo*:#:{
do stuff
}

triggers for either an action or a text event matching foo.


Why on earth you'd then need it to process on action AND text, when the OR statement will tell it to look for text IN EITHER of those on statements, is something I'm trying to comprehend.

You didn't listen, I want it to match an ACTION of *foo* OR a TEXT of *bar*, the match text is NOT the same for both of them.

Ah... so you did.


I can see your point.

I like codemastr's "fall through" suggestion, and Nimue's implementation of it. The reason I like it better than || separation is for two reasons. 1, it looks better with a & suffex, and 2. it allows you to use different prefixes, levels, match text, and *#?=!@s (no, not sh[b][/b]its :tongue:).

- Raccoon

My two cents:
Codemastr's suggestion, although having more scope, would be less practical than neophyte's suggestion which would, in most cases (I think), be the most easily scripted and serves the very purpose of the change in mIRC better. (to simplify the process).

Codemastr's suggestion just saves someone from the "signal" workaround.
compare the following ("commands" was turned into that "big long mess of commands" for more realistic examples):
The 'normal' way to do it:

The current workaround:

The possible future way to do it:

the second possible future way to do it:


If only one suggestion will be implimented, neophyte's should be, because the 'signal' workaround is just as good as Codemastr's suggestion (in terms of functionality), but is very very sloppy and slightly harder to use. Also keep in mind that Codemastr's suggestion is deceptively small and simple because it only has *'s in the info fields. Put real info in those fields, and you'll get a sense of the monotony when coding several instances using his method.

If both suggestions could be implimented though, it'd be nice to see both implimented, to allow for full functionality at half the typing, or basic functionality at the minimal amount of typing.

A suggestion of my own stemming from Codemastr's:
I think Codemastr's way of combining the separate events could be applied to other events as well to simplify the process of using multiple events to run code.

I like codemastr's suggestion because you could have different prefix, match text, user level & such for each event if you wanted ... the other would be cool but it would force you to have same for all four .. just my 3 cents

The signal suggestion isn't nearly as good as mine. Signals are slower. You are triggering an event, then from that, you call an identifier, which in turn triggers another event. Using the & notation, you are not doing this, you trigger one event, nothing more. Thats gonna be faster. And in any case, the || idea could just as easily be implemented with signals. In fact, the code you included to show that the & idea is stupid will also emulate the || idea 100%.

Thats what I was suggesting, it would allow you to "chain" any events together, not specific to text/ctcp/action.

I actually think that both are good.


If you wanted a simple, no mess on event, that didn't need to match certain criteria, an on *:ACTION || TEXT || NOTICE:*#:{ } event would run fine, but then, if you needed it to match certain text, perhaps something like this:


on *:ACTION || TEXT || NOTICE:*#:{
if ($TEXT iswm texttomatch) { do this }
if ($ACTION iswm texttomatch) { do this }
if ($NOTICE iswm texttomatch) { do this }
}

however, that could get rather nasty if you needed to match long strings of text. But I guess by that stage, you would have it stored in a hash table, and be using $hfind.
The only other thing that would needed to happen, would the $TEXT, $ACTION, $NOTICE, in the if statements would then need to be implemented within mIRC so that they could be called properlly, and understood.

However, codemastrs suggestion is a good work around, but it would get just as messy.

Or the other alternative is: on *:CHANMSG:*:#:{ }

ie:

on *:CHANMSG:*:#:{
if (texttomatch isin $1-) { do this }
(or this:)
if (texttomatch iswm $1-) { do this }
}

and you could then apply all the proper prefixes to the on statement.