Forums Feature Suggestions Channel dialog options based on server

I was thinking it would be kinda cool if mIRC could take raw codes 004 and 005, figure out which types of channel modes, etc. are available, and would add/remove channel modes to the channel options dialog. For instance, there are certain channel modes that are not in the channel options dialog. I know they are patches, but they are very common. Channel modes +cCdr are not found in the dialog. The information in the raw codes say that the server supports these modes.

<- :Slim.NY.US.GamesNET.net 004 KilledInAction Slim.NY.US.GamesNET.net u2.10.11.04 dioswkgx biklmnopstvrDcC bklov
<- :Slim.NY.US.GamesNET.net 005 KilledInAction WHOX WALLCHOPS WALLVOICES USERIP CPRIVMSG CNOTICE SILENCE=15 MODES=6 MAXCHANNELS=20 MAXBANS=45 NICKLEN=30 TOPICLEN=300 AWAYLEN=200 KICKLEN=300 :are supported by this server
<- :Slim.NY.US.GamesNET.net 005 KilledInAction CHANTYPES=#& PREFIX=(ov)@+ CHANMODES=b,k,l,imnpstrDcC CASEMAPPING=rfc1459 NETWORK=GamesNET :are supported by this server

Maybe if it is impossible to put these modes in the dialog or to detect if they are available and put them in, it would possible to add a section to the channel dialog for "Server-Specific Channel Modes". In this, it would just have a listing of all the possible modes (as checkboxes) to set on a channel, without a description of what it does.

I like the idea, however an "automatic" detection system won't work correctly. 004 and 005 only say what modes are available, not what they do. For example, Gamesnet has +r as "only registered nicks may join", DALnet has +r as "this channel is registered". On DALnet, +R is "only registered nicks may join". Gamesnet has +C is "no channel ctcp", ConferenceRoom has +e is "no channel ctcp" and IRCNet has +e "ban exceptions". What each mode letter does is not really defined, it's network specific. The best way I could come up with to make this work can be read at https://forums.mirc.com/showflat.php?Cat=...=true#Post29627 If you can come up with a better way of doing it, feel free to comment.

Thats pretty much why i suggested having a "Server-Specific Channel Modes" section with just the checkboxes and the mode letter, without the description.

No description? That wouldn't be very user friendly.

Khaled already said this was planned for a future version.

I wouldn't expect it soon. codemastr raises a good point about compatability between different brands of IRCd. The only common factor here is the mode letters. Everything else is different depending on where you go and also what version of the IRCd is in use.

Is Khaled going to investigate dozens of popular IRCd's and hundreds of one-off versions just to expand the usefulness of the channel central? I predict not as it would take another year to do so and then just about every network will either have replaced some modes or added new ones or deleted old ones as IRCX functions/properties for both channels and users become more popular.

Making a channel central with scripting is fairly easy though it will take a while if you want everything your server supports included. It's definitely the better option.

Thats why I suggested it be user configurable. Khaled could add built in support for DALnet, Undernet, EFnet, IRCNet, Quakenet, etc., and for the smaller networks, the users can configure it on their own.

That would make mIRC political though. Why should a function deliberately favour large networks? It's bad enough that the Big 4 + Dalnet + Austnet chew up half the server list. I'm not against customisation but if users on small networks should be left to fill in the gaps then all should.

I'm talking about what is convenient for the users, not for network owners. The majority of users use the big networks, therefore it is appropriate to have support for them built in. And to say it's unfair... well thats just the way life is.

I'm talking about what is convenient for the users, not for network owners.

So am I - And indeed I am not only speaking about procedural fairness, I am speaking about the patent stupidity of putting a feature in a programme that is suitable only for users who use four out of hundreds of networks.

As I speak there are 1,307,008 users on IRC (quoted from irc.netsplit.de) and 519,626 on the Big 4. So you arn't even representing 50% of users with your second suggestion. Infact you have a shortfall of around 300,000 who probably don't know or care about the Big 4.

