mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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 wink

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

Last edited by Raccoon; 20/02/17 07:04 PM.

Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
/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.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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.

Code:
if ($chan(%chan).status != joined) { return *** We are not joined to %chan ! }
if ($chan(%chan).ial == $true) { return *** %chan 's IAL is already up to date! }
if ($nick(%chan,0) == $ialchan(*,#,0)) { return *** Weird... %chan 's IAL is already up to date, right? }
if ($chan(%chan).inwho == $true) { return *** We are in the middle of an IAL fill right now! }


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? ]]

Code:
On me:*:JOIN:#: ialfill $chan
On *:OP:#: if ($opnick == $me) ialfill -b $chan


Well. At least I won lunch.
Good philosophy, see good in bad, I like!

Link Copied to Clipboard