Creating and editing REDSHIFT missions

XML-formatted files

Editing XML files

All configuration and mission data in REDSHIFT is stored in XML-formatted ASCII text files with different extensions ("cfg", "lst" and "fop"). If you want to create new or edit existing files, make sure you use a plain-text editor like Windows Notepad.

Checking XML files

REDSHIFT will be unable to use files that do not conform with the XML format definition. If you create or edit REDSHIFT files and you want to check if the modified files are syntactically correct, you can use the program xmllint.exe that comes with the REDSHIFT distribution (it is normally placed in the Orbiter install directory). Since the program is console-based, you have to open a shell:

Change to the Orbiter installtion directory and type the following command (in this example we check the file DG_ISS.fop):

  xmllint --noout FOP\DG_ISS.fop

The application will output error messages with line numbering:

  F:\SPACE\Orbiter>xmllint FOP\DG_ISS.fop
  FOP/DG_ISS.fop:20: error: Opening and ending tag mismatch: Var line 14 and Processor
  FOP/DG_ISS.fop:21: error: Opening and ending tag mismatch: Var line 14 and Step
  FOP/DG_ISS.fop:100: error: Opening and ending tag mismatch: Processor line 11 and Sequence
  FOP/DG_ISS.fop:101: error: Opening and ending tag mismatch: Step line 9 and FOP
  FOP/DG_ISS.fop:102: error: Premature end of data in tag Sequence line 8
  FOP/DG_ISS.fop:102: error: Premature end of data in tag FOP line 6

It's a good idea to check all modifications with xmllint to make sure the data is formatted correctly.

Mission lists

The mission list file (standard Missions.lst) is a tree-like, e.g. hierarchical structure of missions. The root node of a mission file is of type <Flights> that holds a single <List> node.

A <List> node is a container for <Entry> nodes. An <Entry> node has a <Label> node that specifies the name of the branch for list display. The second node for an <Entry> node can be one of four different types:

<List>: a sublist (branch) is defined directly:
<XList>: a sublist (branch) is defined indirectly:
The filename (relative to the Orbiter installation directory) is specified as data. A XList file contains XML data with a <List> root node.
<FOP>: a mission (FOP) is defined directly:
For a description of a <FOP> node see next section "FOP files".
<XFOP>: a mission (FOP) is defined indirectly:
The filename (relative to the Orbiter installation directory) is specified as data. A XFOP file contains XML data with a <FOP> root node.
<Processor>: a processor to be executed.
This node holds a processor definition. The processor will be a stand-alone (unsequenced) processor if its label starts with a '[' character. For a description of the <Processor> node see section "FOP files".

You normally use the Missions.lst file to build the tree-like list of missions (using <List> nodes) and refer to the individual missions (using <XFOP> nodes). If you use the standard missions file as a template for own missions, you are likely to end up the same way...

FOP files

File format

An individual mission is normally stored in a FOP file. The root node of a FOP file is always of type <FOP>. A <FOP> node holds a single <Sequence> node. The <Sequence> node is a container for <Step> nodes. A step is a single procedure defined in the Flight Operations Plan.

A <Step> node holds a <Label> node, that gives that procedure a name for display. The second node in a <Step> node is a <Processor>:

A <Processor> defines a built-in or external processor module that can handle the procedure. The processor instanciation is parametrized by node attributes. The following attributes are available:

type: name of a built-in processor.
module: name of am external processor (DLL module).
mode: Optional string argument.

The type and module attributes are mutually exclusive, so make sure you use one or the other but not both. The mode attribute is processor-specific (see processor descriptions)

A <Processor> is also a container for <Var> nodes. A <Var> node is used to define named variables with value specification. These variables are used by the processor to parametrize itself for the task at hand. Each processor has its own set of mandatory and optional variables, so a description of each built-in processors will include a list of the associated variables.

External processors

It is possible for developers to write their own processors (as DLL modules) that can be intergrated into REDSHIFT (any interested developer can ask me for a pre-release version of the SDK to get an impression of how that will be done).

Currently the SpaceShuttle-specific processors are implemented as external processors.

Built-in processors

The following built-in processors (type names) are available; their variables and customization is described in the tutorial mission:

AlignOrbit: Changes the orbital plane (Inclination, LAN) as well as peri- and apoapsis distance.
Approach: Put the vessel into a defined distance to a reference object nearby (depending on the vessel the initial distance should be between 25 km and 250 km). Kills residual relative velocity at hold position.
Ballistic: Ballistic jumps between surface bases on a planet/moon without atmosphere.
Deorbit: Calculate de-orbit time and perform a de-orbit burn.
Docking: Docks the vessel to a defined port at the target vessel. Supports all docking types (nose, tail, top, ...) for vessels.
Landing: Land the vessel at the specified space port. Currently only hovered landings are supported.
Launch: Launch the vessel into orbit. Plane, Hovercraft and rocket launches are supported.
Profile: Follow an ascent profile into orbit. Currently only height-based profiles are supported.
Reentry: Follow a re-entry trajectory down to a surface base.
SyncOrbit: Synchronizes the orbit to meet a vessel on its orbit.
Transfer: Transfer from planet orbit to a moon.