Every Mac client I've used since the beginning of time will auto fetch every user's address in a channel. They all do it the same way. Sending 5 /userhost commands, each /userhost command specifying five nicks too look up. 30 second wait between each set of 25 nick look ups, and once the entire channel has been checked, it waits 300 seconds and then starts again (for obtaining both away and oper status).

My script does this... but really... I think it's time mIRC does the work.

Most features in mIRC are designed to be network resource-friendly. In this particular case, since the large majority of users don't need the IAL to be filled, making mIRC do this automatically would be a waste of IRC network resources. Many users join channels and idle for extended periods of time, and such an automated feature would end up being the reason for much of their network resource usage. This is why the scripting language supports the IAL, to allow those who need it to use it.

Maybe have an opinion that allows one to turn the updating of IAL on and off? This way people that idle can leave it deactivated, and others can activate it as needed.

Try doing a /who $chan whenever you join a room, instead of doing so many /userhost commands. I've always used that to fill my IAL. Granted, if you're in a very large room it may slow things down if you're doing extra processing like storing away status or something.

Said option would be just as good as a simple one line script:

that should be

Hi,

fyi, doing userhost results in a server-notice if the user if an oper hat has enabled a special umode (normally +W). So I'd warn such a user and kill them if they do not stop using this kind of scripts.

I kind of fail to see why you would kill someone who does a simple /who(is) (I can't remember /userhost also throwing that server notice)

not like there is any harm in doing that. and since it doesn't have a high impact on the server if only a few people do it (since it's not a default feature), why make a problem out of it?

I'm an admin and have that mode turned on mostly to check on bots who /who(is) and /ctcp version. never went loose on a regular user doing it.

Then you should either set -W or have your privileges revoked. I can't imagine anyone disallowing users from checking the userhost of another user just because it inconveniences some oper who chose to have every userhost notice flood shown to them. God forbid your buffer should be flooded due to a reasonable usage by a regular IRC user.

Out of interest, does mIRC auto-fill the IAL if n!u@h is displayed in /names?

No it doesn't... just throws a server notice on /whois... not on /userhost. Listen... these Mac clients don't have the option to disable it, neither does my script. I've NEVER EVER EVER have been notified by sending /userhost commands repeatedly. EVER.

And DO NOT USE /WHO <channel> to fill the IAL. /userhost is far more efficient. Using /userhost uses 1/5th the bandwidth versus /who... and you can control the I/O rate.

Seriously... just try using /who <channel> on a channel with many hundreds of users. You'll be disconnected by the server. The whole reason why I would like mIRC to send /userhost commands automatically is to stop people from using /who <channel>. And no, using /userhost in moderation does not put excessive stress on the server. I've connected at 2400bps using the /userhost technique, it's not even noticable at that low speed.

It does.

I've seen it done for /userhost too. It was probably Unreal.

~ Edit ~

How do you figure that using /userhost instead of /who uses 1/5 the bandwidth? If you join a channel of 100 users and send a /who request, that's just 1 request with 100 replies. If you use /userhost that would be 100 requests with 100 replies. I don't think mIRC should auto fill the IAL at all, it's just not important enough to have ALL of the addresses as soon as you join the channel. The average user would not need the addresses at all, let alone get them automatically as soon as they join the channel. The more advanced user can script it.



I do it several times daily and don't get disconnected.

Nor do I.. "max sendQ" may vary from ircd config to ircd config, like some networks may dislike *mass* userhost requests. And that's exactly why it shouldn't be a default setting or a quick checkbox, besides the important reasons already stated, especially with regard to There *may* be situations/scripts that need a complete ial as soon as possible (or an updated ial) - and you can scipt it for these purposes.

Servers don't disconnect you based on how much information they send to you, they disconnect you based on how much you send to them (if you ignore SendQ which I've only ever seen surpassed through /LIST). Sending 5 /who #channel commands in 3 seconds is still only equivalent to sending 5 commands to the server in 3 seconds.. if you think about it, it's not much. I'ved typed faster than that without problems.

What the server sends back is not part of what can flood you off, otherwise PRIVMSG floods would make it extremely easy to disconnect any user. The server will, however, throttle your connection and probably lag you a bit, but you can always put your /who commands in separate timer events to compensate for lag if you join multiple channels on connect. One single who command is unlikely to lag you let alone drop your connection even if the channel had > 300 users in it. I've never seen that happen. You're probably referring to sending multiple who commands successively for large channels, which is your fault as the scripter.

Yes they do, yes it is, yes privmsg floods do disconnect users, and yes a single /who can also cause such a disconnection on big channels and servers with restrictive sendq settings. There are still more than a few of those.

