A mission is one playable scenario: a map, some objects in it, some objectives, and
the events that make things happen. It is the unit a Game Master launches.
The sections
| Group | Section | What it is for |
|---|
| Core | General | Id, name, category, map, mode, description. The minimum. |
| Marquee | How the mission presents itself in the list. |
| Prologue / Epilogue | The briefing before and the wrap‑up after. |
| Options | Settings the GM chooses before launch. |
| Collections | Players | The player vessels and the roles on them. |
| Spawn Points | Where things enter. |
| Objectives | What the crew is trying to do. |
| Objects | Everything placed in the mission. |
| Encounters | Prepared groups the mission can bring in. |
| Events | The logic. Conditions and actions. |
| Variables | Mission state your events read and write. |
| Waypoints | Named places, which is what Flight navigates by. |
| Comm Channels | Who can be talked to. |
| Commodities | Cargo and trade goods in play. |
| Groups | Collections of objects addressed together. |
| Encyclopedia | Reference articles the crew can read in‑game. |
| Collections | Widgets | Extra panels pushed onto consoles for this mission. |
| Advanced | Scripting | Code, for what events cannot express. |
The smallest useful mission
General, one entry in Players, a map, and one objective. That will launch and play.
Everything else is elaboration, and building up from a mission that runs beats
building down from one that will not.
Options are worth the effort
Options are the settings a GM sees before launching, and they turn one mission into
several. They can be lists, numbers or toggles, each with its own description, and
they can be marked admin‑only or hidden.
The base game's training mission is the example to copy: a single option switches
it between five consoles training independently in a loop and five consoles that have
to finish together. Same content, two quite different sessions.
Events are where missions actually live
An event is conditions plus actions. The conditions are checked against the running
game — a property reaching a value, an object destroyed, a shield hit, a variable
changing — and when they match, the actions fire.
Two things follow from that:
- Variables are how events talk to each other. One event sets a
variable, another waits on it. That is how you get sequence out of a system that is
otherwise all reacting at once.
- Conditions are evaluated against live state, so they can fire more than
once unless you gate them. A variable set by the event itself is the usual
gate.
Reach for Scripting only when events genuinely cannot express something. Events
survive the mission being edited by someone else; script tends not to.
Objects and encounters
Objects are placed and present from the start. Encounters are prepared and brought
in later — by an event, or by the GM during play. If something should appear when
the crew does a thing, it is an encounter, not an object.
Testing
Launch it. There is a script test action in the editor for the scripting section,
but for everything else the fast loop is a second browser window on the Game Master
station, launching and ending the mission repeatedly.
Take Flight alongside the GM console for that. Most mission bugs are geometry
— something spawned in the wrong place, a waypoint nobody can reach — and you
see those from the helm immediately.
Compatibility warning
The mission XML element reference in the older entries of this knowledge base
describes a 2016 schema and is wrong. The elements it documents
(difficulty, players, respawn,
spawnpoints, stations) do not match current mission files.
Author through the editor, or copy the structure of a mission that works.
