Forums Feature Suggestions modes +e and +I

I'd like to suggest some identifiers are implemented in future versions of mirc for handling masks referred to by +e and +I, as they've recently been introduced in DALnets bahamut ircD.
These modes are exception type masks which bypass for example...
+e +e stands for except which excepts users from the channel who match a hostmask in the banlist allowing them to join. When a hostmask is set in the except list,the mode +e overrides the ban on the user that matches the hostmask.
+I +I lets people join channels if they match a +I mask, overriding channel modes +k, +i, and even +l.
If there was something like $banmask and $ibl($chan,0), which we could use to script the processing of these modes, I would greatly appreciate it.

If I am not mistaken, mIRC already supports the exception list (+e). In a channel, type /channel and click on the 2nd button from top to bottom, on your right. You'll then see the exception list.

Don't know anything about the +I mode though.

Zyzzyx

/channel has them

true /channel does offer a gui for managing these modes, but my meaning is more geared toward scripting in remotes (events) to react accordingly. for instance, the "on ban" event...and we can use $banmask in there, i'd like to see something made for like "on exception" and similar for the +I too, so we can use remotes to code for this.

+e and +I have been working on ircnet for a long time now, and mIRC suport it just fine.. and i can only guess that Khaled dont have time to keep up with all new modes, on quakenet you have many channel flags and they arent even listed in mirc's *.hlp.. so if a ircd use more flags, then i supose we just have to live with the /command..
*i know I and e arent channel flags, took them just as an example*..

Unreal ircd is said to support invite list but /mode # +i wont send you it i send an email to them but they never replied (

Separate from the suggestion, but have you tried /mode #channel I? Modes are case sensitive. Also, you must be opped to retrieve it on most (if not all) IRCds that support it, same for +e.

Regards,

You do not have to be op to retrieve any channel list (b, e, or I), you don't even need to be in the channel.

It depends on the IRCd. Some prevent non-ops from getting those lists as a method of reducing ban-evasion and the like.

As for the original suggestion; I think mIRC should provide a generic 'internal list' identifier for all type A modes. Something like $ilist(channel, mode-char, N).

The lists for +e,+I,and +b can be retrieved by typing /mode #name +e for example, and managed manually using the channel dialog mirc provides us with when we type /channel and then click on the corresponding button for each aspect (excepts,invites,bans), but what i'd like to have the ability to do would be to reference the actual event. For example, there are many ways to reference a +b which has been set. You could /mode #name +b and the server will send your script the raws,which you could then process automatically via remotes. there's an "on ban" event we can use for scripting, and identifiers such as $ibl($chan,number) and $banmask. For when someone is opped, we can use the "on op" event, and identifiers such as $opnick and $opnick($chan,number). the reason that i feel we should have events to go along with the exception and invite is because each mode references a specific mask. We have identifiers for channel modes such as, just for example, +k and +l ( $chan(#name).limit and $chan(#name).key ) and they're very cool and functional, both triggered by the "on mode" event. We're able to use the "on topic" event and reference it in remotes using $chan(#name).topic. I'd like to see something in coming versions along the lines of the "on ban" event and its corresponding identifiers, but applicable to the +e and +I.

Well as far as events goes you've got on rawmode, which is admittedly a bit awkward to parse, but there's a bit of code here you can use to simplify accessing those mode changes.

I don't think there should be specific events for those modes because they're non-standard and could easily have different meanings on other IRCds. Better access to modes in on rawmode events (which I've suggested previously) and a generic internal list identifier like I mentioned above should provide everything we need.

I recently made a snippet of code which emulates $ibl to create $iel and $iIl (and further customisation for future modes). You can find it here. I hope it helps somewhat.