Forums Bug Reports raw 328 not displayed [7.17]

raw 328, RPL_CHANNEL_URL, is not displayed when set. 328 is in use on bahmaut, AustHex ircd's and any network where services sends 328 to users when they join any channel on any ircd that passes unknown numerics, like unrealircd.

Easiest way to reproduce:
1> log onto dalnet
2> type: /debug @debug debug output to window.
3> join any channel that has a url set in services
4> see 328 sent to client in @debug
5> don't see it in channel during sync

Why is this a bug? mIRC shouldn't display things it isn't programmed to display. Non-standard numerics are part of the things it's not programmed to display. Also known as: this is not a bug, it's simply not implemented because servers that return nonstandard numerics are not fully supported.

If you want to show it, script raw 328:



FWIW, DALNet is the only network that implements this numeric, unless this list is out of date. Sometimes mIRC adds support for WIDELY USED nonstandard numerics, and you can submit a Feature Suggestion for that-- but this is not a widely used numeric. I couldn't even find a channel that used this feature on DALNet, let alone other networks.

Don't be silly. mIRC has always dumped stuff it doesn't know to the status window, and it should do that here too at the very least. Showing it in the channel window is another issue of course, which indeed can be done with a script.


FTFY.

It doesn't dump to status window either.

My turn to say don't be silly, there are countless things that mIRC supports that are "nonstandard" because they only appear in 1 ircd. Unreal's extra operator mode symbols for example. Nothing "standard" about .&%! ChanOp mode symbols and only a few ircds use them. Extended bans are also non-standard and fully displayed in mIRC.

What's standard about this:
* electro.myhidden.net sets mode: +ntfj[5c#C5,8j#R5,15m#M5,3n#N5]:20 4:10

Nothing! Only 1 ircd does it and it's supported and displayed in mIRC.

Additionally, mIRC needs to do this, there are several other numerics that are just as "non-standard" that are getting programed into modern ircds all the time. The bottom line is mIRC needs to display numerics as they are given to the client. Any numeric between 000 and 999 should be considered "standard". Every ircd source code I've ever seen has space for all of them. In use or not is irrelevant.

Bahamut is indeed the only ircd that has 328 used in src/s_err.c, that's true, but many ircds pass on unknown numerics to clients anyway. Unreal, the most widely used ircd, is one of them. It's used on hundreds of networks. Some services packages are modular and can have modules written to add numerics. There is a module for Anope, one of the most popular services packages, that add this ability to mimic DALnet. Rizon, one of the larger networks uses a modified version of Anope services as does SourceryNet and thus there is a very high potential for other "nonsupported" numerics to be added and used by thousands of users on hundreds of networks. I know for a fact that there is more than just DALnet that uses 328.

Half of today's IRC population is on small networks. Most of those networks use an ircd that supports 328, I think that's called "standard". The big 4 aren't the only ones in the world you know.

Both of the things you referenced as non-standard are actually implemented in a standard way: through the 005 numeric. When you connect to a server, you receive a 005 numeric message from the server that tells the IRC client what sorts of modes the server supports. For example, when you connect to a server you will get something like this:



The two portions of this that affect the behavior you referenced in your post are these two values:




You can reference http://www.irc.org/tech_docs/005.html to see what exactly they do, but I trust you can figure it out on your own. The point is that these are actually part of a standard.

Non-standard numerics on the other hand are harder to support because while DALnet has decided to use 328 for a particular purpose, it's possible that another network has used the same numeric for something else. This is why it is a little dangerous to support numerics that are only used in one network and/or ircd. That said, just having any unsupported numeric displayed in the status window wouldn't bother me. How do other IRC clients handle this?

FWIW if it isn't showing up in the status window, it should. I wasn't aware that it was not showing up anywhere. As I mentioned, I could not find a channel with a URL set to test, and I was responding to the bug report's expected/actual action of [not] displaying "in channel".

It should show up in status; it should not show up in channel unless scripted with the above code.

I'm well aware of raw 005 as well as most all the others. Thanks

Point remains, it isn't displaying but should.

Not likely as there are several things wrong with your code.

1> ALWAYS use the -t switch with echo, that way IF timstamp is on, your echo is timestamped as well.

2> $color() returns a numerical value, it does not set the color, you have to do a ctrl+k still. Using the .dd prop is also much better as it returns a 2 digit color to remover any abiguity in the code.

3> $1 is your nick

4> The channel is $2 and should be echo'ed to the channel, otherwise if I have 10 channels in my perform section I'll get all 10 urls in the last channel.

5> The URL is parameter $3 and in keeping with the expected syntax, there is no parameter $4.

6> Lets use haltdef so if/when it does display to status we can halt the default output.




Thanks anyway.

Actually his works just fine. If you look at /echo in the help file, you will see that. Also, there is no need for ctrl+k at all if you use the -c switch with a color name.



I almost always forget that too.

I did look at it and he didn't use the -c switch.

Look at the first parameter for /echo in the help file, and then try it.

My code works as-is and it's not really my intention to sit here and debate scripting preferences.

Back to the topic please, Thanks!

-c isn't necessary to use a numeric as a color with /echo.

To show this:
//echo 5 test

As far as which $N is which, that's easy to get confused because they aren't always in the same order. And considering it was an example, you don't really have to show -t. If that is needed, it's easy to add and if the person doesn't know how, they can always ask.

Re-read my post and you will see that I agree with that.

Ah, I see. I read that differently the first time through. Thanks for pointing it out.

To reiterate: it should display, but in the status window, not the channel. I'd say this is a reasonable compromise. Frankly, I'm not sure why mIRC doesn't pass all events it doesn't understand to the status automatically, but that's partially another issue.

Non-standard numerics should not be implemented by mIRC itself, they should be implemented by scripts for the reasons described above.

You are attempting to "reiterate" something we agree upon, thus making your additional iterations redundant and not needed.

Where we disagree is the definition of "standard".

All i'm say is 328 isn't displayed by mIRC and that is a "bug" .. period.

Support for this numeric and the current behaviour was added many versions ago. The meaning of the numeric varies across networks. If I recall correctly, some users complained about the URL being displayed when joining a channel and suggested that it simply be captured and added to the URLs list, which is the current behaviour.

The "standard" is well defined. "Standard" = IRC RFC 1459 or even 2812. 328 is specified in neither, therefore it is not standard.