Introduction

Wowm is a domain specific language for describing the layout of messages used in the Client/Server communication for World of Warcraft with the intention of auto generating documentation and usable programming libraries.

The language leans heavily on syntax from C/C++ for declaring definers, built-in types, and containers. Definers are simple wrappers over regular numbers that name valid values. Containers specify the order and layout of messages.

Definers can either be flags or enums. enums can only have one valid named value, while flags can have multiple. flags are also known as bitfields.

The following is an example enum and flag:

enum TestEnum : u8 {
    TEST_ONE = 1;
    TEST_TWO = 2;
    TEST_THREE = 3;
}
/* TestEnums can only be either 1, 2, or 3. */


flag TestFlag : u8 {
    TEST_ONE = 1;
    TEST_TWO = 2;
    TEST_FOUR = 4;
}
/* TestFlags can be either 1, 2, 4 or any combination thereof like 0, 3, 7, or 5. */

The u8 after the : specifies the basic type of the definers. This is the type that is actually sent over the network. A u8 is an unsigned integer of 8 bits (1 byte). A u32 would be an unsigned little endian integer of 32 bits (4 bytes). A u32_be would be an unsigned big endian integer of 32 bits (4 bytes).

For a full list of built-in types, see the built-in types section in the specification.

Containers specify the actual message as well as structs which can be used as a type in other containers.

A full list of container variants can be found in the container section of the specification.

The following is an example of a struct using built-in types, that is itself also used as a type in an smsg (world message sent from the server):

struct TestStruct {
    u32 price_in_gold;
    u32 amount_purchased;
}

/* 
    Number after "=" is the opcode. Use hexadecimal.
    Size is automatically calculated based on contents.
*/
smsg SMSG_TEST = 0xFF {
    CString name;
    TestStruct t;
}
/* The above is functionally identical to */
smsg SMSG_TEST = 0xFF {
    CString name;
    u32 price_in_gold;
    u32 amount_purchased;
}

All objects must specify which version of the game they work with. See the section on versioning with tags

Versioning through tags

When resolving type names of dependencies the tag system is used. The compiler will accept names that are as specific or less specific than the tag on the object that needs a dependency.

So in the example:

struct User {
    Boolean has_something;
} {
    versions = "1.12";
}

enum Boolean : u8 {
    FALSE = 0;
    TRUE = 1;
} {
    versions = "1";
}

The struct User is allowed to use the enum Boolean because Boolean has a less specific versions tag than User does. That is, User is valid for all versions of 1.12, while Boolean is valid for all versions of 1. It would not be possible to be valid for all versions of 1 but not 1.12 specifically.

There can not be two objects with the same name and the same version. Two different versions can be each be valid for their own version, but it does not make sense for the same object to have two different representations for the same version.

So this is allowed:

enum Boolean : u8 {  /* Name of Boolean */
    FALSE = 0;
    TRUE = 1;
} {
    versions = "1"; /* <-- versions 1 here */
}

enum Boolean : u8 { /* <-- Same name */
    FALSE = 0;
    TRUE = 1;
    MAYBE = 2;
} {
    versions = "2" /* <-- versions 2 here */
}

But this is not:

enum Boolean : u8 {
    FALSE = 0;
    TRUE = 1;
} {
    versions = "1 2"; /* <-- Added 2 here */
}

enum Boolean : u8 {
    FALSE = 0;
    TRUE = 1;
    MAYBE = 2;
} {
    versions = "2" /* <-- Conflicts with this versions */
}

World and Login versions

clogin and slogin messages are used for communication with the realm/authentication server. These can only have login_versions.

cmsg, smsg, and msg messages are used for communication with the world/game server. These can only have versions.

Mass versioning

The #tag_all command can be used to tag all objects in a file with the same versions string.

#tag_all versions "1.11 1.12"

enum Boolean : u8 {
    FALSE = 0;
    TRUE = 1;
} /* <-- Will have "versions" = "1.11 1.12" automatically applied */


struct Thing {
    Boolean is_thing;
    u8 basic;
} /* <-- Will have "versions" = "1.11 1.12" automatically applied */

Paste versions

Versions must fully deliver what they promise. What this means is that every single field used must also cover at least the same version as the containing object. For example, if there is a Race enum that has been determined to be valid for 1 (Vanilla) and another Race enum that has determined to be valid for 2 (The Burning Crusade), it is not valid to create a single message that uses the Race enum and covers both 1 and 2. An object that only contains a vanilla Race and an object that only contains a Burning Crusade Race are not identical, despite the fields taking up the same amount of space (1 byte, a u8).

So the following is NOT VALID:

enum Race : u8 {
    HUMAN = 1;
    ORC = 2;
    DWARF = 3;
    NIGHT_ELF = 4;
    UNDEAD = 5;
    TAUREN = 6;
    GNOME = 7;
    TROLL = 8;
    GOBLIN = 9;
} {
    versions = "1"; /* <-- Only covers 1 */
}

enum Race : u8 {
    HUMAN = 1;
    ORC = 2;
    DWARF = 3;
    NIGHT_ELF = 4;
    UNDEAD = 5;
    TAUREN = 6;
    GNOME = 7;
    TROLL = 8;
    GOBLIN = 9;
    BLOOD_ELF = 10; /* <-- Clearly not the same */
    DRAENEI = 11;
    FEL_ORC = 12;
    NAGA = 13;
    BROKEN = 14;
    SKELETON = 15;
    VRYKUL = 16;
    TUSKARR = 17;
    FOREST_TROLL = 18;
} {
    versions = "2"; /* <-- Only covers 2 */
}

cmsg CMSG_INVALID_MADE_UP_MSG = 0xDEADBEEF1471D {
    Race race;
} {
    versions = "1 2"; /* <-- NOT VALID. Neither enum can cover both versions 1 and 2. */
}

There are many messages where the only difference between expansions is that they update an enum that is specific to that expansion and version. For example CMSG_EMOTE:

cmsg CMSG_EMOTE = 0x0102 {
    Emote emote; /* <-- This Emote only covers 1.12 */
} {
    versions = "1.12";
}

cmsg CMSG_EMOTE = 0x0102 {
    Emote emote; /* <-- This Emote only covers 2.4.3 */
} {
    versions = "2.4.3";
}

cmsg CMSG_EMOTE = 0x0102 {
    Emote emote; /* <-- This Emote only covers 3.3.5 */
} {
    versions = "3.3.5";
}

There can not be a single message that is valid for all 3 versions since the Emotes are different.

Instead paste_versions can be used. This effectively copy and pastes the textual wowm representation and creates 3 different messages that are each only valid for one version. The two examples above and below are effectively the same, while the bottom one has significantly less duplication. Comments, descriptions, and other tags are also duplicated for the different versions.

cmsg CMSG_EMOTE = 0x0102 {
    Emote emote;
} {
    paste_versions = "1.12 2.4.3 3.3.5";
}

paste_versions only exists for World versions (versions), not for Login versions (login_versions).

Contribution Quick Start Guide

Background

Read the introduction and versioning section. Skim the specification.

Clone the repository

Run git clone https://github.com/gtker/wow_messages.git or equivalent to clone the repository.

Touring the repository

Inside the wow_message_parser directory of the repository is the wowm directory. This contains all the wowm definitions that are parsed by the compiler. Go into the world directory and notice that it consists of subdirectories that contain wowm files.

The directory structure does not make any difference in the final output and is purely there for easier human consumption. Do not stress over which directory a specific message is supposed to go into, and feel free to create new directories.

If messages are small, keep the different versions in the same wowm file. If they are large keep them in separate files with the version appended, like smsg_update_object_3_3_5.wowm for 3.3.5.

Install Rust

Use the official site to install Rust. It is not necessary to have knowledge about Rust in order to contribute, but it is necessary to have it install in order to run the compiler. The compiler must be run after every change in the wowm. The repository manually keeps the generated files up to date to avoid having to generate them each time they are used.

Running the compiler

While inside the repository run cargo run -p wow_message_parser --release to run the compiler. This will give you output like:

    Finished release [optimized] target(s) in 0.03s
     Running `target/release/wow_message_parser`
1.12 Messages without definition:
    SMSG_COMPRESSED_UPDATE_OBJECT: Compressed
    [..]
    SMSG_COMPRESSED_MOVES: Compressed

1.12 Messages with definition: 601 / 607 (99.011536%) (6 left)
1.12 Total messages with tests: 60 / 607 (9.884679%)

2.4.3 Messages without definition:
cmsg CMSG_BOOTME = 0x0001 { unimplemented } { versions = "2.4.3"; }
[..]
smsg SMSG_SUMMON_CANCEL = 0x0423 { unimplemented } { versions = "2.4.3"; }

2.4.3 Messages with definition: 126 / 1058 (11.909263%) (932 left)
2.4.3 Total messages with tests: 17 / 1058 (1.6068052%)

3.3.5 Messages without definition:
cmsg CMSG_BOOTME = 0x0001 { unimplemented } { versions = "3.3.5"; }
[..]
smsg SMSG_MULTIPLE_MOVES = 0x051E { unimplemented } { versions = "3.3.5"; }

