mIRC Home    About    Download    Register    News    Help

Print Thread
Idea for a way to support +eI and the like. #39322 02/08/03 06:15 PM
Joined: Dec 2002
Posts: 2,809
C
codemastr Offline OP
Hoopy frood
OP Offline
Hoopy frood
C
Joined: Dec 2002
Posts: 2,809
mIRC has ON BAN and ON UNBAN, which are very useful, however they only apply to +b. What I'm thinking is a new event. ON LISTMODE, ON UNLISTMODE (yeah I know the names suck, if someone has a better idea for the names, then just say it smile)

ON *:LISTMODE:#channel:letter:{
commands
}

ON *:LISTMODE:#channel:e:{
.echo -a +e was just set on $mask
}

This is better than doing ON EXCEPT/ON CHINVITE or something like that, because this will work for other modes as well. If some server out there has a +J list, LISTMODE will support it. I'd also like to see the IBL redesigned to work with this system as well. I (and others) in the past have suggested things like $iel, and $iil for +eI, but that still suffers from the same problem if a server has +J. The solution is a mode independant address list.

[Internal Mode List]
$iml(#channel,1,b) that would be the same as
$ibl(#channel,1)

The advantage is that it now works for other modes as well, $iml(#channel, 0, e) - returns the total number of ban exceptions.

I think this could prove very useful as a way to allow all "list type" modes to be supported by mIRC scripts without having to play with ON RAWMODE.

Re: Idea for a way to support +eI and the like. #39323 15/08/03 02:07 PM
Joined: Dec 2002
Posts: 169
J
Jerk Offline
Vogon poet
Offline
Vogon poet
J
Joined: Dec 2002
Posts: 169
It's a good idea. It will allow future listable modes to be added easily. Only drawback is that mIRC won't know the raws for filling up a new list (for using an internal list). It would have been much easier had developers simply made one new set of numerics to support additional modes rather than use numerics for each list. Such as:

### <channel> <modeid> <timestamp> <modeletter>
### <channel> <modeletter> :End of mode list.

Then again there is still a problem. How would mIRC know if the mode is seeable to non-ops. If a mode is like that then mIRC needs to wipe out an internal list when you get deopped. Is it too late to have a fifth chanmode token? Hmm, I wonder what the current version of mIRC would do if it got more tokens than it should? Anyway, ON LISTMODE wouldnt have to worry about it, just $iml()