• Welcome to Valhalla Legends Archive.
 

.net...

Started by ExOrCizT, September 30, 2003, 08:07 PM

Previous topic - Next topic

ExOrCizT

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

Hazard

#1
Quote from: ExOrCizT on September 30, 2003, 08:07 PM
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

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.

"Courage is being scared to death - but saddling up anyway." --John Wayne

ExOrCizT

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

iago

Well, VB.net will convert them from VB6.. and tell you about any errors it encountered
This'll make an interesting test for broken AV:
QuoteX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*


Hitmen

#4
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

MyndFyre

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.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

ExOrCizT

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

Kp

Quote from: Myndfyre on October 01, 2003, 01:00 AM
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.
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).
[19:20:23] (BotNet) <[vL]Kp> Any idiot can make a bot with CSB, and many do!

Zakath

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

Quote from: Kp on October 01, 2003, 03:43 PM(1) Concatenate all new data onto the end of any old unprocessed data.
int n;

n = recv( BinaryBotSocket, (char *)(lpbyRecvBuffer + nBufferLen), sizeof(lpbyRecvBuffer) - nBufferLen, 0);

Quote(2) If length of the whole is below 4, break (you don't have a full packet yet).
nBufferLen += n;

while ( nBufferLen >= 4 ) {

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).
WORD PacketLen = *(LPWORD)( lpbyRecvBuffer + 2 );
if ( PacketLen > nBufferLen ) {
break;
}

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).
DoStuffWithPacket( lpbyRecvBuffer, PacketLen );

nBufferLen -= PacketLen;
memmove( lpbyRecvBuffer, lpbyRecvBuffer + PacketLen, nBufferLen );
}


There's some additional error checking you might want to do, but that's the gist of the process.
Quote from: iago on February 02, 2005, 03:07 PM
Yes, you can't have everybody...contributing to the main source repository.  That would be stupid and create chaos.

Opensource projects...would be dumb.

MyndFyre

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.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Zakath

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 from: iago on February 02, 2005, 03:07 PM
Yes, you can't have everybody...contributing to the main source repository.  That would be stupid and create chaos.

Opensource projects...would be dumb.

ExOrCizT

#11
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.

MyndFyre

Quote from: Zakath on October 01, 2003, 07:16 PM
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 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:


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
     }
}
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Kp

Quote from: Myndfyre on October 01, 2003, 06:50 PMThanks 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)
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 from: Myndfyre on October 01, 2003, 06:50 PMLooking 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.
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.
[19:20:23] (BotNet) <[vL]Kp> Any idiot can make a bot with CSB, and many do!

Grok

Quote from: ExOrCizT on October 01, 2003, 09:08 PM
i think im gonna get the vb.net book out by microsoft...1600 pages heh ;D

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.