Please note that if you're executing chanlist after a part or sign bind, the gone user will still be listed, so you can check for wasop, isop, etc.
Taken from Eggdrop TCL Commands file. I dont think this would be a common thing on small channels, only for large channels. Would doing a foreach loop with 'onchan' to creat a new channel list be the best way to avoid this
Please note that if you're executing chanlist after a part or sign bind, the gone user will still be listed, so you can check for wasop, isop, etc.
Taken from Eggdrop TCL Commands file. I dont think this would be a common thing on small channels, only for large channels. Would doing a foreach loop with 'onchan' to creat a new channel list be the best way to avoid this
Why would you need a second list? Are you storing this as a file or something? Wouldn't it just be easier, and more efficient just to use continue?
foreach member [chanlist $chan] {
if {![onchan $member $chan]} { continue }
# do more stuff down here, the user is _actually_ present
}
What do you mean by this statement: "I dont think this would be a common thing on small channels, only for large channels." ??! It has the same bearing on small channels as large channels. What it means is that if you have a procedure bound, to sign/part and within that procedure use the [chanlist $chan]. That user who triggered the bind on sign/part is still going to be listed in the chanlist until the part/sign procedure ends. At which point housekeeping takes place and *poof* they disappear from the chanlist. Their nick will still be passed as usual as one of the arguments of the sign/part as well. It is only during sign/part procedures that this is going to be an issue and it adopts this behavior so it's still possible to tell what mode that person had on irc prior to their depature.
question about why i said the "common on small channels". If its a small channel there wouldn't be that many sign/parts so the [chanlist $chan] wouldn't contain as many (or any for that matter) as a large channel would with alot of sign/parts leaving more chance of getting a [chanlist $chan] with alot of nickname's that are no longer pressant on the channel
TCL_no_TK wrote: question about why i said the "common on small channels". If its a small channel there wouldn't be that many sign/parts so the [chanlist $chan] wouldn't contain as many (or any for that matter) as a large channel would with alot of sign/parts leaving more chance of getting a [chanlist $chan] with alot of nickname's that are no longer pressant on the channel
You do realize this thinking is incorrect right? The [chanlist $chan] list would have only _ONE_ nickname in it that has parted/quit, and that would be the nickname which triggered the bind to sign/part. This would only occur inside the procedure which is invoked from the sign/part and after this procedure ends the normal housekeeping eggdrop does would remove this _ONE_ person from the chanlist afterwards. There is no possibility alot of nicknames not present would occur.
This happens because of how eggdrop handles binds and events. Any tcl script bound will be executed _before_ eggdrop's normal routines will react on the same event. This is so that eggdrop's housekeeping duties do not interfere/remove elements which might be needed within the bound tcl script. Hopefully you get the jist of what I'm saying. If not might need nml375 to re-word what I've said so it's more understandable.
Another approach, most suitable if you need the list of channel members rather than performing an action on each still-present channel member would be to use the nick (which is available from the binding...) to lsearch the list and then just lreplace it.
However, I'd say the continue-approach would be most suitable if you need to run a foreach loop on all the still-present nicknames..
Ganondorf,
That is because the part-binding is triggered before the nickname has been removed from the internal channel-members list.
If you'd like to exclude the parting nick from the iteration, you could either use lsearch/lreplace to remove the nick manually, or compare each item during the iteration to see if it matches the parting nickname.