What does it take to add another airframe? (asked about the UH-72 and the C-130)

A new aircraft is four authoring jobs against interfaces that already exist, in roughly increasing order of effort:

1. A flight spec. An entry in the aircraft registry — mass, inertia, rotor or wing parameters, camera offsets, spawn stance. If the aircraft fits an existing physics family (conventional rotor, tandem rotor, fixed wing) this is a data record. A genuinely new family — a tiltrotor, say — means dynamics work, which is a bigger conversation.

2. A procedural 3D model. All five current airframes are code-built geometry with individually selectable parts; a new one follows the same pattern. This is the largest single line item.

3. A maintenance catalogue. Systems, components, procedures and knowledge checks written to the schema. The five existing catalogues run 25–37 selectable parts each. Content is written to the airframe — the UH-60 set covers elastomeric bearings and the canted tail rotor, the CH-47 set is organised around sync-shaft phasing — because a renamed copy of another aircraft’s content teaches the wrong aircraft.

4. Consequence and exam coverage arrive mostly free. Missions are tagged by physics family, so a new conventional helicopter inherits the rotary syllabus without being listed, and the exam generates from the catalogue you just authored — there is no separate question bank to write.

The build then refuses to ship it until the content validator passes: every part id in the model must resolve to a catalogue record and vice versa. If you have a specific airframe in mind, open a discussion on GitHub or email us — knowing the aircraft lets us give a real estimate.