Changes for page Mission Director Guide

Last modified by Klaus Meyer on 2025/03/31 16:39

From 32972.2 to 32972.1

From version 32984.1

edited by Klaus Meyer
on 2025/03/31 16:39

Change comment: There is no comment for this version

To version 32972.2

edited by Heinrich Unrau
on 2024/10/17 13:10

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

@@ -1,1 +1,1 @@
--xwiki:XWiki.Klaus
++xwiki:XWiki.Heinrich

Content

@@ -220,6 +220,8 @@
  Messages printed with <debug_text> are usually only visible when the "scripts" debug filter is enabled, see [[Script debug output>>doc:||anchor="HScriptdebugoutput"]]
  {{/info}}
++Script debug output
++
  Each child action in a <do_any> node can have a //**weight**// attribute, which can be used to control the random selection of an action node. The default weight of a child node is 1.
  Also available is **<do_if>**, which completes the enclosed action(s) only if one provided value is non-null or matches another. Directly after a <do_if> node, you can add one or more **<do_elseif>** nodes to perform additional checks only in case the previous conditions were not met. The node **<do_else>** can be used directly after a <do_if> or a <do_elseif>. It is executed only if none of the conditions are met.
@@ -226,11 +226,8 @@
  **<do_while>** also exists, but should be used carefully, since it is the only action that could cause an infinite loop, which freezes the game without any chance of recovery.
--Every action can have a //**chance**// attribute, if you only want it to be performed with that chance, given as percentage. Otherwise it will simply be skipped.
++Every action can have a //**chance**// attribute, if you only want it to be performed with that chance, given as percentage. Otherwise it will simply be skipped. If chance is used on a conditional action such as <do_if>, the script will behave as if the condition check failed.
--* If chance is used on a conditional action such as <do_if>, the script will behave as if the condition check failed.
--* If chance is provided on an action within a <do_any>, it will have no effect on the random selection of the action. Only when the action gets selected, the chance will determine whether the action actually gets performed or skipped.
--
  = Libraries =
  Libraries are cues which are not created directly but only serve as templates for other cues. This allows for modularisation, so you can re-use library cues in many different missions.
@@ -570,20 +570,24 @@
  |-|binary|{{code language="xml"}}1 - 1{{/code}}|{{code language="xml"}}0{{/code}}|Subtraction
  |
  lt
--\\&lt; (<)|binary|
--{{code language="xml"}}1 lt 3{{/code}}|{{code language="xml"}}true{{/code}}|Less than
++\\< (<)|binary|
++{{code language="xml"}}1 lt 3{{/code}}
++\\{{code language="xml"}}1 < 3{{/code}}|{{code language="xml"}}true{{/code}}|Less than
  |
  le
--\\&lt;=|binary|
--{{code language="xml"}}1 le 3{{/code}}|{{code language="xml"}}true{{/code}}|Less than or equal to
++\\<=|binary|
++{{code language="xml"}}1 le 3{{/code}}
++\\{{code language="xml"}}1 <= 3{{/code}}|{{code language="xml"}}true{{/code}}|Less than or equal to
  |
  gt
--\\&gt; (>)|binary|
--{{code language="xml"}}1 gt 3{{/code}}|{{code language="xml"}}false{{/code}}|Greater than
++\\> (>)|binary|
++{{code language="xml"}}1 gt 3{{/code}}
++\\{{code language="xml"}}1 > 3{{/code}}|{{code language="xml"}}false{{/code}}|Greater than
  |
  ge
--\\&gt;=|binary|
--{{code language="xml"}}1 ge 3{{/code}}|{{code language="xml"}}false{{/code}}|Greater than or equal to
++\\>=|binary|
++{{code language="xml"}}1 ge 3{{/code}}
++\\{{code language="xml"}}1 >= 3{{/code}}|{{code language="xml"}}false{{/code}}|Greater than or equal to
  |(((
  )))|binary|{{code language="xml"}}1 + 1 == 2.0{{/code}}|{{code language="xml"}}true{{/code}}|Equal to
