Sometimes, the specific IRC nick isn't available for use over the network (this might happen due to a connection issue where a previous instance has neither parted nor timed out of the channel and you try to reconnect). In such a scenario, the IRC library in use falls back to another numbered nick (i.e., if you plotsbot is taken, you will be named plotsbot1 instead).
Naturally, the user would mention the bot by its new (rather strange) name, but as the bot uses config.name internally, it wouldn't be able to know correctly when it is mentioned (because its looking for the wrong name entirely) and also the help message wouldn't make much sense (although each of the mentioned commands would completely work).
We would need to find a way to figure out when the required nick isn't available, which nick we fell back to, and then use THAT nick appropriately.
Preparing a first-timers-only
The various behaviors use and display the botNick variable inside the behaviors object to display the various values and also to ascertain that the message was indeed meant for the bot. Right now, we statically set the value of botNick to be the same as that of the attempted value of the bot's nick. However, if there's an issue and the bot is forced to fall back to an alternate value, there is a discrepancy between the two values - leading to this bug. In order to solve this, let's dynamically set the value of botNick to client.nick instead.
Sometimes, the specific IRC nick isn't available for use over the network (this might happen due to a connection issue where a previous instance has neither parted nor timed out of the channel and you try to reconnect). In such a scenario, the IRC library in use falls back to another numbered nick (i.e., if you
plotsbotis taken, you will be namedplotsbot1instead).Naturally, the user would mention the bot by its new (rather strange) name, but as the bot uses
config.nameinternally, it wouldn't be able to know correctly when it is mentioned (because its looking for the wrong name entirely) and also the help message wouldn't make much sense (although each of the mentioned commands would completely work).We would need to find a way to figure out when the required nick isn't available, which nick we fell back to, and then use THAT nick appropriately.
Preparing a first-timers-only
The various behaviors use and display the
botNickvariable inside the behaviors object to display the various values and also to ascertain that the message was indeed meant for the bot. Right now, we statically set the value ofbotNickto be the same as that of the attempted value of the bot's nick. However, if there's an issue and the bot is forced to fall back to an alternate value, there is a discrepancy between the two values - leading to this bug. In order to solve this, let's dynamically set the value ofbotNicktoclient.nickinstead.