I got very bord, and added realm ladder to my bot and i thought the research i did would be usefull for others, and for bnet docs etc.
The S > C 0x11 MCP_LADDERDATA will normaly come in 2 packets so it is needed to store it untill you have the full packet data ready to parse.
The server will not split the packets data over 2 packets if the recving list contains 13 characters or less.
[S > C] 0x11 MCP_LADDERDATA
(WORD) Packets Lengh
(BYTE) 0x11 MCP_LADDERDATA
(BYTE) Unknown(0x00)
(WORD) Total Data's Lengh
(WORD) Data's Lengh (Ladder Data**)
(WORD) 0x00*
(VOID) Ladder Data**
0x00* will specify the last packets data lengh if this were to be the 2nd packet.
If Data's Lengh (lengh of Ladder Data**) matchs Total Data's Lengh then there will be no following packet, this packet would contain all the infomation; other wise expect another packet with the rest of the data.
Then after you have stored up the data and it matchs the total data lengh, its time to parse your storeage buffer.
The format is as follows;
(DWORD) Starting Rank of the list
(DWORD) Number of Players in the list
(DWORD) Unknown(0x10) <- im guessing total chars the server lists
- Each char listed -
(DWORD) Char exp
(DWORD) Unknown(0x00)
(BYTE) Flags****
(BYTE) Act**
(BYTE) Char's Level
(BYTE) Unknown 0x00
(STRAND[16]) Char Name
The 16 byte strand will be a strand of 16 bytes containing the reall nullstring charname.
IE: if a char was under 15 letters long, it would have somomne else's/fake charname showing behind it.
The Flags**** holds the following infomation:
Client Flags*;
0x00 = D2DV
0x40 = D2XP
Death Flags*;
0x00 = Char is alive
0x10 = Char is dead
Core Flags*;
0x00 = Softcore
0x20 = Hardcore
Character Flags*;
0x00 = Amazon
0x01 = Sorceress
0x02 = Necromancer
0x03 = Paladin
0x04 = Barbarian
0x05 = Druid
0x06 = Assassin
Example:
0x74 would mean the player is a dead expantion hardcore ladder Paladin.
Both the players difficaulty and act can be obtained from the Act**;
Difficultys*;
For D2XP
0x0A = Hell
0x05 = Nightmare
0x00 = Normal
For D2DV
0x08 = Hell
0x04 = Nightmare
0x00 = Normal
Acts*;
0x01 = Act 1
0x02 = Act 2
0x03 = Act 4
0x04 = Act 4
0x05 = Act 5
And a very ugly, over sized but simple example of how to store the packets datas up before handling it.
Public Sub DoThe0x11ThingyDing(ByVal Data As String)
Static tmpBuf As String
Static More As Boolean
Dim TotalLen As Long
Dim ThisDlen As Long
TotalLen = Buf.GetWORD(Mid(Data, 5, 2))
ThisDlen = Buf.GetWORD(Mid(Data, 7, 2))
If More = False Then 'fresh packet
If TotalLen = ThisDlen Then
'All the data is in this packet
'lets dbl check the realm server can count;
If Len(Mid(Data, 11)) = ThisDlen Then
'yep everying is matching perfectly!
'handle the packets data
'HANDLE>>> Mid(Data, 11)
Else
'things didnt add up
End If
'clear are static veribles
'no packet is following this one
tmpBuf = ""
More = False
Else
'Store the packets data on are Static tmpBuf
tmpBuf = Mid(Data, 11)
'now lets check the realm gave us what it said;
If Len(tmpBuf) = ThisDlen Then
'all is ok
'now we wait for the next packet
More = True
Else
'things didnt add up
'clear stuff for a new/next list request
tmpBuf = ""
More = False
End If
End If
Else '2nd packet
More = False
'never seen it split over moe than 2 packets
If Len(tmpBuf) + ThisDlen = TotalLen Then
'the header bytes and are existing stored buffer
'are saying its on track
'add packet1's data to packet2's data
tmpBuf = tmpBuf & Mid(Data, 11)
'check are storage buffer lengh matchs
'the total datas lengh in the header
If Len(tmpBuf) = TotalLen Then
'ok things went perfectly!
'now to parse are stored buffer
'HANDLE>>> tmpBuf
Else
'things didnt add up
End If
Else
'things didnt add up
End If
tmpBuf = ""
End If
End Sub
As for C > S 0x11 MCP_LADDERDATA list requests;
(WORD) Packets Lengh (0x06)
(BYTE) 0x11 MPC_LADDERDATA
(BYTE) Flags**
(WORD) Starting Rank (to list from)
Flags for requesting ladder lists are as follows;
Ladder type*;
0x00 = D2DV Hardcore Ladder
0x09 = D2DV Softcore Ladder
0x13 = D2XP Hardcore Ladder
0x1B = D2XP Softcore Ladder
Char class*;
0x00 = None (requesting the top 1000)
0x01 = Amazon
0x02 = Sorceress
0x03 = Necromancer
0x04 = Paladin
0x05 = Barbarian
0x06 = Druid
0x07 = Assassin
Example;
Sending flags as 0x22 would request the D2XP Softcore Assasin Ladder.
NOTE:
The char class ladders only contain a 200 max listing, so request anything higher than 199 and you wont get a answer.
(This is the same as requesting higher than 999 on the main ladder type lists)
Also note that a Druid and Assasin do not exist on D2DV.
[edit]: changed MPC to MCP
[edit2]: fixed error pointed out by Archangel
Heh nice work :).
I dont know if this is right but:
In the "(Byte) Acts" it shows the completed Acts, Expansion got 5 acts per level and Non-Expansion got 4 acts, so:
For Expansion:
If Byte <= 5 Then Level = "Normal"
If Byte >= 6 and Byte <= 10 Then Level = "Nightmare"
If Byte >= 11 and Byte <= 15 Then Level = "Hell"
Non-Expansion:
If Byte <= 4 Then Level = "Normal"
If Byte >= 5 and Byte <= 8 Then Level = "Nightmare"
If Byte >= 9 and Byte <= 12 Then Level = "Hell"
Quote from: Archangel on July 04, 2005, 11:28 AM
Heh nice work :).
I dont know if this is right but:
In the "(Byte) Acts" it shows the completed Acts, Expansion got 5 acts per level and Non-Expansion got 4 acts, so:
For Expansion:
If Byte <= 5 Then Level = "Normal"
If Byte >= 6 and Byte <= 10 Then Level = "Nightmare"
If Byte >= 11 and Byte <= 15 Then Level = "Hell"
Non-Expansion:
If Byte <= 4 Then Level = "Normal"
If Byte >= 5 and Byte <= 8 Then Level = "Nightmare"
If Byte >= 9 and Byte <= 12 Then Level = "Hell"
You are right :)
I added the browser and all D2DV players say act2 :P
[edit] added it to the top post, thanks
Hmm...don't know if this message format has changed but here is a link (http://forum.valhallalegends.com/phpbbs/index.php?topic=7524.msg69606#msg69606) to my documentation on the packet from about a year back. That explains a few things a bit better than you did here in terms of packet structure and documents the unknown you have.
I am not 100% positive, but I have noticed this before. For some strange reason, maybe just cause b.net likes to be difficult, after every ladder reset for the new season the packet structure varies just slightly, not enough to cause too many problems but still does. So unless you constantly log it and try to update it, than it will most likely always vary, so when you get it to work just leave it unless it's really broken.
Quote from: Ringo on July 04, 2005, 05:52 AM
I got very bord, and added realm ladder to my bot and i thought the research i did would be usefull for others, and for bnet docs etc.
The S > C 0x11 MCP_LADDERDATA will normaly come in 2 packets so it is needed to store it untill you have the full packet data ready to parse.
The server will not split the packets data over 2 packets if the recving list contains 13 characters or less.
[S > C] 0x11 MCP_LADDERDATA
(WORD) Packets Lengh
(BYTE) 0x11 MCP_LADDERDATA
(BYTE) Unknown(0x00)
(WORD) Total Data's Lengh
(WORD) Data's Lengh (Ladder Data**)
(WORD) 0x00*
(VOID) Ladder Data**
....
The unknown byte is Ladder type.
Your (3rd - "Ladder Data**") WORD is the size of the header excluding its first byte and header.
Your (4th - "0x00*") WORD is how big all the unreceived packets are, excluding their headers and first bytes. In the last packet, this value is 0, since there are no unreceived packets.
Also, there should be a total of 5 WORDS (making up a 10-byte header). I leave it up to you to figure out what the other WORD values are for.
Quote from: LivedKrad.fe on July 05, 2005, 01:01 PM
Quote from: Ringo on July 04, 2005, 05:52 AM
I got very bord, and added realm ladder to my bot and i thought the research i did would be usefull for others, and for bnet docs etc.
The S > C 0x11 MCP_LADDERDATA will normaly come in 2 packets so it is needed to store it untill you have the full packet data ready to parse.
The server will not split the packets data over 2 packets if the recving list contains 13 characters or less.
[S > C] 0x11 MCP_LADDERDATA
(WORD) Packets Lengh
(BYTE) 0x11 MCP_LADDERDATA
(BYTE) Unknown(0x00)
(WORD) Total Data's Lengh
(WORD) Data's Lengh (Ladder Data**)
(WORD) 0x00*
(VOID) Ladder Data**
....
The unknown byte is Ladder type.
Your (3rd - "Ladder Data**") WORD is the size of the header excluding its first byte and header.
Yes that WORD specifys the lengh of the data in the currect packet....
Quote from: LivedKrad.fe
Your (4th - "0x00*") WORD is how big all the unreceived packets are, excluding their headers and first bytes.
In the last packet, this value is 0, since there are no unreceived packets.
.... in the [1st] packet this word is null, and in the 2nd packet the word specifys the lengh of the data* in the packet before it.
Quote from: LivedKrad.fe
Also, there should be a total of 5 WORDS (making up a 10-byte header). I leave it up to you to figure out what the other WORD values are for.
lol, what header are you talking about here?
The only thing iv missed out is the unknown byte (ladder type) and the exp is a QWORd not a DWORD.
Thanks for the input tho, rather amusing.
Just an aside note;
I posted this because i thought people would want it, and it could go on bnet docs (seems bnet docs has no info on it)
And have no need for help understanding it...
*Notes that he posted the format FROM BNETDOCS*
Just because you can't see it doesn't mean it's not there.
What I meant by the 10-byte header was this:
(WORD) Packet Length
(BYTE) 0x11
(BYTE) Ladder type
(WORD5) 10-byte header
(VOID) Data
Edit: I'm glad I amuse you, prick.
Quote from: LivedKrad.fe on July 05, 2005, 05:09 PM
*Notes that he posted the format FROM BNETDOCS*
Just because you can't see it doesn't mean it's not there.
What I meant by the 10-byte header was this:
(WORD) Packet Length
(BYTE) 0x11
(BYTE) Ladder type
(WORD5) 10-byte header
(VOID) Data
Edit: I'm glad I amuse you, prick.
The packet is not on bnet docs from what i can see, and if it is, then me and no one else can see it.
This is why i was kind enough to bother posting the 4 hours i spent on it.
So maybe it could be put to some use;
IE: on bnet docs, BNBDR etc etc
And a few kind people pointed out some unknowns and posted out there existing links that documented it, making it more resourcefull for others.
Im sorry you felt differntly.
This is why im not bothering to post anymore infomation on d2gs.
And this is why im not going to bother typing out posts like this any more, because idiots like your self cant see the cause behind it.
I was also going to point out the countless errors you have put on Bnet docs already, but should i even bother with your attitude.
Arta should at least asign somone to do it who knows somthing about D2GS....
Quote from: LivedKrad.fe on July 05, 2005, 05:09 PM
Edit: I'm glad I amuse you, prick.
No flames? Moderatos should deal with people like this.
Bnetdocs is not always right, i have seen some mistakes on D2GS Protocol.
Oh yeah and thnx to persons like Ringo we got public information about protocols, like D2GS.
Confirmed that this is on BnetDocs but at an elevated (private) access level:
QuoteExtra Info: The status of this information is: Draft
Yoni has requested that this remain private.
As it has been asked to be private, I will say only that both BnetDocs listings are significantly different than the one you posted. However, that is not to say that you are wrong; the information very well could be out-of-date. To my knowledge, MCP isn't something researched frequently.
And if people are not allowed to see some packets on BnetDocs is for some reason, one of those is because the author doesnt want to show it or x thing.
In this case this was the reason and you weren't supposed to release that information.
You totally screwed it up.
All he did was copy/paste infomation direct from bnet docs into the topic and basicly said;
This is how it works, you are wrong, i will let u figger the rest out.
Bah, got no time for idiots like that, he should report it to blizzard, because what i posted is what the server is sending d2 clients at the moment.
Alright, I'm wrong apparently. Let's drop it. Sorry for calling you a prick, but saying that I amuse you is a bit demeaning.
Yeah it's private MyndFyre, so what. What I thought were minor corrections (which are apparently wrong) don't really reveal too much about the packet anyway (as you can see by looking at how much information I did not reveal).
I'm sorry if I've made you all angry.