logging in to services and ghosting whoever is on bot's name

dang, I didn't expect to get a reply within less than 10 minutes of posting this

I was looking at their documentation pages on sourceforge and found them rather unsatisfying, thanks for the link!

I probably won't be able to get a patch ready for testing this weekend as my parents are moving and they need help taking their furniture apart (and they have to be able to re-assemble them :P) and we're pushing deadline at the office

ok, so we're passed some big deadlines so I figured I could take a minute to work this out (after all, I sorta promised)

so here's the patch, it adds a field for the nickserv name (coz some networks use other names), which defaults to "NickServ", and it adds a checkbox for ghosting, which defaults to false

every time the "nickname is in use" error is thrown, it will ghost whoever is on its nick (if ghosting is enabled in the settings)

every time it receives a notice like "botname has been ghosted", it will try to change its nick to the one in the settings (only checks for this notice if ghosting is enabled in the settings)

every time it's name is changed, it will check if its current name is the same as the one in the settings and if a password was entered, if so, it will try to identify with nickserv

when cron is run, it will perform an extra check to see if its name is still the one that is in the settings, if not , it'll try to change it doing the stuff mentioned above

I've tested it a few times (but didn't get a netsplit while I was testing, so that hasn't been tested) on freenode only, so I can't guarantee that this works on other servers right now, but I'm planning on checking out how to use tokens so you can define your own strings on how it should ghost and identify

I've also added a lot of comments so you can easily figure out what does what and you can probably improve it a lot ;)

it's not 100% yet, but a decent start to making sure Druplicon won't have some silly name for more than 5 minutes \o/

ok, so I edited it a bit more, now it adds 3 fields, one for nickname service name (defaulting to NickServ), one for the format to identify using placeholders (defaulting to "IDENTIFY @bot_password" but @bot_nickname can also be used here) and one for the format to ghost, also using placeholders (defaulting to "GHOST @bot_nickname @bot_password")

I decided to split it up this way because even though some networks use the "/ghost nickname password" format, they still allow the "/msg nickserv nickname password" format

so if you were to enter "foobar poobla" in the IDENTIFY field, you would effectively be messaging "foobar poobla" to nickserv

also added an extra check in the notice hook to check if the bot's nickname isn't already correct (just in case of weird lags or something)

after some testing I noticed this little bugger is fast, takes it about 0.5 secs to ghost and change nickname

but I've noticed that when I ghosted the bot, it would reconnect, ghost my client, change nickname, but it wouldn't rejoin the channel...

so maybe we should consider moving this:

// to support passwords, we have to make a single join per channel.
$channels = preg_split('/\s*,\s*/', variable_get('bot_channels', '#test'));
foreach ($channels as $channel) {
  $channel_parts = explode(' ', $channel); // use a password if it's defined.
  $irc->join($channel_parts[0], isset($channel_parts[1]) ? $channel_parts[1] : NULL);
}

from bot_start.php to the bot.module inside either a bot_irc_msg_motd() hook or a bot_irc_msg_login() hook, but I need to test this to see which is more reliable

added is an update of the patch, so ignore the previous one ^^

I can understand why you would prefer that and I was originally planning to do that, but the smartirc class doesn't support the sending of custom (network specific) commands like "/ns identify password" or "/ghost nickname password" and adding fields like that would create the illusion that it is supported

so after talking to some of the freenode IRCops I went for the format that is always supported (I tried looking for networks that require u to ctcp or notice send the login and/or ghost commands, but couldn't find a single one)

so it's either forcing to use a /msg or I'd have to check what command is used (ctcp, notice, ...) and then reforming it to a $irc->message($command, $format)

[EDIT]
after digging trough the smartirc class some more I found a way it might be possible to send any command using $irc->_send($data) so I'm going to fool around with it a bit and see if I can find a format that pleases you ^^
[/EDIT]

nvm, it's a private method :(

k, only got 2 fields now and it handles it as we briefly discussed

entering "/msg NickServ ghost @bot_nickname @bot_password" will result in proper ghosting :)

I'm not sure if this is a preferable way to do it, but I used the following:

//making it an array
$message = explode(' ', $message);
//bumping off the "/msg"
shift($message);
//setting the $to to the second word in the array
$to = shift($message);
//turning it back into a string
$message = implode(' ', $message);
bot_message($to, $message);

only had chance to test it once coz I gtg but it seemed to work properly, I'll test some more when I get the chance

didn't mean to assign it to anonymous :x

hmm, looks like I accidentally added 2 empty lines in there, I'll remove them tomorrow when I get back to the office and I'll make a new patch
also forgot to make sure all tabs were removed

Removed accidental linebreaks and converted tabs to spaces

damn, noticed a possible problem:

since the $data object passed to hook_irc_msg_error($data) only contains the message and error code, there's not way of checking what nickname was attempted to change to, so in other words, with this current patch, if any other module tried to change the nickname to something that's already in use, bot_irc_msg_error() will pick it up and if the password is set it will try to ghost whoever if on $bot_nickname, even if this wasn't the nickname that it tried to change to

I guess this could be considered to be a long shot, but it's still a potential flaw :(