<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE book SYSTEM "docbookosm.dtd" [
<!ENTITY scr-legacy SYSTEM "PublicScripts-legacy.xml">
<!ENTITY scr-common SYSTEM "PublicScripts-common.xml">
<!ENTITY scr-t1 SYSTEM "PublicScripts-t1.xml">
<!ENTITY scr-t2 SYSTEM "PublicScripts-t2.xml">
<!ENTITY scr-ss2 SYSTEM "PublicScripts-ss2.xml">
<!ENTITY scr-dev SYSTEM "PublicScripts-dev.xml">
]>
<book>

<bookinfo>

<revhistory>
 <revision>
  <revnumber>1</revnumber>
  <date>2006-02-22</date>
  <authorinitials><ulink url="mailto:telliamed@whoopdedo.org">tnh</ulink></authorinitials>
  <revremark>
    Begin tracking changes.
    TrigOBBCreature also responds to PhysExit.
    TrapRequirement has become a mix-in class.
    Add Transmogrify, TrapFader, TrapRequireOne, TrapRequireOneOnly.
    Document clr parameter to IntrinsicPlaque.
  </revremark>
 </revision>
 <revision>
  <revnumber>2</revnumber>
  <date>2006-04-10</date>
  <authorinitials><ulink url="mailto:the_pix@hotmail.com">pixie</ulink></authorinitials>
  <revremark>
    Describe non-functional AnimLight modes in SS2.
    Clarify use of a locked TraitMachineReusable.
    TurnOn/TurnOff for TrapNanites was reversed.
    Mention the need to set a radius for TrapTexture.
  </revremark>
 </revision>
 <revision>
  <revnumber>3</revnumber>
  <date>2006-04-12</date>
  <authorinitials><ulink url="mailto:telliamed@whoopdedo.org">tnh</ulink></authorinitials>
  <revremark>
    Add anchor point for “scripttiming”.
    Describe TurnOff behavior for TrapHP.
    Remove reference to “smoothly dim/brighten” in AnimLight for SS2.
    Remove non-functional TrigWorldFocus from SS2.
  </revremark>
 </revision>
 <revision>
  <revnumber>4</revnumber>
  <date>2006-08-12</date>
  <authorinitials><ulink url="mailto:telliamed@whoopdedo.org">tnh</ulink></authorinitials>
  <revremark>
    Convert quotes/apostrophes to fancy curly-style. Be sure you’re using a UTF-8 capable editor. (But don’t use a byte-order mark.)
    Descriptions for the factory scripts and HotPlateController.
    Begin work on the develop section.
  </revremark>
 </revision>
 <revision>
  <revnumber>5</revnumber>
  <date>2006-12-30</date>
  <authorinitials><ulink url="mailto:telliamed@whoopdedo.org">tnh</ulink></authorinitials>
  <revremark>
    Drop FrobSounds, StopHere, and TrigBraindead from T1. (Already exist in TG.)
    Add IntrinsicText and adjust IntrinsicCover,IntrinsicPlaque accordingly.
  </revremark>
 </revision>
</revhistory>

 <title>Public Scripts 2.0</title>
 <author>
 <firstname>Tom</firstname> <othername>N</othername> <surname>Harris</surname>
 <address>http://www.thiefmissions.com/telliamed/</address>
 <email>telliamed@whoopdedo.org</email>
 </author>
</bookinfo>

<toc></toc>

<preface id="intro">
<title>Introduction</title>

<para>The <application>Public Scripts</application> package is a collection of scripts modules for <productname>Dark Engine</productname> based games. These modules collect a number of well-known scripts into a single place. So fan-mission designers have greater freedom to create novel and entertaining experiences.</para>
<para>This manual is divided into three parts.
 <variablelist>
  <varlistentry><term><link linkend="install">Installation</link></term>
   <listitem><simpara>If you just need <application>Public Scripts</application> in order to play a fan-mission, this is the only section you need to read.</simpara></listitem>
  </varlistentry>
  <varlistentry><term><link linkend="editref">DromEd Reference</link></term>
   <listitem><simpara>Designers will find descriptions of the scripts here; and instructions on how to use them.</simpara></listitem>
  </varlistentry>
  <varlistentry><term><link linkend="devref">Programmer’s Reference</link></term>
   <listitem><simpara>This section describes the source code to <application>Public Scripts</application> for anyone who wants to make their own custom scripts.</simpara></listitem>
  </varlistentry>
 </variablelist>
