D2GS: 0x6C (C->S) Anyone have information?

[Ringo]

Hmm, sorry I actually meant 0x5E (And possibly 0x97). Here's a dump of a section of the decompressed packet that is troubling me:


2100 0002 0000 00A4 0000 3F00 975E 0100 0000 0000 0001 0001 0000 0000 0101 0100 0000 0000
0000 0100 0000 0101 0000 0000 0000 B128 0600 0000 0000 0100 FD9F FD9F FD9F FD9F FD9F FD9F
0100 0100 1D90 791C FD9F FD9F FD9F E51F 0100 0100 FD9F FD9F FD9F FD9F FD9F FD9F 0100 0100
FD9F FD9D FD9F 0000 0000 0000 0000 0000 0000 0000 FD9F ED9F 0000 FD9F FD9F FD9F 00       


0x97 is said to be 'blank', which I presume means there's just the message ID. Then we have 0x5E where I couldn't find any information on.

Any thoughts?

Ye 0x97 is blank
It means that you switched wepons. Bydefalt d2 is set to side 1, but if there char was last saved useing side 2, it will recv it on joining, so that d2 switchs.

0x5E is some quest nonsence I think. (never really looked at it or seen an importance)
Its always a binary looking (1 bit per byte) message with some byte at the end. (0xB1 in this case) Its also fixed lengh.

Then you have 0x28 (quest tree) after that and by the looks of things you done most of your quests

A few things I forgot the mention about the mapping in d2, is S>C 0x03 contains seeds that are used to generate the act and populate it with objects/npc's/gold piles etc. (nothing but the walkable floor/walls are really important)
Then each section of an area is added/removed with S>C 0x07/0x08 as the player moves around it.
The server populates these sections as they are 1st-time scouted and saves them along with everything on them to file when they are unscouted (no player is inview with it) so that when a player goes back, everything can be reloaded as the player last scouted it and the time idle can be applyed to any vanishing items/healing npcs etc.

[Win32]

Ah, I see.

Um, is there any documentation for these packets? As they aren't listed in the usual D2GS thread. Since I seem to be running into quite a few messages that there doesn't appear to be any info on lying around.

[Ringo]

Ah, I see.

Um, is there any documentation for these packets? As they aren't listed in the usual D2GS thread. Since I seem to be running into quite a few messages that there doesn't appear to be any info on lying around.

Ye, if you cant find any info on them on the web, just say the ID's of the messages your stuck on figgering out and/or what bit your stuck on.
Most of the research i posted in the d2gs thread, was with in a few weeks of me discovering D2 had a ingame protocol so it is pretty basic and doesnt list every single message.
I didnt have any pre-documentation about the protocol or any packet lenghs, just a function to decompress and a function to return some sort of packet header, so its suppriseing I listed as many packets as i did up there
The main idea was for it to be a stepping stone to those wanting to learn about the protocol, so they could get a basic idea of how it worked and could go on to teach them selfs/research the rest.
Abit like the "give a man a fish, or teach a man how to fish" saying
But what goes with out saying is, teach everyone everything there is to know about fishing, and the ocean starts to run out of fish

Somthing that might come in handy, is the packet lenghs. (somone posted them on the 4th - 6th page in the D2GS research thread)

[Win32]

Ah

Hmm, I think 0x22 might've changed? The specification you gave me was:

0x22
(BYTE) Entity Type(?)
(BYTE) Unknown - 0x26
(DWORD) Entity ID
(WORD) Skill Code
(BYTE) Stats Amount
(WORD) Unknown

Here's an example of what I've encountered:

2200 0002 0000 00DB 0001 8600 2200 0002 0000 00D9 0001 8600                               

It would seem the dword at offset+0x2 is the player's identifier (I believe)


I've noticed alot of fields are tagged as 'unknown', I'm thinking, will these holes in the protocol possibly result in being unable to properly implement the protocol?