I want to wrap up development of MSN2.0 and make it final. I plan to make 2 more releases of this. One that includes the changes mentioned below and then a final. Can everyone please tell me what you think is missing, needs to be fixed, any bugs you are still getting, etc.
Things I will be changing in the next release
Renaming some methods to make them consistent (in particular, sendmsg will change to sendMsg); renaming some events to make them consistent (in particular, removing underscores from event names). In this pre-final release, I will deprecate the old methods and events, meaning they'll still work but you'll get big warnings telling you to change them. Then the old stuff will be gone from the final release.
Things I will NOT be putting in the final release:
No MSN Messenger 7 functionality, no nudge, winks, etc. Some of these things are easy to add (you can do them yourself if you want), but MSN 7 is still beta and I don't want to introduce new code into the module right now.
No File Transfer. All the P2P code is being rewritten and will include File Transfer in the next major release.
Don't post random "cool, I can't wait", etc messages (I'll delete them), just post actual things you want fixed or changed.
Well was mentioned before but $user to sub answer.
Also, if its not too hard but some kind of ink handler, something that can just detect it and then mabey pass on to an event with the base64 ...not too bothered but would be nice. Also when setting the msn event maybe sending a font/color/effect unless theres already a way of doing it without editing msn.pm, but i think i was talking to oyu before and there wasnt a way of doing it globally but only in one convo...
O! another, maybe too big though, with somethings like call ect there's errors printed. eg. user not online, could all these be passed in form of numbers or anything when doing the command so you can compare and report to the user that he's not online or something..... Im editing every two mins! re-read
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Mon Nov 15, 2004 7:35 pm Post subject:
Allow settings (like style and P4) to be passed with broadcasts. Minor but it would be nice.
The Answer (which ever event you get when a person opens the window) should pass that users Name. Then the welcome message from a bot would know the person (i think this is one of Dazzys ideas) and its been floating around since we started recoding MSN.pm
Error handling at all spots where the socket is printed to, to handle if the socket has been destroyed already.
I think thats it, i'll post more if i think of them. _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
Multipacket messaging would be a good addition. Maybe making it multipacket if the message was too big, but all done in sendmsg. _________________ ~ Josh
[ Need bot hosting on a dedicated server? PM me. ]
Until then, getting the user's/users' e-mail address(es) with the Answer handler can be done by getting the socket ID, getting users from that sock, etc. but sending the $user and $name to the Answer handler would be nice too.
Also, since the Answer handler is called when the bot is INVITED to a chat, the username sent to the handler should be an array and not a scalar... so that $users[0] would be the first username, which would exist with or without being invited to a huge chat.
That, or make a separate handler for when the bot's invited to an already populated room. ___________________
Another suggestion: the $msn->call() command should be able to pass styles like sendmsg does (font, color, style, etc.)
Another idea for something you can put in, is to have it send a client ID... which can be defined on initialization, and recommend all bots to identify themselves as bots by putting "(bot)" in their client ID (I know some people still won't do it, but it will help a great deal in helping bots identify eachother)... i.e.
Etc... and then Message handler would either pass a variable, or there'd be a switchboard method, of getting the Client ID of a user. I heard Bot2k3 has something similar of sending its ID. Anywho, this isn't such a big deal, just would be another nice feature. _________________ Current Site (2008) http://www.cuvou.com/
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Mon Nov 15, 2004 7:47 pm Post subject:
Your idea for the names for Answer is close but a bit off base. That shows you the users IN the chat you are going to. We would like to get the user that INVITED you to the chat. You can get the users as normal with your method, all we need sent is the username of the person Inviting you, that person which initiated the call. If i remember correctly this is possible with the MSN protocol but i might have to go dig around to verify.
Also if we are going to send ID's then there should be a means to get the ID of a message sent to you. _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
Also, the errors from things like call, invite ect like user not online, should be turned off when debug is not on?
Actually I don't mind that error, it gives me confirmation. Although for another feature, call or invite could return 1 if the invite was sent successfully, or 0 for an error or something. _________________ Current Site (2008) http://www.cuvou.com/
Yea but its no use the users Like i said with the number thing, now where did i see this before.....O yea, umm mojaves floodcheck where it retured the result.....
Yea cer Read my first post... _______________________ Yea and i was thinking the other day, if MSN plus does personalised status's, why cant we? you dont need msn plus to recieve it so...
That, or make a separate handler for when the bot's invited to an already populated room.
There already is a handler for this: Chat_Member_Here, which is called for each user that is in a chat that you are being invited into. Chat_Room_Updated is called after all users have been listed via Chat_Room_Here.
About Client and Client ID:
MSN has a ClientID value, which is implemented in MSN2.0 - it describes what MSN version and capabilities your bot supports. There are several possibly unused bits in the value that could be used to mark the client as a bot, but who knows what MSN might use them for in the future, besides it wouldn't allow us to send much info.
Gaim sends an actual message describing its Client info. This is what I think Cer is suggesting. We could set it up so that all bots that use MSN need (we can't really force it) to send information about their client via a message. This allows us to send much more info, which is great in identifying bots, but how would users respond? Would they like it? Would it fit nicely into a welcome message? How often should it be sent? It really only needs to be sent once ever to each user. But I think it should be sent for each new conversation. What do you all think?
Hmm, it could be sent to a user that hasnt used the bot before, so it wouldnt happen more than once to a user, but then somebody could login to the bots account and not reply to it ect...
I don't know if gAIM actually sends a real message... when I signed on with gAIM, I didn't get people asking why I just sent that message, but my bots receive that type of message all the time.
Maybe the specific format of the message is hidden by MSN clients programmatically, and that the MSN module wasn't programmed to hide it and that's why it comes through as a message....
I'll have to do some testing. _________________ Current Site (2008) http://www.cuvou.com/
User Control Panel
Like i said with the number thing, now where did i see this before.....O yea, umm mojaves floodcheck where it retured the result.....