mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
It usually happens that people become disconnected and reconnect as their alternate nickname because their main nickname is still in use by their ghost connection until it ping-timeouts. Occasionally somebody else might also attempt to use your nickname (maliciously or in play) causing you to connect with your alternate nickname preference.

I propose that mIRC automatically recover the main preference nickname whilst using the alternate nickname preference.

This seems to be a pretty standard feature in many IRC clients, and while scriptable in mIRC, I wouldn't say it's especially "easy" to script.

While using your Alternate Nickname ($anick), detect when your Main Nickname ($mnick) becomes available and change nicknames (to $mnick). Detection can be through standard visible presence of a QUIT, NICK or similar event, and also with the Notify feature via MONITOR, WATCH or ISON as appropriate.

mIRC should be careful to disable this functionality and ignore when a user manually changes their nickname from their $mnick into their $anick, or if the server (or BNC) specifically changes their nickname from their $mnick to their $anick or a Guest-style /^\S\S\S+\d\d\d+$/ nickname. As with any automated actions, there should be a sanity check to detect contrary repetitive behavior to prevent looping fits -- ie, only one nickname recovery allowed after connect, or allowed again if a '433 :Nickname is already in use.' error is encountered (and the user eventually changes into their $anick nickname), but also not more than once in a 10 minute window.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
pseudo-code.

Code:
On *:CONNECT: {
  set -e %NicknameRecovery.Allowed $true
  set -e %NicknameRecovery.Disabled $false
}

RAW 433:*: { ; :Nickname is already in use.
  if ($2 == $mnick) $&
    && (!%NicknameRecovery.Disabled) {
    ; This basically asserts that the user wants to retry claiming their main nickname.
    ;   All they have to do next is change into their alternate nickname.
    set -e %NicknameRecovery.Allowed $true
} }

On me:*:NICK: {
  if ($nick == $mnick) {
    ; The user did this or the server did this intentionally.
    ; (We used to have our $mnick, but we changed it to something else.)
    ; ((Remember that $nick is our old nick, and $newnick is our new nick.))
    set -eu600 %NicknameRecovery.Disabled $true
  }
  elseif ($newnick == $anick) $&
    && (%NicknameRecovery.Allowed) $&
    && (!%NicknameRecovery.Disabled) {
    ; If we're changing from any random nickname to our alt nickname,
    ;   monitor for our main preferred nickname to become available.
    notify $mnick
    notify on
} }

On *:UNOTIFY: {
  if ($me == $anick) $&
    && ($nick == $mnick) $&
    && (%NicknameRecovery.Allowed) $&
    && (!%NicknameRecovery.Disabled) {
    ; super sanity: the former can be reset again by a 433 later on,
    ;   but the latter must first timeout after a 10 minute hard wait.
    set -e %NicknameRecovery.Allowed $false
    set -eu600 %NicknameRecovery.Disabled $true
    nick $mnick
} } ; by Raccoon 2018

; On *:QUIT:
; On *:NICK:
;; both events are handled by On UNOTIFY implicitly.

; There's no feasible easy way to clean up temporary /notify use, so I didn't bother.
; This code is untested.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Mar 2008
Posts: 93
B
Babel fish
Offline
Babel fish
B
Joined: Mar 2008
Posts: 93
I wouldn't mind if this were to become a built-in feature, but I have a script atm that works (for me and me alone). However, I only use it for networks that do not have NickServ (well, because I can just ghost/recover there and be done with it) - so it becomes a simple
Code:
on *:UNOTIFY: {
  if ($nick == $mnick && ($network == QuakeNet || $network == EFNet)) {
    tnick $mnick
  }
}

(aside from the obvious "my $mnick is permanently on NOTIFY", and perhaps a few potential improvements to make it a little more sturdy...but again, it works for me™)

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Absolutely. I have the similar few-line script as yours, all manually configured per network. If you don't turn off your /notify then you can't change nicknames without further complicating the script. A user friendly feature would be neat smile

I like that you use /tnick so it's agnostic to the '[x] Preserve nicknames' setting.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Upon review, my pseudo-code script and definition should exclude On Connect enabling of this functionality. %NicknameRecovery.Allowed should only be set to $true when a RAW 433 ($2 == $mnick) is encountered. This occurrence might happen during connection pre-auth On LOGON, or during the course of regular IRC use. Move %NicknameRecovery.Disabled = $false to On LOGON.

This revision would prevent automatic grabbing of $mnick for merely changing from a random nickname to $anick without first attempting to try $mnick.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Apr 2018
Posts: 83
E
Babel fish
Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
I would hope that any proposed fumctionality like this could be disabled (if implemented).

As you have already stated, too many different ways of things being implemented across different IRC daemons.

Unfortunately there are other considerations:

1) under multiserver working, you may use a network/server where you are not using either your mnick or anick. That was pointed out to me by someone I was in a chat discussion with.

2) there is also a scenario I have encountered on both unreal and inspirc where you get the raw 433 (nick is already in use) and it is a previous 'ghosted' session, but when the server registration period is completed (after user counts raw 251 etc on both of those deamons) and when you try to ghost/recover your nick, Anope sends a NOTICE informing you that the nick is no longer in use (it's a diffent message between different Anope versions). Basically your ghost session timed out before you tried to ghost it.

Given how much can be changed at the server and services ends then I think it might be impractical, even dangerous to add this.

When it comes down to it, this is an easy problem to write code even a scriptlet for, especially since each user can amend it to deal whith their daemon encountered, so why add the complexity to the client where nobody can touch/fix it for a new or different situation.

In light of these, and potentially other 'pit falls' I would suggest giving this idea miss. Just my opinion and therefore as valid/invalid as anyone else's.

Last edited by Erasimus; 31/01/19 05:23 PM.

Link Copied to Clipboard