is there any VB.net basic chat bot out there?

if so is it open source or could u make it priv source and help me out a little? cuz im tryin to learn wat does wat for a bnet bot and code one myself

[quote author=ExOrCizT link=board=17;threadid=2912;start=0#msg22712 date=1064970444]
is there any VB.net basic chat bot out there?

if so is it open source or could u make it priv source and help me out a little? cuz im tryin to learn wat does wat for a bnet bot and code one myself
[/quote]

You don't need to ask people for their private sources. Several programmers such as Stealth, Etheran, and DarkMinion have released some of their older source codes to the public for educational purposes.

[Edit]However, if you are trying to simply leech a bunch of code for a bot with your name on it, don't bother as Stealth (I'm not sure about EthBot and DMBot) will not compile... they are for LEARNING only.

im not tryin to leach... i wanna learn :D and stealth bot and all those are vb6....

Well, VB.net will convert them from VB6.. and tell you about any errors it encountered

With the advertised "95% automatic, 5% manual" conversion needed, that 5% could be hard with a lack of experiance in the language.
[edit]
Of course that 5% could also help you learn the language better too :P

As I've mentioned on this board, I'm developing a pluggable API that you could use... I've got it connecting to SC/BW right now, working on WC2 and D2 next, then LoD, WC3, and TFT. It's written in C#.

I'm not willing to give you my source - considering it took me 2 months to figure out - but I am willing to share the API DLL with you.

Basically, you provide the API file with your settings - bnet server, name and password, bnls user and password, etc, cd keys, yadda yadda. Create a Connection class, inherit its EventHost class, which fires off events.

I'm still working some bugs out - it gets one of every 3 or so packets when they're transferred in burst, and so the channel list doesn't get everything right away. I'm working on that.

i guess thats better than nothing...
see im learning it in Skoo and our teacher dont kno sh**.. all she does is read outta the book.... i wish we had a teacher that actually knows .net
She knows HTML really good.. my friend is in her class but when it comes to .net she sucks..

this is my first programming language... html dont count ;P and i dont kno that much about it... i kno some basics but thats about it.. anyone kno some good places for me to learn VB.NET once i learn VB.net and make some progs i wanna learn C++.net ... but thats later on in a year or two