@@ -712,7 +712,7 @@
  * Strings must start with '$', like variables
  * null cannot be used as table key (but the number 0 is valid)
--* Lists, tables, groups, buildplans, loadouts and constructionsequences cannot be used as table keys
++* Lists, tables, groups and buildplans cannot be used as table keys
  These restrictions only apply to the keys, there are no restrictions for values that you assign to them. For example:
@@ -723,8 +723,6 @@
  * {{code language="xml"}}table[$foo = 'bar']{{/code}}⟹ exactly the same, just a shorter notation for string keys
  * {{code language="xml"}}table[foo = 'bar']{{/code}}⟹ error, 'foo' does not start with a '$'
  * {{code language="xml"}}table[{1} = [], {2} = table[]] {{/code}}⟹ a table that maps 1 to an empty list and 2 to an empty table
--* {{code language="xml"}}table[faction.argon = 'bar']{{/code}}⟹ error, the expression faction.argon will not be resolved into a key value. Requires { } braces.
--* {{code language="xml"}}table[{faction.argon} = 'bar'] {{/code}}⟹ a table that maps the value faction.argon to the string 'bar'
  Just like lists, tables are stored as references, so it's possible that multiple variables reference the same table (see above).
@@ -1006,32 +1006,9 @@
  * MD scripts and cues are identified by their names. So a script can only be refreshed if it has the same script name as before (file name is irrelevant).
  * If there are new script files or new cue nodes (i.e. scripts/cues with new names) they are created and added properly. If you remove script files or cue nodes, the corresponding scripts/cues are removed from the game, including instances.
--** (!) Pitfall: It is recommended that cues are not removed if they were previously released in public builds, to prevent future cues with the same name leading to errors (see example below). Instead they can be emptied and marked as deprecated.
--* As a consequence, you CANNOT rename scripts or cues if you want to refresh them. Doing so would remove the old script or cue and add a new one with the new name.
--* You CANNOT change a <cue> to a <library> or vice versa.
--* You CANNOT add, remove, or change the "ref" attribute of a cue. But it is possible to remove the whole cue. (If all references to a library are removed you can also remove the library itself.)
--* You CANNOT change the cue tree structure, i.e. if you move a cue out of its <cues> node, you also have to change its name (see above). Changing the order of cues within the same <cues> node is possible, however, the order of execution is not reliable anyway.
--* You CAN change a library and change/add/remove its sub-cues. This automatically updates all cues that use the library.
--* You CAN change library parameters (both in libraries and in referencing cues). However, this does not change the variables of a referencing cue if it is already enabled.
--* You CAN change conditions without restrictions. You can even change between event and non-event conditions. If a cue has enabled condition checks, they are aborted and restarted (even if there is no change).
--* Adding root cues enables their condition checks immediately (if the module attribute allows it).
--* Adding sub-cues to active or complete cues enables their condition checks immediately.
--* You CAN change/add/remove <actions>, <force>, <delay>, and all attributes without restrictions, except for the "ref" attribute (see above). You can even change the <delay> while the cue is already active and the timer is running.
--* Changing instantiate="false" to "true" turns the cue into "waiting" state if it was active or complete before.
--* Changing instantiate="true" to "false" removes all instantiated cues and their descendants.
--
--{{warning}}
--Be aware that completed instances can be auto-deleted, and so added sub-cues will not become active in such a case.
--{{/warning}}
--
--{{warning}}
--When adding a variable in a new MD script version and using that variable in multiple places, be aware that the variable doesn't exist yet in older savegames. You may have to check the existence of the variable before accessing it, or add some patch logic that initiailses the variable after loading the savegame, if necessary.
--{{/warning}}
--
--{{warning}}
--(% id="cke_bm_221021S" style="display:none" %) (%%)Cue Removal Pitfall:
++** (!) Pitfall: Cue Removal
  If you remove a cue and then later add another cue with the same name, old save files will not know that the cue has been removed inbetween. In the following example the first cue was created setting $val_1 and the game is saved.
