Replay file

From Worms Knowledge Base

Jump to: navigation, search
(Up to File formats)

Replay (.WAgame) files were introduced to Worms Armageddon with Deadcode's 3.6.19.7 beta update, which was released on 9 February, 2004. The files represent self-contained recordings of games, which can be played on any computer with the corresponding software updates installed.

Recordings of all games played (including offline, mission and training games) are saved automatically to the User\Games folder. File names consist of a date/time stamp, the game type, and the participating players.

The files contain all the information needed to play the replay flawlessly. This includes the game version which was emulated during the game, the map and the scheme, the participating teams (including the custom flags and graves), and the random seed used for random in-game events (such as random initial placement of worms and objects).

File format

A typical replay file consists of a 4-byte header, a map chunk, a settings chunk, and the message (user input) stream.

The file header consists of two signature bytes ("WA"), after which follows a word with the file version. W:A 3.6.26.5 saves replays in the version 12 format (0x000C).

After the header is the map chunk. The map chunk represents a DWORD which represents the chunk's contents' length (chunk length-4, or map length+4), followed by the chunk data. The first DWORD of the chunk's data specifies the map type - it can be 1 for a bitmap (.BIT) monochrome map, 2 for a seed-generated (.LEV) monochrome map, or 3 for a .PNG colour map. The map data follows, its length being the chunk's length - 4.

Following the map data is the settings (initialization) chunk. Its structure:

  • 3 usually null bytes
  • the replay file version (see header), a 2nd time (WORD)
  • the replay date/time in time_t format
  • a null byte
  • game engine version to emulate (0x30 represents 3.6.26.5; 0x4C represents 3.6.28) (DWORD)
  • game type (normal=1, mission=2, training or mission where winning involves a crate=3) (byte)
  • scheme type (usually 0xFF, positive value for intrinsic schemes) (byte)
  • the scheme - see Game scheme file (length is determined by the scheme file format version)
  • initial logic (random) seed (DWORD)
  • blood amount (byte)
  • rope knocking (byte)
  • the game ID (Pascal string)
  • local machine ID (byte)

This is followed by the data about connected machines, and teams.

User Input

Generalities

After the padding mentioned above, the game starts with a Frame 0 checksum. Versions 3.7.0.0 and newer seem to create additional Various player information shortly after this checksum. Versions 3.6.19.15-3.6.29.0 didn't record the passage of time between turns (see Readme): a control spacer was used, so, before advancing into the next turn, the game engine would wait until all pending events were stabilized (Mines triggered, flames falling, animals running, ...). Each turn is divided in frames, at a rate of 50 frames per second. Those frames are seperated by a 02 byte. A frame can be empty, or contain the events happened at that very moment. Each 25 frames, the word 0C 1E is inserted. Its purpose is yet unknown, and it is sometimes followed by a byte ranging from 03 to 07, for unknown reasons too. Each time a weapon is used, a checksum gets inserted into the following frame.

Events

Various events consist of two or more bytes, where the first one is the event itself, and the second one is the team that performed the action. However, it is not possible to change the "Active team" byte to move another worm while it's not his turn. For example, the event 1E corresponds to the left arrow; the event 21 to the down arrow. If the active worm is in the third team, the frame will look like "02 1E 03 21 03" (the end of previous frame, left+down key press of the team #3). Some events are more complex, and require therefore additional arguments. Those are typically inserted before or after the "Active team" byte. Some events take the "machine number" as an argument instead of a team: for example, Machine 0 = Player 1, which is the host of the game. Here is a list of the event codes in the latest replay format, along with their arguments when applicable. Events for older replay formats might be added later.

