Forums Bug Reports Invite message not able to be halted

I've only noticed this on the Rizon network and mIRC 7.52 but I'm getting an invite message from chanserv that I cannot halt or block. This is happening on a fresh install of 7.52.

When I'm in an invite only channel and another user joins I receive a chanserv invite message in the server window which is something new.

This is the message I receive in a debug window
<- :ChanServ!service@rizon.net INVITE nick #chan

I've tried the following events to capture this and only the raw event catches it.

on ^*:invite:*:echo -s on invite: $1-
raw invite:*: { echo -s raw invite: $1- | halt }

The text that appears in the server window is below.

[17:51:17] ChanServ has invited nick to #chan
-
raw invite: nick #chan

Correct me if I'm wrong but most raw events fire before echoing to windows and allow the output to be halted. So it seems like this format of invite message is not being handled like other similar messages.

mIRC didn't expect a third-party invite command like this where the target is not you. But you have 2 options.

1) Go into your channel's ChanServ settings and disable these notifications. Ask on a network's help channel if you can't find the specific option yourself.

2) On PARSELINE events supersede RAW events, and will have a 100% effectiveness. You just have a greater potential to break functionality if you're not careful.

Ok so the root of the message is the chan mode +p. But mIRC 7.52 is showing different raw messages than 7.47. So there is change in behavior somewhere between 7.47 and 7.52, I do not have any in between versions to check futher. This is the same fresh install clean settings just switching between two versions of mIRC.

It would seem that Khaled added CAP support for invite notifications, but perhaps did not [yet] add readiness for this behavior to trigger the On Invite event.

Reasonably, invite notifications do not trigger the On Invite event, because most scripts are used to that event only firing for invites directed at the user and not a third party. I don't know what a good proposal is.

Maybe Khaled can figure out a way to let the RAW event handle all events, even if they're already bound to an On Event handler. Thereby RAW INVITE would handle all invite notifications that On INVITE do not.

In the mean time, you can use On PARSELINE as previously suggested.

I could also recommend this following script, but it won't work on Rizon because their IRCd doesn't allow removing CAPapabilities after they've been enabled, as most other ircds would allow.



So, instead, you'll have to intercept mIRC's initial REQ that gets sent out upon connect, again, using On PARSELINE.

Thanks for your bug report. I was able to reproduce this issue.


Raw events were originally intended to handle numeric events - they trigger only before text is displayed in a numeric event, allowing you to halt the text.

Named events trigger before (using the ^ prefix) and after text is displayed, allowing you to halt the text.

In order to handle unknown named events, raw was extended to handle named events as well. However, this was implemented differently for different events:

1) With older unknown named events, raw triggers once before displayed text, like an numeric event, allowing you to halt it. This applies to ircx events: event, knock, prop, whisper.

2) With newer unknown named events, raw triggers before displayed text, allowing you to halt it, and after displayed text - like a named event. If I remember correctly, this is due to scripters wanting access to lists, such as the IAL, before they are updated. So the ^raw event is meant to provide access to these. This applies to new events: invite (as a channel notification), account, away, batch, chghost, authenticate, cap.

Unfortunately, in 2) the ^raw event is not being triggered correctly. This will be fixed in the next beta.

Regarding the older events in 1), I would like to update these so that raw triggers before and after, like 2), for consistency. However, I am not sure whether these events are still widely used or not - if they are, they may need to be kept as is for backwards compatibility.

Following up on my post:

This has turned out to be more complicated than I thought. Some events already have ^raw events enabled but the ^raw processing in the script parser was not enabled because I considered it experimental, so ^raw has never actually triggered in a release/beta version.

I have decided not to enable ^raw because it is not possible to make it work in a consistent way. It cannot be enabled for numeric events - the code is just too complex. It could be enabled for some named events that are specifically handled by mIRC but not for unknown named events which have always been triggered in a specific way.

In the next beta, the raw event for invite (as a channel notification) will trigger before text is displayed, allowing you to halt it. This will make it consistent with how raw events work in general.

Thanks, I'll give it a try when it's out.