mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
Hello,
I am using last version mIRC 7.74 and older but I encountered the same problem:
Channels with +#voice shown in whois cannot be joined.

[Linked Image from i.ibb.co]
[Linked Image from i.ibb.co]

I think the problem lies in the conflict of these modes:

RFC2812 PREFIX=(ov)@+ CHANTYPES=#&!+ CHANLIMIT=#&!+:41
-
These are the IRCnet settings but I think other networks using the same daemon have the same problem.
Is there a way to solve this problem?

Joined: Dec 2002
Posts: 5,463
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,463
Thanks for your bug report. This has indeed been discussed before. There is no way for an IRC client to know the difference in this case because the ircd is using the same prefix for both nicknames and channel names.

Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
I solved this way

Code
On *:PARSELINE:in:& 005 *:{ noop $regsubex(foo,$parseline,/(\sCHANTYPES=\S+)/g,$remove(\t,+),&foo) | .parseline -ib &foo }

but it only works locally, if you use a bouncer (znc) when you reconnect by reopening mirc the problem returns. If you have another solution, thank you.

Joined: Jul 2014
Posts: 324
Pan-dimensional mouse
Online
Pan-dimensional mouse
Joined: Jul 2014
Posts: 324
I tested it on 4 different networks, and I didn't detect this problem


TECO
irc.PTirc.org (Co-Admin)
Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
probably arent the same prefix for both nicknames and channel names.

ex. EFnet: CHANTYPES=&# PREFIX=(ov)@+

instead IRCnet: PREFIX=(ov)@+ CHANTYPES=#&!+

Joined: Dec 2002
Posts: 5,463
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,463
There is no solution to this that I can see. The numeric 005 and CAP settings tell a client how to behave and how to parse messages. If the settings are invalid or create a conflict, there is little the IRC client can do.

In this case, the network is using the same prefix for both channel and nickname modes. Networks return whois replies that contain channel names with the nickname mode prefix (or none at all or in some cases multiple prefixes) that a user has on that channel.

If the network says + is both a channel and nickname mode prefix, and a user has + mode on channel +test, and the /whois reply returns ++test, then ++test could be either nickname mode prefix "+" channel prefix "+" and name "test", or it could be channel prefix "+" and name "+test" (since + is allowed in a channel name). That said, on IRCnet, +channels do not support modes, so a client could hard-code behaviour that says if a network supports a "+" channel prefix, assume that it is modeless and can never have a mode prefix. So "+test" and "++test" would both need to be parsed as full channel names on IRCnet, even if "+" is listed as a nickname mode prefix. But this would only apply to networks where +channels are modeless, which may not be the case on all networks. Currently, CHANTYPES does not support a method of identifying modeless channel prefixes that require special parsing.

On IRCNet, where allowed channel prefixes are CHANTYPES=#&!+ this also means that "+#test" could either be channel name "+#test" or nickname mode prefix "+" and channel name "#test". IRCnet seems to be aware of this issue and blocks you from creating channel name "+#test". IRCnet also blocks you from creating "+!test" (since ! is a channel prefix) but... it allows you to create channel "+&test". Hmmm. So, on IRCnet, a client would need to parse channel names and prefixes in at least three different ways, depending on the mode prefix, the channel prefix, and the context.

One solution to this could be to extend CHANTYPES to CHANTYPES=#&!+:+ where characters listed after the colon are modeless. But this still wouldn't solve the way the "&" channel prefix is handled on IRCnet. We would need to further extend CHANTYPES to CHANTYPES=#&!+:+:& where the first set lists allowed channel prefixes (all of them for backward compatibility), the second set lists modeless channel prefixes, and the third set indicates prefixes whose behaviours are in a state of indeterminate quantum superposition and are generally beyond human comprehension.

Seriously, there are probably good reasons why these prefixes behave the way they do on IRCnet. The IRC protocol has changed in so many ways since IRCnet was created. Unfortunately, the issue of conflicting prefixes is there. Numeric 005 and CAP were intended to resolve issues like this by defining a consistent set of behaviours across IRC networks for basic features, so that IRC clients and servers could communicate more effectively. In this case, CHANTYPES is not sufficiently detailed to handle the ways in which the IRCnet ircd treats different combinations of prefixes.

Update: On second thought, extending CHANTYPES would not be backward compatible at all because most clients probably don't check for a : colon as a separator in this token, so this change would break all existing clients. A new 005 token would need to be created that describes all of the different ways that prefixes might be parsed.

Last edited by Khaled; 28/08/23 10:18 AM.
Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
thanks for the clarification

Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
it could be an inelegant solution but thanks to my friend Filippo "Zecca" we solved the problem like this:

Code
on ^*:hotlink:+#*:*:{ return | halt }
on *:hotlink:*:*:{ join $mid($1,2,$len($1)) | halt }


Thanks again

Last edited by MadWorldz; 28/08/23 02:54 PM.
Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
I have had the same problem for channel # - in this case also on many other networks.
So I implemented this solution in code as well. For both the channel with voice and #

[Linked Image from i.ibb.co]

on ^*:hotlink:*#*:*:{
if ($+(+,$chr(35),*) iswm $1) return
if ($len($1) < 3) && ($+(*,$chr(35)) iswm $1) return
halt
}
on *:hotlink:*#*:*:{ join $iif($len($1) == 1,$1,$mid($1,2,$len($1))) }

Joined: Dec 2002
Posts: 5,463
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,463
Quote
I have had the same problem for channel # - in this case also on many other networks.
I have not been able to reproduce this issue on IRC networks other than those that are using duplicate prefixes in PREFIX/CHANTYPES. Which other IRC networks are you referring to?

Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
Originally Posted by Khaled
Quote
I have had the same problem for channel # - in this case also on many other networks.
I have not been able to reproduce this issue on IRC networks other than those that are using duplicate prefixes in PREFIX/CHANTYPES. Which other IRC networks are you referring to?

on EFnet
[Linked Image from i.ibb.co]

on Undernet
[Linked Image from i.ibb.co]

mirc 7.74

Joined: Dec 2002
Posts: 5,463
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,463
I tested this in a clean install of mIRC, with no scripts, on Efnet and Undernet and it worked fine. What is probably happening is that your script is over-riding the default hotlink behaviour. This means that your script will need to parse PREFIX and CHANPREFIX and handle all of the prefix combinations itself.

Joined: Feb 2022
Posts: 12
M
Pikka bird
OP Offline
Pikka bird
M
Joined: Feb 2022
Posts: 12
me too, clean mIRC, no scripts.

[Linked Image from i.ibb.co]
[Linked Image from i.ibb.co]

Joined: Jul 2014
Posts: 324
Pan-dimensional mouse
Online
Pan-dimensional mouse
Joined: Jul 2014
Posts: 324
Quote
on Undernet
[Linked Image from i.ibb.co]
I tested it on the UnderNet network with a clean install of mIRC version 7.75 and it works


TECO
irc.PTirc.org (Co-Admin)
Joined: Dec 2002
Posts: 5,463
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,463
Quote
me too, clean mIRC, no scripts.
In your example, it looks like this is happening with the single character channel name "#". I am not sure how this relates to the PREFIX/CHANTYPES combination issue you were reporting on IRCnet due to duplicate prefixes.

The behaviour in your last post is intentional for hotlinks due to the fact that, if it wasn't, all single character punctuation marks would be treated as channels, which makes no sense when parsing text. There are no plans to change this behaviour.


Link Copied to Clipboard