</para>
</preface>

<preface id="copying">
<title>License Agreement</title>
 <indexterm>
  <primary>License</primary>
 </indexterm>
 <indexterm>
  <primary>Copyright</primary>
 </indexterm>

<para><application>Public Scripts</application> are copyright &copy; 2005-2007 Tom N Harris.</para>

<para>This software is released under the terms of the GNU General Public License.</para>

<para>Unmodified copies of the compiled binary files may be distributed along with fan-missions and expansion packs intended for use with <productname>Dark Engine</productname> based games without the creator being required to provide the source code for this software. The fan-mission or expansion pack must completely comply with the terms of the Dromed License issued by Eidos Interactive, and the fan-mission or expansion pack must include the following copyright information:
<blockquote>This fan-mission uses Public Scripts. Copyright &copy; 2007 Tom N Harris
This software is licensed under terms of the GNU General Public License.
Please see http://www.thiefmissions.com/telliamed/#PublicScripts for more information,
or write to [insert your email address here].</blockquote>
You must then be prepared to answer any queries regarding the scripts, which may include offering copies of the original software package in case the official website is inaccessible.</para>

<para>Third-party distributors must include the complete <application>Public Scripts</application> package in their archive if they distribute any fan-missions or expansion packs that use this software.</para>
</preface>

<chapter id="install">
<title>Installation</title>

<section id="inst-scripts">
<title>Installing <application>Public Scripts</application></title>
 <indexterm>
  <primary>Installation</primary>
 </indexterm>
 <indexterm>
  <primary>Setup</primary>
 </indexterm>

<para>The first step to using a custom script module is to copy the appropriate files to a place where the game can find them. The <application>Public Scripts</application> package uses three files: <filename>script.osm</filename>, <filename>version.osm</filename>, and <filename>dh2.osl</filename>. But the first file, <filename>script.osm</filename> must match the game it is being installed for. A script module from <application>Thief Gold</application> can’t be used in <application>System Shock 2</application>. (Although there are exceptions, like <filename>version.osm</filename>.)</para>

<para>The simplest way to copy the right files is to run the included <filename>Setup.exe</filename> program. This is an automated installer that will copy the right files to the right places. If you already have a copy of <application>Public Scripts</application> installed, the older files will be backed-up to a zip-format archive with a name like <filename>_Restore-20060201.zip</filename>, although the numbers will be different. If there is a problem, you can restore the old files from the backup archive.</para>
</section>

<section id="inst-legacy">
<title>“Gaylesaver” Scripts</title>
 <indexterm>
  <primary>Gaylesaver</primary>
 </indexterm>
 <indexterm>
  <primary>Darkhooks.dlx</primary>
 </indexterm>

<para>The main <application>Public Scripts</application> script module is named <osm>script.osm</osm>. This is the same name as an older script module distributed as “Gaylesaver’s Custom Scripts”. The reason the names are the same is because <application>Public Scripts</application> includes scripts that do the same thing as the “Gaylesaver” scripts. These are not merely copies, but completely new scripts made to be compatible, but with less problems than the originals. The “Gaylesaver” scripts are no longer being updated, so I am providing <application>Public Scripts</application> as an improved alternative.</para>

<para>You cannot have both <application>Public Scripts</application> and the “Gaylesaver” scripts installed at the same time. When you install <application>Public Scripts</application>, the old <osm>script.osm</osm> will be overwritten. The old file <osm>darkhooks.dlx</osm> is not removed, however. This is harmless, but if you have no intention of ever using the “Gaylesaver” scripts again, then you probably want to delete it.</para>

</section>

</chapter>


<part id="editref">
<title>DromEd Reference</title>

<partintro>
 <para>This section is for fan-mission authors.</para>
</partintro>

<toc></toc>

