RTS RULES
=========

RTS Execution Semantics:

   (a) At the start of each level, triggers are spawned on the map
       from their definitions in the script file.  The WHEN_APPEAR and
       WHEN_PLAYER_NUM commands affect which triggers get spawned on
       the map.  When triggers have finished all the commands (and for
       repeatable triggers, all the loops), they are removed from the
       map.  
   
   (b) Triggers on the map can either be enabled or disabled.  Only
       enabled triggers can run or react to players.  Disabled
       triggers do nothing -- they are totally inert, and just wait to
       be enabled from an external source (e.g. another trigger).

   (c) Enabled triggers only run their commands when _all_ of their
       conditions are satisfied.

   (d) The main condition to satisfy is the player touching the
       trigger area on the map.  When a radius of -1 is used, or
       TAGGED_IMMEDIATE, this position check is always satisfied
       no matter where the player is.
       
       When TAGGED_USE is used, in addition to touching the trigger,
       the player must also be pressing the `use' button (usually
       SPACEBAR).
 
   (e) The other conditions to satisfy are given by the ONDEATH,
       ONHEIGHT and ONCONDITION commands.

   (f) When TAGGED_INDEPENDENT is used, once all conditions of the
       trigger have been satisfied, they don't need to remain
       satisfied for the trigger to keep running.
 
       When TAGGED_INDEPENDENT is not used, all conditions need to
       _remain_ satisfied for the trigger to keep running.  The
       conditions are re-checked after each command (or group of
       commands) is executed.
 
   (g) New command "RETRIGGER", only usable in TAGGED_INDEPENDENT
       scripts, which requires all of the conditions to be met again
       before the trigger continues.  This can be useful, since
       TAGGED_INDEPENDENT triggers normally never check the conditions
       again, and non-independent triggers can stop mid-way through a
       group of commands if the conditions change (e.g. player moves
       out of radius).


RTS Multiplayer Semantics:

  (a) The normal mode is to spawn a separate trigger from each script
      for each player in the game.  The command is:

         NET_MODE  SEPARATE  [ ALL ]
  
      There will be one trigger from this script for each player, and
      they all run independently.  Only the corresponding player can
      affect his/her trigger, and only him/her will be affected by
      player-specific commands like TIP and DAMAGEPLAYER.

      The 3rd argument is optional: a colon-separated list of player
      numbers to spawn triggers for.  Example: "1:3:5:7" means that
      only those four players will have this trigger.  The keyword
      "ALL" is also accepted and is the default.

  (b) The other main mode is to spawn only one trigger per script, no
      matter how many players are in the game.  This is good for
      triggers that do map changes, e.g. SPAWNTHING and SECTORV.
      It looks like this:

         NET_MODE  ABSOLUTE  [ 1 ]

      The 3rd argument is optional, it is the number of players that
      have to satisfy the conditions (being inside the radius, etc)
      for the trigger to run.  The keyword "ALL" is also accepted.
      The default is 1, which means any player can trigger it.

      For commands that affect players (TIP, DAMAGEPLAYER, etc), they
      will apply to all players that satisfy the conditions.  For
      TAGGED_INDEPENDENT triggers, the set of players who initially
      triggered it are remembered, and only those players are
      affected.
 
  (c) There are commands (both in RTS and in DDF) for enabling
      triggers, by tag and by name.  The normal rule is: if by tag,
      _all_ existing triggers on the map with that tag are enabled,
      even SEPARATE (one-per-player) ones.  If by name (e.g.
      ENABLE_SCRIPT), then only one script is affected (with the
      matching name), and when it is SEPARATE mode then all the 
      player triggers spawned from that script are enabled.

      (The same applies here to the disable commands).

  (d) It may be desirable to have a mode where only one player's
      trigger is affected when that player uses ENABLE_TAGGED (etc) in
      another script or linedef.  The new "TAGGED_PLAYER_SPECIFIC"
      command achieves this.  It can only be used with SEPARATE
      triggers.  
      
      In the case where there is one distinct player, then only the
      destination trigger corresponding to that player is enabled.
      These cases are: source trigger is SEPARATE.  Source is a
      linedef activated by a player.  Source is a player thing.

      When the source is an ABSOLUTE trigger, then only the players
      that cause it to run (i.e. satisfy the trigger's conditions)
      have their destination triggers enabled.
      
      The remaining cases are: linedef activated by monster.  Thing
      which isn't a player.  Since no players are involved, nothing
      happens in these cases.

  (e) The ACTIVATE_LINETYPE command usually requires knowing who
      activated the line, e.g. teleport lines.  For ABSOLUTE triggers,
      the lines will be activating in an "absolute" player-less way,
      with no activator at all.  For SEPARATE triggers, the activator
      is the player corresponding to that trigger.