...
This functionality is only available if the schema files md.xsd and common.xsd are in the correct folder. If you are editing the XML in the game folder directly, all is well and the files are loaded from the libraries folder. However, if you are editing in a separate folder, copy those XSD files from the libraries folder directly into the folder where your XML files are located.
| Note |
|---|
Even if your script is free of XSD errors, that does not mean that the script syntax is correct. For example, there are XML elements that require at least one of multiple attributes, but this requirement cannot be reflected in a schema (apart from documentation text). Please notice the XSD documentation of the elements and attributes, e.g. displayed via tooltips in Visual Studio / Visual Web Developer. Please also note additional requirements for MD cue attributes in this guide (see Conditions). To check for errors, please pay attention to in-game error messages that are produced while your script is imported, and run-time errors while the script runs. The XSD files can help you a lot, but you should not rely on the absence of XSD errors. |
MD script structure
In this section we will look at how to start the whole process by creating a new MD mission file and the basic steps in producing mission content with XML code. There will be a description of the key elements of the mission file.
...
<?xml version="1.0" encoding="utf-8"?>
<mdscript name="ScriptName" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="md.xsd">
“ScriptName” is the name used for this script regardless of the file name. It has to start with an upper case letter and must be unique among all MD script names. It also should not contain spaces, so other MD scripts can use it as an identifier to access this script’s contents easily.
...
<?xml version="1.0" encoding="utf-8"?>
<mdscript name="ScriptName" ...>
<cues>
<cue name="RootCue1"> [...]
</cue>
<cue name="RootCue2"> [...]
</cue>
</cues>
</mdscript>
Anchor cues cues
Cues
| cues | |
| cues |
...
The rules for naming cues is the same for MD script names: The name starts with an upper case letter, and has to be unique within this file. So it is actually possible to use the same cue name in different scripts, which is different from the MD in X3.
Anchor conditions conditions
Conditions
| conditions | |
| conditions |
The <conditions> node can contain one or multiple conditions, all of which must be met to activate the cue. If the node is missing, the cue will become active unconditionally. The conditions are checked in sequence, and if a check fails, the following conditions are ignored. There are two types of conditions: Events and non-event conditions.
Non-event conditions are checked in regular intervalseither once or repeatedly in a fixed interval. They may be based on simple values or ranges, such as a particular in-game time having been reached or the player having a certain amount of money. They may also be based on more complex player information, such as what ships they own, whether the player is in a particular area or near a particular object.
Event conditions are triggered when the corresponding event happens, such as the event that a particular object has been targeted, attacked or destroyed. All event nodes have the prefix “event_” so you can easily determine a condition type. NonAfter an event condition you can specify one or more non-event conditions can be used in combination with an event, so they , which will be checked additionally whenever the event happens. If a condition uses an event, it must be in the first sub-node of the <conditions> node. It is even possible to define multiple alternative events that should activate the cue. The first sub-node should be <check_any> in this case, so only one of its sub-conditions has to be met.
...
If a cue has a <conditions> node without any event, it must have one of the attributes onfail or checkinterval. For onfail, you can use the values
- Use onfail if the conditions should be checked only once. The possible attribute values are “cancel”
...
- and “complete”. If the
...
- conditions are met, the cue will activate and perform the cue actions. Otherwise it's a failure and the cue will be cancelled or completed, based on the onfail attribute. Typically onfail="cancel" is used to prevent any further action. onfail="complete" can be used to continue with the sub-cues even in case of failure (but skipping the current cue actions).
- With checkinterval, you can specify a constant time interval between condition checks. The conditions will be checked regularly forever until they are met, unless the cue’s state is changed explicitly by an external event.
Additionally, you can use the attribute checktime to set the time of the first condition check (also possible in combination with onfail). The checktime can be an expression with variables and is evaluated when the cue is enabled (when the condition checks would normally start , i.e. – for root cues that happens at game start for root cues, or otherwise after the parent cue becomes active).
...
<cue name="Foo" checktime="player.age + 3s" onfail="cancel">
<conditions>
[...]
</cue>
The attributes onfail, checkinterval, checktime are not allowed for cues with event conditions.
| Note |
|---|
Reminder: When using an XSD-capable editor, it's a great help, but you cannot rely on it to verify correctness. Please check the documentation look for errors in the game debug output. Concretely, the schema cannot tell whether the above cue attributes are used correctly. |
Actions
The <actions> node contains the actions that are performed one after another, without any delay inbetween. You can enforce a delay after activation of the cue and actual action performance, using a <delay> node right before the <actions>:
...