Mission Editor

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

Groups and Comm Channels are left over from an older design. Both were folded into teams, which the editor does not show: what you enter in those two sections is not saved, so write teams in the mission file instead.

<teams>
  <team name="Homestead" members="homestead" leader="" formation="" channel="Player, homestead" />
</teams>

The editor leaves a mission's <teams> block alone when it saves.

The smallest useful mission

General, a map, one spawn point, and one entry in Players that names it. That will launch and play. Every player vessel must name a spawn point the mission defines; a vessel that names a missing one is skipped and never appears. Objectives are optional: with none, the mission runs until the GM ends it. Everything else is elaboration, and building up from a mission that runs beats building down from one that will not.

Players and restrictions

The Players section holds the player vessels, and three mission‑wide panels that limit what a crew can bring in the lobby:

• Vessel Restrictions — the classes allowed.
• Faction Restrictions — factions, governments or faction tags (allow-faction, allow-government, allow-faction-tag).
• Bot Restrictions — the bots, by id or tag, a GM may seat on a player ship (allow-bot). Bots the mission defines itself are always allowed. See NPC Archetypes.

Each player vessel can narrow these further for its own slot. A vessel's tags are a comma‑separated list. Two switches in General shape the lobby: Restrict Players To Vessel Roles? and Start When All Players Are Ready?.

Options are worth the effort

Options are the settings a GM sees before launching, and they turn one mission into several. They can be text, check boxes, numbers, times, lists or image lists, each with its own description, and they can be marked admin‑only or hidden from players. An option can be bound to a mission property, such as the respawn delay, so the choice takes effect without any event.

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.

A list item can also choose the map the mission runs on, with <item … map="MapId" />. That attribute is written in the file; the editor has no field for it and drops it if you edit and save that option.

Prologue and epilogue

The epilogue's type decides how the mission ends, including when its time limit runs out. Standard shows the epilogue widget and then ends; None ends at once; Pause freezes the session and leaves it to the GM. New missions start as None. A Standard epilogue needs its widget set.

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.
• An event's Frequency decides whether it fires again. A Single event, the default, switches itself off after firing. A Recurring event fires again only after its conditions have stopped matching and then match again. A Manual event fires only when an action or the GM triggers it. An event with no conditions never fires on its own.

A few conditions worth knowing:

• Event: Duration counts seconds from when the event became active: the mission's start, or the moment an Event: Enable switched it on. It always means "more than".
• Contact: Detected and Contact: Lost fire when an observer first sees, or loses, a contact. Leave the observer blank to mean a player ship.
• Object: Destroyed fires once when a vessel dies; the killer and how it died are already recorded when it does.
• Object: Bearing is how far off pointing at a zone, a waypoint or the nearest vessel something is, measured by its heading or its velocity, in 3D or flat.

Message: Send text can use tokens: [Sender.Name], [Sender.Faction] and similar for the sender, [Name] and similar for the recipient, and [Variable.x] for a mission variable.

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, by the GM during play, or by chance when the mission allows random encounters. If something should appear when the crew does a thing, it is an encounter, not an object.

An object's Type is one of seven kinds. Object is a vessel, which appears as a contact; Static is scenery built from a model, which never does. The others are Drone, Billboard, Cluster, Nebula and Spectator. The file keeps the older names, so Object is type="Vessel" and Static is type="Model".

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 should not be trusted for detail. The element names it uses mostly still load: difficulty, players and respawn are current, and spawnpoints and stations are read as old spellings of spawn-points and objects, which is what the editor writes. Author through the editor, or copy the structure of a mission that works.