[C<>S] 0x11 MCP_LADDERDATA info

[Ringo]

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

Code Select Expand


(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;

Code Select Expand


(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 -

Code Select Expand


(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*;

Code Select Expand


    0x00 = D2DV
    0x40 = D2XP

Death Flags*;

Code Select Expand


    0x00 = Char is alive
    0x10 = Char is dead

Core Flags*;

Code Select Expand


    0x00 = Softcore
    0x20 = Hardcore

Character Flags*;

Code Select Expand


    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*;

Code Select Expand


For D2XP
    0x0A = Hell
    0x05 = Nightmare
    0x00 = Normal
For D2DV
    0x08 = Hell
    0x04 = Nightmare
    0x00 = Normal

Acts*;

Code Select Expand


    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.

Code Select Expand


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;

Code Select Expand


(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*;

Code Select Expand


    0x00 = D2DV Hardcore Ladder
    0x09 = D2DV Softcore Ladder
    0x13 = D2XP Hardcore Ladder
    0x1B = D2XP Softcore Ladder

Char class*;

Code Select Expand


    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

[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"

[Ringo]

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

[edit] added it to the top post, thanks

[dxoigmn]

Hmm...don't know if this message format has changed but here is a link 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.

[LordNevar]

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.

[LivedKrad]

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

Code Select Expand


(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.

[Ringo]

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

Code Select Expand


(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....

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.

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

[LivedKrad]

*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.

[Ringo]

*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....

[Archangel]

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.

[MyndFyre]

Confirmed that this is on BnetDocs but at an elevated (private) access level:

Extra 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.

[Archangel]

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.

[Ringo]

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.

[LivedKrad]

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.