BNETDocs Redux

Used by StarCraft, Diablo, and WarCraft II use the Storm UDP Protocol to communicate during games.

As detailed by skywing:

The header you are working with is specific to the Storm UDP protocol
and is [n]ot ever assembled or viewed by the game protocol module itself. Thus
only [c]ontrol messages for the Storm UDP protocol use the command field.

The way this is laid out can be represented something like this:

-----------------
-- Storm Header--
-----------------
-- Data Payload -
-----------------

Storm.dll receives the data off the wire, and interprets class 0
control messages directly, instead of passing them on to the game (except
perhaps in the form of high level callbacks, such as a "player joined the game"
callback or event).

For non-class0 messages, the data payload is passed uninterpreted on to
the game protocol parser itself, whether that be in Diablo.exe,
Starcraft.exe,
etc:

-----------------
-- Data Payload -
-----------------

Since the main game module never sees the Storm header, command ids for
other than the internal control class can't be stored there.

Note that I am logically equating Storm.dll and the Storm network
service provider (SNP) as the same module. In reality, the SNP is responsible
for sending and receiving the game data off of the wire, whether that be a
UDP socket or an IPX socket, or just an internal loopback (e.g. standard.snp).

Class 1 is used for messages that do not need to be synchronized with
the game state, such as chat commands. Thus, class 1 commands can be sent
and received at any time.

Class 2 is used for messages that do need to be synchronized with the
game state, such as unit orders. Thus, class 2 commands can only be sent
once each game turn (as a result they are typically queued internally inside
the game protocol module until the next turn is transmitted).

The storm packets are sent and received "inside" the Battle.net UDP Message dubbed [0x00] PKT_STORM, from client to client only. Therefore, the "Storm Header" above is documented in [0x00] PKT_STORM.
On the wire, it appears as starting with four bytes of zeros, but remember, that's the Battle.net UDP Message header.

In the Storm Protocol Messages and the three game specific sections, CLS 1 and 2 paclets are documented.

The documentation is quite complicated, so here is how it is laid out here:
For CLS 0 packets, they are listed under Storm UDP Messages in the form "C > C [CLS 0 0xXX] STORM_PACKETNAME" where XX is the command ID in PKT_STORM and PACKETNAME is an invented name to identify the right packet.
For CLS 1 and 2 packets, they are listed under SCGP Messages (for StarCraft), W2GP Messages (for WarCraft II), or D1GP Messages (for Diablo) in the form "C > C [0xXX] YYYY_PACKETNAME" XX is the first byte in the data payload. YYYY_PACKETNAME is an invented name to identify the right packet. The PKT_STORM command will be 0 due to the reasons above. In a protocol, CLS 1 and 2 packets never have conflicting packet IDs. To see what CLS a packet is, see the packet's page.

For consistency, all packet format fields will start after the end of the storm header. So for CLS 1 and 2, they will contain the packet ID. For CLS 2, there may be more than one packet after the header to parse, depending on what was sent during the game turn.

All packet names were invented for consistency in this documentation based on their purpose.

Links

RSS Feeds