mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
I'm handling the nicklist myself when joining a channel (after waiting for raw 366). When I join a channel, I clear the nicklist with /parseline via a raw 353 injection, so far so good. I then try to populate the nicklist by myself but when I try to inject my own nickname via a basic JOIN message using /parseline, mIRC doesn't display my nickname in the nicklist, it works for any nick value different from $me.
Is there any good reason for this, or is it a bug?

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Only Khaled can explain this handling of own JOIN messages affecting the nicklist. It may help if you shared the exact command(s) that you used, and indicate whether the address information matched or not.

If you do not need to see the fake Join messages in the channel buffer, then you ought to send yourself a fake NAMES reply instead. This will allow you to populate the nicklist with a single command.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
There is a lot going on in the code for events like join and nick, so providing details on what it does would be difficult. If you are trying to manipulate the nick list in the same event as the nick list is being updated, it may simply be a timing issue. If you delay your own processing with a /timer until after the event has been processed, does it work then? If not, we would need to see a minimum script example, that is as small as possible, that reproduces the issue.

Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
In the script, I'm waiting for the raw 366 as I already mentioned.
But to test it, you can just execute /parseline from the mIRC's editbox, so that's not related to mIRC being in an nicklist-update event, where using a timer is irrelevant.
Quote:
If not, we would need to see a minimum script example, that is as small as possible, that reproduces the issue.
Yes sorry I forgot to give that, but any /parseline which is doing what I said would work really.

So if I'm connected to roubaix.fr.epiknet.org with the full address kiikuchi!~kiikuchi@1FDC720B.CBCD66EF.872EC2FC.IP and I'm on channel #t, the following will empty the nicklist:

Code:
//.parseline -iqt :roubaix.fr.epiknet.org 353 kiikuchi = #t :

and then to try to repopulate the nicklist with the nickname kiikuchi:

Code:
//parseline -itq :kiikuchi!~kiikuchi@1FDC720B.CBCD66EF.872EC2FC.IP JOIN :#t



Something I noticed: emptying the nicklist removes my address from the IAL, but mIRC still show a hand when hovering my nickname in the channel

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
If you have already joined the channel, why do you expect a second join message of yourself (which is obviously a massive violation of the IRC protocol) to have any effect? Whatever it is that you're actually trying to do: you're doing it wrong.


Saturn, QuakeNet staff
Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Self-joining a channel.
Code:
//.parseline -itq : $+ $ial($me) JOIN : $+ $chan

Blanking the nicklist.
Code:
//.parseline -itq : $+ $server 353 $me = $chan :
//.parseline -itq : $+ $server 366 $me $chan :End of /NAMES

Adding your name to the nicklist.
Code:
//.parseline -itq : $+ $server 353 $me = $chan : $+ $me
//.parseline -itq : $+ $server 366 $me $chan :End of /NAMES


This just appears to be a client behavior. mIRC doesn't add your own name to the nicklist when you join a channel because it expects to find it in the NAMES listing, and it doesn't want you to think you are alone in the channel as you await the NAMES listing. Other people's names are added to the nicklist on JOIN because this happens after NAMES has already been received.

