Valhalla Legends Forums Archive | Battle.net Bot Development | BNCS Chatgate Event Handler (VB 6.0)

AuthorMessageTime
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]
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
[/code]

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!
March 25, 2003, 1:54 AM
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! :D)
March 25, 2003, 2:49 AM
MesiaH
i dont know about people starting off in programming, but i always go with event handlers when parsing battle.net events.
March 25, 2003, 3:10 AM
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.
March 25, 2003, 3:26 AM
MailMan
Looks good.
March 25, 2003, 3:37 AM
zorm
Should use callbyname for dispatching the messages to event handlers, could cut down on code a lot by doing that.
March 25, 2003, 4:34 AM
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.
March 25, 2003, 4:47 AM
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!
March 25, 2003, 10:10 PM
St0rm.iD
ph34r, i am writing a chatbot as well.
chat4life kthnx
March 26, 2003, 12:23 AM
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.
March 29, 2003, 1:37 AM
St0rm.iD
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.
March 29, 2003, 11:01 PM
Skywing
[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6648 date=1048978918]
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.
[/quote]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.
March 30, 2003, 1:48 AM
St0rm.iD
Can you explain?
March 30, 2003, 6:57 PM
Skywing
[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6687 date=1049050655]
Can you explain?
[/quote]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.
March 30, 2003, 7:05 PM
St0rm.iD
Doesn't that require multithreading?
March 30, 2003, 7:20 PM
DrivE
I thought that it does. But then again I may be wrong.

-:DRivE:-
March 30, 2003, 7:40 PM
Skywing
[quote author=St0rm.iD link=board=17;threadid=812;start=0#msg6691 date=1049052046]
Doesn't that require multithreading?
[/quote]No. BinaryChat uses overlapped I/O and runs everything (the GUI included) in a single thread, and supports any number of bot connections per process.
March 30, 2003, 7:41 PM
DrivE
See... never listen to me when it comes to programming.

-:DRivE:-
March 30, 2003, 7:46 PM
St0rm.iD
I don't understand how that's different from select().
March 30, 2003, 10:30 PM
Skywing
[quote author=St0rm.iD link=board=17;threadid=812;start=15#msg6710 date=1049063402]
I don't understand how that's different from select().
[/quote]It's completely different. If you read the Winsock documentation, select is severely crippled under Win32.
March 30, 2003, 10:47 PM
St0rm.iD
Perhaps I'm writing in Python...;)
What exactly does overlapped I/O do though? select() for me returns a list of channels that are readable at the moment and can do non-blocking reads, I just set the select() value to 5 ms so it has a little waiting time.
March 31, 2003, 2:05 AM
Skywing
[quote author=St0rm.iD link=board=17;threadid=812;start=15#msg6729 date=1049076317]
Perhaps I'm writing in Python...;)
What exactly does overlapped I/O do though? select() for me returns a list of channels that are readable at the moment and can do non-blocking reads, I just set the select() value to 5 ms so it has a little waiting time.
[/quote]Whether you are using Python or not doesn't matter if it's on Win32, which your earlier comments suggested.

Overlapped I/O lets the system perform the I/O operations in dedicated worker threads, returning the result to you when it's completed. In Windows NT, for the most part this is what goes on already, it's just that for example ReadFile by default waits for the I/O operation to complete.

When used with sockets, you eliminate extra copying of data, thus increasing performance. Additionally, it removes the 64-socket limitation; you can have any number of pending overlapped operations per thread.
March 31, 2003, 1:17 PM

Search