I've found what appears to be a slight quirk in how the Login Method feature (of a Server's settings) is implemented, when used in conjunction with the Connect / Options / Perform... feature, in the scenario where the Login Method fails (but the server IS connected and functional). I should note that in this particular network's case, NickServ is not truly required for authentication, but more as a nicety.
- Server configuration uses Login Method "NickServ (/NICKSERV)" and a password is chosen
- Connect / Options / Perform... has "Enable perform on connect" checked, "Network" set to "All networks", and "Perform commands" is "/join #test"
The situation:
- mIRC connects to the server successfully -- note: IRC commands are fully functional
- mIRC issues the /NICKSERV {password} command
- /NICKSERV command fails (IRC protocol returns a 402 indicating No such server -- for example, the NickServ service is unavailable on the network)
- mIRC sits for 60 seconds (interval seems to come from from Connect / Options / Retry...) -- you can issue manual commands during this time without any issue, of course
- mIRC suddenly joins /#test even though it could have done so 60 seconds prior without issue
mIRC is treating /NICKSERV returning a 4xx as "failed to connect to server", which is not really true. However, as I think about it a bit more, I can see how/why mIRC might treat this scenario the way it does. But it's a bit strange to see the "Retry..." timeout/interval kick in in this situation. Are there actual IRC networks which *require* NickServ authentication before any other IRC commands are functional?
Prior to using the Login Method feature, I simply put /NICKSERV {password} into my "Perform commands" area/script, where I never encountered this problem (when NickServ was down). Of course, this also had the downside of storing the password in plaintext.
This is using mIRC 7.72, by the way.