<chapter id="version">
<title>VersionCheck</title>
 <indexterm>
  <primary>VersionCheck</primary>
 </indexterm>
 <indexterm>
  <primary>Version.osm</primary>
 </indexterm>

<para>You are free to include copies of <osm>script.osm</osm> and <osm>dh2.osl</osm> with your fan-mission, provided that you follow all the <link linkend="copying">rules</link>. But do you really want to? Scripts are computer code, and some people may rightfully be concerned about letting any random computer program they download be run on their computer. There is also the possibility that there may be a bug in this particular version of <application>Public Scripts</application>. (And a very good possibility at that, it annoys me to say.) So do you really want to have to release a new copy of your FM every time I discover some new problem with the scripts; or worse, leave an old buggy copy floating around?</para>

<para>The more reasonable solution is to ask the end-users to download the scripts themselves. They can be more confident that the scripts are safe, and upgrade whenever the need arises. To make this practical, though, you need a way to notify the user when the scripts have <emphasis>not</emphasis> been installed. The script <script>VersionCheck</script> is what makes this possible. This script is placed into a separate module named <osm>version.osm</osm>, and it is this file that you include with your FM. The same file can be used in <application>Thief 1</application>, <application>Thief 2</application>, and <application>System Shock 2</application>.</para>

<para>The <script>VersionCheck</script> script is intended to be used as a trigger. If the required scripts are found, it will send a <message>TurnOn</message>, or it will send <message>TurnOff</message> otherwise. Specify the script modules to look for in the <property>Editor\Design Note</property> or, in <application>System Shock 2</application>, <property>Script\Objlist</property>. The property is a list of file names separated with semi-colons (<literal>;</literal>). If a file doesn’t have an extension, then <filename>.osm</filename> will be added. The script will fail if any of the files can’t be found in the game directory. The version of a file can be checked by typing a ‘<literal>=</literal>’ followed by the minimum version number. The script will fail if the version of the file is lower than specified. The following example tests if <osm>script.osm</osm> is present, and if <osm>tnhscript.osm</osm> is at least version 1.5.
 <informalexample>
  <simpara><literal>script.osm;tnhscript=1.5</literal></simpara>
 </informalexample>
</para>

<para><script>VersionCheck</script> can also display a message if the scripts aren’t found. In <application>Thief</application>, it uses the <property>Book\Text</property> and <property>Book\Art</property> properties. It’s just like any other book. In <application>System Shock 2</application>, the property <property>Script\Use Message</property> is used. The property value is the name of a string that will be read from the file <filename>strings\error.str</filename>.</para>

</chapter>

<chapter id="darkhook2">
<title>Dark Hook 2</title>
 <indexterm>
  <primary>Dark Hook 2</primary>
 </indexterm>
 <indexterm>
  <primary>DH2.osl</primary>
 </indexterm>

<para>Some of the scripts need an external library called <application>Dark Hook 2</application>. This is provided by the file <filename>dh2.osl</filename>. If the file isn’t found then the script won’t operate. However, other scripts that don’t require <application>Dark Hook 2</application> will still work.</para>

</chapter>