3.3.5 Messages with definition: 128 / 1309 (9.778457%) (1181 left)
3.3.5 Total messages with tests: 12 / 1309 (0.91673034%)

This contains a list of unimplemented messages for the versions that we currently want messages from. Under 1.12, messages with a colon (:) are followed by a reason for them not being implemented currently. So SMSG_COMPRESSED_MOVES: Compressed are not implemented because we are lacking support for compression. 1.12 messages are shown this way because are very few left for 1.12.

2.4.3 and 3.3.5 instead output a copy pastable wowm snippet that allows for less manual typing.

Implementing a message

Let's implement a fictional message for training purposes. Imagine that when running the compiler it told you that MSG_FICTIONAL was not implemented by outputting msg MSG_FICTIONAL = 0x1337 { unimplemented } { versions = "3.3.5"; }.

Let's break down what exactly that is for clarity:

msg MSG_FICTIONAL = 0x1337 { /* <-- Describes the message */
    unimplemented /* <-- Tells the compiler that this message is unimplemented. */
} { /* <-- Tags start */
    versions = "3.3.5"; /* <-- For version 3.3.5 */
} /* <-- Tags end */

The above is the preferred formatting for wowm files. Use 4 spaces instead of a tab, and add newlines like you see above.

Just putting the snippet into a wowm file inside the wow_message_parser/wowm/world directory would make the compiler compile it and add it to the generated code, documentation, and the Wireshark implementation, but it would not tell us anything useful about the message.

Research

Before we can implement the message we need to figure out what the layout is and if it is even used by the client.

Use SourceGraph to search through many emulators at the same time, as well as repositories you probably didn't know existed.

If the message does not appear to be used by the client, pick a new message.

