[Crossfire-wiki] [Crossfire DokuWiki] page changed: user:cavesomething:guide_to_quest_dialogs

no-reply_wiki at metalforge.org no-reply_wiki at metalforge.org
Fri Apr 30 13:33:08 CDT 2010


A page in your DokuWiki was added or changed. Here are the details:

Date        : 2010/04/30 13:33
User        : cavehippo
Edit Summary: Improve and update description of include blocks

@@ -43,19 +43,35 @@
  </code>
  
  ===== Taking it apart =====
  
- Each potential line of dialog forms a 'rule' these rules are checked in sequence, from the top of the file down.
+ Each potential line of dialog forms a 'rule' these //rules are checked in sequence, from the top of the file down//. Note that because of this, the most restrictive rule (with the most pre conditions) should go first. In the example above, the rules in filewithmoredialog2.msg and filewithmoredialog3.msg can never be matched because there is a rule which matches everything before they are reached. (They are however, included in the list of rules to check)
  
- Some of the 'rules' say "include" followed by one or more files, when these are encountered, these files are read in in the order they appear, and are added to the rest of the rules in the order they appear. This is useful for 'generic' lines of dialog that several npcs may say.
+ Each rule has one of two forms:
  
-   * The first part of each rule is the 'match' - This is what the player has said to the NPC - These ones are all * so will match on anything the player might say.
-   * Next are the 'pre' conditions, in order to match a rule, **all** of the pre-conditions must be true.
-   * After that we have 'post' actions, these are things that happen after
-   * Then we have the 'msg' which is what the NPC will say.
-   * Finally, there is an optional last part, which can have two forms, 'suggests' or 'requires' - these hold responses that the client can give.
+ ==A message rule==
+ These rules contain something that the NPC should say, they contain the following elements:
  
- Because we check from the top down, the most restrictive rule goes first. Note that in the example above, the rules in filewithmoredialog2.msg and filewithmoredialog3.msg can never be matched because there is a rule which matches everything before they are reached.
+ 
+   * 'match' - **Required** - This is what the player has said to the NPC - These ones are all * so will match on anything the player might say.
+   * 'pre'  - **Required** - Conditions which have to be met in order to match a rule, **all** of the pre-conditions must be true.
+   * 'post' - **Required** - Actions which take place after a rule has been matched these are things that happen after
+   * 'msg' - **Required** - This is what the NPC will say.
+   * 'suggests' - **Optional** - These are responses that the client can give which 'make sense'. The client should permit other responses not on this list.
+   * 'requires' - **Optional** - These are a list from the responses that the client must give. The client may choose not to permit other responses that are not on this list.
+ 
+ Any other types of element will be **ignored** this does mean you can put in something like a 'comment': element to explain why some really complex rules are structured the way they are, this is recommended for very complex dialog.
+ 
+ ==An include rule==
+ These rules determine whether to include a file which can contain additional rules.
+ These included files can also include more files, there is no theoretical limit to this, although you probably don't want to go more than 3 or 4 levels down just because it becomes a little impractical then.
+ 
+ The following elements are allowed.
+ 
+   * 'include' - **Required** This is followed by a list of files that should be included
+   * 'pre'     - **Optional** This is the set of conditions under which this file will be included, it is checked in the same way as for a message rule.
+ 
+ Any other types of element will be **ignored** this does mean you can put in something like a 'comment': element to explain why some really complex rules are structured the way they are, this is recommended for very complex dialog.
  
  ==== Rule 1 ====
  
  We'll look at the topmost rule first.
@@ -116,23 +132,45 @@
  
  Tokens are stored in the player file, under the "location" which was specified at the top of the file. Any dialog files which point to the same location have access to the same tokens (and can affect the values they hold). Two tokens with the same name but in different locations are treated separately.
  
  Finally there is the message block where //$me// is replaced by the name of the NPC.
+ 
+ ====Rule 4 ====
+ 
+ <code>
+ {
+ include" : ["filewithmoredialog2.msg", "filewithmoredialog3.msg"]
+ }
+ </code>
+ 
+ This is an include rule. The include section lists the files that should be opened to get more dialog rules, any rules in these files will be added to the list of rules that is actually evaluated.
+ 
+ There are two files listed here, rules from them will be added in order from left to right.
+ 
+ There is no 'pre' block for this rule, so these files will always be added.
  
  ===== Full List of options =====
  
  The options that can be used vary in the different blocks:
  
  ==== The Include Block ====
  
- If a rule has an include block, it should have no other blocks and should list one or more files.
+ If a rule has an include block, then either:
+   * This should be the only block
+   * There should be only the include block and a pre block.
+ 
+ No other types of block will do anything when an include block is present, so they should not be used.
+ 
+ The include block itself should list one or more files.
  
  eg
  <code>
  "include": ["gateguardcommon.msg"]
  </code>
  
  Each of these files should contain additional rules that the npc should follow.
+ 
+ If a pre block is included, then all of the checks in the pre block must pass for the files to be included, otherwise they are ignored.
  
  Included files can include more files, there is no limit to the depth of recursion, but do be careful not to get a situation where file A includes file B and file B includes file A, the python interpreter should stop that running away indefinitely, but your speech will not work correctly.
  
  ==== The Match Block ====
@@ -482,12 +520,8 @@
  The title provides the name that the players will know the quest by - This is optional (but recommended)
  
  ===description===
  'description' appears on a line on its own on a line on its own, everything that follows until a line containing 'end_description' is a summary of the purpose of the quest overall. - This is optional (but recommended for non-hidden quests)
- 
- ===stopstep===
- This is the step after which the quest will be consider 'complete'
- you need to specify a stopstep if you want your quest to be able to end.
  
  ===restart===
  either 0 or 1.
  Whether it is permitted for a player to play through this quest multiple times. 1 indicates a restartable quest, 0 a non-restartable one. If constructing a quest which is restartable, then you should be careful of items like keys, which might be able to be kept between attempts allowing parts of the quest to be bypassed. consider also the use of a marktime/age combination in a conversation to stop the quest restarting immediately.


IP-Address  : 81.141.58.188
Old Revision: http://wiki.metalforge.net/doku.php/user:cavesomething:guide_to_quest_dialogs?rev=1272327231
New Revision: http://wiki.metalforge.net/doku.php/user:cavesomething:guide_to_quest_dialogs

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/




More information about the crossfire-wiki mailing list