Changes for page Mission Director Guide
Last modified by Klaus Meyer on 2025/03/31 16:39
From version 31072.1
edited by Daniel Turner
on 2023/04/14 17:05
on 2023/04/14 17:05
Change comment:
There is no comment for this version
To version 31190.1
edited by Daniel Turner
on 2023/04/25 11:20
on 2023/04/25 11:20
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -1,12 +10,3 @@ 1 -{{info body="Please note that this is officially-maintained documentation. 2 - 3 -To ensure that you can rely on the information having been checked by Egosoft, you will not be able to edit this page."/}} 4 - 5 - 6 - 7 -(% style="color: rgb(0,0,0);text-decoration: none;" %) 8 - 9 - 10 10 (% style="color: rgb(0,0,0);text-decoration: none;" %)The Mission Director (MD) is a subsystem of the game and interprets mission scripts, which are written in an XML-based language. The Mission Director in X Rebirth and X4 is based on the MD in X3: Terran Conflict, with some major changes based on feedback from MD users. 11 11 12 12 ... ... @@ -160,15 +160,35 @@ 160 160 161 161 (% style="color: rgb(0,0,0);text-decoration: none;" %)Example for an event condition: 162 162 163 -{{code}}<conditions>  <event_object_destroyed object="$target"/></conditions>{{/code}} 154 +{{code language="xml"}} 155 +<conditions> 156 + <event_object_destroyed object="$target"/> 157 +</conditions> 158 +{{/code}} 164 164 165 165 (% style="color: rgb(0,0,0);text-decoration: none;" %)Example for an event condition with an additional (non-event) check: 166 166 167 -{{code}}<conditions>  <event_player_killed_object/>  <check_value value="event.param.isclass.turret"/></conditions>{{/code}} 162 +{{code language="xml"}} 163 +<conditions> 164 + <event_player_killed_object/> 165 + <check_value value="event.param.isclass.turret"/> 166 +</conditions> 167 +{{/code}} 168 168 169 169 (% style="color: rgb(0,0,0);text-decoration: none;" %)Example for an event condition with two alternative events and a common additional check: 170 170 171 -{{code}}<conditions>  <check_any>    <event_cue_completed cue="Cue1"/>    <check_all>      <event_player_killed_object/>      <check_value value="event.param.isclass.turret"/>    </check_all>  </check_any>  <check_age min="$starttime"/></conditions>{{/code}} 171 +{{code language="xml"}} 172 +<conditions> 173 + <check_any> 174 + <event_cue_completed cue="Cue1"/> 175 + <check_all> 176 + <event_player_killed_object/> 177 + <check_value value="event.param.isclass.turret"/> 178 + </check_all> 179 + </check_any> 180 + <check_age min="$starttime"/> 181 +</conditions> 182 +{{/code}} 172 172 173 173 (% style="color: rgb(0,0,0);text-decoration: none;" %)For more information about expressions and event parameters, see below. 174 174 ... ... @@ -186,11 +186,21 @@ 186 186 187 187 (% style="color: rgb(0,0,0);text-decoration: none;" %)Check conditions every 5 seconds, but start checking only 1 hour after game start. 188 188 189 -{{code}}<cue name="Foo" checktime="1h" checkinterval="5s">  <conditions>  [...]</cue>{{/code}} 200 +{{code language="xml"}} 201 +<cue name="Foo" checktime="1h" checkinterval="5s"> 202 + <conditions> 203 + [...] 204 +</cue> 205 +{{/code}} 190 190 191 191 (% style="color: rgb(0,0,0);text-decoration: none;" %)Check conditions 3 seconds after the cue is enabled, and cancel the cue in case of failure. 192 192 193 -{{code}}<cue name="Foo" checktime="player.age + 3s" onfail="cancel">  <conditions>  [...]</cue>{{/code}} 209 +{{code language="xml"}} 210 +<cue name="Foo" checktime="player.age + 3s" onfail="cancel"> 211 + <conditions> 212 + [...] 213 +</cue> 214 +{{/code}} 194 194 195 195 (% style="color: rgb(0,0,0);text-decoration: none;" %)(% style="color: rgb(0,0,0);text-decoration: none;" %)(% style="color: rgb(0,0,0);text-decoration: none;" %)The attributes //onfail//, //checkinterval//, //checktime// are not allowed for cues with event conditions. 196 196 ... ... @@ -210,11 +210,15 @@ 210 210 211 211 (% style="color: rgb(0,0,0);text-decoration: none;" %)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>: 212 212 213 -{{code}}<delay min="10s" max="30s"/>{{/code}} 234 +{{code language="xml"}} 235 +<delay min="10s" max="30s"/> 236 +{{/code}} 214 214 215 215 (% style="color: rgb(0,0,0);text-decoration: none;" %)Note that during the delay the cue is already in the active state, and the sub-cues have been enabled! If you want to make sure that a sub-cue only becomes active after this cue is complete, there is a useful event condition for that: 216 216 217 -{{code}}<event_cue_completed cue="parent"/>{{/code}} 240 +{{code language="xml"}} 241 +<event_cue_completed cue="parent"/> 242 +{{/code}} 218 218 219 219 (% style="color: rgb(0,0,0);text-decoration: none;" %)<actions> is optional. Leaving it out may be useful if you only want to enable sub-cues after the cue’s condition check. The state transition from active to complete will still take the <delay> node into account. 220 220 ... ... @@ -222,8 +222,18 @@ 222 222 223 223 (% style="color: rgb(0,0,0);text-decoration: none;" %)Example, which selects one of the three texts randomly: 224 224 225 -{{code}}<actions> <do_any>   <debug_text text="'Hello world'"/>   <debug_text text="'Welcome to the MD'"/>   <debug_text text="'And now for something completely different'"/> </do_any><actions>{{/code}} 250 +{{code language="xml"}} 251 +<actions> 252 + <do_any> 253 + <debug_text text="'Hello world'"/> 254 + <debug_text text="'Welcome to the MD'"/> 255 + <debug_text text="'And now for something completely different'"/> 256 + </do_any> 257 +<actions> 258 +{{/code}} 226 226 260 + 261 + 227 227 {{note body="<span style=~"color: rgb(0,0,0);text-decoration: none;~">Messages printed with <debug_text> are usually only visible when the “scripts” debug filter is enabled, see [[NULL|Script debug output]].</span>"/}} 228 228 229 229 ... ... @@ -253,17 +253,26 @@ 253 253 254 254 (% style="color: rgb(0,0,0);text-decoration: none;" %)Library cues are written like normal cues, they are also defined in a <cues> node, just with the difference that the XML tag is called library instead of cue: 255 255 256 -{{code}}<library name="LibFoo" checktime="1h" checkinterval="5s">  <conditions>  [...]</library>{{/code}} 291 +{{code language="xml"}} 292 +<library name="LibFoo" checktime="1h" checkinterval="5s"> 293 + <conditions> 294 + [...] 295 +</library> 296 +{{/code}} 257 257 258 258 (% style="color: rgb(0,0,0);text-decoration: none;" %)Although it is called library, it’s basically just a cue that doesn’t do anything. You can mix cues and libraries as you want, as root cues or sub-cues - the location within the file is unimportant. All that counts is the library name, which has to be unique within the MD script, like all other cue names. 259 259 260 260 (% style="color: rgb(0,0,0);text-decoration: none;" %)To use a library, use the attribute ref: 261 261 262 -{{code}}<cue name="Foo" ref="LibFoo"/>{{/code}} 302 +{{code language="xml"}} 303 +<cue name="Foo" ref="LibFoo"/> 304 +{{/code}} 263 263 264 264 (% style="color: rgb(0,0,0);text-decoration: none;" %)This will create a cue with the name Foo that behaves just like the library cue LibFoo. In this example, LibFoo has to be a library in the same MD script file. To use a library LibFoo from another script, you have to qualify it with the script name, using the (%%)**(% style="color: rgb(0,0,0);text-decoration: none;" %)md(%%)**(% style="color: rgb(0,0,0);text-decoration: none;" %) prefix: 265 265 266 -{{code}}<cue name="Foo" ref="md.ScriptName.LibFoo"/>{{/code}} 308 +{{code language="xml"}} 309 +<cue name="Foo" ref="md.ScriptName.LibFoo"/> 310 +{{/code}} 267 267 268 268 (% style="color: rgb(0,0,0);text-decoration: none;" %)When the ref attribute is provided, all other attributes (except for name) will be ignored and taken from the library cue instead. ((% style="color: rgb(0,0,0);text-decoration: none;" %)By default a library creates its own namespace, as if namespace="static" were specified. See the section about namespaces.(%%)) 269 269 ... ... @@ -271,8 +271,28 @@ 271 271 272 272 (% style="color: rgb(0,0,0);text-decoration: none;" %)In contrast to X3TC, a cue that references a library also has its own name (Foo in the example above), so other cues can access it in expressions by that name. Sub-cues of Foo cannot be accessed by their name though. Within the library itself, expressions can use all names of cues that belong to the library (the <library> and all sub-cues). They will be translated properly when the library is referenced. Examples: 273 273 274 -{{code}}<cue name="Foo" ref="LibFoo"/><cue name="Bar" ref="LibFoo"/><library name="LibFoo">  <actions>    <cancel_cue cue="this"/>             <!-- Cancels the cue referencing LibFoo -->    <cancel_cue cue="LibFoo"/>           <!-- Cancels the cue referencing LibFoo -->    <cancel_cue cue="Foo"/>              <!-- Error, Foo not found in library -->    <cancel_cue cue="Baz"/>              <!-- Cancels Baz in the referencing cue -->    <cancel_cue cue="md.Script.Foo"/>    <!-- Cancels Foo -->    <cancel_cue cue="md.Script.LibFoo"/> <!-- Error, trying to cancel library -->    <cancel_cue cue="md.Script.Baz"/>    <!-- Error, trying to cancel library sub-cue -->  </actions>  <cues>    <cue name="Baz"> [...] <!-- Sub-cue is created in all cues referencing LibFoo -->  </cues></library>{{/code}} 318 +{{code language="xml"}} 319 +<cue name="Foo" ref="LibFoo"/> 320 +<cue name="Bar" ref="LibFoo"/> 275 275 322 +<library name="LibFoo"> 323 + <actions> 324 + <cancel_cue cue="this"/> 325 + <cancel_cue cue="LibFoo"/> 326 + <cancel_cue cue="Foo"/> 327 + <cancel_cue cue="Baz"/> 328 + <cancel_cue cue="md.Script.Foo"/> 329 + <cancel_cue cue="md.Script.LibFoo"/> 330 + <cancel_cue cue="md.Script.Baz"/> 331 + </actions> 332 + <cues> 333 + <cue name="Baz"> [...] 334 + </cues> 335 +</library> 336 +{{/code}} 337 + 338 + 339 + 276 276 {{warning body="These examples are definitely <u>not</u> examples of good scripting style."/}} 277 277 278 278 ... ... @@ -293,15 +293,38 @@ 293 293 294 294 (% style="color: rgb(0,0,0);text-decoration: none;" %)Parameters are defined like this: 295 295 296 -{{code}}<library name="Lib" onfail="cancel">  <params>    <param name="foo"/>    <param name="bar" default="42"/>    <param name="baz" default="player.age"/>  </params>  [...]</library>{{/code}} 360 +{{code language="xml"}} 361 +<library name="Lib" onfail="cancel"> 362 + <params> 363 + <param name="foo"/> 364 + <param name="bar" default="42"/> 365 + <param name="baz" default="player.age"/> 366 + </params> 367 + [...] 368 +</library> 369 +{{/code}} 297 297 298 298 (% style="color: rgb(0,0,0);text-decoration: none;" %)If a default value is supplied, the parameter is regarded as optional, otherwise it’s required. When providing the actual parameters in a referencing cue, note that there is no <params> node: 299 299 300 -{{code}}<cue name="Foo" ref="Lib"> <param name="foo" value="race.argon"/> <param name="bar" value="0"/></cue>{{/code}} 373 +{{code language="xml"}} 374 +<cue name="Foo" ref="Lib"> 375 + <param name="foo" value="race.argon"/> 376 + <param name="bar" value="0"/> 377 +</cue> 378 +{{/code}} 301 301 302 302 (% style="color: rgb(0,0,0);text-decoration: none;" %)The values (including default values) can be variable expressions and will be evaluated when the cue is enabled, i.e. when it starts checking the conditions. They will be available to the cue as variables, using the parameter name with a ‘$’ prefix. In the example above, the variables $foo, $bar, and $baz would be created. 303 303 304 -{{code}}<library name="Lib">  <params>    <param name="foo"/>  </params>  <actions>    <debug_text text="$foo"/>  </actions></library>{{/code}} 382 +{{code language="xml"}} 383 +<library name="Lib"> 384 + <params> 385 + <param name="foo"/> 386 + </params> 387 + <actions> 388 + <debug_text text="$foo"/> 389 + </actions> 390 +</library> 391 +{{/code}} 305 305 306 306 (% style="color: rgb(0,0,0);text-decoration: none;" %)If your library is supposed to provide a result to the library user, it is recommended to store a predefined variable in the library cue with a standardised name, e.g. $result. The user will be able to read it via CueName.$result. This variable does not have to be defined as a parameter but should be documented in the library. 307 307