<chapter id="overview">
<title>Overview</title>

 <section id="usage">
 <title>Using the Scripts</title>
 <indexterm>
  <primary>Loading Scripts</primary>
 </indexterm>
 
 <para>Before using any scripts, you must load the appropriate modules into each mission. You’re probably already familiar with doing this for <osm>gen.osm</osm>, <osm>convict.osm</osm>, or <osm>allobjs.osm</osm>. A custom script is just one more module that needs to be loaded. DromEd lets you load as many script modules as you want.</para>
 
 <para>Type the DromEd command: <command>script_load</command> and the name of a script module to load it. The <filename>.osm</filename> extension isn’t necessary. When DromEd needs a script, it will search each loaded module beginning with the most recently loaded. You can print the list of loaded modules to the monolog with the command <command>script_dump_files</command>.</para>

 <indexterm>
  <primary>Inheritance</primary>
 </indexterm>

 <para>Scripts are attached to an object with the <property>Scripts</property> property. You can put the names of four scripts in each property, but DromEd will combine all the <property>Scripts</property> properties from all of the ancestors of an object. This is different than other properties where each object will override the properties that come before it. When you need to override an inherited script property, you set the <symbol>Don’t Inherit</symbol> flag on the <property>Scripts</property> property.</para>

 <para>Scripts also inherit features of base scripts, so many scripts can have similar behaviors. This inheritance is built-in to the scripts and doesn’t require you to do anything in DromEd. The inheritance described in this manual refers to this, not the object hierarchy. Some of the base scripts are also described separately, to make the manual easier to read.</para>

 </section>

 <section id="debug">
 <title>Debugging Scripts</title>
 <indexterm>
  <primary>Debugging Scripts</primary>
 </indexterm>
 <indexterm>
  <primary>Monolog</primary>
 </indexterm>
 
 <anchor id="monolog" />
 <para>The more you use scripts, the more you need to know about what is going on behind the scenes. This becomes most obvious when the game isn’t working as you expected it to. DromEd provides some commands to aid in the debugging of scripts. To view the debug information, you need to have a monolog enabled. The monolog is a text file that records messages from the DromEd, the game, and some scripts.</para>

 <para>There are two ways to enable a monolog. You could tell DromEd to automatically open it at startup. Edit your <filename>dromed.cfg</filename> or <filename>user.cfg</filename> configuration file. (I prefer to use <filename>dromed.cfg</filename> for editor-only options.) Add on a new line the option <command>monolog</command> and the name of the file you want to create. The disadvantage with automatically opening the monolog is that the previous contents of the file will be erased each time you start DromEd. Instead, you can manually open the monolog every time you need it. After starting DromEd, type the command <command>mlog</command> and the name of the file. If you type <command>mlog close</command>, then the monolog is closed. Opening a monolog with a different name will close the previous file.</para>

 <anchor id="traceline" />
 <indexterm>
  <primary>Trace Lines</primary>
 </indexterm>
 <indexterm>
  <primary>Tracing</primary>
  <secondary>Trace Lines</secondary>
 </indexterm>
 <para>With the monolog open, you can use DromEd’s built-in script debugging commands. These are called trace lines. A trace monitors the messages sent to a particular object. You create a trace with the <command>trace_add</command> command. The command takes four arguments, the object to monitor, the message to trace, the word “<literal>spew</literal>”, then a trace line number. A trace line is a group of traces so you can toggle many traces on and off together. There are 32 trace lines. A line is toggled with the <command>trace_line</command> command. The “<literal>spew</literal>” argument tells DromEd to write the message to the monolog. The word “<literal>break</literal>” could also be used, but this is only useful for script programmers with a symbolic debugger installed.</para>

 <para>Trace lines just tell you when an object receives a certain message. Many messages contain extra information that you may want to know about. <application>Public Scripts</application> includes a script for this purpose. Add the script <script moreinfo="refentry">Spy</script> to any object and it’ll record every message that the object receives in the monolog, along with the extra information from the message.</para>

 </section>

 <section id="designnote">
 <title>Design Note Parameters</title>
 <indexterm>
  <primary>Design Note</primary>
 </indexterm>
 <indexterm>
  <primary>Parameters</primary>
 </indexterm>
 
 <para>Many custom scripts need extra information to function. They may use an already existing property, but most often there isn’t anything suitable. So a special string property is used to give options to the scripts. In <application>Thief</application> this is the <property>Editor\Design Note</property>, and in <application>System Shock 2</application> it is the <property>Script\Objlist</property>. This will be referred to as the “design note” from now on.</para>

 <para>The design note consists of a list of parameter names and values separated with semi-colons (‘<literal>;</literal>’). Parameter names do not contain spaces and are not case-sensitive. The parameter name is followed by ‘<literal>=</literal>’ then the value. Any space before or after the value will be ignored. The value can be enclosed in single or double-quote marks, which must be done if you need to use a quote mark or semi-colon in the value. The value may be interpreted as an integer, floating-point number, string, boolean, time, or object.
  <variablelist>
   <varlistentry><term>Integer</term>
    <listitem><simpara>A whole number, positive or negative.</simpara></listitem>
   </varlistentry>
   <varlistentry><term>Floating-Point</term>
    <listitem><simpara>A positive or negative number with optional fractional part. Use a period (‘<literal>.</literal>’) to separate the whole and fractional parts.</simpara></listitem>
   </varlistentry>
   <varlistentry><term>String</term>
    <listitem><simpara>Any kind of text.</simpara></listitem>
   </varlistentry>
   <varlistentry><term>Boolean</term>
    <listitem><simpara>A true or false value. The words ‘<literal>true</literal>’ or ‘<literal>yes</literal>’, or a non-zero number will be considered true. You can also shorten the word to a single letter, i.e. ‘<literal>T</literal>’ for true and ‘<literal>F</literal>’ for false.</simpara></listitem>
   </varlistentry>
   <varlistentry><term>Time</term>
    <listitem><simpara>As a number by itself, it’s milliseconds. Put the letter ‘<literal>s</literal>’ after the number for seconds, and ‘<literal>m</literal>’ for minutes.</simpara></listitem>
   </varlistentry>
   <varlistentry><term>Object</term>
    <listitem><simpara>A DromEd object. Can be the numeric ID, or the name of the object.</simpara></listitem>
  </varlistentry>
   <varlistentry><term>Color</term>
    <listitem><simpara>Color values can be written in HTML format, which is a hash mark (‘<literal>#</literal>’) followed by six hexadecimal numbers. The English color names described in HTML 4 are also recognized. Another way to specify a color is the red, blue, and green components (in that order) separated with commas.</simpara></listitem>
  </varlistentry>
  </variablelist>
 </para>

 <para>Where an integer, boolean, or time is requested, you can substitute the name of a quest variable for the value. Type a dollar sign (‘<literal>$</literal>’) followed by the name of the qvar.</para>

 </section>

 <section id="scr-traps">
 <title>Common Trap Features</title>
 <indexterm>
  <primary>Traps</primary>
 </indexterm>
 <indexterm>
  <primary>Triggers</primary>
 </indexterm>

 <para>Many of the scripts are types of “traps”. (The terms “relay”, “router”, “filter”, and “trigger” are also sometimes used, but they all amount to the same thing.) The purpose of a trap is to respond to, or generate, <message>TurnOn</message> and <message>TurnOff</message> messages. Some traps both respond to and generate messages. And sometimes one or the other message will be ignored.</para>

 <anchor id="triggerlink" />
 <indexterm>
  <primary>ControlDevice</primary>
 </indexterm>
 <indexterm>
  <primary>SwitchLink</primary>
 </indexterm>
 <para>Traps are usually linked together using <flavor>ControlDevice</flavor> links. <application>System Shock 2</application> uses <flavor>SwitchLink</flavor> links instead, but this manual will only refer to <flavor>ControlDevice</flavor>; you’ll just have to mentally translate for SS2.</para>

 <anchor id="trapflags" />
 <indexterm>
  <primary>Trap Control Flags</primary>
 </indexterm>
 <para>The behavior of a trap can be altered with the <property>Script\Trap Control Flags</property> property. The <constant>Invert</constant> flag will reverse the normal meanings of <message>TurnOn</message> and <message>TurnOff</message>. <constant>Once</constant> causes the trap to be locked after it has been activated. The <constant>NoOn</constant> and <constant>NoOff</constant> flags make the trap ignore the respective messages. (Prior to reversing by <constant>Invert</constant>.) In <application>System Shock 2</application>, <constant>Enter</constant> means <constant>NoOff</constant> and <constant>Exit</constant> means <constant>NoOn</constant>.</para>

 <para><application>Thief 1</application> doesn’t have the <property>Script\Trap Control Flags</property>, so a design note parameter is used instead. The parameter name is <parameter>tcf</parameter> and it is specified as a string of two-character symbols. The flags are:
  <variablelist>
   <varlistentry>
    <term><literal>!+</literal></term>
    <listitem><literal>NoOn</literal></listitem>
   </varlistentry>
   <varlistentry>
    <term><literal>!-</literal></term>
    <listitem><literal>NoOff</literal></listitem>
   </varlistentry>
   <varlistentry>
    <term><literal>&lt;&gt;</literal></term>
    <listitem><literal>Invert</literal></listitem>
   </varlistentry>
   <varlistentry>
    <term><literal>01</literal></term>
    <listitem><literal>Once</literal></listitem>
   </varlistentry>
  </variablelist>
 </para>

 <anchor id="scripttiming" />
 <indexterm>
  <primary>Timing</primary>
 </indexterm>
 <indexterm>
  <primary>Delay Time</primary>
 </indexterm>
 <para>When a trap is locked, it will ignore all messages. A trap that has been turned on will automatically turn off if the <property>Script\Timing</property> (Thief) or <property>Script\Delay Time</property> (SS2) is set. The time is in milliseconds for Thief and seconds (with fractional part) for SS2. The timer is not used when a trap is turned off.</para>

 <para>In the <application>Thief</application> games, it is possible to link to the <object>Player</object> object. Create the link to the starting-point marker and when the game starts, those links will be moved to the <object>Player</object> marker. This even applies to some non-trap scripts.</para>

 </section>

</chapter>

<chapter id="scripts"><title>The Scripts</title>

 <section id="scr-descs"><title>Script Summary</title>
  <variablelist>
  <varlistentry>
   <term><link linkend="scr-legacy">Compatible Scripts</link></term>
   <listitem><simpara>These are scripts that appeared in an older custom script module.</simpara></listitem>
  </varlistentry>
  <varlistentry>
   <term><link linkend="scr-common">Common Scripts</link></term>
   <listitem><simpara>These scripts are useful in all games.</simpara></listitem>
  </varlistentry>
  <varlistentry>
   <term><link linkend="scr-t1">Thief 1 Scripts</link></term>
   <listitem><simpara>Scripts for <application>Thief: The Dark Project</application> and <application>Thief Gold</application>.</simpara></listitem>
  </varlistentry>
  <varlistentry>
   <term><link linkend="scr-t2">Thief 2 Scripts</link></term>
   <listitem><simpara>Scripts for <application>Thief 2: The Metal Age</application>.</simpara></listitem>
  </varlistentry>
  <varlistentry>
   <term><link linkend="scr-ss2">SS2 Scripts</link></term>
   <listitem><simpara>Scripts for <application>System Shock 2</application>.</simpara></listitem>
  </varlistentry>
  </variablelist>
 </section>

 <section id="scr-legacy"><title>Compatible Scripts</title>
 <simpara>These are scripts that appeared in an older custom script module. Missions that already use the older version should be able to upgrade simply by changing the OSM file.</simpara>

&scr-legacy;

 </section>

 <section id="scr-common"><title>Common Scripts</title>
 <simpara>These scripts are useful in all games. </simpara>

&scr-common;

 </section>

 <section id="scr-t1"><title>Thief 1 Scripts</title>
 <simpara>Scripts for <application>Thief: The Dark Project</application> and <application>Thief Gold</application>. These are mostly ports of scripts from <application>Thief 2</application>.</simpara>

&scr-t1;

 </section>

 <section id="scr-t2"><title>Thief 2 Scripts</title>
 <simpara>Scripts for <application>Thief 2: The Metal Age</application>. Many of these scripts originally appeared in <application>Thief 1</application>.</simpara>

&scr-t2;

 </section>

 <section id="scr-ss2"><title>SS2 Scripts</title>
 <simpara>Scripts for <application>System Shock 2</application>. Many of these scripts are ports from <application>Thief</application>.</simpara>

&scr-ss2;

 </section>

</chapter>

</part>

<part id="devref">
<title>Programmer’s Reference</title>

<partintro>
 <para>This section is for OSM developers.</para>
</partintro>

<toc></toc>

<chapter id="dev-source">
<title>Source Code Overview</title>

<para>The source code for <application>Public Scripts</application> is included with the software. Under the terms of the <link linkend="copying">GNU General Public License</link>, you may use this source code to create your own software. Or you can just study it for informational purposes.</para>

<para>The source code that makes up the scripts is actually four somewhat independent packages.
 <variablelist>
  <varlistentry>
   <term>Public Scripts</term>
   <listitem>
    <simpara>The scripts themselves. This is the core of the OSM; everything else is supplemental.</simpara>
   </listitem>
  </varlistentry>
  <varlistentry>
   <term>ScriptLib Library</term>
   <listitem>
    <simpara>A library of functions useful in any script project.</simpara>
   </listitem>
  </varlistentry>
  <varlistentry>
   <term>lg Library</term>
   <listitem>
    <simpara>The core headers and support code required to build an OSM.</simpara>
   </listitem>
  </varlistentry>
  <varlistentry>
   <term>Dark Hook 2</term>
   <listitem>
    <simpara>A DLL that allows script modules to register hook functions with the game.</simpara>
   </listitem>
  </varlistentry>
 </variablelist>
</para>

&scr-dev;

</chapter>

<chapter id="dev-docs">
<title>Documentation Source</title>

<para>The documentation files for <application>Public Scripts</application> (what you are now reading) are generated from a modified DocBook XML source. The root of the document is in <filename>PublicScripts.xml</filename> and other fragments are in <filename>PublicScripts-common.xml</filename>, <filename>PublicScripts-dev.xml</filename>, <filename>PublicScripts-legacy.xml</filename>, <filename>PublicScripts-t1.xml</filename>, <filename>PublicScripts-t2.xml</filename>, and <filename>PublicScripts-ss2.xml</filename>. All the files use UTF-8 encoding and CRLF line-endings.</para>

</chapter>

</part>

<appendix id="history"><title>Revision History</title>
<itemizedlist mark="dash" spacing="compact">
 <listitem>
  <synopsis><emphasis role="bold">2.0</emphasis> - The “<emphasis>Machina Populi</emphasis>” release.
   Sometime in the future.
  </synopsis>
 </listitem>
 <listitem>
  <synopsis><emphasis role="bold">Beta 1</emphasis> - 2006-12-30
   Adjustments for compatibility with MSVC.
   Drop <script moreinf="refentry">FrobSounds</script>, <script moreinf="refentry">StopHere</script>, and <script moreinf="refentry">TrigBraindead</script> from T1. They’re already in <application>Thief Gold</application>.
   <script moreinfo="refentry">TrapFlipFlop</script> initializes on <message>BeginScript</message>.
   Add <script moreinfo="refentry">IntrinsicText</script>. Affects <script moreinfo="refentry">IntrinsicCover</script> and <script moreinfo="refentry">IntrinsicPlaque</script>.
  </synopsis>
 </listitem>
 <listitem>
  <synopsis><emphasis role="bold">Test 4</emphasis> - 2006-08-12
    Add <script moreinfo="refentry">TrapRequireOne</script>, <script moreinfo="refentry">TrapRequireOneOnly</script>.
    SS2: <script>TrapRequirement</script> is gone. Requirements are handled by an abstract class that can be used in any game.
    Population tracking for OBB and Room triggers moved into a common abstract class.
    <script moreinfo="refentry">TrigOBBSpec</script>: Trigger on any submodel. Use population tracking to avoid double-triggering.
    <filename>utils.cpp</filename>: But in FixupScriptParamsHack.
    <script moreinfo="refentry">TrapMissionQVar</script>: SS2 can use this script to store mission-specific qvars.
    Change how <script moreinfo="refentry">TrapRequireOne</script> and <script moreinfo="refentry">TrapRequireOneOnly</script> deal with trap control flags so it makes more sense.
    T2: <script moreinfo="refentry">HotPlateControl</script> didn’t set the meta-property at the right times.
  </synopsis>
 </listitem>
 <listitem>
  <synopsis><emphasis role="bold">Test 3</emphasis> - 2006-02-15
   Still working at it.
   Haven’t really been keeping track of changes, I’ll do a better job from now on... maybe.
   First appearance of this snazzy XML documentation.
  </synopsis>
 </listitem>
 <listitem>
  <synopsis><emphasis role="bold">Test 2</emphasis> - 2005-11-28
   Some further refinements. I think I only showed this to NamelessVoice.
  </synopsis>
 </listitem>
 <listitem>
  <synopsis><emphasis role="bold">Test 1</emphasis> - 2005-06-29
   A first glimpse at <application>Public Scripts</application>.
  </synopsis>
 </listitem>
</itemizedlist>
</appendix>

</book>