mIRC seems to know when YOU join a channel, so that it can make the channel active and bring it to the foreground. Sending the above JOIN parseline command makes mIRC pop the channel into the foreground. (I personally dislike this behavior, and wish mIRC didn't bring self-joined channels to the foreground as this induces flicker spam on reconnect.)


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Right, after looking into this I remember why I was concerned about /parseline when I first added it to mIRC. This is actually a good example of why /parseline can be tricky to use. The /parseline command simulates server events. mIRC expects server events to arrive in a specific order and format. If a scripter uses /parseline in a way that does not match the expected order and format of events, mIRC will not behave the way you expect.

Does a server normally send an empty nicknames list to the client while it is joined to a channel? Not that I am aware of.

As a scripter, you will need to mimick event formats and their order as closely as possible. It is not enough to think "an empty numeric 353 will clear the nicknames list". There are all manner of internal flags that track events, eg. keeping a channel window open during a disconnect/part/hop for an automatic rejoin will result in the next JOIN adding your nickname to the nicknames list. But it does not do that if the channel window is open and another JOIN is received for no reason. While I could change this particular behaviour, there are numerous similar behaviours.


Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
Right, the context here is twitch, I get the nicklist for a channel from the web, which indicates who are op/halfop etc, and it also indicates that for my own nickname, which is why I was trying to remove my own nickname from the nicklist, to then re-add it (this was all just me toying around, I was unsure where my problem was at some points and thought I had to inject the JOIN event, eventually I realized I could/should just be using the raw 353, but still the behavior seemed weird, one could assume that since /parseline was added, mIRC would actually handle this fine.

I should be simulating the PART event for all those nicknames which are present on the channel when I'm about to empty the nicklist, but the issues is that I'm dealing with 30000+ nicklist users, and simulating 30000 JOIN messages is super slow (and the idea is to refresh the nicklist from the web on a 20s timer basis or so), whereas using the raw 353 to inject nickname into the nicklist is pretty fast.

Quote:
While I could change this particular behaviour, there are numerous similar behaviours.
I agree that for now nothing should be changed, I'll keep playing around with this and see if it can be made without in a decent (not too slow) way.

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Unless something has changed recently. The twitch api endpoint for chatters* returns the same batched list of users as is given with the batched IRC events. After 30s or so of sitting in the IRC channel mIRC's nicklist should reflect that given by the api. This is why I scrapped handling the nicklist with my mTwitch scripts.

*: Also of note is that twitch stops preparing event batches for non channel-mods once a channel reaches 3k chatters.

Last edited by FroggieDaFrog; 15/12/17 02:01 PM.

I am SReject
My Stuff
Joined: Jul 2013
Posts: 27
K
kikuchi Offline OP
Ameglian cow
OP Offline
Ameglian cow
K
Joined: Jul 2013
Posts: 27
Quote:
Unless something has changed recently.
It has.
I just made some simulation and simulating 15000 JOIN message with /parseline -q to 'properly' add nickname to the nicklist is just taking ages, it's not viable and note that I was hiding the window and hiding the join event message with on ^*:join + haltdef to speed it up.
Using the raw 353, it's almost immediate, which is why I was toying with it (but I just tested it again to confirm).

I was using JOIN message because I need to simulate a /mode as well and wanted to do it 'properly'.
However, it looks like mIRC understand the NAMESX protocol regardless of the proper handshake with the server regarding it (Twitch does not support NAMESX), so I can add modes that way directly with the raw 353.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Originally Posted By: Khaled
Does a server normally send an empty nicknames list to the client while it is joined to a channel? Not that I am aware of.

Khaled, some IRCDs have a decades old channel mode for "auditorium" channels, where only the ops' nicknames are visible. AFIAK, if there are no ops, then NAMES returns empty. It has always worked.

Originally Posted By: kikuchi
Right, the context here is twitch, I get the nicklist for a channel from the web, which indicates who are op/halfop etc, and it also indicates that for my own nickname, which is why I was trying to remove my own nickname from the nicklist, to then re-add it ...

I should be simulating the PART event for all those nicknames which are present on the channel when I'm about to empty the nicklist

kikuchi, If Twitch already populates the nicklist, then just simulate a series of MODE commands to give the necessary (few) nicknames Ops or Voice status on your screen.

Originally Posted By: Khaled
Right, after looking into this I remember why I was concerned about /parseline when I first added it to mIRC. This is actually a good example of why /parseline can be tricky to use. The /parseline command simulates server events. mIRC expects server events to arrive in a specific order and format. If a scripter uses /parseline in a way that does not match the expected order and format of events, mIRC will not behave the way you expect.

Khaled, We're having a lot of fun debugging mIRC's behaviors with /parseline. It'll certainly prove itself useful in finding and explaining bugs, or managing work-arounds for adhoc IRC implementations like Twitch. Thank you for this feature!


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

Link Copied to Clipboard