In progress
Software
DCS World
Tool
Updated: Oct 2026

JATF Briefing
Builder

A compiler for JATF briefings in DCS World. Create the briefing, load the .miz, and the application fills in what the mission actually contains; correct it, complete it, and out come a single PDF for the package and a PNG kneeboard for every flight. Every field declares where it came from, and whatever the .miz owns gets validated rather than rewritten.

What it is

The Briefing Builder compiles briefings in the JATF format starting from the real mission. The flow is short: create the briefing, load the .miz, let the application fill in what the mission actually contains, correct and complete it by hand, and come out with a single PDF for the package and a PNG kneeboard for every flight.

It is one of the tools of SECTOR, the application that also hosts Mission Tracker, Live View, GCI Scope, ACIS, ATC, JTAC and Comms, and like Live View it sits behind an admin session.

The point: giving back the time spent recopying

A package briefing is largely the same data written three times. A flight’s radio and TACAN exist only once, yet they end up in the COMM-PLAN, in the package task and on the kneeboard, and every copy is a chance to get one wrong. Here there is one source and three renderings, produced by the same function: write it once and the three views follow.

The import is an accelerator, not a premise

The model does not assume a .miz exists. Every field can be filled by hand from the first line to the last, and the file is only a way of getting there faster.

To keep that legible rather than magic, every field carries its origin class:

Class Where it came from
E Extracted from the .miz
A Assigned by the application
M Written by hand

An auto-filled field the author edits becomes M, and from that moment no reimport overwrites it. The lock is per field, and it is not a flourish: regenerating after a small change to the .miz must not reshuffle values that have already been passed to the pilots.

Validate rather than rewrite

On the fields that genuinely live inside the .miz (radio, TACAN, ICLS) the application validates and flags, it does not correct: the correction belongs in the Mission Editor, where that value has its one true version. This removes the worst risk of a generated briefing at the root, namely a kneeboard printing a frequency that does not exist in the cockpit.

Automatic assignment stays where it is useful and harmless, on the fields that do not exist in the .miz at all: laser codes, fuel, the briefing’s common channels.

The loadout takes the shape of the aircraft

How you describe a load depends on what is carrying it: numbered pylons for a fighter, a manifest for a Hercules, cargo and passengers for a transport helicopter. Printing “PYLON 7” on a C-130 kneeboard produces a card nobody can fill in, so the shape changes with the aircraft.

The data comes from the DCS datamine and can be regenerated: 1900 CLSIDs resolved to weapon name and weight, and the pylon count for 144 aircraft. A CLSID that does not resolve stays as it is and gets flagged, never translated by guesswork, because a wrong weapon name sends a pilot off planning around a load they are not carrying.

The outputs

A single PDF with an index and numbering, and a 1536x2048 PNG for every flight. The PDF does not replace the image export: DCS loads kneeboards as graphics files from the Kneeboard folder, so both are needed.

The kneeboard is one per flight, not one per package, because the INTRAFLIGHT differs for every flight. The PNG is produced by going from SVG to a data URI to a canvas, with no external libraries, because the application’s CSP does not allow scripts served from a CDN.

Server passwords never end up in the PDF or on the kneeboards.

Reading files safely

A .miz is a zip arriving from outside, so it gets treated as one. Reading it has a budget (60 MB of archive, 24 MB per member) that stops zip bombs before they become a memory problem, and the Lua is handled by a parser covering only the tabular subset that is needed: a loadstring would be more convenient but would offer no way to impose a ceiling.

Uploaded images follow the same principle: the type is decided from the byte signature rather than the extension, the filename is chosen by the server, and the dimensions are read from the header without pulling in an imaging library.

Distances and bearings

The projection changes by theatre, but distance and bearing do not use it: they are computed in the .miz’s own metric space, where the numbers are already the right ones. That is why they stay exact even where the projection constants are still to be verified.

What is missing, declared

The open points are written inside the interface rather than buried in the code: the JATF grid is only partly filled in (bands and common assignments still to be completed), the channels and projection constants are marked unverified, and the table translating an airfield’s numeric identifier into its name, the one that would prefill departure, arrival and alternate, is missing.