Okies ... I have a complicated problem...
My problem is this. I have a nick keeper bot in my channel, along with a few others. A piece of code I am trying to write always fails, because I'm running through all the bots trying to see if they are on a channel, and the nick-keeper bot always fails, because its real name is not the name it has right at the mo.
However, it would seem I can only get the bots real name (not sure if its that or handle) from the tand_t structure. Therefore ismember fails becaus there is no such nick on that channel. HELP!!! I think I need some kind of hand to nick converter, but I cant work out how to do that.
Any clues?? (even if in tcl, 'cos I can easily convert it)
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
Aaaaargh .. one bot - how many nicks?
Ok - scrap that .. just tried handtonick (using the bot->bot name as input) and I get nothing back!!! waaaaaaaahhhh!!!
What it is...
Scratchy's botnick is Photon
Scratchy's altbotnick is Scratchy
Scratchy's botnetnick is Scratchy
(all this from a nick holder tcl script found in the archive)
However, in from bot->bot I get the name Scratchy, and I need to trace that to Photon.... any clues? Or are u as confused as I am..?
What it is...
Scratchy's botnick is Photon
Scratchy's altbotnick is Scratchy
Scratchy's botnetnick is Scratchy
(all this from a nick holder tcl script found in the archive)
However, in from bot->bot I get the name Scratchy, and I need to trace that to Photon.... any clues? Or are u as confused as I am..?
Well no...
what I'm trying to do is send a message to all bots in the channel, but because of the duplicity of the nick-holder bot (Scratchy), it always thinks Scratchy is not on the channel. ('cos its nick is currently Photon)
Only thought of one other solution - do a zapf_broad, and make each individual bot check if they are on the channel. Problem with this is that I have no idea how many reponses to expect, and I'll just have to allow a set time for response...
All I basically need is something that takes in a botnetnick and returns the bots current botnick...
the code below always fails
what I'm trying to do is send a message to all bots in the channel, but because of the duplicity of the nick-holder bot (Scratchy), it always thinks Scratchy is not on the channel. ('cos its nick is currently Photon)
Only thought of one other solution - do a zapf_broad, and make each individual bot check if they are on the channel. Problem with this is that I have no idea how many reponses to expect, and I'll just have to allow a set time for response...
All I basically need is something that takes in a botnetnick and returns the bots current botnick...
the code below always fails
Code: Select all
static int Chan_Send_Zapf(struct chanset_t * pChan, char * pZapf)
{
int nBots = 0;
tand_t * pBot;
for(pBot = tandbot; pBot; pBot = pBot->next)
{
// if(HandOnChan(pBot->bot, pChan))
if(ismember(pChan, pBot->bot))
{
int nBotID;
nBotID = nextbot(pBot->bot);
if(nBotID >= 0)
{
nBots++;
botnet_send_zapf(nBotID, botnetnick, pBot->bot, pZapf);
putlog(LOG_CMDS, "*", "Sent zapf to %s", pBot->bot);
}
}
else
{
putlog(LOG_CMDS, "*", "%s is not on chan", pBot->bot);
}
}
return nBots;
}
First of all, I have no idea what a nick holder bot is or why you need to see if all the bots are on the channel.
But anyway, if Scratchy is the one running this code, and your problem is only that your code can't tell whether he's on the channel, I'd say learn about the "botonchan" command heh. As for nick2hand / hand2nick, why not use the combo punch "handonchan" for the other bots? (I see you have your own HandOnChan(), but does it do the same thing?)
Finally, note that your idea of sending a message the over botnet is the only way to guarantee that the bots are on or off the channel. If you rely on local information (handonchan, etc), your code may be confused when the bot really isn't on the channel but someone matching his hostmask is.
Maybe you don't have a user added for Scratchy? The bot does not create a user for himself by default, so unless you added it,it's not there.Ok - scrap that .. just tried handtonick (using the bot->bot name as input) and I get nothing back!!! waaaaaaaahhhh!!!
But anyway, if Scratchy is the one running this code, and your problem is only that your code can't tell whether he's on the channel, I'd say learn about the "botonchan" command heh. As for nick2hand / hand2nick, why not use the combo punch "handonchan" for the other bots? (I see you have your own HandOnChan(), but does it do the same thing?)
Finally, note that your idea of sending a message the over botnet is the only way to guarantee that the bots are on or off the channel. If you rely on local information (handonchan, etc), your code may be confused when the bot really isn't on the channel but someone matching his hostmask is.
Confusion!!!
Okies ... a little background. The idea is that when someone says a public trigger in the channel, that only on bot will respond to it, even though they are all running the same code (got a bit fed up with using different command characters for each bot...)
The only sensible way to do this was to elect a 'spokesbot' on each channel that would decide who responded to what - this would be done by election (hence the sending a message to each bot in the channel) based on things such as processor speed, netspeed, number of bots on this host, etc. These elections to be held when a bot joins the channel, parts the channel or gets split.
The problem with the 'nick keeper' bot is that it keeps my nick (Photon) when I'm not there. Therefore it has two nicks, either one of which it could have at any time (Scratchy or Photon). This casued a problem with the boptnet initially, but then I discovered - set a botnetnick that is always scratchy and the problem is solved. ahhhhh no....
Now I have the problem that when I trawl through the bot list, I get the botnetnick for each bot (in Scratchy's case 'Scratchy'), and doing a handonchan (or whatever) it fails, 'cos Scratchy is Photon in the channel.
Ppslims idea is interesting - I'll have to try that, but it would seem that the whole user records are confused, 'cos if I do a whois on Scratchy when he is Photon, it tells me its hand is Photon, which is MY hand!!!
Confused yet?? I am....
At the moment its working with doing a zapf_broad (putallbots to ya tclers) with each bot fast rejecting due to not being on the channel - but this is a waste of bandwidth (oh and the election has to be held over time, rather than waiting for n responses as it did before). If only I had a botnetnick_to_hand then it wall all be easily sorted, but unfortunately it would seem that the only person that knows that info is the bot itself...
(thinks : now I could waste even more bandwidth getting the bot to tell me .. lol)
Okies ... a little background. The idea is that when someone says a public trigger in the channel, that only on bot will respond to it, even though they are all running the same code (got a bit fed up with using different command characters for each bot...)
The only sensible way to do this was to elect a 'spokesbot' on each channel that would decide who responded to what - this would be done by election (hence the sending a message to each bot in the channel) based on things such as processor speed, netspeed, number of bots on this host, etc. These elections to be held when a bot joins the channel, parts the channel or gets split.
The problem with the 'nick keeper' bot is that it keeps my nick (Photon) when I'm not there. Therefore it has two nicks, either one of which it could have at any time (Scratchy or Photon). This casued a problem with the boptnet initially, but then I discovered - set a botnetnick that is always scratchy and the problem is solved. ahhhhh no....
Now I have the problem that when I trawl through the bot list, I get the botnetnick for each bot (in Scratchy's case 'Scratchy'), and doing a handonchan (or whatever) it fails, 'cos Scratchy is Photon in the channel.
Ppslims idea is interesting - I'll have to try that, but it would seem that the whole user records are confused, 'cos if I do a whois on Scratchy when he is Photon, it tells me its hand is Photon, which is MY hand!!!
Confused yet?? I am....
At the moment its working with doing a zapf_broad (putallbots to ya tclers) with each bot fast rejecting due to not being on the channel - but this is a waste of bandwidth (oh and the election has to be held over time, rather than waiting for n responses as it did before). If only I had a botnetnick_to_hand then it wall all be easily sorted, but unfortunately it would seem that the only person that knows that info is the bot itself...
(thinks : now I could waste even more bandwidth getting the bot to tell me .. lol)
I understand perfectly now.
This is basicaly nothing to do with C, or Tcl.
To solve this, use better hostmask records for the bot, int he other bots.
handonchan tracks users using hostmasks.
IE.
Bot1!userA@host.c
The other bots have a a hostmask set for this bot as *!userA@host.c".
No matter what nickname the bot uses, the other can track the bot, due to wildcard matching any nickname.
The above hostmask can be rather open, and anytime that user acount is compromised, simply running a client with the same v-host would mean that person is trackedas the bot.
This is why eggdrop allows more than 1 hostmask to be stored for each user.
IE, my bot does nick-keeping too.
This, all the bots have 2 hostmasks for my bot.
ppslim!username@host
&
nickname!username@host
That way, if my bot uses wither nickname, the other bots still recognise him as the same handle.
This is basicaly nothing to do with C, or Tcl.
To solve this, use better hostmask records for the bot, int he other bots.
handonchan tracks users using hostmasks.
IE.
Bot1!userA@host.c
The other bots have a a hostmask set for this bot as *!userA@host.c".
No matter what nickname the bot uses, the other can track the bot, due to wildcard matching any nickname.
The above hostmask can be rather open, and anytime that user acount is compromised, simply running a client with the same v-host would mean that person is trackedas the bot.
This is why eggdrop allows more than 1 hostmask to be stored for each user.
IE, my bot does nick-keeping too.
This, all the bots have 2 hostmasks for my bot.
ppslim!username@host
&
nickname!username@host
That way, if my bot uses wither nickname, the other bots still recognise him as the same handle.
Aha!!!!
Thankyou very much!!! (although it wasnt quite as simple as you said...)
I set the hostmasks properly - they were all set to *!bothand@wibble.wobble and it still didnt work.... then I noticed that my ident daemon was identifiying them all as me....
So slight idiocy on my behalf... its interesting that the code sets such lax hostmasks as standard...
But cheers!! Chan_Send_Zapf now works ... unbelievable I tell you.
More problems will be posted as they come up...
P.
Thankyou very much!!! (although it wasnt quite as simple as you said...)
I set the hostmasks properly - they were all set to *!bothand@wibble.wobble and it still didnt work.... then I noticed that my ident daemon was identifiying them all as me....
So slight idiocy on my behalf... its interesting that the code sets such lax hostmasks as standard...
But cheers!! Chan_Send_Zapf now works ... unbelievable I tell you.
More problems will be posted as they come up...
P.
The Lax standard hostmask is there, mainly as a compromise.
Most users of eggdrop, fail to grasp the idea behind hostmasks, and how they relate to handles (most don't even know that a handle isn't anything to do with IRC).
As such, if stronger hostmasks (EG nick!*user@*.region.isp.com) where used, this would mean most users bcome unrecognisable the next time they log on.
Thus, this hostmask (which I belive is the standard mIRC mask as well) is used.
Most users of eggdrop, fail to grasp the idea behind hostmasks, and how they relate to handles (most don't even know that a handle isn't anything to do with IRC).
As such, if stronger hostmasks (EG nick!*user@*.region.isp.com) where used, this would mean most users bcome unrecognisable the next time they log on.
Thus, this hostmask (which I belive is the standard mIRC mask as well) is used.