I reiterate that any feature in mIRC should be suitable for all users.

Well I never said "big 4" in fact if you look at my post you will see I listed 5 and added an "etc."

But in any case, your argument makes no sense, I didn't say "This feature will only work on big networks" I said "users of small networks can add the modes through the configuration interface" Should Khaled go to the hundreds of networks and inventory which servers support what modes? And keep in mind many small servers use either software compliant with RFC1459 or the software used by the "big 4" and therefore would be supported as well. But again, I didn't say "this will only work on EFnet" I said EFnet will be configured by default, if the user goes to MyNet instead, then the user can configure it, or download a script from the networks website to automatically configure it. I really don't see why that is so horrible.

Should Khaled go to the hundreds of networks and inventory which servers support what modes?

Not at all. The user-configurability should be able to be added without making it automatic for certain networks. That is what I am trying to get into your head. But you don't want that. You want mIRC to operate one way for some and another way for others. It's your argument that makes no sense here. Wanting mIRC to operate the same way everywhere makes perfect sense to me.

And keep in mind many small servers use either software compliant with RFC1459 or the software used by the "big 4" and therefore would be supported as well.

True and there is alot of servers that do not which is why there's only eight modes supported to begin with, or did you suddenly forget that?

I scripted my own channel central three years ago and included all of the channel modes that apply to the IRCd my network uses (approx 20). It was a time-consuming job but certainly no harder or more technically advanced than scripting any other kind of dialogue. Those I gave the channel central to loved it because they just added the file to mIRC or their script and it worked without any other settings changes. That is what the users want. What they don't want is to have to stuff around making adjustments to anything that someone somewhere else gets loaded without any effort at all by the programme. The big difference here is that mIRC's job is to support all RFC compatible IRCd's - a job it already does well and my channel central is there to support one particular network. In this case both mIRC and addons are doing their intended job.

You are yet to convince me that discriminatory automation will benefit the users of mIRC as a whole and you probably never will.

Thats exactly what I'm suggesting, note the part about "just loading a script." I say not only should it be configurable, it should be scriptable:
/chancentral -a +R You must use a registered nickname to enter
/chancentral -ap +f Flood control
/chancentral -r +R
(-a = add mode, -p = mode takes a param, -r = remove a mode). Then all someone needs to do is a simple ON LOAD script that executes the /chancentral commands and then the user has to do nothing else.


Where does RFC1459 mention halfops? Ban exceptions? Invite lists? It doesn't. The latter two were originally added to mIRC and only functioned on IRCNet, if you used another network that had +eI it didn't work.


Lets face it, mIRC discriminates. As you said, the server list consists of like 60% of the large nets, and the default selection is DALnet. mIRC discriminates in the channel folder by only including channels that Khaled/Tjerk choose, I really don't see how adding this to the equation signifigantly harms anyone. Your main reason against it is it is "unfair" well I reiterate, life is unfair. You are right, it is unfair, however it won't harm the people who use other networks, they can just simply add it themselves, and it will help those who do use those networks. So why is that such a big deal? I really don't see it.

Where does RFC1459 mention halfops? Ban exceptions? Invite lists? It doesn't. The latter two were originally added to mIRC and only functioned on IRCNet, if you used another network that had +eI it didn't work.

Now you are just wandering off the subject. What the hell has Halfops got to do with the channel mode selection on the channel central? Absolutely nothing. :tongue:

You know as well as I do that channel modes applying to nicknames, (EG: +b, +o, +h, +v, +u) RFC compatible or not, are a bit difficult to be represented by checkboxes in the channel central. Even if it was practical why would you bother? It's much easier to manage these with popups.

Here's an example of what I mean:



There is alot of channel modes and once again, I think some user configurability would be good for the standard dialogue but favouring the networks you mentioned (Big 4 + Dalnet) is not fairdinkum.