Valhalla Legends Archive

Well, I'm guessing it's all clumped packets together but I could be mistaken.

I'm mainly having trouble joining a channel with 20 people or more.

This is what happens.
http://www.bloodynub.com/files/bots/owns/DebugLog.txt
http://www.bloodynub.com/files/bots/owns/OwNs.jpg

If you look at the debug log you'll see that my userlist (which is a listview) is missing quite a few people, along with the user messages.

It seems to me it's something to do with the massive clumped packets.
99% of the time I don't receive any info messages logging on "Welcome to battle.net", "This server is hosted by", ect.


If anyone can help me troubleshoot this I would be most grateful.
I've been trying to figure this out for a few days.

Any information that I'm lacking in this message that might help just ask.

Crap, I thought I put that in, sorry.
here it is:

Private Sub sckBNet_DataArrival(ByVal bytesTotal As Long)
   On Error Resume Next
   Dim strBuffer As String, TempRecv As String, lngLen As Long
   Dim recv As New RecvBuffer
   frmMain.sckBNet.GetData TempRecv, vbString
   DebugOutput TempRecv, "recv"
   strBuffer = strBuffer & TempRecv
   While Len(strBuffer) > 4
       lngLen = Val("&H" & StrToHex(StrReverse(Mid$(strBuffer, 3, 2))))
       If Len(strBuffer) < lngLen Then: Exit Sub
       recv.OnRecieve Left$(strBuffer, lngLen), frmMain.sckBNet
       strBuffer = Mid$(strBuffer, lngLen + 1)
   Wend
End Sub


It's that I'm not recieving clumped packets well at all. generally like it shows in my DebugLog where it lists the users where it comes in 2 big clumped packets.

Before I attempt to help you.....lemme get this straight...
You are not receiving ID_INFO [&H12] correctly? Or is it...
you are not receiving ID_USER [&H1] correctly?

Your problem is that you have to use the length of the packet to complete it.  So if you see this:
FF 0F 00 10 00 00 00 00
You know that you HAVE to wait for the next next 8 bytes (no more, no less) to arrive, then process them and wait for the next packet.  If it's already there, even better.

He is saying that his packet receiving function is not parsing out multiple packets correctly and therefore he frequently loses data.  Post your oh this is sad I dont even remember the VB socket receive event but post that thing where you copy the received data into a buffer and parse it.

not sure if you would be able to tell i edited this from the botdev index, so check my edit. I'll reply from now on.

Might also wanna format your milisecond timestamps to the hundred form to make your bot text aligned and purty.

You're strBuffer should be a static variable or else you wont be able to parse any packets that come in pieces rather than whole...


Dim strBuffer As String

should be

Static strBuffer as String


Yeah, LoRd that has been pissin me off, just to worried about other stuff to fix it.
Lenny, i bet you're absolutely right, let me go try that.
Success! Thank you Lenny.. I figured it was probably something stupid like that I wouldn't notice.
As I'm sure you can probably tell I'm just a beginner (newb) when it comes to programming.. Thanks so much

You need to store the number of bytes that your socket actually received, and also store the asserted packet length that is found within the packet.  When your parsing function begins to check a packet, if the asserted length is less than what you actually received, you must store the incomplete data and wait for more data to come in via your socket.

It's not as hard as it sounds, just have to do it right...my parsing function will return 0 if the buffer holds nothing but complete packets, and then the buffer will be cleared, if it returns > 0, the buffer will not be cleared, and the bot will wait for more data.

Shouldn't do > 4, some packets like SID_NULL may only be 4 bytes long and shouldn't be ignored

Actually, SID_NULL should be ignored

Quote from: iago on March 17, 2004, 06:55 PM
Actually, SID_NULL should be ignored

Why?

I try to be like the real game client as much as possible, in my opinion, so should other bots. I believe it's best to support every message that you can and handle them properly

Edit:

Ok, better example: 0x59

Quote from: UserLoser. on March 17, 2004, 06:39 PM
Shouldn't do > 4, some packets like SID_NULL may only be 4 bytes long and shouldn't be ignored

I wouldn't use such a check either.
However.. It isn't really ignored.
It will get "processed" as soon as another packet arrives.

Add-On:

That is.. if you don't clear the buffer
like in the example given by uh.. whats his name..

Quote from: o.OV on March 17, 2004, 07:14 PM

Quote from: UserLoser. on March 17, 2004, 06:39 PM
Shouldn't do > 4, some packets like SID_NULL may only be 4 bytes long and shouldn't be ignored

I wouldn't use such a check either.
However.. It isn't really ignored.
It will get "processed" as soon as another packet arrives.

But then wouldn't the following packet not be processed?

I'd then be something below be parsed?:

FF 00 04 00 <other packet>

Quote from: UserLoser. on March 17, 2004, 07:21 PM

Quote from: o.OV on March 17, 2004, 07:14 PM

Quote from: UserLoser. on March 17, 2004, 06:39 PM
Shouldn't do > 4, some packets like SID_NULL may only be 4 bytes long and shouldn't be ignored

I wouldn't use such a check either.
However.. It isn't really ignored.
It will get "processed" as soon as another packet arrives.

But then wouldn't the following packet not be processed?

I'd then be something below be parsed?:

FF 00 04 00 <other packet>

huh? what are you talking about.
In the example by fuzz
it allows the null packet to sit in the buffer
without actually entering the loop
until another packet arrives which
adds to the length of the buffer so len(buffer) > 4
then it starts to process.