$nick().realname would return the real name of the chosen nick, which can be found from raw numerics 311 and 352 iirc.

I really wanted to get the ial auto updated whenever I join a channel or even someone joins. also add several identifiers such as the one you mentioned instead of using raw events all the times to just get the info from someone (i.e. $nick($nick).chans which will return every channels he's on.)

Invision used to do that by default. The problem occurs on really large channels, where you can experience a lot of lag when joining while the IAL is updated. Channels with 300+ people can become troublesome in that situation, which is why Invision has it optional now. Of course, it could just be how Invision did it as I've never looked into it. In either case, I think if mIRC added that, it should be optional unless it can do it without lag when channels are really large (1000+).

The problems with implementing such properties are:

1. the attributes they return are not provided by the server automatically when you join a channel or when a new user joins a channel you're on (the client needs to ask the server that info)
2. when those attributes change, the client is not notified automatically

#1 complicates things as discussed before, ie the client has to /whois each nick already in the channel as well as new nicks that join, which is an obvious problem on large channels. Alternatively, mirc could skip those /whois's and ask the server for that info when it actually needs it. This however causes the problem described later.

#2 means that at any given time your script uses $nick().realname, it cannot be sure that the result will be accurate; the user may have changed that information without you (mirc) being notified. For example, if $nick().chans (mentioned before) were to be accurate at all times, mirc would have to /whois the specified nick behind the scenes and *pause* the script until it gets a reply. This is simply not a viable option under the current architecture of mirc. For $nick().realname, the situation is a little better, as once the information is retrieved, it is guaranteed not to change as long as that user stays on the channel.

Conclusion: $nick() can only support those properties that are readily (ie locally) available and guaranteed to be accurate at all times.

thanks for your replay. I agree to make it optional also has a maximum limit to trigger below that.

Well... technically for real large channels you could do something like

/who <chan> a*
/who <chan> b*
/who <chan> 0*
/who <chan> [*
etc...

Of course you would need to wait a couple of seconds between each /who sent...

Excepting IRCops, users cannot change their realname while connected. So you only need to /who(is) users when you first see them.

I agree with the realname thing, not the chans though
I've always wondered why realname isnt included in $address.

It is as likely to change as your ident (VERY unlikely)
Also, just as with an ident, you need to /who a room *or whois etc* to get it
Technically, With the exception of when a user joins a channel, it would be just as easy to get the realname as the ident.

I think this is a great idea, and could easily return $null if UNKNOWN.
(Just like $ial when mIRC isnt sure of the info)

As Riamus2 pointed out, I did say that about .realname but that paragraph was a bit misleading perhaps; its first sentence should read
"#2 means that at any given time your script uses $nick().someproperty,"
instead of
"#2 means that at any given time your script uses $nick().realname,"
as I was talking in general there.

Some network services allow an ident@host style of vhost, on such networks its quite common for an ident to change. Just a note that on some networks its just as likely for an ident to change without notice, as a mask.

To the user that suggested doing a bunch /who # a* etc, that seems rather inefficient and ultimately a bad idea to me. It would then need to send 40+ individual /who requests, for each channel. A single /who # and dealing with the lag all at once would be better than joining several large channels, and issuing all those seperate /who requests for each channel and experience extended lag issues (pausing and unpausing everytime it recieves a result set).

One the one network I see that used, the server sends a part and a join whenever ident or host is changed.

Let the scripters deal with that.

PS: It would be nice if someone split this thread