Skip to Content

Changes for page Mission Director Guide

Last modified by Klaus Meyer on 2025/03/31 16:39
From version 32947.1
edited by Daniel Turner
on 2023/08/22 18:52
Change comment: There is no comment for this version
To version 32949.1
edited by Daniel Turner
on 2023/08/22 18:54
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -14,7 +14,7 @@
14 14  
15 15  MD scripts are not necessarily missions. An MD file can contain a part of a mission, multiple missions, or no mission at all, as the MD is used for more than just missions.
16 16  
17 -MD files are XML files located in the game folder {{code}}md{{/code}}. All XML files in that folder are loaded at game start. The file names are irrelevant, since the internally used script names are read from the XML root nodes. However, it's recommended to keep file name and internal script name identical to avoid having to look up the names.
17 +MD files are XML files located in the game folder **md**. All XML files in that folder are loaded at game start. The file names are irrelevant, since the internally used script names are read from the XML root nodes. However, it's recommended to keep file name and internal script name identical to avoid having to look up the names.
18 18  
19 19  To edit MD scripts, an XML editing tool is needed. Microsoft Visual Studio (if available) or [[Microsoft Visual Web Developer>>url:http://www.microsoft.com/express/vwd/]](%%) (for free) are highly recommended because they have pretty good support for XML schemas (XSD). The provided Mission Director schema files help you create the XML file by displaying all available tags and attributes as you edit the XML.
20 20  
... ... @@ -182,7 +182,9 @@
182 182  
183 183  
184 184  
185 -{{info}}Reminder: When using an XSD-capable editor, it's a great help, but you cannot rely on that alone to verify correctness. Please also check the documentation and look for errors in the game debug output. Concretely, the schema cannot tell whether the above cue attributes are used correctly.{{/info}}
185 +{{info}}
186 +**Reminder**
187 +When using an XSD-capable editor, it's a great help, but you cannot rely on that alone to verify correctness. Please also check the documentation and look for errors in the game debug output. Concretely, the schema cannot tell whether the above cue attributes are used correctly.{{/info}}
186 186  
187 187  == Actions ==
188 188  
... ... @@ -349,7 +349,7 @@
349 349  
350 350  Cancelling a cue with **<cancel_cue>** also cancels all its sub-cues, and cancelling a static cue stops it from instantiating more cues - but it does not cancel its instances. Resetting a cue with **<reset_cue>** resets both sub-cues and instantiated cues, but has the (desired) side effect that condition checks will start again if the parent cue's state allows it. Even a sub-instance that has been reset can return to the //waiting// state. Resetting an instantiated cue will stop it forever, because it is not supposed to be in the //waiting// state (only its static cue is). Resetting will also induce the clean-up reliably, but keep in mind that this is not the case for instance sub-cues.
351 351  
352 -{{info body="<cancel_cue> and <reset_cue> only take effect after all remaining actions of the current cue are performed. So you can even safely cancel the cue that you are currently in (keyword "'''this'''") or any ancestor cue, and still perform more actions afterwards."/}}
354 +{{info}}<cancel_cue> and <reset_cue> only take effect after all remaining actions of the current cue are performed. So you can even safely cancel the cue that you are currently in (keyword "'''this'''") or any ancestor cue, and still perform more actions afterwards.{{/info}}
353 353  
354 354  == Access to instances ==
355 355