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]SOCKET.getdata data, vbstring[/code]
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.

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

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.

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

[quote author=Tontow link=topic=12149.msg119742#msg119742 date=1120861386]what would be considered bad bot programming practice.[/quote]

Using VB to develop a bot. ;)

[quote author=Tontow link=topic=12149.msg119742#msg119742 date=1120861386]Everyone also seems to use the exact same addchat and packet buffer class; is this good bot programming practice?[/quote]

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.

[quote author=Tontow link=topic=12149.msg119742#msg119742 date=1120861386]Is using vbstring good bot programming practice?[/quote]

See above re: good bot programming practice.

[quote author=Tontow link=topic=12149.msg119742#msg119742 date=1120861386]How many forms, classes, modules, etc do you normally use and what for?  Or dose it really even matter?[/quote]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.

[quote author=Tontow link=topic=12149.msg119742#msg119742 date=1120861386]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.[/quote]

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

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

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

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

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

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

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.


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

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?

[quote author=Tontow link=topic=12149.msg119785#msg119785 date=1120884921][quote]No forms, no modules (unless you want to count the shared objects that provide loadable extension support!).  [/quote]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.[/quote]

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.

[quote author=Tontow link=topic=12149.msg119785#msg119785 date=1120884921][quote]Why would you want to break it down?  Just pass it as a raw byte stream and let the handler do its job. [/quote]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?[/quote]

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:[list][li]detect when a full message is ready[/li][li]sanity check the message (i.e. not thousands of bytes long)[/li][li]pass the byte stream to a handler[/li][li]update the receive state to reflect that the message is no longer present.[/li][li]goto 1;[/li][/list]

[quote author=Kp link=topic=12149.msg119787#msg119787 date=1120886578]
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.
[/quote]
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.  :P

[quote author=MyndFyre link=topic=12149.msg119794#msg119794 date=1120897353]However, even though some things don't require a GUI, I know I certainly want one.  And I want it to look pimpin.  :P[/quote]

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).]

[quote author=Kp link=topic=12149.msg119787#msg119787 date=1120886578]
[list][li]detect when a full message is ready[/li][/list]
[/quote]

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

I'm guessing that I need to:

Use [code]socket.getdata data, vbArray + vbByte[/code] 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.

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.

[quote author=Tontow link=topic=12149.msg120164#msg120164 date=1121097901]
[quote author=Kp link=topic=12149.msg119787#msg119787 date=1120886578]
[list][li]detect when a full message is ready[/li][/list]
[/quote]

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

I'm guessing that I need to:

Use [code]socket.getdata data, vbArray + vbByte[/code] 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.


[/quote]

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.

A few points to make.

[list][*]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.[/list]

Hope that helps you out.

A correction to make. :)

[quote author=Dyndrilliac link=topic=12149.msg120208#msg120208 date=1121104759]
[list][*]In C/C++, a BYTE is defined as an unsigned char.[/list][/quote][pre]$ 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[/pre]

So - no, BYTE is not defined to unsigned char in C [u]or[/u] 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. :)

Not programming in VB.

(Dunno if someone already said this lol)

[quote author=Sorc.Polgara link=topic=12149.msg120288#msg120288 date=1121132584]
Not programming in VB.

(Dunno if someone already said this lol)
[/quote]

I agree!

Microsoft may have screwed up,  but…..

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/veendf98/html/defbytedatatype.asp
[quote]Byte data type
A data type used to hold positive integer numbers ranging from 0255. Byte variables are stored as single, unsigned 8-bit (1-byte) numbers.[/quote]

Yet a string is different—(At least by Microsoft’s definition):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/veendf98/html/defstringdatatype.asp
[quote]String data type
A data type consisting of a sequence of contiguous characters that represent the characters themselves rather than their numeric values. A String can include letters, numbers, spaces, and punctuation. The String data type can store fixed-length strings ranging in length from 0 to approximately 63K characters and dynamic strings ranging in length from 0 to approximately 2 billion characters. The dollar sign ($) type-declaration character represents a String in Visual Basic.[/quote]

And so the question is: Would I be better off a BYTE Array or a String/String Array? - I don't know if vbArray + vbString would be valid because only the BYTE Array type is documented on MSDN.

------------------------------------------------------------------------------------------------

What about:
[quote]
PeekData Method

Similar to GetData except PeekData does not remove data from the input queue. This method works only for TCP connections.

Syntax

object.PeekData data, [type,] [maxLen]
[/quote]
???

The Beginning of every header is 0xFF (1 byte).  And then that is followed by the Message ID (1 byte). 
That is then followed by the Packet length which is a WORD (2 bytes. This tells me that I need to grab 4 bytes.

[quote author=rabbit link=topic=12149.msg120169#msg120169 date=1121099107]
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.
[/quote]

Wait a sec.  If the objective is to keep from combining the end and beginning of two packets without losing data then wouldn’t the following be better?

Keep in mind that:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mswnsk98/html/vbmthgetdatawinsock.asp
[quote]It's common to use the GetData method with the DataArrival event, which includes the totalBytes argument. If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 [u]indicating that the remaining bytes will be lost.[/u][/quote]

Well, that’s no good because I can’t retrieve a single packet and remove that packet from the input queue without risking the loss of data, -- (PeekData wouldn’t work either because of it doesn’t remove the packet from the input queue) ; I think this is why you need to write your own receive buffer. 
And that receive buffer should have the equivalents to—(for ease of use)–: BytesReceived Property, PeekData Method, GetData Method and DataArrival Event. 
All I need from the Winsock buffer is GetData and trash the rest of the Winsock buffer and write my own buffer that lets me
[quote author=Kp link=topic=12149.msg119787#msg119787 date=1120886578]
[list][li]detect when a full message is ready[/li][li]sanity check the message (i.e. not thousands of bytes long)[/li][li]pass the byte stream to a handler[/li][li]update the receive state to reflect that the message is no longer present.[/li][li]goto 1;[/li][/list]
[/quote]
with ease.

So I should:

Use my equivalent to object.BytesReceived to check and make shore that you have received the required 4 bytes of the header. – I’m thinking that you only need to go that far since you only need the packet length to get the rest of the packet.

If my equivalent to object.BytesReceived is greater than or equal to 4 then I use my equivalent  to object.PeekData to retrieve the Packet length. 
If my equivalent to object.BytesReceived is less than 4 then I just need to wait until my equivalent to object.BytesReceived is greater than or equal to 4.

Then once my equivalent to object.BytesReceived is greater than or equal to the Packet Length I would use my equivalent to GetData to retrieve that single packet,( and remove that packet from the my input queue without risking the loss of data),  and pass the packet to my data handler.  I should also do a sanity check on the message somewhere along the line as Kp suggested.


(PS: please excuse any grammar or spelling mistakes; it is late and has been a very long day.)

[quote author=Kp link=topic=12149.msg120284#msg120284 date=1121131376]
A correction to make. :)

So - no, BYTE is not defined to unsigned char in C [u]or[/u] 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. :)[/quote]

My apologies Kp. I should have mention I was referring to Win32 systems.

[quote author=Tontow link=topic=12149.msg120327#msg120327 date=1121157142]
The Beginning of every header is 0xFF (1 byte).  And then that is followed by the Message ID (1 byte). 
That is then followed by the Packet length which is a WORD (2 bytes. This tells me that I need to grab 4 bytes.

[quote author=rabbit link=topic=12149.msg120169#msg120169 date=1121099107]
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.
[/quote]

Wait a sec.  If the objective is to keep from combining the end and beginning of two packets without losing data then wouldn’t the following be better?[/quote]You know where a packet starts, so you can get the first header by looking for the first 0xff recieved.  The byte after that is the packet id, and then the next two bytes are the length.  If your current buffer length < 4, you don't have a header.  If it's >= 4, does it == packet length?  If yes, move it to the parser and remove it from the data buffer, and repeat.

[quote author=rabbit link=topic=12149.msg120394#msg120394 date=1121206853]

You know where a packet starts, so you can get the first header by looking for the first 0xff recieved.  The byte after that is the packet id, and then the next two bytes are the length.  If your current buffer length < 4, you don't have a header.  If it's >= 4, does it == packet length?  If yes, move it to the parser and remove it from the data buffer, and repeat.
[/quote]

Yes--(Isn't that what I said that I was going to use my equivalent to object.BytesReceived for?  Or at least close to it)--, but what I'm saying is that I can't use Winsock's socket.getdata to retreave a single packet because "If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 indicating that the remaining bytes will be lost" ; and if i lose a few bytes form the header of the next packet then I'm screwed......

[quote author=Dyndrilliac link=topic=12149.msg120331#msg120331 date=1121163270][quote author=Kp link=topic=12149.msg120284#msg120284 date=1121131376]So - no, BYTE is not defined to unsigned char in C [u]or[/u] 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. :)[/quote]My apologies Kp. I should have mention I was referring to Win32 systems.[/quote]

So was I.  That was output from a Windows system using MinGW special 20030804-1. :)

Tontow: are you certain that the item you quoted is related to TCP?  It's common for UDP sockets to lose the tail of a message if you recv with too small a buffer, but I've never heard of a TCP implementation that loses data like that.  Apparently I'm classified as a robot, so I cannot access the Microsoft documentation to verify/disprove what you quoted.

[quote author=Tontow link=topic=12149.msg120414#msg120414 date=1121209868]
[quote author=rabbit link=topic=12149.msg120394#msg120394 date=1121206853]

You know where a packet starts, so you can get the first header by looking for the first 0xff recieved.  The byte after that is the packet id, and then the next two bytes are the length.  If your current buffer length < 4, you don't have a header.  If it's >= 4, does it == packet length?  If yes, move it to the parser and remove it from the data buffer, and repeat.
[/quote]

Yes--(Isn't that what I said that I was going to use my equivalent to object.BytesReceived for?  Or at least close to it)--, but what I'm saying is that I can't use Winsock's socket.getdata to retreave a single packet because "If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 indicating that the remaining bytes will be lost" ; and if i lose a few bytes form the header of the next packet then I'm screwed......
[/quote]You will only lose data if your implementation is wrong :P

[quote author=rabbit link=topic=12149.msg120463#msg120463 date=1121228644]
You will only lose data if your implementation is wrong :P
[/quote]
[quote author=Kp link=topic=12149.msg120434#msg120434 date=1121218051]
Tontow: are you certain that the item you quoted is related to TCP?  It's common for UDP sockets to lose the tail of a message if you recv with too small a buffer, but I've never heard of a TCP implementation that loses data like that.  Apparently I'm classified as a robot, so I cannot access the Microsoft documentation to verify/disprove what you quoted.
[/quote]

Ok, here is a quote of the full page (via Ctrl+A, Ctrl+V):

[quote]
   MSDN Home >  MSDN Library >  Development Tools and Languages >  Visual Studio 6.0 >  Visual Basic 6.0 >  Reference >   
Visual Basic: Winsock Control

GetData Method (WinSock Control)
See Also    Example    Applies To

Retrieves the current block of data and stores it in a variable of type variant.

Return Value

Void

Syntax

object.GetData data, [type,] [maxLen]

The GetData method syntax has these parts:

Part  Description
object An object expression that evaluates to an object in the Applies To list.
data Where retrieved data will be stored after the method returns successfully. If there is not enough data available for requested type, data will be set to Empty.
type Optional. Type of data to be retrieved, as shown in Settings.
maxLen Optional. Specifies the desired size when receiving a byte array or a string. If this parameter is missing for byte array or string, all available data will be retrieved. If provided for data types other than byte array and string, this parameter is ignored.


Settings

The settings for type are:

Description Constant
Byte vbByte
Integer vbInteger
Long vbLong
Single vbSingle
Double vbDouble
Currency vbCurrency
Date vbDate
Boolean vbBoolean
SCODE vbError
String vbString
Byte Array vbArray + vbByte


Remarks

It's common to use the GetData method with the DataArrival event, which includes the totalBytes argument. If you specify a maxlen that is less than the totalBytes argument, you will get the warning 10040 indicating that the remaining bytes will be lost.


Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
© 2005 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks |Privacy Statement 
 

[/quote]

Why not create a secondary buffer for the data to be lost? Place it in there and access it when you need it.

[quote author=Dyndrilliac link=topic=12149.msg120491#msg120491 date=1121258048]
Why not create a secondary buffer for the data to be lost? Place it in there and access it when you need it.
[/quote]

Please take the time to read reply #16 carfully.........

Tontow: based on all the things you've posted, I don't see the problem.  If you specify a max length argument, then no more than that can be returned.  So why specify the max length?  Leave it blank and let the system return as much data as it can!

But wouldn't it be better/faster if I eliminate the need for a secondary buffer?  Why double buff when you can avoid it?

Well, first and foremost I always like to throw a little code out here and there:

[code]
    'string
    Dim strData As String
    wsSocket.GetData strData, vbString, bytesTotal

    'byte array
    Dim bytData() As Byte
    wsSocket.GetData bytData, vbArray, bytesTotal
[/code]

The obvious improvement would be memory usage.  A byte array to hold the data is going to be twice as effecient when it comes to storage.

As for speed and other reasons why?  You figure that out? :P

[quote author=Tontow link=topic=12149.msg120824#msg120824 date=1121400218]But wouldn't it be better/faster if I eliminate the need for a secondary buffer?  Why double buff when you can avoid it?[/quote]

I find it absolutely hilarious that someone determined to do this in VB cares about speed.  VB is meant to be written quickly and run slowly.  If you care about performance, use a real language.

Nothing wrong with using vb to the max while you're programming in it ;)

[quote author=Kp link=topic=12149.msg120963#msg120963 date=1121480864]
[quote author=Tontow link=topic=12149.msg120824#msg120824 date=1121400218]But wouldn't it be better/faster if I eliminate the need for a secondary buffer? Why double buff when you can avoid it?[/quote]

I find it absolutely hilarious that someone determined to do this in VB cares about speed. VB is meant to be written quickly and run slowly. If you care about performance, use a real language.
[/quote]

:P :P :P

[quote author=Warrior link=topic=12149.msg120965#msg120965 date=1121481338]
Nothing wrong with using vb to the max while you're programming in it ;)
[/quote]

Thank you.  I believe that everything can be translated from one programming language to another, including both good and bad programming habits.  Thus, I want to do the best job I possibly can instead of producing something that looks like I wiped my ass with.

[quote author=Tontow link=topic=12149.msg120967#msg120967 date=1121482117]
Thank you.  I believe that everything can be translated from one programming language to another, including both good and bad programming habits.  Thus, I want to do the best job I possibly can instead of producing something that looks like I wiped my ass with.
[/quote]
Still, though, there are different kind of habits used in different settings.  I again reiterate that [u]Code Complete[/u] is an invaluable resource.  Your habits should reflect what you're going for -- code reuse, code portability, RAD.  My current project is aiming primarily for code reuse and portability, and so almost everything that I'm designing is deliberate, structured, and abstract.  If you're using RAD, you might not worry about code portability (for example, in my project, I have generic collections for compilation in .NET 2.0.  I pretty much only write code in VS.NET 2003 (.NET 1.1), but whenever 2.0 is released, I'll be ready to support either platform.

[quote author=UserLoser link=topic=12149.msg120180#msg120180 date=1121100347]
[quote author=Tontow link=topic=12149.msg120164#msg120164 date=1121097901]
[quote author=Kp link=topic=12149.msg119787#msg119787 date=1120886578]
[list][li]detect when a full message is ready[/li][/list]
[/quote]

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

I'm guessing that I need to:

Use [code]socket.getdata data, vbArray + vbByte[/code] 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.


[/quote]

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.
[/quote]

I use Socket.PeekData(Data, vbString) first to check if there is any data.

[quote author=DDA-TriCk-E link=topic=12149.msg124488#msg124488 date=1124235686]
I use Socket.PeekData(Data, vbString) first to check if there is any data.
[/quote]

What's the point?  The DataArrival event will only be fired if there's any data received