[VB] Good Bot Programming Practices?

[Tontow]

 I consider myself a to be somewhere between a moderate Visual Basic programmer and  I would like to discuss and learn what would be considered good bot programming practice and what would be considered bad bot programming practice.

From what I have read in the forums,  using CleanSlate or any form of it is considered bad practice. 

Also, it seems that everyone prefers to use some form of  C to program a bot; I myself would use some form of C# to program my bot, but I'm a C# newb and I know Visual Basic allot better.

Everyone also seems to use the exact same addchat and packet buffer class; is this good bot programming practice?

I also see the following code in allot of open source bots:

Code Select Expand

SOCKET.getdata data, vbstring
Is using vbstring good bot programming practice?

How many forms, classes, modules, etc do you normally use and what for?  Or dose it really even matter?

What is the best way to break down or phrase data before you pass it to wherever you handle your chat events and packet data.

[iago]

Doing something that's already been done to death is boring.  Think of something new that nobody's done

[Warrior]

You use as much forms/classes/modules as you need, of course each programmer has different methods of programming. Just use them how you feel they should be used.

[MyndFyre]

I highly recommend Code Complete.  It's one of the best books on programming practices that I've ever read.

[Kp]

what would be considered bad bot programming practice.

Using VB to develop a bot.

Everyone also seems to use the exact same addchat and packet buffer class; is this good bot programming practice?

Correction: the people who go throwing source at a problem all (instead of explaining it) all seem to use the exact same addchat etc.  Those of us who stand back and offer higher level advice have much nicer constructs.  For instance, I have no equivalent to AddChat at all, because it doesn't make sense in my design model.  My approximation of a "packet buffer" is also quite different, and uses far fewer calls to achieve the same goals.

Is using vbstring good bot programming practice?

See above re: good bot programming practice.

How many forms, classes, modules, etc do you normally use and what for?  Or dose it really even matter?

No forms, no modules (unless you want to count the shared objects that provide loadable extension support!).  Some classes, some structs, depending on whether the type is intended to be POD or an advanced container.  Number varies by project size, but you should generally have one class per logical set of data.  That is, it makes sense to have a class for managing a socket stream, because that is a well-defined concept which can be freestanding in many environments.

What is the best way to break down or phrase data before you pass it to wherever you handle your chat events and packet data.

Why would you want to break it down?  Just pass it as a raw byte stream and let the handler do its job.

[Tontow]

Doing something that's already been done to death is boring.  Think of something new that nobody's done

True, but you must do what has already been done before you can do something new.

I highly recommend Code Complete.  It's one of the best books on programming practices that I've ever read.

Thanks, I'll look into getting that.   Is there a similar book for C languages?

No forms, no modules (unless you want to count the shared objects that provide loadable extension support!). 

No Forms?  How do you do you GUI then?  I really need to learn how to make a good bot GUI; my last GUI was crap.

Why would you want to break it down?  Just pass it as a raw byte stream and let the handler do its job.

Now that I think about it, that seems allot better than how I was doing it; I was treating incoming data as a string and then splitting it to get the needed data.

So I should grab the 6 32 bit DWORDs then the null terminated character array STRINGs based on there predetermined size? - I'm assuming that this method will work for both BNLS and CHAT logon types?

[Kp]

No forms, no modules (unless you want to count the shared objects that provide loadable extension support!). 

No Forms?  How do you do you GUI then?  I really need to learn how to make a good bot GUI; my last GUI was crap.

We don't need no stinkin' GUI!  Kids these days.  They think everything has to have a pretty GUI attached to it.  In my day, we understood there were some things that just didn't need a GUI.

Why would you want to break it down?  Just pass it as a raw byte stream and let the handler do its job.

Now that I think about it, that seems allot better than how I was doing it; I was treating incoming data as a string and then splitting it to get the needed data.

So I should grab the 6 32 bit DWORDs then the null terminated character array STRINGs based on there predetermined size? - I'm assuming that this method will work for both BNLS and CHAT logon types?

No, you should pass the byte stream off to the handling function raw and let it extract the necessary data.  The dispatcher's only actions should be:

