What is 0x42?
0x42 - SID_CDKEY3 D2 beta? Not sure though.
Hurem, I dont think its for D2, I think its for W2BN, But im not sure either
Was it sent to you? and at what point? Packet log?
Yes it was sent to me, and it was apon enter chat, and packet log is:
Unidentified Packet: 0x42
4E 42 32 57 20 30 20 30 20 38 36 20 30 20 30 20 NB2W 0 0 86 0 0
30 20 30 20 30 20 4E 42 32 57 00 FF 0F 3B 00 01 0 0 0 NB2W ;
00 00 00 00 00 00 00 6E 00 00 00 00 00 00 00 0D n
F0 AD BA 0D F0 AD BA 4E 69 4E 65 00 4E 42 32 57 NiNe NB2W
20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 0 0 0 0 0 0 0 0
20 4E 42 32 57 00 FF 0F 45 00 01 00 00 00 00 00 NB2W E
00 00 7D 00 00 00 00 00 00 00 0D F0 AD BA 0D F0 }
AD BA 5E 5F 2D 69 7C 4C 65 24 27 7C 27 2D 5F 5E ^_-i|Le$'|'-_^
00 4E 42 32 57 20 30 20 30 20 30 20 30 20 30 20 NB2W 0 0 0 0 0
30 20 30 20 30 20 4E 42 32 57 00 0 0 0 NB2W
-.- Thats a 0x0F packet...
I dont think so =\
Quote from: NiNe on January 30, 2005, 06:45 PM
4E 42 32 57 20 30 20 30 20 38 36 20 30 20 30 20 NB2W 0 0 86 0 0
30 20 30 20 30 20 4E 42 32 57 00 FF 0F 3B 00 01 0 0 0 NB2W ;
00 00 00 00 00 00 00 6E 00 00 00 00 00 00 00 0D n
F0 AD BA 0D F0 AD BA 4E 69 4E 65 00 4E 42 32 57 NiNe NB2W
20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 0 0 0 0 0 0 0 0
20 4E 42 32 57 00 FF 0F 45 00 01 00 00 00 00 00 NB2W E
00 00 7D 00 00 00 00 00 00 00 0D F0 AD BA 0D F0 }
AD BA 5E 5F 2D 69 7C 4C 65 24 27 7C 27 2D 5F 5E ^_-i|Le$'|'-_^
00 4E 42 32 57 20 30 20 30 20 30 20 30 20 30 20 NB2W 0 0 0 0 0
30 20 30 20 30 20 4E 42 32 57 00 0 0 0 NB2W
Aww i see now, its cluttered stupid me
Bnet usally sends 0x0F User in Channel in one big clump.
Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.
Now, I'm asuming that we have a packet, or a series of them, in strBNCS. I know I'm likely to be the only one to use that name, so change it accordingly.
Public Sub PrepareParse(strBNCS as String)
While Len(strBNCS) > 4
ParseBNCS Mid(strBNCS, 1, GetWORD(Mid(strBNCS, 3, 2)))
strBNCS = Mid(strBNLS, GetWORD(Mid(strBNCS, 3, 2)) + 1)
Wend
End Sub
Right?
Try using it in _DataArrival, Then have it parse out then length, if the lengtih of the buffer > LengthOfPacket then parse it, else wait till next dataarival.
Static strBuffer As String
Dim strTemp As String, lngLen As Long
With Config(Index)
wsBNET.GetData strTemp, vbString
strBuffer = strBuffer & strTemp
While Len(strBuffer) > 4
lngLen = GetWORD(Mid(strBuffer, 3, 2))
If Len(strBuffer) < lngLen Then Exit Sub
Call ParseBNCS(Left(strBuffer, lngLen))
strBuffer = Mid(strBuffer, lngLen + 1)
Wendas such, works perfectly for me.
QuoteAh, wonderful. Another reason that packets suck and CSB owns.
No jsut anoyher reason you need to fix your coding, CSB does the egzact same thing, it parses out each packet even if there jumbled together, Self-Parsed will forever be greater then CSB.
~-~(HDX)~-~
Quote from: JoeTheOdd on January 30, 2005, 08:49 PM
Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.
Packets rock, CSB sucks. I hate text-based protocols. Packets are so much more definite, IMO. For one, it's easier to know whether or not you've received a whole "message" when the underlying protocol specifies the length of the message. Most text-based protocols do specify a maximum length of messages, but without a message length specifier, there is no telling when you might receive a message longer than the specified length. For example, IRC specifies that the end of a message is crlf, and that a message can not be longer than 512 bytes (including the crlf, so a total of 510 bytes for the message). So what do you do if you receive 512 bytes and still have not received crlf? You close the connection and go "wtf GAY PROTOCOL!!!"
Quote from: tA-Kane on January 31, 2005, 01:34 AM
Quote from: JoeTheOdd on January 30, 2005, 08:49 PM
Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.
Packets rock, CSB sucks. I hate text-based protocols. Packets are so much more definite, IMO. For one, it's easier to know whether or not you've received a whole "message" when the underlying protocol specifies the length of the message. Most text-based protocols do specify a maximum length of messages, but without a message length specifier, there is no telling when you might receive a message longer than the specified length. For example, IRC specifies that the end of a message is crlf, and that a message can not be longer than 512 bytes (including the crlf, so a total of 510 bytes for the message). So what do you do if you receive 512 bytes and still have not received crlf? You close the connection and go "wtf GAY PROTOCOL!!!"
And? What do you do if you receive a packet with a specified length of 0xffff but never actually receive all those bytes? You close the connection and go "wtf GAY PROTOCOL!!!"
One of the things binary protocols do better is not wasting space as a text protocol does. However, with text protocols it's readable. There are certain tradeoffs.
Quote from: JoeTheOdd on January 30, 2005, 08:49 PM
Ah, wonderful. Another reason that packets suck and CSB owns. I will now attempt to redeem myself worth, by posting a routine to seperate them.
You do realize that CSB just hides the packet data from you, the user of CSB, right? It's called "information hiding," a very effective and efficient programming practice. Unfortunately, CSB does *not* allows you as much flexibility as you might like, such as a priority-based event caller and the like. So when information is hidden and you work with only an interface, the way in which the interface is exposed defines how much you can do with it.