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:
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.
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 (http://www.amazon.com/exec/obidos/tg/detail/-/0735619670/qid=1120869412/sr=8-1/ref=pd_bbs_ur_1/103-7332857-2892662?v=glance&s=books&n=507846). It's one of the best books on programming practices that I've ever read.
Quote from: Tontow on July 08, 2005, 05:23 PMwhat would be considered bad bot programming practice.
Using VB to develop a bot. ;)
Quote from: Tontow on July 08, 2005, 05:23 PMEveryone 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.
Quote from: Tontow on July 08, 2005, 05:23 PMIs using vbstring good bot programming practice?
See above re: good bot programming practice.
Quote from: Tontow on July 08, 2005, 05:23 PMHow 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.
Quote from: Tontow on July 08, 2005, 05:23 PMWhat 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.
QuoteDoing 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.
QuoteI 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?
QuoteNo 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.
QuoteWhy 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?
Quote from: Tontow on July 08, 2005, 11:55 PMQuoteNo 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.
Quote from: Tontow on July 08, 2005, 11:55 PMQuoteWhy 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;
Quote from: Kp on July 09, 2005, 12:22 AM
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. :P
Quote from: MyndFyre on July 09, 2005, 03:22 AMHowever, even though some things don't require a GUI, I know I certainly want one. And I want it to look pimpin. :P
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 (http://www.catb.org/~esr/jargon/html/W/WIMP-environment.html) (see also The Jargon File, version 4.4.7 (http://www.catb.org/~esr/jargon/)).]
Quote from: Kp on July 09, 2005, 12:22 AM
- 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
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.
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 from: Tontow on July 11, 2005, 11:05 AM
Quote from: Kp on July 09, 2005, 12:22 AM
- 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 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.
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.
A correction to make. :)
Quote from: Dyndrilliac on July 11, 2005, 12:59 PM
- 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. :)
Not programming in VB.
(Dunno if someone already said this lol)
Quote from: Sorc.Polgara on July 11, 2005, 08:43 PM
Not programming in VB.
(Dunno if someone already said this lol)
I agree!
Microsoft may have screwed up, but.....
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/veendf98/html/defbytedatatype.asp
QuoteByte 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.
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
QuoteString 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.
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]
???
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 from: rabbit on July 11, 2005, 11:25 AM
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.
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
QuoteIt'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.
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 from: Kp on July 09, 2005, 12:22 AM
- 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;
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 from: Kp on July 11, 2005, 08:22 PM
A correction to make. :)
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. :)
My apologies Kp. I should have mention I was referring to Win32 systems.
Quote from: Tontow on July 12, 2005, 03:32 AM
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 from: rabbit on July 11, 2005, 11:25 AM
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.
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?
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 from: rabbit on July 12, 2005, 05:20 PM
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.
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 from: Dyndrilliac on July 12, 2005, 05:14 AMQuote from: Kp on July 11, 2005, 08:22 PMSo - 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. :)
My apologies Kp. I should have mention I was referring to Win32 systems.
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 from: Tontow on July 12, 2005, 06:11 PM
Quote from: rabbit on July 12, 2005, 05:20 PM
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.
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......
You will only lose data if your implementation is wrong :P
Quote from: rabbit on July 12, 2005, 11:24 PM
You will only lose data if your implementation is wrong :P
Quote from: Kp on July 12, 2005, 08:27 PM
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.
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
Why not create a secondary buffer for the data to be lost? Place it in there and access it when you need it.
Quote from: Dyndrilliac on July 13, 2005, 07:34 AM
Why not create a secondary buffer for the data to be lost? Place it in there and access it when you need it.
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:
'string
Dim strData As String
wsSocket.GetData strData, vbString, bytesTotal
'byte array
Dim bytData() As Byte
wsSocket.GetData bytData, vbArray, bytesTotal
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 from: Tontow on July 14, 2005, 11:03 PMBut wouldn't it be better/faster if I eliminate the need for a secondary buffer? Why double buff when you can avoid it?
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 from: Kp on July 15, 2005, 09:27 PM
Quote from: Tontow on July 14, 2005, 11:03 PMBut wouldn't it be better/faster if I eliminate the need for a secondary buffer? Why double buff when you can avoid it?
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.
:P :P :P
Quote from: Warrior on July 15, 2005, 09:35 PM
Nothing wrong with using vb to the max while you're programming in it ;)
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 from: Tontow on July 15, 2005, 09:48 PM
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.
Still, though, there are different kind of habits used in different settings. I again reiterate that
Code Complete 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 from: UserLoser on July 11, 2005, 11:45 AM
Quote from: Tontow on July 11, 2005, 11:05 AM
Quote from: Kp on July 09, 2005, 12:22 AM
- 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 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.
I use
Socket.PeekData(Data, vbString) first to check if there is any data.
Quote from: DDA-TriCk-E on August 16, 2005, 06:41 PM
I use Socket.PeekData(Data, vbString) first to check if there is any data.
What's the point? The DataArrival event will only be fired if there's any data received