Doing /who on join should never be done by mIRC. The solution used by all of MeStinkBAD's mac clients isn't bad, but since most mIRC users don't need it anyway, why not just leave this up to a script? I think the status quo is fine.

s/"don't"/"shouldn't"/.

Because you get up to five users per line... here is an actual example...



Listen... Ircle has ALWAYS done this. As does just about every Mac client.

Ok so it's 20 requests for 100 replies for for a 100 user channel, it's still not 1/5 the badwidth of a single /who request at 1 request for 100 replies. I agree with Sat that it's fine the way it is and mIRC should not do it automatically. Having all the addresses in the IAL just isn't that improtant to the average user, not to mention that it isn't "network resource-friendly" as Khaled put it earlier in this thread. The are some things that should just be left to script. I don't care what ircle does, or any other client for that matter.

Khaled, /userhost, as you know, returns one line back for each one sent. So, the only way it would be resource intensive is if the client didn't throttle it's output. mIRC uses /userhost for commands such as /ban and /dns when that user is not in the IAL. Perhaps you should explain why you choose /userhost vs. /who. I don't think anyone else here has any idea what the intent of the /userhost command is. It probably is the most network-resource friendly command used by IRC servers. Honestly it's about as resource intensive as using the /ison command for checking the notify list on legacy servers.

Listen Khaled, if you know a more effecient way of obtaining the information for a complete IAL, I would like to here it. Honestly, why have an IAL if mIRC can't fill it on it's own? People can script there own IAL's too.

Listen, this feature could be enabled or disabled the same way you could originally enable or disable the IAL. Leave it disabled by default. You would might be surprised how many people actually enable it and *like* this feature.

I'd also like to see this implemented. Have a simple check box and possibly some kind of throttle if that's needed. Make sure the basic version of Mirc has it unchecked. Those that need it and know how to use it can check the box.

Honestly, I doubt if more than 5% of the people would check the box. And those 5% are the ones who are using /who $chan when they join anyway.

Sure about that?
Suppose mIRC does request the addresses of the existing people in the joined channels.
It means a script has to wait for all received before being sure to have the address available.
Does this make life easier for scripters?

It still can't be done in the same processing cycle.
They still need to split the code up as is the case now.

The most occurring IAL related problem that I see is that scripters try to scram it all together in one code which doesn't work if mIRC has to request the used data from the IRC server.

Suppose mIRC does auto-request it upon own join.
Can we tell them now that they can do that?
No.
Because the chance is there that it isn't present yet.
And they're not gonna accept that it 'sometimes' fails.
I wouldn't too.
What's the gain of this feature then?

I still don't understand what you think the benefit is for most users. Having the IAL filled is useless for the vast majority of people who just use mIRC for chatting and don't script. For scripters, 90% of the time when they believe they need the IAL they can actually use $fulladdress and other event identifiers which provide the relevant information when it's most often needed so an auto-filled IAL is redundant. Even when it is needed, as RRX pointed out mIRC still cannot guarantee that the IAL will be filled at any given moment so it doesn't make anything simpler for the scripter - they must still be able to write code that can put in an immediate userhost query (waiting for mIRC to query it itself could be a long time depending on the channel size and where it is in the list) and then write code to do something with the response. Nothing is gained.

As for a continuously updated IAL, I don't really see what users get from that anyway. Knowing which users have IRCOp status is beyond useless, the only thing I can see anyone using that for is trolls knowing when they should behave and when they think the can get away with murder. Knowing the away status of every user on every channel is also, generally, useless (especially when it will only be accurate to the nearest 5-20 minutes). Even when you're speaking in the channel it really doesn't matter what 90% of the users are doing, you'll only ever really be speaking to a handful of users at any one time. For PMs obviously the server will tell you if someone is away, anywhere else the user can append [AWAY] or something to their nick if they think their status is really that important that everyone should know it. The network usage doesn't justify the very limited usefulness IMO.

Even the ISON system for notify lists - which is a great deal less network intensive, is widely considered poor and many networks have dropped the challenge-response method in favour of WATCH lists which allow servers to provide the updates as and when they happen instead of requiring a constant barrage of "are they online yet?" queries from every client. If the away status of users is so important to you you should be bugging IRCd developers about developing some kind of WATCHSTATUS that would have the servers sending a raw for status updates of users sharing channels (or perhaps just ones the user has asked to track - just like WATCH does). Asking mIRC to half-ass a feature on the client-side with an awful implementation method is the wrong way this feature should come about.

Because we don't agree with you? lol you're killin' me.