An idea would be to notify users if a user is offline in the invite command, then if there online there invited if there offline/dont allow the bot then we recieve 217 so send back a message.
Code:
$self->sendmsg("0info0 Sorry i could not invite the user, Maybe there offline or have blocked me.") if($cmd eq '217');
In switchboard.pm find sub dispatch and place the code under
There is no way to get around the privacy settings anymore, so the only way you are going to be able to tell for certain is if they have your bot added, and they are online with that and offline on the users list. Other than that they could show as offline if you are blocked, they are actually offline, or they have the privacy set to not let people not on their allow list to contact them. Just like brother said, it was fixed long ago, making it a waste of time.
Joined: 19 Jul 2004 Posts: 556 Location: Los Angeles, CA votes: 1
Posted: Thu Jan 27, 2005 9:02 pm Post subject:
there is a "status checker" on this site...that never messages me or added me to its list....and it seems to work, so i dont se that as a waist of time to build...you dont have to join..you can just call and not join...thats how this status checker works. _________________ [ matt ]
It can get your status under the right conditions. If you turned around and changed your privacy settings, everytime it checked it should show you as offline, and everytime someone else checked you, it would show you as offline. Sure it will work for some people, but it will never be 100% correct like to good old days. Now to even get that far with privacy settings set, they'd have to have the bot on it's list, which is very limiting.
Joined: 19 Jul 2004 Posts: 556 Location: Los Angeles, CA votes: 1
Posted: Thu Jan 27, 2005 9:16 pm Post subject:
OK if somone has adjusted these settings or has accually blocked the bot it wont work your right...the point is under most condetions it does still work _________________ [ matt ]
Heh, the way block checkers 'use' to work, wasn't using CAL (that would invite you into the conversation, so don't even bother with CAL). It was by opening a socket with the user and close the conversation (I think the call thing in MSN.PM would do the trick), to check if they're online or not. It would still work but, the privacy is preventing it for some people (As keenie said...)
And alienz your not the most useful tool in the shed either, I actually know what i'm talking about instead of you, making up some random stuff that wouldn't even change the out-come. Tsk. tsk. only if you can read, I am giving out useful information. soo ssh.
QUOTE(..::BIGmouth( )::.. @ Jan 27 2005, 07:53 PM)
I actually know what i'm talking about instead of you, making up some random stuff that wouldn't even change the out-come.
LOL Ok, I made it all up, there's no such thing as the code I posted. Everything I said was completely wrong because it was at random. Get a grip. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
Hm, well the block checker I was using just opened a socket with the user. I'll post a small script that does it later. I know it'll work alienz, but still it wouldn't change anything what would happen, and your telling me to get a grip? while your the one whose snapping over me saying thats a dumb way of doing it.
QUOTE(..::BIGmouth( )::.. @ Jan 28 2005, 04:21 AM)
Hm, well the block checker I was using just opened a socket with the user.
Please define 'opening socket to user'...
As far as can tell this involves getting a free SB from the NS, then CAL'ling your 'victim'. So why do you keep putting stress on the 'opening a socket' part? It's exactly what was stated in previous posts.
Anyhow, CAL'ling a user into a convo and then closing it might not trigger a window on 'real' MSN clients, third party users might still be 'bothered' by an empty convo opening, not sure about this. Maybe someone has tested this method with a few of the most popular 3rd party MSN clients around.
Well, at least it's better then (temporarily) adding the user to the FL and then getting their status...
[EDIT]: The above method of CAL'ling the user will leave his client into an empty convo though, unless the official client disconnects you from the SB when all occupants have left and nothing was said. Maybe i'm just rambling here, but isn't that wasting the 'victim' resources (allthough it will timeout after a while)?
While i'm writing this, i'm just thinking of possible abuse... Is it possible to crash someones client by keep inviting him to new SBs and then leaving them again? I'm not going to try myself though, but is there some way of 'protection' to flood opening SBs provided in the protocol?
Other third party messenger clients "know" more things than the standard MSN Messenger does. For example, on normal MSN, you can't tell when somebody opens a convo with you, or closes the window... but our bots do know, because those handlers do exist. So third party clients are just as capable of knowing, and some of them probably have handlers that would tell you about that.
MSN just hides a lot of those things... but third party clients (I know gAIM tells you when the user closes the window, for example) would see it.
QUOTE(..::BIGmouth( )::.. @ Jan 28 2005, 07:21 AM)
while your the one whose snapping over me saying thats a dumb way of doing it.
If you call defending yourself snapping, go ahead. There was nothing dumb about it, and there was no reason for you to insult me over it. _________________ Check out Botworld! A dev resource for things bot.
Downloads, articles, news, fourm and more.
http://botworld.marzopolis.com
is there some way of 'protection' to flood opening SBs provided in the protocol?
There is an event handler in MSN 2.0 called Ring which is called when a user tries to open a conversationg with you. If you wish to accept, return 1, if you don't want to join the conversation, return 0.
Code:
sub Ring<br />{<br /> my ($self, $username, $friendly) = @_;<br /><br /> if( you want to accept ) { return 1; }<br /> else { return 0; }<br />}
User Control Panel
It would still work but, the privacy is preventing it for some people (As keenie said...)
Posted: Sat Jan 29, 2005 12:21 am Post subject: 