--{{code language="xml"}}<cue name="Deprecated_Test1">
++{{code language="xml"}}<cue name="Deprecated_Test1" namespace="this">
    <actions>
      <set_value name="$val_1" exact="'old value'"/>
      <debug_text text="$val_1"/>
@@ -1038,7 +1038,7 @@
    </actions>
  </cue>{{/code}}
  \\If the Cue is deleted and years later a new cue with the same name appears, the old save will consider the new cue as already completed without executing its actions. The Cue PrintValue will fail to find a variable set up in its parent.
--{{code language="xml"}}<cue name="Deprecated_Test1">
++{{code language="xml"}}<cue name="Deprecated_Test1" namespace="this">
    <actions>
      <set_value name="$val_2" exact="'new value'"/>
      <debug_text text="$val_2"/>
@@ -1046,7 +1046,7 @@
    <cues>
      <cue name="PrintValue">
        <actions>
--        <debug_text text="$val_2"/>
++        <debug_text text="parent.$val_2"/>
        </actions>
      </cue>
    </cues>
@@ -1054,8 +1054,27 @@
  \\To avoid this, do not delete any cues (once they are public for save game compatibility), but empty them out and mark them as deprecated. This will prevent new cues with the same name in the script.
  {{code language="xml"}}<!-- Deprecated Cues, kept to not duplicate names in future cues -->
  <cue name="Deprecated_Test1" comment="deprecated"></cue>{{/code}}
++* As a consequence, you CANNOT rename scripts or cues if you want to refresh them. Doing so would remove the old script or cue and add a new one with the new name.
++* You CANNOT change a <cue> to a <library> or vice versa.
++* You CANNOT add, remove, or change the "ref" attribute of a cue. But it is possible to remove the whole cue. (If all references to a library are removed you can also remove the library itself.)
++* You CANNOT change the cue tree structure, i.e. if you move a cue out of its <cues> node, you also have to change its name (see above). Changing the order of cues within the same <cues> node is possible, however, the order of execution is not reliable anyway.
++* You CAN change a library and change/add/remove its sub-cues. This automatically updates all cues that use the library.
++* You CAN change library parameters (both in libraries and in referencing cues). However, this does not change the variables of a referencing cue if it is already enabled.
++* You CAN change conditions without restrictions. You can even change between event and non-event conditions. If a cue has enabled condition checks, they are aborted and restarted (even if there is no change).
++* Adding root cues enables their condition checks immediately (if the module attribute allows it).
++* Adding sub-cues to active or complete cues enables their condition checks immediately.
++* You CAN change/add/remove <actions>, <force>, <delay>, and all attributes without restrictions, except for the "ref" attribute (see above). You can even change the <delay> while the cue is already active and the timer is running.
++* Changing instantiate="false" to "true" turns the cue into "waiting" state if it was active or complete before.
++* Changing instantiate="true" to "false" removes all instantiated cues and their descendants.
++
++{{warning}}
++Be aware that completed instances can be auto-deleted, and so added sub-cues will not become active in such a case.
  {{/warning}}
++{{warning}}
++When adding a variable in a new MD script version and using that variable in multiple places, be aware that the variable doesn't exist yet in older savegames. You may have to check the existence of the variable before accessing it, or add some patch logic that initiailses the variable after loading the savegame, if necessary.
++{{/warning}}
++
  == Patching ==
  Cues can have **<patch>** elements with actions that will be performed when an old savegame is loaded. To control which savegames should be affected, you can add a //**version **//attribute to the <cue> node and a //**sinceversion**// attribute in the patch. When a cue is loaded from a savegame that has an older version than //sinceversion//, the <patch> actions will be performed immediately after loading.

Changes for page Mission Director Guide

Summary

Details

Navigation

Applications