Code Arguments Event Example
00 Control spacer. Only valid in the replay formats of 3.6.19.15-3.6.29.0, to wait until the next turn. 00
02 Frame end. 02
06 mm Round Finish acknowledgement. mm is the number of the machine. Usually happens in the end of the game. 02 06 00 : Round Finish was acknowledged by Player 1
08 xx xx xx xx zz zz zz zz Checksum. xx is the frame number in which it happened for the active team, and zz is the checksum. 02 08 xx xx xx xx zz zz zz zz
09 zz zz zz zz Frame 0 checksum. 00 09 xx xx xx xx
0C xx zz zz zz zz Unknown. Seems to be ignored by the game. xx is usually 1E or 1F, sometimes 20 in older versions, and zz is a dword usually consisting of the 02 bytes, which can occasionally be different. 02 0C 1E 02 02 02 02
0D mm zz Supplementary disconnection information. mm is the number of the machine, and zz is the information code. See the table below. 02 0D 00 01 - The host of the game is quitting
0F x1 x2 yy [...] 00 Discussion (in chat). [...] is the text string, terminated with a null afterwards. x1 is the real machine who sent the message, x2 is the number of a visually represented (imaginary) sender (FF for anon, normal for everything else), and yy is the receiving machine. See the table below. 02 0F 01 01 FF [...] 00 : Player 2 (machine 1) has sent a public chat message.
11 tt XX XX YY YY Cursor movement. tt is the team number; the XX and YY word values represent the position of the mouse cursor. 02 11 01 8B 06 01 FF : Team 1 has placed the mouse at X = 1675 (0x068B) and Y = -255 (0xFF01)
12 tt zz Orienting a girder. tt is the team number; zz represents the new orientation of the girder. (01-0F) 02 12 01 0B 01 : Team 1 oriented the girder to a long topright inclined girder.
13 tt zz Shifting strike aimer. tt is the team number; zz represents the new orientation of the Aimer. (01 to the right ; FF to the left) 02 13 01 01 : Team 1 oriented the strike aimer to the right (Pressing Left key).
16 xx The end of the game. xx is the reason (see the table below) 02 16 00 : Player ended the game by using Alt+F4.
17 Cut the parachute of a falling crate. This is usually performed instantly.
1A tt Thought bubble : Equivalent to keypress T. tt is the team number. 02 1A 01 : Team 2 displayed a Thought Bubble over controlled worm.
1B xx Unknown event with 1 unknown argument.
1E tt Left arrow (in all its in-game usages). tt is the team number. 02 1E 02 21 02 : Team 2 had Left+Down pressed in that frame.
1F tt Right arrow. tt is the team number.
20 tt Up arrow (in all its in-game usages). tt is the team number.
21 tt Down arrow. tt is the team number.
24 tt Release (unmount) of the ninja rope; Forward Jump; Backward jump if used twice (not in the same frame). tt is the team number. 02 24 04 02 02 02 02 24 04 02 02 : Team 4 pressed Enter twice, with a 3 frames interval, to backjump
25 tt Upward jump; Backflip if used twice (not in the same frame). tt is the team number. 02 25 04 02 02 02 02 24 04 02 02 : Team 4 pressed Backspace-Enter, with a 3 frames interval, to backjump
26 tt Usage (launch) of a weapon: from the ground, via a teleport/strike click, or from any utility (rope, parachute, ...) allowing weapon drops. It can appear several times for weapons having multiple shots (guns, rope, ...), but not in the same frame. It triggers a checksum except in the case of a ninja rope being re-fired from the air (depends on various factors). tt is the team number. 02 26 01 02 08 tt yy 00 00 zz zz zz zz 02 20 01 02 20 01 02 20 01 02 20 01 02 20 01 02 24 01 02 26 01 : Team 1 fires the ninja rope, causing a checksum, then shortens it during 5 frames, then releases it and fires it again. The second firing won't generate any checksum.
27 tt Release of a power-managed weapon: e.g. Bazooka, Grenade, and anything else that requires you to hold the spacebar for getting a power increase. tt is the team number. 02 26 02 02 02 02 02 02 02 02 27 02 : Team 2 presses space to fire a bazooka, and releases space 7 frames later. tt is the team number. (Note the possible confusion between frame separator 02 and "Active team" 02.)
2B tt Team got forced out. tt is the number of the team; a value out of range like 0 will apparently just produce a "coward" sound without doing anything. The extended information about this is provided by the event 6D, which, in its turn, is also feeded by 0D. If either of those are missing, it's assumed that the team got forced out due to a possible message injection. 02 2B 01 : Team 1 got forced out
2C tt A self-managed weapon trigger (Sheep, Skunk, ...) after having launched it. tt is the team number. 02 2C 01 02 02 02 2C 01 : Team 1 has its skunk start to fart, then makes it explode 3 frames later.
2D tt Direct the flying Sheep to the left. tt is the team number.
2E tt Direct the flying Sheep to the right. tt is the team number. 02 2E 01 02 2E 01 02 02 2D 01 02 2D 01 : Team 1 Turns the flying sheep to the right during 2 frames, waits one frame, then turns to the left during 2 frames
2F ww nn Setting fuse (grenades and related weapons). ww represents both the team and worm (as detailed in event 32) and nn is the fuse, from which 1 is substracted (00-04). 02 33 21 06 01 02 2F 21 04 : First worm of the second team (21) selects a grenade (06) and sets its fuse to 5s (04)
30 ww nn Setting herd size (cows and related weapons). ww represents both the team and worm (as detailed in event 32) and nn is the size of the herd (01-06). 02 33 21 34 01 02 30 21 02 : First worm of the second team (21) selects a Mad Cow (34) and sets its Herd size to 2 cows (02)
31 ww nn Setting the height of bounciness (grenades and related weapons). ww represents both the team and worm (as detailed in event 32) and nn is the bounciness power (00 for MIN and 01 for MAX). 02 33 21 06 01 02 2F 21 00 02 31 21 01 : First worm of the second team (21) selects a Grenade (06), sets its fuse to 1s (00), and it's bounce height to MAX (01)
32 ww ?? zz XX XX YY YY Mouse click: ww represents both the team number and worm number, zz represents the event involved by the click, XX and YY are the coordinates. 02 32 23 01 01 XX XX YY YY 26 02 : Team 2 (nn = 02) places (zz=01 : initial placement) the 3rd worm of the 2nd team (ww = 23) at the related X and Y coordinates. This triggers a checksum (due to the event 26 being in there too)
33 ww zz ?? Weapon selection. ww represents both the team number and worm number (the same way ww from event 32 does) and zz is the weapon code. 02 33 14 0B 01 : the 4th worm of team 1 selects a Shotgun (zz=0B)
3A Sudden Death. It is in fact triggered before the start of the next team's turn.
43 tt Worm selection (via the Tab key). When rolling arrows above the worm are active, the control will be given to the next worm in the team. Might be present several times within one frame. tt is the team number.
62 tt Pressing Shift. tt is the team number.
6B xx zz zz zz zz Unknown. Seems to be ignored by the game.
6C Spurious Extra Frame (will probably cause a desynchronisation). Inserts an extra frame.
6D mm zz Player disconnection. mm is the number of the machine. Event 0D happened prior to this one provides extended disconnection information (otherwise it's assumed as a network drop). zz is the type of the disconnection (see the table below). 02 6D 00 01 : Player 1 is disconnecting due to a network drop
70-73 mm ss zz [...] Various player information. m is the number of the machine, ss is the size of the data (in [...]), and zz is the type of such information (see the table below). If the size exceeds FF, then the second digit of 70 may contain the high-order digit (e.g. 71), however it's uncertain how it behaves beyond 73 since 74 is occupied.
74 mm zz zz zz A Skipped Packet possibility. mm is the number of the machine, and zz is the index jump value (apparently a 24-bit integer).

Tables

Related to event 0D: Supplementary disconnection information. The valid types are described below.

Type Description
01 Player is quitting
02 Player disconnected due to timeout
04 Player disconnected due to desynchronisation
05 Invalid data received from the player

Related to event 0F: Game chat.

Receiver Meaning
FF Public chat. The message appears as anonymous if the imaginary sender is also FF.
FE A /me action.
10-15 Red, Blue, Green, Yellow, Purple, Cyan team chat respectively.
Others This is a PM to the respective machine (usually in the range 0-6).

Related to event 16: The end of the game.

Type Description
00 User quit with Alt+F4
01 User quit
02 User draw
03 The game ended normally, unless this happened prior to the end of the round (in which case it's assumed as an Alt+F4 quit)
Others Assumed as User quit with Alt+F4

Related to event 32: Mouse click.

Type Purpose
01 Initial worm placement, strike aiming
0B Girder placement

Related to event 33: Weapon selection. The order of the weapons is just like in the grid appearing in-game, with the F5 row having 6 actual weapons, and the utilities being in the end. Instant utilities can't technically be used because their ammo drains immediately once a team holding such a weapon in its possessions starts a turn.

Related to event 6D: Player disconnection. It's assumed by default that the disconnection happened due to a network drop, however an event 0D preceding this one can provide extended information such as quitting.

Type Description
01 Player disconnected due to a network drop
02 Player is disconnecting due to a network drop
03 Player is being disconnected due to desynchronisation
04 Player is being disconnected due to timeout on receive
05 Player is being disconnected due to timeout on send


Related to events 70-73: Various player information. It's mostly unknown.

Type Description
01 Unknown, and the data size seems to stay consistently at 0x0B.
02 A player has reported that another player desynchronized.
06 A bunch of unknown, differently-sized data from W:A v3.7 and newer, usually in the beginning of the game.

Security

The format incorporates periodic checksums, embedded into specific actions. This allows to detect modifications to the replay, causing warning messages during playback.

The tool-assisted versions of W:A save replays in an encrypted format, which is playable only with the tool-assisted version. Only Deadcode can decrypt them, thus making them playable with normal versions of W:A.

Export Log

A log file can be extracted from a replay file to give a text representation of what happens in the replay. The log file includes:

  • The date and time that the game was played, GMT
  • The game version with which the game was played
  • Mission number and name, if applicable
  • A list of the players involved, the colours they played as, the names of the teams they used, and any CPU teams involved (and their skill levels)
  • A chronologically-ordered list of things that happened in the game, including:
    • Comments made by players in the chat window
    • Turn starts
    • Weapon shots (with some details e.g. herd number; fuse time; bounce; jetpack fuel used etc.)
    • Health deductions (not including poison)
    • Turn endings (including time used and retreat time used)
    • End of game
  • Total time used by each team, split into turn time and retreat time
  • Mission result, if applicable
  • Round number
  • Round time
  • Total game time
  • Total worms killed
  • Total health lost
  • Name of the team which won the game
  • Name of the "worm of the round"
  • Name of the worm that dealt the most damage with one shot
  • Match awards

Extracting maps

The Extract Map command will extract the map in the appropriate file format (.png for colour maps, and .bit/.lev for monochrome maps and auto-generated terrain maps). If you need to extract a colour map in a common format for any map type, you can use the Export LOG command (WA.exe /getlog Replay.WAgame) and extract the map pixels from the Land Data file which was updated by the command.

Retrieved from "https://worms2d.info/?title=Replay_file&oldid=26603"
Personal tools