The structure definitions kind of follow the BinData Ruby Gem declarations. They should be as readable as pseudo code though. More information on BinData can be found here.
Tag | Description | Validated | ||
---|---|---|---|---|
SYNCH |
Tag | Description | Validated | ||
---|---|---|---|---|
0x000001F4 | GAMESTART | |||
0xFFFFFFFF | CHAT | + |
Tag | Description | Validated | ||
---|---|---|---|---|
0x00 | ATTACK | + | ||
0x01 | STOP | + | ||
0x02 | AI_PRIMARY | + | ||
0x03 | MOVE | + | ||
0x0a | AI_MOVE | |||
0x0b | RESIGN | + | ||
0x10 | WAYPOINT | + | ||
0x12 | STANCE | + | ||
0x13 | GUARD | + | ||
0x14 | FOLLOW | + | ||
0x15 | PATROL | + | ||
0x17 | FORMATION | + | ||
0x1b | SAVE & EXIT | |||
0x1f | AI_COORD | + | ||
0x64 | AI_TRAIN | + | ||
0x65 | TECH | + | ||
0x66 | BUILD | + | ||
0x67 | MULTIPURPOSE | |||
0x69 | WALL | + | ||
0x6a | DELETE | + | ||
0x6b | ATTACKGROUND | + | ||
0x6c | TRIBUTE | + | ||
0x6e | REPAIR | + | ||
0x6f | UNGARRISON | + | ||
0x72 | GATE | + | ||
0x73 | FLARE | + | ||
0x75 | GARRISON | + | ||
0x77 | TRAIN | + | ||
0x78 | RALLY | + | ||
0x7a | SELL | + | ||
0x7b | BUY | + | ||
0x7e | RELIC | + | ||
0x7f | TOWNBELL | + | ||
0x80 | BACKTOWORK | + | ||
0xFF | GAMESTATS | UP only |
-
What actions are not saved but only calculated on replay simulation?
- Only actions that are actively taken by players are stored
- Any other actions are either simulated during replay (map reveal) or determined by the random number generator (Gaia movement)
- Pause is not saved, that is why chat messages that were sent during the pause are displayed nearly at once when replayed.
-
What actions are only saved for certain players, i.e., the owner of the recorded game?
- Viewpoints (for lock view) are only saved for the owner of the recorded game, together with the sychronization info.
-
How does AoE2 create an .mgx file?
- Singleplayer games are recorded by getting actions from the input buffer and writing them into the .mgx file.
- During multiplayer games, actions are distributed to all players (even messages). The input buffer is transferred over the network to the other players.
-
Why are there so many zeros in the actions?
- Most of the zeros are caused by memory alignment. Because networking and recording directly work on the input buffer, the data is aligned to 3the size of (menory) words (4 bytes). Example:
struct example { uint8_t player_id; uint32_t unit_id; };
Here the first variable player_id will take up 1 out of 4 bytes of the first word. The next variable, unit_id, doesn't fit into the first word anymore, so it will use a second word instead. The remaining 3 bytes in the first word remain uninitialized and therefore have zero values in them.
-
Why are they doing this weird memory stuff? It sounds stupid
- Because it is fast. Data can be put to use directly and does not have to be parsed.
-
What are the various IDs used for?
- Players have an ID and a number. This is necessary because of an undocumented cooperative mode in AoE2, where players can have the same player number.
- Unit IDs reference a type of unit/building or object in the game files.
- Object IDs reference a specific object during a game. Every building, unit or resource gets an ID. For new units, the IDs are incremented.