Forums Bug Reports New /ialfill command: How does it work?

I'm curious what parameters /ialfill takes. I gather /ialfill [#channel], but are there any other parameters or automatic modes? Eg: /ialfill on, /ialfill off, /ialfill -delay 2000, /ialfill -auto #mirc,#irchelp,#moo

Tested: $chan().inwho -- works correctly even with new WHOX.

Tested: /ialfill will WHO the channel, again, even if ($chan().ial == $true) ; intended behavior perhaps?

Observation: Cannot specify /ialfill #chan1,#chan2,#chan3 in one command, nor /ialfill * or /ialfill all.

The use of %t,NNN is a nice touch for message suppression in the Status Window. But, what would you think about choosing a singularly static NNN, instead of a random one each time, so you don't accidentally trigger other people's scripts that are watching out for their own NNN magic numbers? You could document which NNN mIRC uses for /ialfill and nobody else will use that number.

I notice that mIRC suppresses all WHOX messages that uses %t,NNN from the Status Window, indiscriminately, and not only the ones that /ialfill had issued itself. I wonder if strange combinations of WHOX options that use %t,NNN might also confuse mIRC and mess up the IAL. Another reason /ialfill should use its own unique (never changing) magic number. Maybe "295" for February 1995

Now I can retire my own /ialfill script by the same name!

/ialfill has no other parameters or options. At this point, I would rather make sure it is working correctly in its simplest form across all ircds and may consider adding extensions later on.

Good point about the T parameter. I'll set it to a fixed number.

Yes, WHOX can return different combinations of parameters and there is no way for mIRC to know what they are. mIRC performs multiple checks on the WHOX 354 reply to verify that it is in a format it expects before parsing it as an /ialfill request. As you say, it was hiding the results for any T request - this will be fixed in the next beta.

Hi Khaled,

I've been using /ialfill for a while now, and I think it's quite alright. Though, I haven't been able to give up my own /ialfill script because it still requires a bit of hand-holding for regular use. So, I'm hoping we can add a few extensions to it.

Make /ialfill determine if the IAL really needs to be filled, ignoring subsequent /ialfill commands when they are not needed. Presently I have to perform a lot of if-checks to make this determination myself. Namely $chan() .status, .ial, and .inwho properties.



I also recommend adding a 10 second delay between successive WHO requests issued by a series of multiple /ialfill commands. This way, when a user joins 10 channels and requests On Join /ialfill, those requests are throttled so as not to punt the user off the server or induce a hideous 'synchronization delay' (the initial wait time between connecting and having your first words received by somebody).

I also recommend the switch /ialfill -f to force-fill on demand, ignoring the above sanity checks.

I would also like to request that /ialfill $nick be supported.

I think that's everything.

Nope. Feature creep: Add /ialfill -b $chan or /iblfill $chan to request all of the channel's -beIq ban lists. The same sync checks and 10 second successive delay would also be of great benefit. Issue the command MODE $chan +bq if the user is not opped, and if the server supports +q. Issue the command MODE $chan +bqeI if the user is opped, since +eI are only visible to ops. Don't require the -f switch if the user has become opped since their previous request and the +eI lists are marked as unfilled per $chan() .iel and .iil properties. [[ are these properties marked $true if an empty list is retrieved? ]]