Forums Feature Suggestions A few feature suggestions

I think there should be an event similar to on CONNECTFAIL that triggers when each connection error occurs, rather than only after x amount of retries.

I would also like to see an on FIREWALL event. This event would trigger when there is an error with the firewall you are using. It would also return a $1- as the error message.

Example:




Another feature I'd like to see is a dynamic "Channel Central" dialog that shows the modes based on the type of IRC server you are connected to.

For example, if you are connected to an IRCX server, the "Channel Central" dialog should show modes +u (Knock), etc.

In responce to the first part the firewall that would be nice but maybe not have it so broad more like
on *:FireWallFailed: and FireWalledConnect and disconnect and for the second thing dynamic channel central this has been majoryly debated in the past and it probably wont happen.

I like the channel central suggestion and have been all for
it in the past. Why some wouldn't want this is beyond me,
but it just seems to me that mIRC would just check the
available channel modes on connect and disable on the
channel central dialog those modes that are not available.

The only valid reason I can think of on why they might be against it is because it can be scripted. Now that I think of it, that really isn't much of a valid reason either...

Quote:

that really isn't much of a valid reason either

I agree

who should write this then ? you have almost as many modes as you have ircd's/networks, and it's allot, and i dont think somone want to spend like 1 year write so everyone can use the modes they like to.. bether in that case to have "undefined modes" in the channel dialog. then you can add the modes you want your self.. that way it wouldent take much time for anyone like a Tab with empty modes you have to type in by hand.. then save it to mirc.ini

the major reason was yea it can check 005 for what the modes are but mirc has no way of knowing what they are or what they do, on one network u could be no knocks on another it could be ssl only clients

This would have never been a problem if IRCd developers followed strict protocols and traditional methods of IRC/IRCX...

If a network correctly implements the CHANMODES token from raw 005, then an IRC client can give that mode an appropriate control in the dialog (a listbox for type A modes, an editbox for type B modes, a checkbox and editbox for type C modes, and a checkbox for class D modes). mIRC needn't try and decide what each mode letter stands for, it could simply label each control with the mode letter. They should probably be separated from the standard modes, tabs for 'Standard' and 'Extended' modes could be used, and for servers which return no CHANMODES token the Extended tab can simply be disabled.

Quote:

If a network correctly implements

Well, it seems like they all have to do it different.
Like maybe they do it just to be different and can
call the ircd their own. It's stupid if you ask me.

~ Edit ~
They can call it better ideas all they want, but I
haven't seen any one ircd that was better than
any of the others.

Actually about 90% of IRCds (that I'm aware of) correctly implement the CHANMODES token.

Well what about all the stupid prefixes like ~ and !
I didn't even care for halfop when it first started showing up.
Just another stupid mode IMO. I know this is different than
the channel modes we're discussing, but just as an example.

~ Edit ~
I guess I'm asking, what's to stop one of them from changing
+m to mean something totally different in the future?
Really it won't matter to the client as long as the new meaning
doesn't require a parameter, but still, it seems to me like
it's just to be different.

I'm not talking about IRCds all using the same modes and the same meanings for modes, quite the opposite in fact. I'm talking about the CHANMODES token, which allows IRCds to support differing modes with differing meanings while providing the IRC client with the necessary information to 'support' them itself. By telling the client what modes it uses and what parameters they accept and when, it allows an appropriate dialog control to be displayed for that mode without knowing anything about it.

If an IRCd changed the meaning of a standard mode such as +m then they'd lose all compatability with all IRC clients. They'd have to deal with the complaints from IRC developers and users alike, and probably ultimately any IRC server using such an IRCd would lose users because of it, meaning the server admins would likely switch IRCds. In other words, it won't happen unless an IRCd's developers decide to commit product 'suicide' and destroy all support for their software.

Quote:

commit product 'suicide'

Good point, sorry I misunderstood about the
chanmodes token, yes you're right about that.

Lets compare channel mode on "u" on UnrealIRCD is Auditorium mode (/names and /who #channel only show channel ops) but on another is no knocks. How is mirc to label this then? It wouldnt know what the mode is really for itll just know how to switch it on and off. not what to label it. Then well get swarms of users on here asking why their mIRC is setting this mode and its doing something else.

Why not include information about modes in servers.ini? Or better yet a networks.ini with for each network group a list of modes with their type and description.

It need not be that much work either, make a webform where the irc network operators can input their list of modes and descriptions, or just wait for mIRC users to make their lists.

This could even open the way for different language versions of the channel central, just by using (or merging) different networks.ini files.

Maybe even add another indirection like
[somenet]
m=moderated
k=key

[modes-EN]
moderated=moderated
key=Key: $1
[modes-NL]
moderated=gemodereerd
key=wachtwoord: $1

As I said in my post above, mIRC can simply label it with the mode letter, in this case: 'u'.

Why detach it from the IRC connection? If correct labels were to be provided they should be given by the server at connection time via a numeric. Using separate lists and ini files simply means they'll quickly become outdated and useless or worse, misleading, whenever a server changes it's IRCd version or mode support.

Surely it wouldnt be too hard to add to ircd's a simple command to return all the names for modes and the like
/modeinfo [country-code]
ie.
/modeinfo US
/modeinfo AU
/modeinfo NL
with all appropriate info returned, and not necessarily specify a country code, and return a 'default' set.
so mirc can 'store' all modes for that network based on 'build' information on connect to the network.
If the 'build' for a network has changed it asks for a new list.
More new numberics?

Why not just supply this information every connect
in the 005, I agree with starbucks that it shouldn't be
stored in the servers file at all, it seems to me that
eventually the servers file would become huge and
because servers and networks are here today but
gone tomorrow constantly, the servers file would
become filled with outdated/useless information, as
starbucks also mentioned. mIRC should get this
information everytime it connects and store it
temporarily as it currently does.