Forums Bug Reports Dont join in +#chan shown in whois

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.




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?

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.

I solved this way


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.

I tested it on 4 different networks, and I didn't detect this problem

probably arent the same prefix for both nicknames and channel names.

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

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

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.

thanks for the clarification

it could be an inelegant solution but thanks to my friend Filippo "Zecca" we solved the problem like this:



Thanks again

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 #



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))) }

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


on Undernet


mirc 7.74

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.

me too, clean mIRC, no scripts.

I tested it on the UnderNet network with a clean install of mIRC version 7.75 and it works

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.