# Missions, tasks and routes

The reference installation contains 110 missions in its active English bundle: 60 campaign missions, 30 single missions, ten training missions and ten Hind versus Apache missions. The campaign is divided between Yemen, Korea and Cyprus. Training uses Fort. Each campaign has eight levels, with multiple missions in some levels.

| Mission IDs | Selection |
| --- | --- |
| 1–60 | Campaigns, 20 missions per warzone |
| 61–70 | Training |
| 81–90 | Yemen single missions |
| 101–110 | Korea single missions |
| 121–130 | Cyprus single missions |
| 141–150 | Hind versus Apache |

The menu metadata carries the game-flow value, warzone and campaign level. These fields drive grouping in the workbench. Names and briefings come from the resource text.

## Briefing bundles

A `.BLK` briefing bundle is a sequence of little-endian records:

1. Signed 32-bit mission ID.
2. Unsigned 32-bit text length, followed by that many bytes of briefing text.
3. Unsigned 32-bit metadata length, followed by the metadata text.

ID `−1` terminates the file. The text uses Windows-1252. A line beginning with a colon introduces a tag; the following nonempty lines belong to that tag. Preserve their order. Repeated tags describe successive actors or waypoints and cannot be flattened into a dictionary.

Four supplied bundles contain 411 entries in total. All IDs, titles, game-flow values, warzones and campaign levels match execution of `initialise_missions_`. See [the bundle check](native-mission-check.json).

## Actor files

The corresponding numbered `.DTA` file defines tasks, drones, formations, routes and mission conditions. A task has a side and task type, with `User Task` marking the player group. `Battle Cell` connects opposing formations for the ground battle simulation. The browser shows the original task names, battle-cell numbers, entry times, starting waypoints and objective flags. Each `Drone` begins an actor record. Formation IDs expand that record using the executable's authored offsets and model numbers. The formation names also come from the executable.

Waypoint lines contain nine comma-separated integers, with some files retaining another nine values. The original loader consumes the first nine values; the ninth does not enter the waypoint structure. The extra tail is not part of the loaded route. The first eight describe the waypoint type, position and scheduling/movement fields.

The runtime waypoint is 48 bytes: previous and next pointers, drone pointer, type, X/Y/Z, time, two auxiliary movement fields, speed and a waypoint letter. The loader rearranges some source fields rather than copying the line directly.

Tasks are linked 36-byte records. Full drones occupy 464 bytes and contain a 68-byte model instance at offset 8, a world transform at `0x60`, class and formation information, route pointers, start time, weapon state and other runtime fields. Formation members use a separate linked list. The player drone is rebuilt as the detailed Apache during game initialization, with attached weapon pods from the selected loadout.

## Original-execution checks

All 110 active files have been loaded by the unchanged original parser and actor constructors. The independent extraction agrees on **1,871 tasks, 8,944 authored actor records, 21,989 expanded units and 42,054 waypoints**. `initialise_drones_` supplies the starting transforms used by the browser.

Those transforms precede the player's flight model and carrier-following update. In particular, an aircraft attached to a ship may not yet have its final deck-relative position. The native mission harness continues through that setup and the first simulation steps.

The [actor report](native-actor-check.json) and per-mission files in `native/` retain the comparison results. `tools/native_mission.py` executes the original mission loader, gameplay initialization and full view/instrument drawing for more detailed reference cases.

## Compressed development missions

Eight files use a `TCdf` wrapper: `M1.DTA` to `M4.DTA` and their matching `.TXT` briefings. All eight decode completely, with no trailing bytes, to the lengths stored in their headers. They include **Tank Buster**, **Not So Simple Mission**, **New Mission** and **First Training Mission**. One briefing explicitly describes itself as a test. The training briefing contains `{TRACK}`, `{ROTATE A}`, `{FLY AB}` and `{SYNC ...}` commands.

The header is the four-byte signature followed by a little-endian 32-bit expanded length. Each control byte is XORed with `0x64` and read from its most significant bit downwards. A zero selects one literal byte, XORed with `0x66`. A one selects a little-endian 16-bit match: the high 12 bits are a backward distance and the low four bits give length minus three. Copying can overlap. Decoding ends at the expanded length.

The [decoded files and checksums](legacy/index.json) retain both mission data and briefing text. `tools/tcdf.py` rejects truncated streams, invalid distances, overlong matches and trailing data. These are separate from the 110 active missions. The reference executable contains no `TCdf` signature, and its active mission loader reads ordinary text from the numbered `.DTA` files.

Quick-start and multiplayer definitions are connected to their original menu and session paths in the reconstruction. The [multiplayer notes](../network.md) document their setup, including the incomplete European capture-the-flag mission and the complete US/Japanese version. Older loose numbered missions and editor files remain separate from the active catalogue.

## Objective and battle fields

`Kill Failure`, `Kill Success` and `Kill Outstanding` set actor flags `0x1000`, `0x2000` and `0x4000`. The setters propagate the flag to existing members of a formation. `Laser Designated` sets bit 0 in the same flags word. `Start Waypoint` is stored at actor offset `0xc0`; the start time at `0xcc` uses the 200 Hz game clock. Task offset `0x1c` holds the battle-cell number. These fields are now compared with the original loader for all 110 active missions.

The [AI and battle analysis](../ai/index.html) follows their runtime use.

## C++ loading comparison

`tools/check_cpp_missions.py` compares the reconstructed loader with the original-loader exports for every supplied mission. It checks all four language bundles (411 entries), 89 formations with 803 members, 110 missions, 1,871 tasks, 8,944 actor definitions, 21,989 expanded model IDs, 42,054 waypoints and 156,552 authored setting records. Titles preserve their original whitespace, including trailing spaces in the French bundle. All compared fields match, also under AddressSanitizer and UndefinedBehaviorSanitizer. Reports are in `work/checks/cpp/missions/` and `missions-sanitize/`.

The loader preserves repeated tags in order. Runtime actor initialization, placement and behavior are checked separately from the text parser. Formation definitions come from the original executable at `0x4e017c`, including its empty formation zero.

## Reconstructed actor initialization

`tools/check_cpp_mission_actors.py` compares C++ actor construction with all 110 original snapshots. All 1,315 type records, 58,496 model instances and attachment trees, and 263,868 world-transform fields match. `tools/check_cpp_actor_state.py` executes the original initializer afresh and compares another 483,758 fields across the 21,989 units: flags, angles, velocities, speed, route distance, ammunition, selected weapon, random serial, carrier assignment and current waypoint. Both complete comparisons pass under AddressSanitizer and UndefinedBehaviorSanitizer.

Carrier registration reserves the last free deck slot on the first available ship. A helicopter whose route ends at a carrier can reserve a slot even when it starts airborne; its relative-transform pointer remains set after the initial takeoff operation. Formation members are constructed in source order but linked and initialized in reverse order. That order also determines their random serials. The first member uses a heading-only matrix, while later members use the full transformation routine with zero pitch and roll.

Reports: `work/checks/cpp/mission-actors/`, `actor-state/`, and their `-sanitize` counterparts. These checks end before the player aircraft is rebuilt and its flight model initialized.