If you are absolutely certain that the message is not used, remove it from the list in wow_message_parser/src/parser/stats/wrath_messages.rs (or tbc_messages.rs if it's for TBC).

Implementation

Let's pretend that the MSG_FICTIONAL message is used for something auction house related.

First search for MSG_FICTIONAL in the entire wowm folder for other versions of this message. If you find any then place the new implementation next to the other ones, otherwise navigate into the wow_message_parser/wowm/world/auction directory and see that it's split into the directories:

• cmsg
• msg
• smsg

Recall that the directory layout of the wowm files do not matter for the final product, so this folder layout is not a requirement.

Go into the msg directory and create a new file called msg_fictional.wowm (all lowercase).

Paste the wowm output from before into the file with the correct formatting.

Lean on the specification, versioning with tags and other messages inside the repository for examples of how to represent the chosen message.

It is very possible that the message you are trying to implement can not be correctly represented in wowm or leads to compile errors when trying to test the libraries. In this case ask for help on the discord or go to another message.

Correct versioning

Currently you are only saying that specifically version 3.3.5 is supported by your message but it might be possible that 3.3.4 or even 3.1.0 also use the samme message. Research the emulators and decide if it seems like the message has the same format in other version as well.

For example, if the message has the same layout in both a 2.4.3 TBC emulator and a 3.3.5 Wrath emulator, you are allowed to assume that any versions in between have the same layout. You would therefore write versions = "2.4.3 3";, since you can't know if versions prior to 2.4.3 have the same layout, but you do know that 3.3.5 is the last Wrath release and that all previous releases have the same layout.

If other objects are preventing you from applying a larger version, for example because it depends on an Emote enum that only has version 3.3.5, then simply give it the biggest possible gap you can and move on.

Comments

During your research you may discover some things that are uncommon, surprising, or noteworthy. In this case you can use the comment tag to pass on this knowledge. If you end up writing a long comment you can use multiple tags and they will all appear in the final product. Like so:

msg MSG_FICTIONAL = 0x1337 { /* <-- Describes the message */
    u8 thing; /* <-- Implementation that you should have here now. */
    u32 other_thing {
        comment = "mangoszero always sets this to 0."; /* <-- comment on this specific field */
    }
} {
    versions = "3.3.5";
    comment = "This message is entirely fictional so that the documentation doesn't go out of date as quickly.";
    comment = "But we still have some secret knowledge to share."; /* <-- Comment on the entire message. */
}

Remember that wowm comments (in between /* and */) are not propagated further than the wowm sources, so put everything related to the messages in "real" comments and only use the wowm comments for TODOs or related items.

Descriptions

If you know enough about the message or any particular fields you can also add description tags.

This step, along with the comment step, is not required but it would be nice if other people didn't have to go digging in the sources to uncover information that was already known.

Testing

Run cargo run -p wow_message_parser --release and then cargo test --all-features. This will ensure that

• Any changes to the wowm files are propagated.
• All tests compile and pass.

Commit changes

Commit your changes and go on to the next message.

Questions

If you have any questions ask on the Discord channel.

Specification

A .wowm file starts with 0..* commands, and ends with 0..* statements. Commands are prefix with # and statements start with an object keyword.

Commands

The file must start with all commands. A command appearing after a statement is invalid.

Commands take the form

#<command> <command_parameters>;

For example:

#tag_all versions "1.12";

Built-in Types

The following types are not looked up but are expected to be handled by the compiler and code generator:

• The basic integer types u8, u16, u32, and u64 are sent as little endian over the network.
• The floating point type f32 is sent as little endian over the network.

The String type is the same as a sized u8 array (u8[len]) containing valid UTF-8 values plus a u8 for the length of the string, although it should be presented in the native string type.

The CString type is an array of valid UTF-8 u8s terminated by a null (0) byte.

The SizedCString is the same as a u32 followed by a CString, but they are kept in the same type to semantically convey that the u32 field has no purpose other than to parse the CString.

Arrays

Arrays are semi-built-in types of the form <type>[<length>] where <type> is any built-in or user defined type, and <length> is either a constant integer value, a previous integer field in the same object, or the character - for "endless" arrays.

Endless arrays do not have a field that specifies how many items the array contains. This information is instead deduced from the total size of the message minus the sizes of any previous fields.

Statements

Statements start with one of the following keywords:

• enum, a definer, for descriptions of values where only one value is valid.
• flag, a definer, for descriptions of values where several values are valid at the same time.
• struct, a container, for collections of fields that do not fit into any of the below.
• clogin, a container, for login messages sent from the client.
• slogin, a container, for login messages sent from the server.
• msg, a container, for world messages that can be sent from both client and server.
• smsg, a container, for world messages sent from the server.
• cmsg, a container, for world messages sent from the client.
• test, a description of a full valid message and the expected values.

A definer creates a new type that gives names to basic integer values, like an enum would do in most programming languages. A container is a collection of types that describes the order in which they are sent, as well as other information.

All statements can be followed by a tags block of the form

{
    <tags>
}

Where <tags> is of the form

<tag_name> = "<tag_value>";

Where <tag_name> is a valid identifier, and <tag_value> is a string value.

A list of tags with meaning for the compiler can be found at Tags.

Definer

Definers take the form of

enum <name> : <basic_type> {
    <enumerators>
}

Where <name> is a unique identifier, <basic_type> is an integer type u8, u16, u32, and u64.

<enumerators> is one or more enumerators of the form

<name> = <value>;

where <name> is a unique identifier inside the definer, and <value> is a valid value. Enums can not have multiple names with the same value, while flags can. Flags can not be signed types (i*), while enums can.

The allowed number formats in definers and how they are sent over the network are:

enum EnumAllowedInteger : u32 {
    INTEGER = 22; /* 22, [22, 0, 0, 0]  */
    HEXADECIMAL = 0xFF; /* 255, [255, 0, 0, 0] */
    BINARY = 0b0101; /* 5, [5, 0, 0, 0] */
    STRING = "\0AB"; /* 0x4142, [66, 65, 0, 0] */
}

The string syntax has the special case of \0 which is replaced with a single zero byte.

Container

Containers take the form of

<keyword> <name> [= <opcode>] {
    <declaration | if_statement | optional_statement>*
}

Where <keyword> is one of

• struct.
• clogin, for a login message sent from the client.
• slogin, for a login message sent from the server.
• msg, for a world message sent by both the client and server.
• smsg, for a world message sent from the server.
• cmsg, for a world message sent from the client.

<name> is a valid identifier.

[= <opcode>] is an allowed value in the same format as for definer values that defines the unique opcode value for the container. The <opcode> is required for every container except for structs, which have no opcodes.

For msg, smsg, and cmsg the size field is implicitly added as part of the message header. clogin and slogin messages that require a specific size field must set the field equal to self.size.

Declaration

<declaration> is of the form

[<upcast>]<type> <identifier> [= <constant_value>];

Where <type> is either a built-in or user defined type.

<identifier> is a legal identifier. Two declarations or optional statements in the same object must not have identical identifiers, even across if statement blocks.

The optional <constant_value> defines which value this field should always be sent as, used for padding values. Fields received with a different value will not lead to failed parsing.

The optional <upcast> is used for an enum which should be sent over the network as a different type than it is defined with. This is in order to prevent needing multiple enums for the same concept. Upcasts have the form ( <integer_type> ) where integer_type is an integer type of larger size or different endianness from the type in the original enum.

If Statement

<if_statement> is of the form

if (<variable_name> <operator> <definer_enumerator>
    [|| <variable_name> <operator> <definer_enumerator>]*) {
    <declaration | if_statement | optional_statement>*
} [ else if (<variable_name> <operator> <definer_enumerator> 
    [|| <variable_name> <operator> <definer_enumerator>]* {
    <declaration | if_statement | optional_statement>*
}]* [ else {
    <declaration | if_statement | optional_statement>*
}]?

Where:

• <variable_name> is the name of a variable from a declaration that has previously appeared. The variable name must be the same in all statements.
• <operator> is either ==, &, or !=. Restrictions apply to !=.
• <definer_enumerator> is a valid enumerator in the type of <variable_name>.

If statements that use != can not have any else if or || options, but they can have the else option.

Optional Statement

<optional_statement> is of the form

optional <identifier> {
    <declaration | if_statement | optional_statement>*
}

Where <identifier> is a legal identifier. Two declarations or optional statements in the same object must not have identical identifiers, even across if statement blocks.

Optional statements can only occur as the last element of a message.

Test

Tests take the form of

test <name> {
    <fields>
} [
    <bytes>
]

Where <name> is a valid name of an existing container.

<fields> is zero or more field definitions of the form

<name> = <value> | "[" <array_fields>[","] "]" | "{" <subobject_fields> "}" ;

that describe which value to expect for a specific field.

<array_fields> and <subobject_fields> consist of 1 or more <fields>.

<bytes> are the raw byte values sent over the network, including the size and opcode fields in unencrypted format. The allowed formats are the same as those in definer values.

Commands

The following commands have compiler behavior defined.

tag_all

Applies the selected tag to all objects in the file.

Format

#tag_all <tag_name> "<tag_value>";

Where <tag_name> is the name of the tag to be applied and <tag_value> is the value.

If a tag already exists on an object tag_all will append the value.

Examples

#tag_all versions "1.12";

enum Boolean : u8 {
    YES = 0;
    NO = 1;
}

struct S {
    u8 basic;
}

would be the same as

enum Boolean : u8 {
    YES = 0;
    NO = 1;
} {
    versions = "1.12";
}

struct S {
    u8 basic;
} {
    versions = "1.12";
}

#tag_all "3";

enum Boolean : u8 {
    YES = 0;
    NO = 1;
} {
    versions = "1.12";
}

struct S {
    u8 basic;
} {
    versions = "1.12";
}

would be the same as

enum Boolean : u8 {
    YES = 0;
    NO = 1;
} {
    versions = "1.12 3";
}

struct S {
    u8 basic;
} {
    versions = "1.12 3";
}

Tags

The following tags have compiler defined meaning.

For Objects, Definer Enumerators, and Object Declarations

comment

Used to provide description, or describe quirks and non-obvious information regarding something. Will be shown in documentation and generated code.

The format is general text input.

For example

smsg SMSG_TEST = 0x00 {
    u8 basic;
} {
    comment = "Spell id 1337 prevents this from being sent.";
}

Multiple comment tags are allowed and will not overwrite each other. One comment tag should be used for each distinctive comment.

For example

smsg SMSG_TEST = 0x00 {
    u8 basic {
        comment = "This is one thing to say.";
        comment = "This is something else.";
    }
}

The descriptive comment version of this can also be used. Any line that starts with three forward slashes (///) will be interpreted as a comment on the item below.

So the above two examples would be:

/// Spell id 1337 prevents this from being sent.
smsg SMSG_TEST = 0x00 {
    u8 basic;
}

And

smsg SMSG_TEST = 0x00 {
    /// This is one thing to say.
    /// This is something else.
    u8 basic;
}

This is the preferred way of adding comments.

Linking

Text in comments can hyperlink to other objects by surrounding them in square brackets ([ and ]).

For example

smsg SMSG_TEST = 0x00 {
    u8 basic;
} {
    comment = "Reponse to [CMSG_TEST].";
}

For Objects

versions

Used for defining world message versions.

MUST be in the format of either:

• <major>
• <major>.<minor>
• <major>.<minor>.<patch>
• <major>.<minor>.<patch>.<build>
• *

Or any repetition of any of the above separated by space, except for * which overrides all other options.

Where:

• <major> is the expansion release of the game. E.g. 1 for Vanilla, 2 for The Burning Crusade.
• <minor> is the major patch release of the game, sometimes named.
• <patch> is the quick patch release of the game.
• <build> is the exact build number of the client. Often different between localizations.
• * means all known versions.

Multiple versions separated by a space are allowed.

For example

struct S {
    u8 basic;
} {
    versions = "1.12";
}

Or covering more versions

struct S {
    u8 basic;
} {
    versions = "1.12 1.11 1.8";
}

Which cover versions 1.12, 1.11, and 1.8 and no others.

paste_versions

Used for defining versions but objects that have an identical layout, but where the types inside the object have different versions so that it is not the same object.

This is intended to reduce copy pasting for objects with identical layouts across versions. Format is the same as versions.

For example

enum Complex : u8 {
    ONE = 1;
    TWO = 2;
} {
    versions = "1.12";
}

enum Complex : u8 {
    ONE = 1;
    TWO = 2;
    THREE = 3;
} {
    versions = "2.4.3";
}

struct S {
    Complex c;
} {
    paste_versions = "1.12 2.4.3"
}

would be the same as

enum Complex : u8 {
    ONE = 1;
    TWO = 2;
} {
    versions = "1.12";
}

enum Complex : u8 {
    ONE = 1;
    TWO = 2;
    THREE = 3;
} {
    versions = "2.4.3";
}

struct S {
    Complex c;
} {
    versions = "1.12"
}

struct S {
    Complex c;
} {
    versions = "2.4.3"
}

login_versions

Used for defining the protocol version used when clients initially connect.

MUST be in the format of a single positive integer.

This value is first sent by the client in CMD_AUTH_LOGON_CHALLENGE_Client or CMD_AUTH_RECONNECT_CHALLENGE_Client.

Multiple versions separated by a space are allowed.

For example

struct S {
    u8 basic;
} {
    login_versions = "2";
}

Or covering more versions

struct S {
    u8 basic;
} {
    login_versions = "2 3 8";
}

Which means that S is valid for versions 2, 3, and 8, and no other versions.

test

Used to signify that the object is made up for internal testing purposes. Objects with these should be ignored unless testing.

Allowed values are either true or false. The absence of a test tag is the same as test = "false";.

For example

smsg SMSG_TEST = 0x00 {
    u8 basic;
} {
    test = "true";
}

zero_is_always_valid

Used on flags when a zero value implicitly also means that any specific enumerator is valid.

For example on AllowedRace, a 0 value means that all races are allowed, but a 0xFFFFFFFF value also means that all races are allowed.

For Definer Enumerators

display

Used for defining how the enumerator should be displayed to users. Can be used when the "real" name contains characters that aren't allowed in enumerators, or the enumerator name is undescriptive.

For example

enum Map : u8 {
    VASHJIR = 0 {
        display = "Vashj'ir";
    }
}

For Container Declarations

Valid Values

Specifies valid values for a integer type. Any values that do not conform to the values defined will lead to an invalid message which should be discarded. It is a good idea to use a comment tag to explain why the values are invalid.

Note that values outside of the valid range MUST be invalid in every situation, either because the client can't handle values outside of the valid range, or if regular clients can never send values outside of the valid range.

valid_range

Specifies a range of valid values. MUST be in the format of two integers separated by a space.

Note that these values are inclusive, so for a valid range = "2 10"; both 2 and 10 are also valid values while 1 and 11 are not.

For example

struct S {
    u8 basic {
        valid_range = "0 10";
        comment = "Values outside of 0-10 crash the client";
    }
}

valid_values

Specifies the only values which are valid. MUST be in the format of one or more integers separated by a space.

For example

struct S {
    u8 basic {
        valid_values = "2 4 6 8 10";
        comment = "Odd values crash the client.";
    }
}

For Strings

Size

maximum_length

Specifices an upper limit on the size of the string. This should only be used in cases where the client absolutely can not handle larger strings.

For example

struct S {
    u32 length;
    CString basic {
        maximum_length = "200";
        comment = "Client buffer is only 200 bytes.";
    }
}

Compression

In wowm both messages and individual arrays can have the compressed tag.

Before the compressed data there is a u32 with the size of the data after decompression. This is present both for entire messages that are compressed and for individual arrays.

Both variables and messages can be decompressed with zlib.

In order to verify, the following bytes:

0x78, 0x9c, 0x75, 0xcc, 0xbd, 0x0e, 0xc2, 0x30, 0x0c,
0x04, 0xe0, 0xf2, 0x1e, 0xbc, 0x0c, 0x61, 0x40, 0x95,
0xc8, 0x42, 0xc3, 0x8c, 0x4c, 0xe2, 0x22, 0x0b, 0xc7,
0xa9, 0x8c, 0xcb, 0x4f, 0x9f, 0x1e, 0x16, 0x24, 0x06,
0x73, 0xeb, 0x77, 0x77, 0x81, 0x69, 0x59, 0x40, 0xcb,
0x69, 0x33, 0x67, 0xa3, 0x26, 0xc7, 0xbe, 0x5b, 0xd5,
0xc7, 0x7a, 0xdf, 0x7d, 0x12, 0xbe, 0x16, 0xc0, 0x8c,
0x71, 0x24, 0xe4, 0x12, 0x49, 0xa8, 0xc2, 0xe4, 0x95,
0x48, 0x0a, 0xc9, 0xc5, 0x3d, 0xd8, 0xb6, 0x7a, 0x06,
0x4b, 0xf8, 0x34, 0x0f, 0x15, 0x46, 0x73, 0x67, 0xbb,
0x38, 0xcc, 0x7a, 0xc7, 0x97, 0x8b, 0xbd, 0xdc, 0x26,
0xcc, 0xfe, 0x30, 0x42, 0xd6, 0xe6, 0xca, 0x01, 0xa8,
0xb8, 0x90, 0x80, 0x51, 0xfc, 0xb7, 0xa4, 0x50, 0x70,
0xb8, 0x12, 0xf3, 0x3f, 0x26, 0x41, 0xfd, 0xb5, 0x37,
0x90, 0x19, 0x66, 0x8f

Should decompress to the following bytes:

66, 108, 105, 122, 122, 97, 114, 100, 95, 65, 117, 99, 116, 105, 111, 110, 85, 73, 0, // [0].AddonInfo.addon_name: CString
1, // [0].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [0].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [0].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 66, 97, 116, 116, 108, 101, 102, 105, 101, 108, 100, 77, 105, 110, 105, 109, 97, 112, 0, // [1].AddonInfo.addon_name: CString
1, // [1].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [1].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [1].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 66, 105, 110, 100, 105, 110, 103, 85, 73, 0, // [2].AddonInfo.addon_name: CString
1, // [2].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [2].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [2].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 67, 111, 109, 98, 97, 116, 84, 101, 120, 116, 0, // [3].AddonInfo.addon_name: CString
1, // [3].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [3].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [3].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 67, 114, 97, 102, 116, 85, 73, 0, // [4].AddonInfo.addon_name: CString
1, // [4].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [4].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [4].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 71, 77, 83, 117, 114, 118, 101, 121, 85, 73, 0, // [5].AddonInfo.addon_name: CString
1, // [5].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [5].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [5].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 73, 110, 115, 112, 101, 99, 116, 85, 73, 0, // [6].AddonInfo.addon_name: CString
1, // [6].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [6].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [6].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 77, 97, 99, 114, 111, 85, 73, 0, // [7].AddonInfo.addon_name: CString
1, // [7].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [7].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [7].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 82, 97, 105, 100, 85, 73, 0, // [8].AddonInfo.addon_name: CString
1, // [8].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [8].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [8].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 84, 97, 108, 101, 110, 116, 85, 73, 0, // [9].AddonInfo.addon_name: CString
1, // [9].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [9].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [9].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 84, 114, 97, 100, 101, 83, 107, 105, 108, 108, 85, 73, 0, // [10].AddonInfo.addon_name: CString
1, // [10].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [10].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [10].AddonInfo.addon_extra_crc: u32
66, 108, 105, 122, 122, 97, 114, 100, 95, 84, 114, 97, 105, 110, 101, 114, 85, 73, 0, // [11].AddonInfo.addon_name: CString
1, // [11].AddonInfo.addon_has_signature: u8
109, 119, 28, 76, // [11].AddonInfo.addon_crc: u32
0, 0, 0, 0, // [11].AddonInfo.addon_extra_crc: u32

The Python standard library has a zlib module which can be used for this:

import zlib
data = bytes([0x78, 0x9c, 0x75, 0xcc, 0xbd, 0x0e, 0xc2, 0x30, 0x0c, 0x04, 0xe0, 0xf2, 0x1e, 0xbc, 0x0c, 0x61, 0x40, 0x95, 0xc8, 0x42, 0xc3, 0x8c, 0x4c, 0xe2, 0x22, 0x0b, 0xc7, 0xa9, 0x8c, 0xcb, 0x4f, 0x9f, 0x1e, 0x16, 0x24, 0x06, 0x73, 0xeb, 0x77, 0x77, 0x81, 0x69, 0x59, 0x40, 0xcb, 0x69, 0x33, 0x67, 0xa3, 0x26, 0xc7, 0xbe, 0x5b, 0xd5, 0xc7, 0x7a, 0xdf, 0x7d, 0x12, 0xbe, 0x16, 0xc0, 0x8c, 0x71, 0x24, 0xe4, 0x12, 0x49, 0xa8, 0xc2, 0xe4, 0x95, 0x48, 0x0a, 0xc9, 0xc5, 0x3d, 0xd8, 0xb6, 0x7a, 0x06, 0x4b, 0xf8, 0x34, 0x0f, 0x15, 0x46, 0x73, 0x67, 0xbb, 0x38, 0xcc, 0x7a, 0xc7, 0x97, 0x8b, 0xbd, 0xdc, 0x26, 0xcc, 0xfe, 0x30, 0x42, 0xd6, 0xe6, 0xca, 0x01, 0xa8, 0xb8, 0x90, 0x80, 0x51, 0xfc, 0xb7, 0xa4, 0x50, 0x70, 0xb8, 0x12, 0xf3, 0x3f, 0x26, 0x41, 0xfd, 0xb5, 0x37, 0x90, 0x19, 0x66, 0x8f])

decompressed_data = zlib.decompress(data)

compressed_data = zlib.compress(decompressed_data)

AchievementDoneArray

Array of AchievementDone structs that, like the AchievementInProgressArray, does not have a size variable but instead terminates if the achievement value is -1.

AchievementDoneArray is only for Wrath.

AchievementInProgressArray

Array of AchievementInProgress structs that, like the AchievementDoneArray, does not have a size variable but instead terminates if the achievement value is -1.

AchievementInProgressArray is only for Wrath.

AddonArray

Array of Addon for TBC and Wrath that rely on externally knowing the amount of array members.

Masks

Masks consist of an integer pattern mask and a member for every set bit in the pattern mask.

Vanilla

AuraMask has a pattern of 32 bits, with u16 members.

TBC

AuraMask has a pattern of 64 bits with Aura struct members.

Wrath

AuraMask has a pattern of 64 bits with Aura struct members.

pub struct AuraMask {
    auras: [Option<u16>; Self::MAX_CAPACITY],
}

impl AuraMask {
    const MAX_CAPACITY: usize = 32;

    pub fn read(r: &mut impl Read) -> Result<Self, io::Error> {
        let mut auras = [None; Self::MAX_CAPACITY];
        let bit_pattern: u32 = crate::util::read_u32_le(r)?;

        for (i, aura) in auras.iter_mut().enumerate() {
            if (bit_pattern & (1 << i)) != 0 {
                *aura = Some(crate::util::read_u16_le(r)?);
            }
        }

        Ok(Self { auras })
    }

    pub(crate) fn write_into_vec(&self, mut v: &mut Vec<u8>) -> Result<(), std::io::Error> {
        let mut bit_pattern: u32 = 0;
        for (i, &b) in self.auras().iter().enumerate() {
            if b.is_some() {
                bit_pattern |= 1 << i;
            }
        }

        std::io::Write::write_all(&mut v, bit_pattern.to_le_bytes().as_slice())?;

        for &i in self.auras() {
            if let Some(b) = i {
                std::io::Write::write_all(&mut v, b.to_le_bytes().as_slice())?;
            }
        }

        Ok(())
    }

    pub const fn auras(&self) -> &[Option<u16>] {
        self.auras.as_slice()
    }

    pub const fn size(&self) -> usize {
        std::mem::size_of::<u32>() + std::mem::size_of::<u16>() * self.auras.len()
    }
}

CacheMask

A u32 followed by a u32 for every set bit in the first u32. CacheMask is only for Wrath.

DateTime

u32 in the format of years_after_2000 << 24 | month << 20 | month_day << 14 | weekday << 11 | hours << 6 | minutes.

All values start on 0, and weekday starts on Sunday.

EnchantMask

EnchantMask has a pattern (u16) of 16 bits with 16 bit (u16) members. The EnchantMask is Wrath only.

InspectTalentGearMask

InspectTalentGearMask has a pattern of 32 bits with members the size of their individual InspectTalentGear. InspectTalentGearMask is Wrath only.

MonsterMoveSpline

Array of splines used in SMSG_MONSTER_MOVE for Vanilla/TBC/Wrath. Consists of a u32 with the amount of splines, followed by the first spline as a Vector3d (x, y, z as floats) and then the remaining splines as packed u32s.

A C function for converting to and from the packed u32s would be:

uint32_t to_packed_vector3d(float x, float y, float z)
{
    uint32_t packed = 0;
    packed |= ((uint32_t)(x / 0.25f) & 0x7FF);
    packed |= ((uint32_t)(y / 0.25f) & 0x7FF) << 11;
    packed |= ((uint32_t)(z / 0.25f) & 0x3FF) << 22;
    return packed;
}

Vector3d from_packed(uint32_t p)
{
    float x = (float)((p & 0x7FF) / 4);
    float y = (float)(((p >> 11) & 0x7FF) / 4);
    float z = (float)(((p >> 22) & 0x3FF) / 4);

    return Vector3d { x, y, z };
}

PackedGuid

NOT VALID FOR ALL VERSIONS. ONLY KNOWN VALID FOR VANILLA, TBC AND WRATH

Some messages omit zero bytes from the GUID and instead send a byte mask as the first value. The byte mask is then iterated through and every set bit indicates that a byte of the GUID has been sent.

Note that the bit positions and not the integer values determine how many GUID bytes are sent. So for example a byte mask of 0b00000010 (0x2) indicates that the second least significant byte will be sent and the rest are zero, not that two bytes will be sent.

Since this format is impossible to model elegantly in the Wowm language it is treated as a built-in type that codegen units handle.

Examples

Assume the following bytes are sent (first byte is shown as binary for ease of understanding)

0b00001010, 0xDE, 0xAD

This means that:

• The least significant (0th) byte is zero
• The second least significant byte (1st) byte is 0xDE
• The third least significant (2nd) byte is zero
• The fourth least significant (3rd) byte is 0xAD
• The rest are zero.

Giving a final GUID of 0x00000000AD00DE00.

The following C code will parse packed GUIDs:

#include <stdint.h>
#include <stdio.h>

// Assume data is a pointer to immediately after the byte mask
uint64_t parse_packed_guid(uint8_t byte_mask, uint8_t* data) {
    uint64_t guid = 0;
    // We can't use i because only set bits move the cursor
    uint8_t cursor = 0;

    for (uint8_t i = 0; i < 8; ++i) {
        if (byte_mask & (1 << i)) {
            guid |= (data[cursor] << (i * 8));

            ++cursor;
        }
    }

    return guid;
}

int main() {
    uint8_t byte_mask = 0b00001010;
    uint8_t data[] = { 0xDE, 0xAD };

    uint64_t guid = parse_packed_guid(byte_mask, (uint8_t*)&data);

    printf("%lx", guid);
}

The following Python code will parse packed GUIDs:

# Assume data is a list of the remaining message data
def parse_packed_guid(byte_mask, data):
    guid = 0
    # We can't use i because only set bits move the cursor
    cursor = 0

    for i in range(0, 8):
        if byte_mask & (1 << i):
            guid |= (data[cursor] << (i * 8))
            cursor += 1

    return guid


byte_mask = 0b00001010
data = [0xDE, 0xAD]

print(hex(parse_packed_guid(byte_mask, data)))

NamedGuid

A u64 followed by a CString if the u64 is not equal to 0.

UpdateMask

An UpdateMask is a variable length way of sending known fields to the client. It is represented by a byte mask that decides which fields are sent afterwards.

Representation

The UpdateMask starts with a single u8 that decides how many u32 mask blocks will follow. The bit pattern in these mask blocks determine how many additional u32s of data will follow and how to interpret that data.

Examples

The absolute minimum amount of fields that need to be set to log a player into the world are:

• OBJECT_GUID, an Object field.
• OBJECT_TYPE, an Object field.
• UNIT_HEALTH, a Unit field.
• UNIT_BYTES_0, a Unit field.

To find out how many mask blocks we need to send we take the highest offset field (UNIT_BYTES_0 with 36) and divide it by the amount of bits in a u32 and rounding up. This gives us 2 mask blocks that we need to send.

To figure out which bits must be set on the mask blocks we look up the offset and sizes for our fields. A size of 1 means that only the bit at the offset should be set. A size of 2 means that the bit at the offset and the bit at the offset + 1 should be set, and so on.

Realistically you will have to store the mask blocks in an array of u32s. The correct index and bit position can then be found by dividing to find the index, and modulus to find the bit position within that index.

For UNIT_BYTES_0 with an offset of 36, this means that our index and bit position is:

index = 36 / 32 = 1
bit = 36 % 32 = 4

We do this for every field.

We then send, in order:

1. A u8 with the amount of mask bytes.
2. The mask bytes as u32s.
3. The data values as u32s.

Examples

The following Python example uses the asyncio module. Additionally read_int is a function that reads a certain amount of bytes and returns it as an integer. So read_int(reader, 1) would return a u8 and read_int(reader, 4) would return a u32.

The dict[int, int] is a dictionary of integers, also called a hash map. The keys are the offsets defined below, and the values are u32 data values.

The write function uses Python's struct module to pack the data into a byte array. The reference for struct lists the different format characters used.

The Python code below does not have the best API; users will have to fill out the dict using the offsets defined as constants without any type safety, merging of fields for Guids, or splitting of fields into smaller types. When designing your own UpdateMask type consider what API it allows you to expose.

class UpdateMask:
    fields: dict[int, int]

    @staticmethod
    async def read(reader: asyncio.StreamReader):
        amount_of_blocks = await read_int(reader, 1)

        blocks = []
        for _ in range(0, amount_of_blocks):
            blocks.append(await read_int(reader, 4))

        fields = {}
        for block_index, block in enumerate(blocks):
            for bit in range(0, 32):
                if block & 1 << bit:
                    value = await read_int(reader, 4)
                    key = block_index * 32 + bit
                    fields[key] = value

        return UpdateMask(fields=fields)

    def write(self, fmt, data):
        highest_key = max(self.fields)
        amount_of_blocks = highest_key // 32
        if highest_key % 32 != 0:
            amount_of_blocks += 1

        fmt += 'B'
        data.append(amount_of_blocks)

        blocks = [0] * amount_of_blocks

        for key in self.fields:
            block = key // 32
            index = key % 32
            blocks[block] |= 1 << index

        fmt += f'{len(blocks)}I'
        data.extend(blocks)

        for key in sorted(self.fields):
            fmt += 'I'
            data.append(self.fields[key])

        return fmt, data

    def size(self):
        highest_key = max(self.fields)
        amount_of_blocks = highest_key // 32

        extra = highest_key % 32
        if extra != 0:
            extra = 1
        else:
            extra = 0

        return 1 + (extra + amount_of_blocks + len(self.fields)) * 4

Lookup Table

Version 1.12

Taken from vmangos with some modifications.

Fields that all objects have:

Fields that all items have:

Fields that all containers have:

Fields that all units have:

Fields that all players have:

Fields that all gameobjects have:

Fields that all dynamicobjects have:

Fields that all corpses have:

Version 2.4.3

Taken from mangosone with some modifications.

Fields that all objects have:

Fields that all items have:

Fields that all containers have:

Fields that all units have:

Fields that all players have:

Fields that all gameobjects have:

Fields that all dynamicobjects have:

Fields that all corpses have:

Version 3.3.5

Taken from ArcEmu with some modifications.

Fields that all objects have:

Fields that all items have:

Fields that all containers have:

Fields that all units have:

Fields that all players have:

Fields that all gameobjects have:

Fields that all dynamicobjects have:

Fields that all corpses have:

VariableItemRandomProperty

This type is simply a u32 followed by another u32 if the first one was not equal to 0. VariableItemRandomProperty is only for TBC and Wrath.

The first u32 is the item_random_property_id, the second is the item_suffix_factor.

u48

A u32 followed by a u16. This is a workaround to MovementFlags for 3.3.5 requiring control flow from both a u32 and a separate u16, which complicates the implementation.

The lower 32 bits (4 bytes) are sent first as little endian, then followed by the upper 16 bits (2 bytes) as little endian.

Introduction

The wowm data contained in this repository can be read in a structured manner from the intermediate_representation.json file. It uses the JSON Typedef schema in the intermediate_representation_schema.json file.

jtd-codegen can be used to automatically create language bindings in some modern languages, including TypeScript and Python.

It is highly recommended to automatically generate bindings rather than manually parsing the JSON.

If JSON Typedef doesn't work for you for whatever reason, it is also possible to deduce a JSON Schema of the intermediate_representation.json file and autogenerate bindings from that. They will likely be of much lower quality though.

After generating the bindings, take a look at Implementing login messages.

Tests

Some containers have associated tests that consist of binary data as well as what is expected to be parsed. Creating simple tests that read the raw bytes, asserts that the read went successfully, writing the bytes back and asserting that raw bytes match, as well as testing that the size is calculated correctly will save you a lot of effort.

Design of types

Before writing the auto generator it's a good idea to know what you actually want to generate. For this reason I suggest manually writing the implementations for a few select types, and using it to have a client connect. This will allow you to detect things that need to be changed as early as possible as well as having executable code that can be used to test your auto generated code later, even in interpreted languages.

Implementing login messages

The login message data can be found in the intermediate_representation.json file. The intermediate_representation_schema.json contains a JSON type def schema for the intermediate_representation.json. The json-typedef-codegen program can be used to generate bindings for many popular languages.

The wow_messages_python repository contains the Python code used to generate the Python message library. It can be used as inspiration for your own implementation. The generator directory contains the actual code generation, and the wow_login_messages directory contains the generated library.

Python code will be shown in this document to provide examples of how libraries could be implemented. If you want to use the Python library then just bypass this and use the library directly instead. A C# library is available here.

Message Layout

All interactions start with the client sending a message, then reading the reply from the server.

All login messages start with an opcode field field that specifies the message contents. This is the only thing the messages have in common.

The only way to know how much data to expect in a message is by a combination of the protocol version sent in the very first message by the client, CMD_AUTH_LOGON_CHALLENGE_Client, and the opcode.

Take a look at the wiki page on login in order to get an understanding for what is going to happen.

Types used for login messages

Login messages use the following types, including enums, flags, and structs:

Library layout

Consider what you want the layout of the library to look like regarding files and directories.

There are several different protocol versions, objects that are valid for more than one version, as well as objects that are valid for all versions. Consider if your programming language benefits from having a type that is identical, but for a different version actually be the same type.

For the Python library, I chose to have a Python file for each version, as well as one for all. Objects that are valid for more than one version are reexported from the lowest version.

The folder layout for the Python library is as follows:

├── README.md
└── wow_login_messages
    ├── all.py
    ├── __init__.py
    ├── opcodes.py
    ├── util.py
    ├── version2.py
    ├── version3.py
    ├── version5.py
    ├── version6.py
    ├── version7.py
    └── version8.py

The __init__.py file is what is imported when just importing wow_login_messages. The opcodes.py file just contains the opcode values for the different messages. The util.py file contains utility functions intended to be used by the user of the library, such as a function that reads the opcode and automatically reads the remaining fields and returns the message as a Python class.

Enums

Enums can only have a single enumerator value, and it can not have any other values than those specifically described. Consider how you would implement and use the ProtocolVersion enum in your programming language.

Newer Python versions have the enum module, which provide an easy way of creating enum types.

So the ProtocolVersion enum in Python looks like:

import enum


class ProtocolVersion(enum.Enum):
    TWO = 2
    THREE = 3
    FIVE = 5
    SIX = 6
    SEVEN = 7
    EIGHT = 8


protocol_version = ProtocolVersion(2)
value = protocol_version.value

This simple snippet allows construction of ProtocolVersion types through ProtocolVersion(2) and getting the value of an enumerator through protocol_version.value.

I have chosen not to include a read or write function on the enum, since this is handled by the object that needs to read/write the enum.

The python library places all imports at the top of the file, and all objects for the same version are in the same file, so it is not necessary to import enum for every enum.

Flags

Flags are like enums, but can have multiple enumerator values at the same time, or none of them. Consider how you would implement and use the RealmFlag flag in your programming language.

The enum module used for enums can also be used for flags.

So the RealmFlag enum in Python looks like:

import enum


class RealmFlag(enum.Flag):
    NONE = 0
    INVALID = 1
    OFFLINE = 2
    FORCE_BLUE_RECOMMENDED = 32
    FORCE_GREEN_RECOMMENDED = 64
    FORCE_RED_FULL = 128


realm_flag = RealmFlag(32) | RealmFlag(2)

assert realm_flag.OFFLINE
assert realm_flag.FORCE_BLUE_RECOMMENDED

value = realm_flag.value

This snippet allows the construction of RealmFlag through RealmFlag(32), the bitwise or through the | operator and getting the value through realm_flag.value.

Flags also do not handle reading and writing, that is handled by the objects containing them, although it could be different in your programming language.

CMD_AUTH_LOGON_CHALLENGE_Client

This is the first message sent by the client. It is sent automatically upon connecting.

It is the only message to have the String type, which is a single length byte (u8) followed by as many bytes as the length byte says of string. All other messages use the CString type, which is an arbitrary amount of bytes terminated by a 0 byte.

It is the only message that contains the IpAddress type alias. This is not a "real" type, but simply a u32 that should be interpreted as an IP address if the programming language has built in ways of dealing with IP addresses.

It contains the ProtocolVersion enum, which determines which version of messages is used.

It contains the Version struct.

For writing a server, it requires being able to be read, and for clients it requires being able to be written. When sent by clients, it has to calculate how large the actual message being sent is, and put it in the size field.

In Python, the definition would be:

import dataclasses


@dataclasses.dataclass
class CMD_AUTH_LOGON_CHALLENGE_Client:
    protocol_version: ProtocolVersion
    version: Version
    platform: Platform
    os: Os
    locale: Locale
    utc_timezone_offset: int
    client_ip_address: int
    account_name: str

The types after the colon (:) are type hints. The @dataclasses.dataclass attribute adds some niceties like automatic constructors.

All containers have read, write and _size methods. The underscore in _size is a Python way of signalling that the method should be private.

The read function looks like

@staticmethod
async def read(reader: asyncio.StreamReader):
    # protocol_version: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U8: 'U8'>, type_name='ProtocolVersion', upcast=False))
    protocol_version = ProtocolVersion(int.from_bytes(await reader.readexactly(1), 'little'))

    # size: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U16: 'U16'>)
    _size = int.from_bytes(await reader.readexactly(2), 'little')

    # game_name: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    _game_name = int.from_bytes(await reader.readexactly(4), 'little')

    # version: DataTypeStruct(data_type_tag='Struct', content=DataTypeStructContent(sizes=Sizes(constant_sized=True, maximum_size=5, minimum_size=5), type_name='Version'))
    version = await Version.read(reader)

    # platform: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Platform', upcast=False))
    platform = Platform(int.from_bytes(await reader.readexactly(4), 'little'))

    # os: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Os', upcast=False))
    os = Os(int.from_bytes(await reader.readexactly(4), 'little'))

    # locale: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Locale', upcast=False))
    locale = Locale(int.from_bytes(await reader.readexactly(4), 'little'))

    # utc_timezone_offset: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    utc_timezone_offset = int.from_bytes(await reader.readexactly(4), 'little')

    # client_ip_address: DataTypeIPAddress(data_type_tag='IpAddress')
    client_ip_address = int.from_bytes(await reader.readexactly(4), 'big')

    # account_name: DataTypeString(data_type_tag='String')
    account_name = int.from_bytes(await reader.readexactly(1), 'little')
    account_name = (await reader.readexactly(account_name)).decode('utf-8')

    return CMD_AUTH_LOGON_CHALLENGE_Client(
        protocol_version,
        version,
        platform,
        os,
        locale,
        utc_timezone_offset,
        client_ip_address,
        account_name,
    )

It reads every member in sequence before returning an object with all the fields. The comments print the name and type of variables, in order to make debugging easier.

This showcases how enums are ready by reading an appropriately sized integer and then passing it into the enum constructor.

The struct Version is read by calling a read function defined on that object.

The IpAddress is simply read as an integer.

Python allows changing the type of a variable, so the account_name variable is first used for the length, and then for the contents.

_size is not included in the object, since manually modifying the size is error prone and tedious. It is instead calculated automatically in write. _game_name is not included in the object since it has a constant value.

The write function looks like

def write(self, writer: asyncio.StreamWriter):
    fmt = '<B'  # opcode
    data = [0]

    # protocol_version: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U8: 'U8'>, type_name='ProtocolVersion', upcast=False))
    fmt += 'B'
    data.append(self.protocol_version.value)

    # size: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U16: 'U16'>)
    fmt += 'H'
    data.append(self.size())

    # game_name: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    fmt += 'I'
    data.append(5730135)

    # version: DataTypeStruct(data_type_tag='Struct', content=DataTypeStructContent(sizes=Sizes(constant_sized=True, maximum_size=5, minimum_size=5), type_name='Version'))
    fmt, data = self.version.write(fmt, data)

    # platform: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Platform', upcast=False))
    fmt += 'I'
    data.append(self.platform.value)

    # os: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Os', upcast=False))
    fmt += 'I'
    data.append(self.os.value)

    # locale: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Locale', upcast=False))
    fmt += 'I'
    data.append(self.locale.value)

    # utc_timezone_offset: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    fmt += 'I'
    data.append(self.utc_timezone_offset)

    # client_ip_address: DataTypeIPAddress(data_type_tag='IpAddress')
    fmt += 'I'
    data.append(self.client_ip_address)

    # account_name: DataTypeString(data_type_tag='String')
    fmt += f'B{len(self.account_name)}s'
    data.append(len(self.account_name))
    data.append(self.account_name.encode('utf-8'))

    data = struct.pack(fmt, *data)
    writer.write(data)

The complexity of this is because of how Pythons struct module for writing values to bytes works. The line with data = struct.pack(fmt, *data) writes the data to a byte array that is then written to the stream on the next line. Hopefully your programming language has a more sane way of writing data to a stream.

The final part is the size calculations, it looks like

def size(self):
    size = 0

    # protocol_version: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U8: 'U8'>, type_name='ProtocolVersion', upcast=False))
    size += 1

    # size: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U16: 'U16'>)
    size += 2

    # game_name: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    size += 4

    # version: DataTypeStruct(data_type_tag='Struct', content=DataTypeStructContent(sizes=Sizes(constant_sized=True, maximum_size=5, minimum_size=5), type_name='Version'))
    size += 5

    # platform: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Platform', upcast=False))
    size += 4

    # os: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Os', upcast=False))
    size += 4

    # locale: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U32: 'U32'>, type_name='Locale', upcast=False))
    size += 4

    # utc_timezone_offset: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U32: 'U32'>)
    size += 4

    # client_ip_address: DataTypeIPAddress(data_type_tag='IpAddress')
    size += 4

    # account_name: DataTypeString(data_type_tag='String')
    size += len(self.account_name)

    return size - 3

This sums up the sizes of all members, and then subtracts the fields that come before the size field.

CMD_AUTH_LOGON_CHALLENGE_Server

The servers reply to the client has the same opcode as the initial message, and it provides the first example of a message that has control flow (if statements).

@dataclasses.dataclass
class CMD_AUTH_LOGON_CHALLENGE_Server:
    result: LoginResult
    server_public_key: typing.Optional[typing.List[int]]
    generator: typing.Optional[typing.List[int]]
    large_safe_prime: typing.Optional[typing.List[int]]
    salt: typing.Optional[typing.List[int]]
    crc_salt: typing.Optional[typing.List[int]]

The Python version solves this issue by making every variable that is not certain to be in the message Optional. This type hint means that the variables can also be None, and have no value of their actual type.

The python code for reading reads the result and then branches based on the value.

    @staticmethod


async def read(reader: asyncio.StreamReader):
    server_public_key = None
    generator_length = None
    generator = None
    large_safe_prime_length = None
    large_safe_prime = None
    salt = None
    crc_salt = None

    # protocol_version: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U8: 'U8'>)
    _protocol_version = int.from_bytes(await reader.readexactly(1), "little")

    # result: DataTypeEnum(data_type_tag='Enum', content=DataTypeEnumContent(integer_type=<IntegerType.U8: 'U8'>, type_name='LoginResult', upcast=False))
    result = LoginResult(int.from_bytes(await reader.readexactly(1), "little"))

    if result == LoginResult.SUCCESS:
        # server_public_key: DataTypeArray(data_type_tag='Array', content=Array(inner_type=ArrayTypeInteger(array_type_tag='Integer', inner_type=<IntegerType.U8: 'U8'>), size=ArraySizeFixed(array_size_tag='Fixed', size='32')))
        server_public_key = []
        for _ in range(0, 32):
            server_public_key.append(
                int.from_bytes(await reader.readexactly(1), "little")
            )

        # generator_length: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U8: 'U8'>)
        generator_length = int.from_bytes(await reader.readexactly(1), "little")

        # generator: DataTypeArray(data_type_tag='Array', content=Array(inner_type=ArrayTypeInteger(array_type_tag='Integer', inner_type=<IntegerType.U8: 'U8'>), size=ArraySizeVariable(array_size_tag='Variable', size='generator_length')))
        generator = []
        for _ in range(0, generator_length):
            generator.append(int.from_bytes(await reader.readexactly(1), "little"))

        # large_safe_prime_length: DataTypeInteger(data_type_tag='Integer', content=<IntegerType.U8: 'U8'>)
        large_safe_prime_length = int.from_bytes(
            await reader.readexactly(1), "little"
        )

        # large_safe_prime: DataTypeArray(data_type_tag='Array', content=Array(inner_type=ArrayTypeInteger(array_type_tag='Integer', inner_type=<IntegerType.U8: 'U8'>), size=ArraySizeVariable(array_size_tag='Variable', size='large_safe_prime_length')))
        large_safe_prime = []
        for _ in range(0, large_safe_prime_length):
            large_safe_prime.append(
                int.from_bytes(await reader.readexactly(1), "little")
            )

        # salt: DataTypeArray(data_type_tag='Array', content=Array(inner_type=ArrayTypeInteger(array_type_tag='Integer', inner_type=<IntegerType.U8: 'U8'>), size=ArraySizeFixed(array_size_tag='Fixed', size='32')))
        salt = []
        for _ in range(0, 32):
            salt.append(int.from_bytes(await reader.readexactly(1), "little"))

        # crc_salt: DataTypeArray(data_type_tag='Array', content=Array(inner_type=ArrayTypeInteger(array_type_tag='Integer', inner_type=<IntegerType.U8: 'U8'>), size=ArraySizeFixed(array_size_tag='Fixed', size='16')))
        crc_salt = []
        for _ in range(0, 16):
            crc_salt.append(int.from_bytes(await reader.readexactly(1), "little"))

    return CMD_AUTH_LOGON_CHALLENGE_Server(
        result,
        server_public_key,
        generator,
        large_safe_prime,
        salt,
        crc_salt,
    )

CMD_AUTH_LOGON_PROOF_Client

This message is much like the others, but it contains an array of structs.

CMD_REALM_LIST_Client

This message is not empty, but has a padding variable that should always be a constant value, so it becomes empty if constant values are removed.

CMD_XFER_ACCEPT

This message has an empty body.

CMD_REALM_LIST_Server

This message has a bunch of padding and an array of Realm structs, as well as having a size field.

Realm

This struct has several CString variables, which are read by reading until finding a 0 byte.

It also has the Population alias, which can just be substituted for a 4 byte floating point value.

Version 8 additionally has an if statement that uses a flag instead of an enum.

Implementing world messages

If you have autogenerated the login messages you will have a reasonable base for proceeding with the world messages, however this is not a requirement.

The world message data can be found in the intermediate_representation.json file. The intermediate_representation_schema.json contains a JSON type def schema for the intermediate_representation.json. The json-typedef-codegen program can be used to generate bindings for many popular languages.

The wow_messages_python repository contains the Python code used to generate the Python message library. It can be used as inspiration for your own implementation. The generator directory contains the actual code generation, and the wow_world_messages directory contains the generated library.

Python code will be shown in this document to provide examples of how libraries could be implemented. If you want to use the Python library then just bypass this and use the library directly instead. A C# library is available here.

Message Layout

For Vanilla and TBC, all messages start with a 2 byte big endian size field.

For Wrath, all messages from the client (CMSG) start with a 2 byte big endian size field, but at some unknown point in Wrath the possibility of having SMSG with 3 byte opcode was added. If the most significant (first) byte of the size field has the most significant bit set (that is, first_size_byte & 0x80 != 0) the size field is 3 bytes instead of 2. When sending messages from the server you must handle this special case for messages that are larger than 0x7FF bytes.

For all versions, messages sent from the server (SMSG) have a 2 byte opcode field and messages sent from the client (CMSG) have a 4 byte opcode field.

For all versions, the size field contains the size of the opcode field and the size of the remaining message body.

So in the case of the CMSG_PLAYER_LOGIN message:

test CMSG_PLAYER_LOGIN {
    guid = 0xDEADBEEF;
} [
    0x00, 0x0C, /* size */
    0x3D, 0x00, 0x00, 0x00, /* opcode */
    0xEF, 0xBE, 0xAD, 0xDE, 0x00, 0x00, 0x00, 0x00, /* guid */
]

Has a single Guid field (of 8 bytes), but the reported size is 0x0C/12 because it includes the 4 byte opcode field.

Encryption

SMSG_AUTH_CHALLENGE and CMSG_AUTH_RESPONSE are sent in plain text and used to negotiate a simple header encryption based on the session key. It is described in detail for 1.12 in this blog post The wow_srp library written in Rust has implementations for Vanilla (1.12), TBC (2.4.3), and Wrath (3.3.5).

CMSG_PING and SMSG_PONG can also be sent unencrypted if the client has not yet received a reply to CMSG_AUTH_SESSION. These four messages are the only messages that can be sent unencrypted.

Types used for login messages

World messages use the following types, including enums, flags, and structs:

Library layout

Consider what you want the layout of the library to look like regarding files and directories.

You will likely want to limit yourself to a limited set of client versions such as Vanilla (1.12), TBC (2.4.3), and Wrath (3.3.5).

The exact layout of your library will depend on the scope. For the Python library I decided to have a single wow_world_messages package with a module each for Vanilla, TBC, and Wrath.

This is the layout of the Python library:

├── README.md
└── wow_world_messages
    ├── __init__.py
    ├── wrath.py
    ├── tbc.py
    ├── util.py
    └── vanilla.py

AreaFlags

Client Version 1.12

Used in AreaTable.dbc.

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/area_flags.wowm:2.

flag AreaFlags : u16 {
    SNOW = 0x01;
    UNK = 0x02;
    DEVELOPMENT = 0x04;
    UNK2 = 0x08;
    UNK3 = 0x10;
    CITY_SLAVE = 0x20;
    CITY_ALLOW_DUELS = 0x40;
    UNK4 = 0x80;
    CITY = 0x100;
    TEST = 0x200;
}

Type

The basic type is u16, a 2 byte (16 bit) little endian integer.

Enumerators

Used in:

ArenaTeamRole

Client Version 2.4.3, Client Version 3

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/arena/smsg_arena_team_roster.wowm:10.

enum ArenaTeamRole : u8 {
    CAPTAIN = 0;
    MEMBER = 1;
}

Type

The basic type is u8, a 1 byte (8 bit) integer.

Enumerators

Used in:

AttackHand

Client Version 1.12

Used in AttackAnimKits.dbc.

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/attack_hand.wowm:2.

enum AttackHand : u8 {
    MAIN_HAND = 0;
    OFF_HAND = 1;
}

Type

The basic type is u8, a 1 byte (8 bit) integer.

Enumerators

Used in:

AttributesEx1

Client Version 1.12

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/external_spell_1_12.wowm:42.

flag AttributesEx1 : u32 {
    NONE = 0x00;
    DISMISS_PET_FIRST = 0x00000001;
    USE_ALL_MANA = 0x00000002;
    IS_CHANNELED = 0x00000004;
    NO_REDIRECTION = 0x00000008;
    NO_SKILL_INCREASE = 0x00000010;
    ALLOW_WHILE_STEALTHED = 0x00000020;
    IS_SELF_CHANNELED = 0x00000040;
    NO_REFLECTION = 0x00000080;
    ONLY_PEACEFUL_TARGETS = 0x00000100;
    INITIATES_COMBAT_ENABLES_AUTO_ATTACK = 0x00000200;
    NO_THREAT = 0x00000400;
    AURA_UNIQUE = 0x00000800;
    FAILURE_BREAKS_STEALTH = 0x00001000;
    TOGGLE_FARSIGHT = 0x00002000;
    TRACK_TARGET_IN_CHANNEL = 0x00004000;
    IMMUNITY_PURGES_EFFECT = 0x00008000;
    IMMUNITY_TO_HOSTILE_AND_FRIENDLY_EFFECTS = 0x00010000;
    NO_AUTOCAST_AI = 0x00020000;
    PREVENTS_ANIM = 0x00040000;
    EXCLUDE_CASTER = 0x00080000;
    FINISHING_MOVE_DAMAGE = 0x00100000;
    THREAT_ONLY_ON_MISS = 0x00200000;
    FINISHING_MOVE_DURATION = 0x00400000;
    UNK23 = 0x00800000;
    SPECIAL_SKILLUP = 0x01000000;
    AURA_STAYS_AFTER_COMBAT = 0x02000000;
    REQUIRE_ALL_TARGETS = 0x04000000;
    DISCOUNT_POWER_ON_MISS = 0x08000000;
    NO_AURA_ICON = 0x10000000;
    NAME_IN_CHANNEL_BAR = 0x20000000;
    COMBO_ON_BLOCK = 0x40000000;
    CAST_WHEN_LEARNED = 0x80000000;
}

Type

The basic type is u32, a 4 byte (32 bit) little endian integer.

Enumerators

Used in:

AttributesEx2

Client Version 1.12

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/external_spell_1_12.wowm:81.

flag AttributesEx2 : u32 {
    NONE = 0x00;
    ALLOW_DEAD_TARGET = 0x00000001;
    NO_SHAPESHIFT_UI = 0x00000002;
    IGNORE_LINE_OF_SIGHT = 0x00000004;
    ALLOW_LOW_LEVEL_BUFF = 0x00000008;
    USE_SHAPESHIFT_BAR = 0x00000010;
    AUTO_REPEAT = 0x00000020;
    CANNOT_CAST_ON_TAPPED = 0x00000040;
    DO_NOT_REPORT_SPELL_FAILURE = 0x00000080;
    INCLUDE_IN_ADVANCED_COMBAT_LOG = 0x00000100;
    ALWAYS_CAST_AS_UNIT = 0x00000200;
    SPECIAL_TAMING_FLAG = 0x00000400;
    NO_TARGET_PER_SECOND_COSTS = 0x00000800;
    CHAIN_FROM_CASTER = 0x00001000;
    ENCHANT_OWN_ITEM_ONLY = 0x00002000;
    ALLOW_WHILE_INVISIBLE = 0x00004000;
    UNK15 = 0x00008000;
    NO_ACTIVE_PETS = 0x00010000;
    DO_NOT_RESET_COMBAT_TIMERS = 0x00020000;
    REQ_DEAD_PET = 0x00040000;
    ALLOW_WHILE_NOT_SHAPESHIFTED = 0x00080000;
    INITIATE_COMBAT_POST_CAST = 0x00100000;
    FAIL_ON_ALL_TARGETS_IMMUNE = 0x00200000;
    NO_INITIAL_THREAT = 0x00400000;
    PROC_COOLDOWN_ON_FAILURE = 0x00800000;
    ITEM_CAST_WITH_OWNER_SKILL = 0x01000000;
    DONT_BLOCK_MANA_REGEN = 0x02000000;
    NO_SCHOOL_IMMUNITIES = 0x04000000;
    IGNORE_WEAPONSKILL = 0x08000000;
    NOT_AN_ACTION = 0x10000000;
    CANT_CRIT = 0x20000000;
    ACTIVE_THREAT = 0x40000000;
    RETAIN_ITEM_CAST = 0x80000000;
}

Type

The basic type is u32, a 4 byte (32 bit) little endian integer.

Enumerators

Used in:

AttributesEx3

Client Version 1.12

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/external_spell_1_12.wowm:120.

flag AttributesEx3 : u32 {
    NONE = 0x00;
    PVP_ENABLING = 0x00000001;
    NO_PROC_EQUIP_REQUIREMENT = 0x00000002;
    NO_CASTING_BAR_TEXT = 0x00000004;
    COMPLETELY_BLOCKED = 0x00000008;
    NO_RES_TIMER = 0x00000010;
    NO_DURABILITY_LOSS = 0x00000020;
    NO_AVOIDANCE = 0x00000040;
    DOT_STACKING_RULE = 0x00000080;
    ONLY_ON_PLAYER = 0x00000100;
    NOT_A_PROC = 0x00000200;
    REQUIRES_MAIN_HAND_WEAPON = 0x00000400;
    ONLY_BATTLEGROUNDS = 0x00000800;
    ONLY_ON_GHOSTS = 0x00001000;
    HIDE_CHANNEL_BAR = 0x00002000;
    HIDE_IN_RAID_FILTER = 0x00004000;
    NORMAL_RANGED_ATTACK = 0x00008000;
    SUPPRESS_CASTER_PROCS = 0x00010000;
    SUPPRESS_TARGET_PROCS = 0x00020000;
    ALWAYS_HIT = 0x00040000;
    INSTANT_TARGET_PROCS = 0x00080000;
    ALLOW_AURA_WHILE_DEAD = 0x00100000;
    ONLY_PROC_OUTDOORS = 0x00200000;
    CASTING_CANCELS_AUTOREPEAT = 0x00400000;
    NO_DAMAGE_HISTORY = 0x00800000;
    REQUIRES_OFFHAND_WEAPON = 0x01000000;
    TREAT_AS_PERIODIC = 0x02000000;
    CAN_PROC_FROM_PROCS = 0x04000000;
    ONLY_PROC_ON_CASTER = 0x08000000;
    IGNORE_CASTER_AND_TARGET_RESTRICTIONS = 0x10000000;
    IGNORE_CASTER_MODIFIERS = 0x20000000;
    DO_NOT_DISPLAY_RANGE = 0x40000000;
    NOT_ON_AOE_IMMUNE = 0x80000000;
}

Type

The basic type is u32, a 4 byte (32 bit) little endian integer.

Enumerators

Used in:

AttributesEx4

Client Version 1.12

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/external_spell_1_12.wowm:159.

flag AttributesEx4 : u32 {
    NONE = 0x00;
    NO_CAST_LOG = 0x00000001;
    CLASS_TRIGGER_ONLY_ON_TARGET = 0x00000002;
    AURA_EXPIRES_OFFLINE = 0x00000004;
    NO_HELPFUL_THREAT = 0x00000008;
    NO_HARMFUL_THREAT = 0x00000010;
    ALLOW_CLIENT_TARGETING = 0x00000020;
    CANNOT_BE_STOLEN = 0x00000040;
    ALLOW_CAST_WHILE_CASTING = 0x00000080;
    IGNORE_DAMAGE_TAKEN_MODIFIERS = 0x00000100;
    COMBAT_FEEDBACK_WHEN_USABLE = 0x00000200;
    WEAPON_SPEED_COST_SCALING = 0x00000400;
    NO_PARTIAL_IMMUNITY = 0x00000800;
}

Type

The basic type is u32, a 4 byte (32 bit) little endian integer.

Enumerators

Used in:

Attributes

Client Version 1.12

Wowm Representation

Autogenerated from wowm file at wow_message_parser/wowm/world/external/external_spell_1_12.wowm:3.