BNCS Chatgate Event Handler (VB 6.0)

[n00blar]

First off, before you start saying chat bots are no longer used blah blah blah.  This is just to show someone, wether they are making a binary bot or a chatbot, some basic oop techniques on how to manage things.  This is a collection of class modules (yes, an oop designed way of handling events!) that will take the raw data you recieve, do some work on it, then raise the appropriate event and pass an object that contains all the information (already parsed inside properties) to the event.

Download Here: http://www27.brinkster.com/wsckvbupdates/default.html

Here is an example using the Event Handler in a "contained enviornment", meaning its not on battle.net and I pass a string in that would be exactly like something you would receive from battle.net.

Code Select Expand


Private WithEvents EventHandler As CEventHandler

Private Sub Form_Load()
   Set EventHandler = New CEventHandler
   EventHandler.DispatchEvent ("1002 JOIN Dword 0010 [D2XP]")
End Sub

Private Sub EventHandler_OnJoin(ByVal EventJoin As CEventJoin)
   Debug.Print EventJoin.EventUser & " has joined the channel as " & EventJoin.EventClient & " (" & EventJoin.EventFlags & ")"
End Sub


This may not be done the best way, but it sure as hell is better than spaghetti code and probably better than some other implementations using OOP!  

[n00blar]

Common guys tell me what you think, whats good, whats bad, and whats ugly?  (Seems to have a problem with people compulsively not posting and has to request it! )

[Mesiah / haiseM]

i dont know about people starting off in programming, but i always go with event handlers when parsing battle.net events.

[n00blar]

MesiaH, did you actually download the project and look at it?  If not I recommend doing so, for everyone, much more than what you see in the code example.  

[MailMan]

Looks good.

[Zorm]

Should use callbyname for dispatching the messages to event handlers, could cut down on code a lot by doing that.

[n00blar]

zorm, it wouldn't make too much of a difference if I hardcode them or not.  It might cut down on the code, but I don't think it would speed it up at all, it would probably slow it down.  I say this without actual evidence, however, CallByName determines the name at runtime, so i'm sure there is some overhead there.  The only benefit _might_ be readability, be even that doesn't help too much.

[n00blar]

BTW This is part of a package that will eventually be combined into a full working bot.  Stay tuned in because I will be releasing other parts of the bot as time goes by!

[Banana fanna fo fanna]

ph34r, i am writing a chatbot as well.
chat4life kthnx

[n00blar]

Really storm?  Would you like to talk to me some time about how yours works?  My chatbot isn't to show people how to connect to battle.net, but rather techniques on handling/managing things.

[Banana fanna fo fanna]

OK.

My bot is written in Python/wxPython (a better windowing environment).

Basically, I have a timer call a special method in my ChatConnection class every 10ms. This method calls select() on a nonblocking socket. If the socket is in the read list, read data and add it to the buffer. If a newline is in the buffer, chop off the newline and everything before and pass it to the parser and dispatcher.

The parser splits it by spaces and quotes. The dispatcher checks its message ID and iterates through a list of Listeners and calls methods in them (on_join, on_leave, etc).

If a socket is in the write list, send the next message in the queue if the antiflood wait time is up. If it's in the error list, we terminate.



ChatConnection can be observed by serveral objects, which makes it very versitile and decoupled from the main window.

[Skywing]

OK.

My bot is written in Python/wxPython (a better windowing environment).

Basically, I have a timer call a special method in my ChatConnection class every 10ms. This method calls select() on a nonblocking socket. If the socket is in the read list, read data and add it to the buffer. If a newline is in the buffer, chop off the newline and everything before and pass it to the parser and dispatcher.

The parser splits it by spaces and quotes. The dispatcher checks its message ID and iterates through a list of Listeners and calls methods in them (on_join, on_leave, etc).

If a socket is in the write list, send the next message in the queue if the antiflood wait time is up. If it's in the error list, we terminate.



ChatConnection can be observed by serveral objects, which makes it very versitile and decoupled from the main window.

Hmm.. Why not setup for some kind of notification for socket events instead of polling it every 10ms?  Your method wastes lots of processor time.

[Banana fanna fo fanna]

Can you explain?

[Skywing]

Can you explain?

There are lots of things which allow you to in some way receive notification of the completion of an asynchronous operation.  Perhaps the simplest are the functions WSAAsyncSelect and WSAEventSelect, though I'd recommend you stay away from WSAAsyncSelect as much as possible, as it's got the annoying habit of creating extra threads in your process which don't go away.

If you're really wanting good performance, I'd recommend that you go with overlapped I/O - see ReadFileEx, WriteFileEx, WSARecv, and WSASend.  Note that overlapped operations typically require your thread to be alertable - that is, you need to use one of SleepEx, WaitForSingleObjectEx, WaitForMultipleObjectsEx, MsgWaitForMultipleObjectsEx, or SignalObjectAndWait as the thread-blocking function in your main loop.

It is important to note that typical system modal dialog loops are not alertable.

[Banana fanna fo fanna]

Doesn't that require multithreading?