Start Here

If you flew U.S. Navy Fighters, ATF, or Fighters Anthology in the 90s — and especially if you ever swapped a skin, edited a mission, or poked at the Pro editors — you already understand this game. What you're missing is the layer underneath: where each thing you remember actually lives on disk, what its bytes mean, and which part of the engine brings it to life. That's what this knowledge base documents, and this page is the map.

Everything here was recovered by reverse engineering and is validated by working code: for every format, the fx toolkit can decode and re-encode the real game files byte-identically — a round-trip is the proof that a spec is right, and the status matrix tracks exactly how far that proof extends for every format.

The 30-second map

Almost every file the game owns is packed into a handful of .LIB archives (in the install directory and on the CDs). The engine unpacks entries through its resource manager and hands each format to the subsystem that consumes it. Modding, at its core, has always been: unpack a LIB, change a file, put it back. The LIB spec makes the container itself editable; the rest of the specs make the contents editable.

What you already know, in file terms

In the game	On disk	Start with
An aircraft's 3D model (and its damage states)	.SH shape	SH
Its flight model, thrust, hardpoints	.PT	PT
The reference-section spec sheet	.INF	INF
A mission — placements, waypoints, triggers	.M	M
Briefing and debrief text	.MT	MT
A campaign	.CAM	CAM
A theater — terrain and the planning map	.T2 + .MM	T2, MM
Skins, cockpit art, menu screens	.PIC + .PAL	PIC, PAL
Sound effects	.11K / .8K / .5K	11K
Music	.XMI + .MUS	XMI, MUS
Intro movies and video briefings	.CB8 / .VDO	CB8, VDO
The Pro editors' object definitions	the BRF text DSL family	BRF
Enemy behavior	.AI scripts (+ compiled .BI)	AI, BI

The full catalog — all formats, grouped the same way — is the format reference.

How the game is put together

Three layers, each documented at its own depth:

1. The archives. .LIB containers hold the assets; the architecture page explains the runtime environment, the resource manager, and how the game finds and prefers files (which is why dropping a modified LIB into the install directory works).
2. The executable. The engine is documented as named subsystems — the game loop dispatches objects, physics, the AI interpreter, weapons, the renderer, the HUD, and the rest. Every function and every referenced global in the executable has been named; each subsystem page gives you the recovered symbols, struct layouts, and a flow diagram.
3. The overlay binaries. Audio (WAIL32), the serial/modem comms stack (comms), and the other companion binaries the game ships get the same treatment.

How to read a spec page

Format specs follow one template (spec-authoring.md), so once you can read one, you can read all of them:

• Front matter states the spec's completeness and which codec/tests validate it — claims are checked in CI, so what a page says matches what the tools do.
• Facts carry a confidence vocabulary — confirmed (proven by round-trip or engine disassembly) vs inferred (consistent with observations, not yet proven).
• File Layout is the byte-level truth; Engine Notes connect the format to the subsystem that consumes it; Open Questions are tracked as issues, not left to rot.

Pick your track

The modder. You want to change the game. Read the modding guide first — step-by-step recipes with fx commands. Then go deeper per asset type: LIB → PIC/PAL for art, PT and the BRF family for stats and loadouts, M/MT for missions. The status matrix tells you which formats round-trip cleanly today.

The tool writer. You want to build your own extractor, converter, or editor. Start with LIB (everything else is inside it), then the format specs you care about; the CLI reference and C++ API show how the validation toolkit is put together, and spec-authoring.md defines the vocabulary the specs use. Fixture and fuzzing conventions are in development.md.

The engine archaeologist. You want to know how it works. Architecture → game loop → objects, then follow the subsystem pages wherever curiosity leads. The reconstruction matrix shows the naming/documentation state of every subsystem across all binaries; symbols, globals, and structs are the recovered-fact registries behind them.

Where the ground truth lives

Specs are prose, but the facts underneath are mechanical: recovered names and types live in the symbol database, codecs prove the formats, and CI regenerates and checks the matrices so the docs can't drift from reality. When a page says confirmed, something executable stands behind it.