mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#112925 27/02/05 08:03 PM
Joined: Jan 2005
Posts: 37
S
Scratch Offline OP
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 37
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:

Code:
on ^*:FIREWALL:{
  if ($1- == Unable to connect to firewall) { 
    echo -s There was a firewall error!
    haltdef
  }
}



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.

Joined: Mar 2004
Posts: 540
A
Fjord artisan
Offline
Fjord artisan
A
Joined: Mar 2004
Posts: 540
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.

Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
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.

Last edited by mIRCManiac; 27/02/05 09:42 PM.
Joined: Jan 2005
Posts: 37
S
Scratch Offline OP
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 37
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...

Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
that really isn't much of a valid reason either


I agree

Joined: Feb 2003
Posts: 3,432
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Feb 2003
Posts: 3,432
Quote:

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

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 smile like a Tab with empty modes you have to type in by hand.. then save it to mirc.ini smile


if ($me != tired) { return } | else { echo -a Get a pot of coffee now $+($me,.) }
Joined: Mar 2004
Posts: 540
A
Fjord artisan
Offline
Fjord artisan
A
Joined: Mar 2004
Posts: 540
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

Joined: Jan 2005
Posts: 37
S
Scratch Offline OP
Ameglian cow
OP Offline
Ameglian cow
S
Joined: Jan 2005
Posts: 37
Quote:
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...


Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
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.

Last edited by mIRCManiac; 28/02/05 08:05 PM.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
Actually about 90% of IRCds (that I'm aware of) correctly implement the CHANMODES token.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
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.

Last edited by mIRCManiac; 28/02/05 08:24 PM.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
Quote:
commit product 'suicide'


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

Joined: Mar 2004
Posts: 540
A
Fjord artisan
Offline
Fjord artisan
A
Joined: Mar 2004
Posts: 540
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.

Joined: Apr 2003
Posts: 701
K
Hoopy frood
Offline
Hoopy frood
K
Joined: Apr 2003
Posts: 701
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

Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
As I said in my post above, mIRC can simply label it with the mode letter, in this case: 'u'.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
Joined: Dec 2002
Posts: 2,962
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.


Spelling mistakes, grammatical errors, and stupid comments are intentional.
Joined: Feb 2004
Posts: 201
J
Jae Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2004
Posts: 201
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? frown

Joined: Feb 2005
Posts: 681
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Feb 2005
Posts: 681
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.

Last edited by mIRCManiac; 01/03/05 10:12 PM.
Page 1 of 2 1 2

Link Copied to Clipboard