[quote author=Myndfyre link=board=17;threadid=2912;start=0#msg22734 date=1064988000]
I'm still working some bugs out - it gets one of every 3 or so packets when they're transferred in burst, and so the channel list doesn't get everything right away. I'm working on that.[/quote]Sounds like you're not buffering up messages properly. Check that you follow a procedure similar to this:

(1) Concatenate all new data onto the end of any old unprocessed data.
(2) If length of the whole is below 4, break (you don't have a full packet yet).
(3) Extract the second two bytes (at offsets [2] and [3]) as a little endian 16-bit value. If the length of the whole is below this value, break (you have a BNCS packet header, but you don't have the entire message).
(4) Process the message, and strip off from the head a number of bytes equal to the value of the aforementioned little endian. Loop back to (2).

This procedure will eventually process all received data and break (note that zero is below 4, so if there were only whole packets, this still works fine).

Something like this. It's C, but you should get the idea.

[quote author=Kp link=board=17;threadid=2912;start=0#msg22748 date=1065040997](1) Concatenate all new data onto the end of any old unprocessed data.[/quote]
[code]int n;

n = recv( BinaryBotSocket, (char *)(lpbyRecvBuffer + nBufferLen), sizeof(lpbyRecvBuffer) - nBufferLen, 0);[/code]
[quote](2) If length of the whole is below 4, break (you don't have a full packet yet).[/quote]
[code]nBufferLen += n;

while ( nBufferLen >= 4 ) {[/code]
[quote](3) Extract the second two bytes (at offsets [2] and [3]) as a little endian 16-bit value. If the length of the whole is below this value, break (you have a BNCS packet header, but you don't have the entire message).[/quote]
[code]WORD PacketLen = *(LPWORD)( lpbyRecvBuffer + 2 );
if ( PacketLen > nBufferLen ) {
break;
}[/code]
[quote](4) Process the message, and strip off from the head a number of bytes equal to the value of the aforementioned little endian. Loop back to (2).[/quote]
[code]DoStuffWithPacket( lpbyRecvBuffer, PacketLen );

nBufferLen -= PacketLen;
memmove( lpbyRecvBuffer, lpbyRecvBuffer + PacketLen, nBufferLen );
}[/code]

There's some additional error checking you might want to do, but that's the gist of the process.

Thanks for the help guys, but I actually today figured out what the problem was. I saved all received data buffers (buffering is done automatically in .NET) directly into a raw file. Looking at it, it turns out that for whatever reason, bnet can transfer one, two, or three packets in one buffer burst. So what I'll do is retrieve the first packet out of the transfer, and once I've got that data, put the rest of the data back into the front of the buffer to be processed.

As soon as I have this stuff fixed, the bot will be fully functional in the way of chatting on SC, BW, WC2, D2 Classic, and JStr. I have a LOT of UI features I'm planning on implementing - but this is independent of the chat API. I'm also planning on getting LoD, W3, and TFT support in there, as well as realms.

To the dude thinking about learning VB.NET - check out the GotDotNet website @ http://www.gotdotnet.com/ . They have a ton of great stuff, particularly message boards and user samples. I would personally learn C# along with VB.NET if you're going to learn VB.NET - not having a background in object-oriented programming, it helped me immensly. Pick up the book C# for the .NET Platform. It explains all the relevant terms and concepts - so for example, if you know a method is marked "virtual" in C# or in some API documentation, that means that it is "Overridable" in VB7. You know that an "abstract" member is implemented as "MustOverride" in VB7 because an inheriting class must override an abstract member. You understand what the "Overrides" and "Overloads" keywords mean and why they are used. The list goes on.

The point is - in C#, you _don't_ need to know what a lot of these terms mean; you can write a class without marking any of these and you mostly won't have a problem; however, VB enforces the use of "Overrides," "Overridable," "Overloads," and "Overloadable". I don't understand why MS would put such a huge array of keywords in a single programming language.... Not to say that it is ineffective for newbs, but the target audience was definitely a group that had OOP experience.

I'd be careful assuming that you only get 3 packets at once. I'm pretty sure I remember getting larger numbers of packets jumbled together when joining large (i.e. 30+ user) channels.

i think im gonna get the vb.net book out by microsoft...1600 pages heh ;D
http://www.amazon.com/exec/obidos/tg/detail/-/0735613753/ref=lib_dp_TBCV/002-7848044-9268048?v=glance&s=books&vi=reader&img=73#reader-link
look good?

Edit - Use the [ url ] tags when pasting URLs which have lost-linking.

[quote author=Zakath link=board=17;threadid=2912;start=0#msg22765 date=1065053795]
I'd be careful assuming that you only get 3 packets at once. I'm pretty sure I remember getting larger numbers of packets jumbled together when joining large (i.e. 30+ user) channels.
[/quote]

I know - what I intend to do is this - I'm using an ArrayList right now to hold the data in the order that it was received. Each buffer stuck into the arraylist is a byte[]. So:

[code]
private void ParsePacket(byte[] data)
{
if (data.Length > 0)
{
byte pid = data[1];
short len = BitConverter.ToInt16(data, 2);
byte[] work = new byte[len - 4];
byte[] remain = new byte[data.Length - len];
// copy bytes from the buffer back into the arraylist to be processed next
// pseudo-recursive operations on the data in the buffer.
Array.Copy(data, len + 1, work, 0, data.Length - len);
this.alIncomingEvents.Insert(0, remain);
Array.Copy(data, 4, work, 0, len - 4);
ParseEvents(pid, len, work);
}
else
{
// check to see if we have received several 0-length packets
// in a row - could indicate a disconnect
}
}
[/code]

[quote author=Myndfyre link=board=17;threadid=2912;start=0#msg22763 date=1065052246]Thanks for the help guys, but I actually today figured out what the problem was. I saved all received data buffers (buffering is done automatically in .NET)[/quote]There is a layer of buffering done directly by the OS for you on any stream socket. Is this what you meant, or is .NET wasting extra resources by rebuffering beyond that?

[quote author=Myndfyre link=board=17;threadid=2912;start=0#msg22763 date=1065052246]Looking at it, it turns out that for whatever reason, bnet can transfer one, two, or three packets in one buffer burst. So what I'll do is retrieve the first packet out of the transfer, and once I've got that data, put the rest of the data back into the front of the buffer to be processed.[/quote]Isn't that what I told you to do in the first place? :) Anyway, that behavior is not bnet's fault. It's inherent in the design of TCP as a byte stream. You're guaranteed the data all arrives and in the same order it was sent, but there's no provision in TCP for the application to discover how many sends it took for the message to enter the network. The sender could theoretically call send on one byte at a time - it'd be very inefficient, but as long as the entire message is inserted in order, TCP will deliver it in order and we can receive it back out in however many calls we want.

Also, I find the implementation of your parsing code to be greatly amusing. It is approximately the same length as my C implementation, except mine does no extra memory allocations, and performs copies only when absolutely necessary (which is generally quite rare due to how I handle incoming messages :)). It's not your fault your parser is so much less efficient, at least not directly. It's the fault of your choice of language. :) Am I correct to assume that, like Java, .NET lacks the concept of pointer arithmetic? If it has such a concept, your code could potentially be improved quite a bit performance-wise.

[quote author=ExOrCizT link=board=17;threadid=2912;start=0#msg22774 date=1065060499]
i think im gonna get the vb.net book out by microsoft...1600 pages heh ;D[/quote]

Francesco Balena is a well respected heavyweight in Visual Basic. He's contributed to nearly everything of substance since VB3 days or earlier. You could do worse than read what he has to say. But I don't know how well he teaches, having never read one of his books.

[quote author=Kp link=board=17;threadid=2912;start=0#msg22785 date=1065065554]
There is a layer of buffering done directly by the OS for you on any stream socket. Is this what you meant, or is .NET wasting extra resources by rebuffering beyond that?
[/quote]
Well, they *call* it a buffer, and so I've just more or less gone with the flow.... In reality, I'm supposed to declare a byte[] and the system transfers the received data into the byte[], where I then get to parse it into Unicode or ASCII or UTF-8... or just the dwords, etc. Buffering is done by the system, I just get the data.

[quote author=Kp link=board=17;threadid=2912;start=0#msg22785 date=1065065554]Isn't that what I told you to do in the first place? :)[/quote]
Well, I don't know, I guess I misunderstood what you meant....

[quote author=Kp link=board=17;threadid=2912;start=0#msg22785 date=1065065554]Also, I find the implementation of your parsing code to be greatly amusing. It is approximately the same length as my C implementation, except mine does no extra memory allocations, and performs copies only when absolutely necessary (which is generally quite rare due to how I handle incoming messages :)). It's not your fault your parser is so much less efficient, at least not directly. It's the fault of your choice of language. :) Am I correct to assume that, like Java, .NET lacks the concept of pointer arithmetic? If it has such a concept, your code could potentially be improved quite a bit performance-wise.
[/quote]
Not exactly.... Essentially, the *common type system* doesn't support pointers; however, a language can support pointers. In my case, using C#, I *could* use pointers, but I'd have to enable "unsafe code support" in the compiler. The class library doesn't really provide much in the way of pointers, either, so I don't see what the big deal is. Eh, I'm not overtly concerned about performance right now - it's actually running fairly well. I might rewrite it to Managed C++ for the next version - but that will be once I *learn* C++. =) I just got pointer arithmetic down a couple weeks ago.

I'm having trouble getting WC3 (standard) to authenticate. Here are my packet orders:

BNLS_AUTHORIZE (0x0e)
BNLS_AUTHORIZEPROOF (0x0f)
SID_AUTH_INFO (0x50)
BNLS_VERIFYSERVER (0x11) -- I'm getting a failure back here, although I might be copying the data wrong.
BNLS_CDKEY (0x01)
SID_AUTH_CHECK (0x51)
BNLS_HASHDATA (0x0b)
SID_LOGINRESPONSE2 (0x3a) -- I don't think I'm getting quite this far.

This works for SC, BW, W2, D2, and (I assume) JStr. Any ideas?

Thanks!

--Rob

[quote author=Myndfyre link=board=17;threadid=2912;start=15#msg22800 date=1065075776]
I might rewrite it to Managed C++ for the next version - but that will be once I *learn* C++. =) I just got pointer arithmetic down a couple weeks ago.
[/quote]


Don't bother -- Managed C++ is good if you have some c++ library that you want to quickly port to .NET or need to do things .NET has trouble with. IMO, if you want managed code, stick with C#; if you want unmanaged, use C/C++. If you want both, write a dll or write only the required assemblies in managed c++.

[quote author=Kp link=board=17;threadid=2912;start=0#msg22785 date=1065065554]...The sender could theoretically call send on one byte at a time...
[/quote]
I've seen that happen with Telnet, makes it very annoying to read packet logs!

I would check the endianness of the server IP address that send to BNLS. This should be in network byte order (I don't think anyone stores IP addresses as little endian doublewords).

You cannot use the old-style login method with Warcraft III; the server requires that you use NLS. You should make the decision on whether or not to use NLS based on the SID_AUTH_INFO reply sent to you by Battle.net.

I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks

[quote author=TriCk link=board=17;threadid=2912;start=15#msg23157 date=1065428276]
I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks
[/quote]
You are intended to use sockets for serious network programming with .NET. This means that keeping track of the 'connection state' is up to you.

[quote author=Skywing link=board=17;threadid=2912;start=15#msg23181 date=1065460041]
[quote author=TriCk link=board=17;threadid=2912;start=15#msg23157 date=1065428276]
I have realised a few things on .NET that are different ...
For instance... u can't get the Winsock's Connection State ... i tried on .NET and gave up due to the amount of things that i just couldnt figure out using winsocks
[/quote]
You are intended to use sockets for serious network programming with .NET. This means that keeping track of the 'connection state' is up to you.
[/quote]

Aye.... Until I started working with Sockets for my bot project, I hardly understood what a byte[] was. I'm glad, though, that I started this project before I got into my Assembler class... Now I know about endian-ness and all that good stuff ahead of time. =D