• detect when a full message is ready
• sanity check the message (i.e. not thousands of bytes long)
• pass the byte stream to a handler
• update the receive state to reflect that the message is no longer present.
• goto 1;

[MyndFyre]

We don't need no stinkin' GUI!  Kids these days.  They think everything has to have a pretty GUI attached to it.  In my day, we understood there were some things that just didn't need a GUI.

While I agree with this statement, it's only to a certain extent.  Your bot's connection work should be entirely distinct and separate from your GUI -- this encourages code reuse and modularization, so if there's an error in something your bot displays, you know for sure that it's something to do with your GUI code.

However, even though some things don't require a GUI, I know I certainly want one.  And I want it to look pimpin. 

[Kp]

However, even though some things don't require a GUI, I know I certainly want one.  And I want it to look pimpin. 

GUIs do have their place, as its sometimes much nicer to present information in a GUI (or a curses-driven CUI) than to try to keep reprinting it in a logfile.  My point was that the bot's GUI should be a separate component, if created at all, rather than tightly integrated.

[Edit: forgot to point out some people's attachment to WIMP environments (see also The Jargon File, version 4.4.7).]

[Tontow]

• detect when a full message is ready

How/what would be the best way to do that?

I'm guessing that I need to:

Use

Code Select Expand

socket.getdata data, vbArray + vbByte to retrieve the data as a byte array.

And since all packets have a message length, that also includes the header, I should create an equivalent to SOCKET.BytesReceived to detect when a full message is ready.

[R.a.B.B.i.T]

Although that may work, it's not recommended (if you have packet fragments, you might combine the end and beginning of two packets).  You should read data, get the size from the header, wait for that much more - 4, then send that to the parser.  Data after that will be another bundled packet, so just do the same thing.

[UserLoser.]

• detect when a full message is ready

How/what would be the best way to do that?

I'm guessing that I need to:

Use

Code Select Expand

socket.getdata data, vbArray + vbByte to retrieve the data as a byte array.

And since all packets have a message length, that also includes the header, I should create an equivalent to SOCKET.BytesReceived to detect when a full message is ready.

You're better off with Socket.GetData(Data, vbString)..  It would probably be vbArray Or vbByte anyways, and I doubt it would work also.  A byte array could be pretty much the same thing as a string.  You're using VB, so just stick to a string.

[Dyndrilliac]

A few points to make.

• In C/C++, a BYTE is defined as an unsigned char. That being said, a byte array would essentially be the same as a character array (a string). I would just stay with the string, as you're passing the same data regardless.
  
• In response to your query about vbString/vbArray/vbByte, use natively provided constants whenever possible. Constants are always better than passing the numeric counterpart. One good reason is that it makes code easier to manage, read, and understand. For example, in code checking for a hotkey, using the constant VK_MULTIPLY instead of its numeric value would tell you instantly it was tied to the Multiply key on the NumPad, speeding up debug time by not making you look up the meaning.

Hope that helps you out.

[Kp]

A correction to make.

• In C/C++, a BYTE is defined as an unsigned char.

$ cat foo.c
BYTE b;
BYTE foo() {
   return '\0';
}
$ gcc -c foo.c
foo.c:1: error: syntax error before "b"
foo.c:1: warning: data definition has no type or storage class
foo.c:2: error: syntax error before "foo"
$ mv foo.c foo.cc
$ g++ -c foo.cc
foo.cc:1: error: 'BYTE' is used as a type, but is not defined as a type.
foo.cc:2: error: syntax error before `)' token

So - no, BYTE is not defined to unsigned char in C or in C++.  In fact, it isn't defined to anything at all!  Perhaps you meant to tell him that Microsoft polluted the namespace with the identifier 'BYTE', which is typedef'd to unsigned char?  This bit of pollution is in some sense commendable, because they actually got the name correct.  Neither WORD nor DWORD are correctly named: WORD is a halfword, and DWORD is a word.  Worse, a DWORD64 is actually a doubleword.

[Sorc.Polgara]

Not programming in VB.

(Dunno if someone already said this lol)