About mIRC v5.8+

Try this:

//mode # +b aaa!*@*
--> * _geo_ sets mode: +b aaa!*@*
//mode # +b bbb!*@*
--> * _geo_ sets mode: +b bbb!*@*
//mode # +b ccc!*@*
--> * _geo_ sets mode: +b ccc!*@*
//echo -a $ibl(#,0)
--> 3

Now part and rejoin this channel...

/hop
--> * Attempting to rejoin channel #xxxxxx
--> * Rejoined channel #xxxxxx
//echo -a $ibl(#,0)
--> 0
(not only the 1st time)


So if you want to write an remote like this:

on *:JOIN:#: {
if ($nick == $me) {
var %tmp = 1
while (%tmp <= $ibl(#,0)) {
; check Internal Ban List if you are banned
}
}
}

it has no possibility to work...


Any explanation???

Interesting, this is true......However, here''s how to populate the banlist.

mode #channel +b

And then it will populate and you can use $ibl() for that channel

It's not a bug, mIRC can't know whats in the banlist until it recieves the banlist.

well yeah collective, that's true, but you would think there'd be an option to get the IBL on join just as there is one for IAL.

I think in 5.9x there was a point where it did do this but I think it had some serious issues. Maybe it was 6.x? I forget, but I do remember it.

Anyways, that's all you have to do is type mode #channel +b and it will receive the IBL. No you don't have to be opped for this to work and it will not give an error. In fact, I had figured this out by packet monitoring mIRC when you double click the window It doesn't document this in the help file.

The question for me is whether the banlist should be cleared on /hop or not...

ditto for +I and +e

I think it should be cleared, like it does now. The integrity of those internal lists (IAL, IBL) is more important than any obstacle presented to the scripter (which isn't so terrible anyway).

a /hop is no more then a /part and /join of a channel with which the channel window stays open

after a part it should be cleared, but at a /join it should be refreshed imo

I dont agree....
There are many commands that could be sent on join
Some networks dont display topic/mode information when you join, so they have to be requested... none afaik send ban or /who information... and I'm sure that none send +I/e info...
If bans are going to be retrieved, what about /who to update the IAL? what about /mode +I or /mode +e to retrieve the other lists?

All that adds up to is a LOT of lag right when someone joins a chan and expects to do something (such as request for ops)

To get the banlist on join you can use this code:

How can you join if you're banned?

you can be invited through a ban on ircu (probably on more ircds too)

Or you can be an Oper on server that suppprts banwalk, or you can fit in chmode +e mask, or...
There are many ways to override a ban, depends what type of server you use.

I think it would be nice if mIRC had an option, to update banlist and/or IAL on-join.
It'd probably be better than our scripted versions of it

thats just taking the piss.. how many reasons are necessary?

From the helpfile:

$ibl(#channel,N)
Returns Nth item in the Internal Ban List, or if N is 0 returns total number of items in list.

Propreties: by, date, ctime

$ibl(#mirc,1) returns the first address in the ban list
$ibl(#mirc,1).by returns the address of the user who set the ban
$ibl(#mirc,1).date returns the date when the user set the ban
$ibl(#mirc,1).ctime returns $ctime format for ban date

Note: See $chan() for more information.



Sorry, but nowhere says that I should "take" the ibl alone (or by "mode #chan +b" or by double clicking to the channel's window...:).
I knew what I have to "take" the ibl alone, but for which reason $ibl() command exists?????? Would be bad if mIRC asks for ibl (lists for excepts and invites too)? We know how to solve this problem, but what about other "progremmers" :P?

So, I still believe that this is a bug... :P

How is it a bug? At no point without doing a /mode #channel +b or /channel does mIRC ever retrieve the full banlist, just the same as it does not fill the IAL without /who #channel or whatever. If you don't fill the IBL then the only thing mIRC will know about is any bans that get set/unset while you are in it, just the same as the IAL works when users join/part/quit.

If you look at the "Note:" under $ibl(#channel/N), you will see the "$chan()" is a link. Click it and read the linked $chan() item.
$chan(N/#)
Properties: topic, mode, key, limit, ial, logfile, stamp, ibl, status, inwho, wid, cid, hwnd
....
....
$chan(1).ibl returns $true if mIRC has already seen a /mode +b and has list of bans for the channel, or $inmode if a /mode +b is currently being listed. See the $ibl() identifier for more information.

If $chan(1).ibl != $true it stands to reason that the IBL would not be filled, and therefore that $ibl() wouldn't work.

Yeah, mIRC shouldn't do this by default. Imagine connecting to a server and joining 10 channels each having a full banlist. If your server supports 30 bans, that's 300 ban lines you have to receive before you can start anything else, and getting the nick list of all those channels is bad enough. If you need to know then send out the the /mode +b and use the raw remote to trigger your script instead of on join.

Cheers,
GregMo