Scenario creation guide to GGScript for the GGame Engine (The Gemstone of Balance and Other Stories)

by Gary Arndt


--------------------------------------------------------------------------------
About this document

- This section contains preliminary notes for this document

- This document details GGame scripting, a custom language that I created from scratch and built into my GGame engine that is important for advanced features of scenario creation

- To be more precise, this document contains extremely extensive additional information regarding the subject started and still in the main manual of creating your own scenario.  The specific topic addressed here is a guide to my built-in scripting language.  Eventually I may move the information from the main manual into this document so it becomes one single, comprehensive scenario creation manual but I have not reached a point where I want to do so just yet for reasons related to the writing/editing process.

- This information was written while I was using a cell phone (in order to optimize my time), however unfortunately the text editors insisted for some reason on adding non-standard versions of characters for apostrophes, single quotes, double quotes, and double hyphens rather than standard ascii.  And there may be more such garbage characters that I did not catch.  I found a way to fix those that I listed, but may have missed some.  Therefore, if you see any strange characters in the subsequent text, that is the reason.

- The document is almost reasonable complete [although there's a little more work on some of the later command descriptions to do], but there are still some notes within the text indicating work that I have deferred for now but do want to complete at some point in the future.

- This is intended to be an accurate account of the current state of the game implementation, even including things that need work.  For both that work and any other future changes, the intent would be firstly to typically remain backwards-compatible (refer to the section named "API evolution") and secondly for documenting here of any new capabilities to correspond to a given version number (which would of course also include versions newer than that).  However, as of this note there have been no such changes and so there is no need to cite a particular version number, meaning this information should apply to any existing version until if and when any newer version of this document indicates otherwise.  If a version number is ever needed in the future for this purpose, it will be included this note.  To work against an older version, use the corresponding older version of this document.


--------------------------------------------------------------------------------
GGScript
("GGame script")

 How to use this guide:

This information is intended for scenario builders, not players.  It is very long and much of it is for advanced scenario design.  This information is NOT required in order to create a simple scenario but is very useful if you want to have more flexibility.  A large part of it towards the end is effectively an API reference guide.  It is NOT necessary to read everything in order to make use of this information.  Some of the initial topics may be more useful for somewhat more simple use and general clarification whereas later topics and the full lists of available commands towards the end are likely to be a little overwhelming to read completely and are more intended for looking up the information as it is needed.


Overview:

While the basic concept of the built-in scripting system is described elsewhere (such as in the main game manual), a few points should be mentioned here.

First of all, this is a full, original scripting system I developed specifically for this game and built into it.  All aspects of it were created entirely from scratch.

It consists of a combination of a fairly simple scripting language and an extremely large and flexible API.  That said, the system has few distinctions between these two concepts with respect to the commands, although one could perhaps attempt to categorize those commands as one or the other (for example, BREAK vs. AlterTiles).

The game implementation and the scripting language implementation itself (which is simply a component of the game implementation) is written in an extremely efficient, low-level language (C/C++) and I have been extremely careful about writing efficient code.  As a result, the scripting language / API should be very efficient, as well (relative to it being high level and interpretive) and in fact a few efficiency tests seem to have shown that this is the case.  Just as with the other data files, scripting is used as one of the means of detailing the scenario specifics.

The core language syntax is intentionally very simple so that it is easier for scenario designers to use and so that it is very efficient (again, meaning as efficient as possible with respect to it being a high-level scripting language).

The API is extremely extensive to provide for maximum control of all aspects of scenario design.  That said, the most basic tasks can be done with just a few simple commands.

Also note that for those seeking more advanced techniques, other languages CAN be used via the separate plugins system, in which case each simple scripting command serves as an API call.  Many other languages used to do so can provide features such as regular variables, functions, parameters, etc. although at the cost of more complexity and less efficiency.  Just to be clear, the plugins system can also be used for other purposes such as adding new functionality; it is not just for using other languages.

Anyway, it is NOT necessary to use this scripting language at all in order to create a simple scenario but does provide significant flexibility in doing so.  Further, the most basic operations were intentionally kept very simple.

For example, here's a simple script to display some text:
0 M "Hello, world!"

There are many other examples with the command descriptions.


Line syntax:

A typical script command consists of the following:

[tag] [command] [[args]]

For example:

0 M "Hello, world!"

The tag is detailed in a subsequent topic.

The commands and their args are listed in great detail in topics towards the end.

The term "args" stands for arguments and simply means flexible information passed to the given command.  Another term for them could be "parameters".  Args must be provided in the given order and are delimited by at least 1 space.  Some args are required and some are optional.  This is the same basic concept used for other data file types, as well.


Line tags:

Script commands can be used in a few cases without line tags such as at the script testing console.

The commands in separate scripts (such as script files and trigger scripts) all start with a line tag, a number between 1 and 65535, or 0.  Use 0 when none is needed (and ONLY when none is needed).  Any reference to a tag will use the first instance found which normally means from the top of the script.  For the sake of efficiency and memory, each tag is stored as a number, not as a string, meaning strings as tags are NOT supported (unlike in some languages).

Some but not all commands that reference line tags allow a preceding 'N' or 'P' that means "next" or "previous", respectively (when supported these are notated in the command descriptions as "TagEx", whereas simply "tag" means it is not).  When using this syntax, the search for a line tag will use the next or previous one from the current line.  Because of this, multiple instances of a given line tag are useful and thus allowed.

Commands that go to a tag do not support going to tag 0 but most instead do support a shortcut of treating a tag given as 0 as "BREAK".

Example:
(not a useful script but just to clarify the subject)
0 GOTO 20
10 M "This message will NOT be displayed"
10 M "This message will be displayed second"
0 BREAK
20 M "This message will be displayed first"
0 GOTO P10


Script states:

Script states are tracked as each script command is processed and used directly by a few commands such as BREAK.

NORM: Normal.  This token usually doesn't have to be referenced directly.  For example, BREAK without any argument defaults to it so is the same as "BREAK NORM".

ERROR: Used to indicate that an error occurred.  This can be indicated explicitly via BREAK.

ABORT: Used only for particular script types.  For example, an item script for an item that would normally use up a charge will cause the charge not be used up if this is used via BREAK.

INC: "Incomplete", used only for particular script types.  For example, a trigger script for a trigger that only happens once will cause that trigger to remain active if this is used via BREAK.

TRM: "Target removed", used only for particular script types.  This is normally used via BREAK when you need to indicate that the target was removed explicitly so not to do any subsequent processing on it.  For example, such subsequent processing may be done after an item script has run unless this is used.

RESTART: Used only for particular script types

END: Used only for particular script types


Internal script variables:

To keep the core syntax of this scripting language more simple (although the number of specific commands and their options is extremely large and thus not so simple), normal defined variables are NOT used.  However, some commands are complex enough that they require interaction between them or with a target of various internal mechanisms.  Therefore, there are a few hardwired script variables that are used in very specific ways.  Also note that ARE some methods for very complex scripts to essentially use flexible variables.

The primary internal script variables include various targets and such:

- Target X and Y position: Numbers

- Target creature: A creature object

- Target object: A general object

- Target number: A number

- Target amount: A number

These also sometimes behave as internal script variables:

- The PC: A PC object, which behaves as an internal script variable when there is a party

- Script selection flag ("SFLAG"): 0 to 255, this can optionally be set when a script is called to behave as a simple parameter.  This is discussed in more detail in a later section.

Various commands may use or set one or more of these, as may some directly-associated internal mechanisms.  Be careful not to use commands together that set these for different uses.  If you have no choice in a complicated script that must do so (something that has in fact happened even in scenario 2), you must store then restore the value using special advanced commands, but the need to do this is very rare.

If you have a complicated script that must use a standard variable, you have the following options:

- Use keywords and DoKeyWord.  Note that keywords starting with an underscore character are specifically reserved for this purpose, meaning they are protected from being processed by player entry during complex conversations and such.

- Set aside and use a quest flag as a variable, assuming it is a number between 0 and 255.  Also remember that these can be used for 8 separate bit flags.  For example, scenario 2 at least currently sets aside 3 "temp flags" to use in this manner.

- Store then restore the value to/from an internal variable using the ScriptVal options, at best to another internal variable (if it supports the same type and range of values), a little more complex to a line tag (if it is a number between 0 and 65535), or at the most complex to a Def command arg.  Using Def will support any variable type but is more complicated to use.

- Store then restore using special options when they fit the situation such as some of the options for Party

For example, a script implementing some of the more complicated spells in scenario 2 must iterate through the members of any party, the iterator using the target object, but also set the target object for another purpose during the iteration.  It uses the ScriptVal command with the Def command to store the iterator target while it uses the target object for the other purpose.


Script uses:

Although scripts may be used in many different places throughout the game for many different purposes and there are sometimes a few specific details for those uses, scripting typically works about the same way.

Just some of these uses include:

- Complex conversations or similar interactions.  The target creature is set to the NPC in question.

- Positional trigger results.  Triggers that happen only once may use "BREAK INC" if they need to indicate an incomplete status and that the trigger should thus remaining active.

- Any map turn scripts.  Refer to the subsequent separate section for further details.

- Any map start script or exit script.  Start scripts are a good place to create temporary objects.  Exit scripts are a good place to check any quest requirement for the map has been completed (for example, all goblins defeated) then set a corresponding flag.

- The implementations of some items.  The target object is set to the item in question.  If the script removes the item then use "BREAK TRM" to indicate that the target was removed and thus should not be processed further (to decrease charges and such).

- Any results of Yell

- Any special results of winning the scenario

- The implementation of resting

- Complex spells

- More complicated game effects can be set up to result in running a script

- Location objects that reference a script.  For example, this is how the text-based settlements are implemented in scenario 2.

- Complex container interactions

- Scripts referenced by other scripts

- And there are more

Note that some further details need to eventually be added for some of the above.  For example, many of the return states have specific results for each specific script use.


Turn scripts:

As mentioned earlier, scripting typically works about the same way for most uses.  However, turn scripts is a special use of scripting that is more separate.

Most scripts run until they are completed.  Turn scripts, however, run until the WaitTurns command is used.  This allows a script to run continually for things such as deciding when a portal may close and another open or the walls of a room to close in.  One turn script may be defined for a given map.  A turn script is allowed to end manually, for example if the walls of a room are done moving.  It will automatically end if the map changes or the game ends.


Temporary objects

The game includes an extensive system for temporary game objects which is accessed through a number of scripting commands.  The purposes of this are to reduce memory usage, increase efficiency, create dynamic objects, and to avoid conceptually cluttering the standard definitions with objects that are used only once or only very rarely.

Temp objects may seem a little complicated to use at first but give the scenario designer a great deal of flexibility.

Most of these commands include a Create and Delete, and some also an Edit.  For example, for standard (overhead) tile frames there is a CreateFrame, DeleteFrame, and EditFrame.

To be clear, the primary purpose of these commands is to allow creating TEMPORARY objects and are not intended for creating permanent objects (although is possible), the later optimally defined using the standard method of other scenario data files, for example for tile frames with TILESET.dat along with the referenced *.til files.

By default, game objects created with these commands are automatically "reversed" (meaning, the changes reversed) when the map changes.  The -NOREV ("no reverse") option prevents this so it can be done manually using functions like DeleteFrame (or could theoretically be used to make the change permanent until reloading the game, at which time they would need to be rebuilt).

Existing game objects can also be temporarily replaced using the -REPLACE option.  This is extremely useful if you want to leave everything else as it is, for example change just the way a tile frame looks but keep the same ID so everything referencing it can remain unmodified.

The -COPY option is very useful if you want to make changes to an existing object, for example copy the definition of an orc but increase a few fields to make a more powerful version, perhaps even with a modified tile, as well (to be clear, the later would require separate commands to create the tile frame and tile but may also benefit from their own -COPY options, depending on how they were constructed).

Sometimes it is better to create a tile frame in the usual way rather than with the Edit, in which case the -LOAD option can be used.  Scenario 2 conceptually separates these by keeping their ID's in the 1000's range, but this isn't actually required.  Note that the -LOAD option is the only choice for some objects such as for temporary sounds.

When a temporary object is created, it is added to the respective object set, for example a frame is added to the frameset.  Because of this, there needs to be enough extra space defined unless it is a replacement (which are stored in place of the original while the original is stored in a separate location).  For example, if your tile set is defined as size 50 and 49 are already used then there will only be enough space for 1 temp frame.  If you use up to 6 temp frames at a time then you'd need to increase the frameset size to at least 55.

Further, a few object sets in the game including the creature definitions (the definition list, not the map creature list) and the NPC definitions list tie the ID to a particular position and thus you must also reserve some ID's for temporary objects.  For example, scenario 2 reserves ID's 1-9 in the creature definitions list for temporary definitions (allowing up to 9 at once, although more could be added using any unused ID's, if needed).  That said, for most object sets any arbitrary unused ID is fine (1-65535).  The reason behind this development decision was related to efficiency and in any case was implemented long before temp objects.

When a temp game object is reversed, it is removed from the object set.  If it was a replacement, then the original version is put back.

Game objects are processed ("applied") automatically to the game in a logical sequence as they are loaded.  Anything referencing a temp object, however, must delay doing this so that it can first be defined by the given script.  Because of this, some special provisions are required:
- The temp objects must be applied manually after they are defined.  Each Create command includes an -APPLY option or in some cases there are separate commands to do so that are best if there are multiple temp objects.
- Any creature with a temp definition that may persist via a save game or is used prior to being defined by the script commands (such as in a map file) must be marked as a temp object so that it will not be included in the standard apply processing.  There are multiple methods for doing this including various command options (such as -TEMPDEF) and in a map file, the "TEMPDEF" tag.

It should be clear if this had not been done properly when an error message appears regarding not being able to apply the given object.

Scenario 2 makes extremely extensive use of temp objects, just a few of which include:
- A hybrid tile frame when the PC sleeps in a bed or sits in a chair
- A tile if the PC is stuck in water
- A variety of unique or rare creatures and NPC's.  Many of the settlements designed more recently use unique NPC's.
- Creatures with slight differences in look and capabilities such as some customized for particular terrain
- OH and FP tiles that appear only very rarely
- Altered OH and FP tiles such as arctic embankments
- Sounds that are used only in one place
- Many more

One other important matter is that there ARE several methods to use temp frames and tiles in the separate graphics editor program.  Refer to the manual for that for more information, but briefly:
- The easiest way to design a map is to use a normal tile as a placeholder and then replace it later directly in the editor or dynamically using script commands in the game
- The editor doesn't support script commands like the game does but instead does include support for some special control commands that, amongst other things (such as loading multiple maps at once) includes just enough of the same temp frame and tile capabilities to allow editing with them (the different approaches are due to the control command mechanism being the more optimal approach for the separate editor program and therefore it not being worth what would be a rather significant effort to port over from the game program the far more complex scripting system).  Those commands can be placed in a special text file and then loaded to take effect.  The file extension for these must be ".ecl", which stands for "editor control list".  Several of these have been created for my work on scenario 2 such as for editing many of the arctic maps that rely heavily on temp frames and tiles.  There are some examples of these files in the separate editor program install's "Sample" subdirectory and the overall subject is detailed in the editor manual.  (As of this note, that manual is still under construction and so the section can be found several topics down into the first section named "Notes", or, perhaps more easily, by searching for "ecl".  That said, it is planned to eventually be relocated to an entirely distinct and separate section.)  Just a few of the supported commands include '#' for a comment (as usual), "Map" to load a given map, "MELoadFrame" to as the given ID load a given frame from a file into the map editor, and "MEEditFrame" for various editing options, amongst many other commands (to be clear, these are specific to the editor program and are NOT part of the scripting described in this document, although there ARE scripting commands that cover the same functionality and beyond).


General notes:

- As with most data files requiring the maximum number of entries to be defined ahead of time, the maximum number of lines must be defined for a standard script.  This is typically done as the single parameter to "SCRIPT" as in:
SCRIPT: [lines]

- Because scripts can and often do loop there is a maximum number of lines that can run in a row known as the safety maximum to prevent an infinite loop.  The number of lines that run in a row is tracked for this purpose and the script will stop if the maximum is exceeded.  While the default maximum is usually more than enough, there may rarely be a script that needs to exceed that amount and so can be changed with the SetSafety command.

- Scripts support the usual data file syntax for comments and such, meaning '#', "/*", and  "*/"

- As with most data file entries, any text with spaces requires being enclosed within double quotes

- Options that are listed with the suffix "(s)" means that more than 1 is optional, usually meaning the value is allowed to be a range as [start]-[end].

- Args listed as "[options]" (plural) may be in any order in a general sense (sometimes the order must correspond to how they behave, however) and are typically relatively unlimited even including multiple uses of the same option when doing so makes sense.  That said, there is a maximum number of args [amount to be found and listed later but is something like 256].

- As with most data files, you can use extra spaces between args.  For scripts this can help to better see separate lists of associated args, for example in the following note that there are TWO spaces between each keyword/tag pair:
AddKeyWords bye 2  name 3  job 4

- The term "token" is used to describe a character or string that will be interpreted as having some special meaning, for example "RED" for a color.  Note that these can ONLY be used when it is specifically indicated that they are supported in the given context.

- The SFLAG, which stands for "script flag", is a value between 0 and 255 that can be optionally passed to many scripts like a simple input parameter.  It is also discussed with the internal script variables in that separate section.  Anyway, it can be particularly useful along with flag checking commands to select a sub-option within a more general script and thus avoid multiple redundant scripts and/or numerous short script files.  The default value is 0.
 
- Some commands or option have args that are a numeric value.  Such values are restrained to a given range.  This is most often described for each specific case, but if it is not then the rule of thumb is that it will use the most restrictive range that still allows for maximum flexibility.  For example, a party of 255 characters is far more than necessary so higher values are not supported (255 is the lowest normal positive limit or it would be even less).
-- Numbers may often support negative values if doing so makes sense, although sometimes the behavior may be undefined/unpredictable/unsupported (for example, the healing commands are not intended for inflicting damage by using negative numbers but rather there are entirely separate damage commands).
-- Numbers that may only be positive (known as "unsigned") are either from 0 to an extremely high value (4,294,967,295), or sometimes only to 65535 (for example, most ID's), or sometimes only to 255 (for example, a few ID's or a party member position in the party)
-- Numbers that may be either positive or negative (known as "signed") are either from an extremely high negative value (about -2,147,483,647) to an extremely high positive value (about 2,147,483,647) (for example, item quantity, although only positive values actually allowed with the negative values only being used for special internal purposes), sometimes from about -32767 to 32767 (for example, map position), and very rarely from about -127 to 127.
-- ID's are usually 0-65535, although in a few cases are 0-255

- Some commands deal with a position.  A position can be specified in several different ways, but the most common is with a coordinate where "x" means horizontal and "y" means vertical, a traditional approach (with "z" sometimes being used for height).  Note that this is actually BACKWARDS from another traditional approach, that of listing row (y) then column (x).  Anyway, in this case the origin (0 0) is at the upper left corner and the values increase when going right or down.  Negative numbers are not used except for special purposes (such as to indicate uninitialized values).  The game supports a maximum coordinate value of 32767, more than enough for any reasonable map layout and size (the maximum total map size being x * y = no greater than 65536, and for more room maps can be logically placed adjacent to each other, a good idea in any case for supporting smaller maps since that will increase efficiency and decrease memory usage).

- Some commands deal with a direction.  This is sometimes specified as a single character, sometimes with a number, or sometimes either of those.  As numeric, they progress clockwise from north.
N or 0: North
E or 1: East
S or 2: South
W or 3: West

- Some commands use the following tokens as abbreviations:
Y, N: Yes or no
C, I, V, L: Creature, item, vehicle, or location
!: Not

- Some commands deal with a condition which unless specified otherwise refers to numeric comparison.  This uses the same syntax as many programming languages:
==: Equal (note the TWO signs)
!=: Not equal
<: Less
>: Greater
<=: Less or equal
>=: Greater or equal

- Some commands deal with filenames directly while many others deal with them indirectly such as definitions made in numerous separate data files.  In both cases the default or only directory location where these almost always reside is the main scenario subdirectory of the install.  This means that for direct filenames without a path this is almost always the expected location.  Filenames are often used in building a more specific directory path and as part of that sometimes a filename including a path will not work properly and other times it does work.  Relative paths are more likely to work than absolute paths.  The exceptions where looking in other directories is explicitly supported are extremely rare (some development/cheat options are for convenience designed to allow it, plugins should be located separately, there are some general files in the install root, etc.).  The bottom line is that it is usually best or required to locate most or all referenced files in the scenario data subdirectory.

- Some commands deal with colors.  These are specified as usual using RGB, meaning red, green, and blue in the range of 0-255, 0 being none and 255 maximum.  For anyone unfamiliar, various combinations of these 3 values can be used to define any color.

- Some commands deal with a transparency color.  This means one color is treated as transparent during a given operation, often by ignoring it in some way.  The default transparency color is pure black (RGB 0  0 0) but can often be changed.

- Some commands deal with the terrain.  The meaning depends on the context such as the terrain of the tile or the terrain capability of a creature, item, etc..  This can be provided as an ID as per the scenario terrain definitions or as one of several predefined or default tokens:
BLOCKED: Generic blocked terrain (such as a wall) or creature unable to move
UNBLOCKED: Generic unblocked terrain
ALL: Creature can move onto all terrain (for example, incorporeal undead)
EMPTY: Creature or item can move or be placed onto position with no objects
LAND: Default for generic land (used by scenario 2 for open terrain such as grasslands)
WATER: Default for generic water (used by scenario 2 for standard deep water such as oceans)

- Some commands deal with the tile view type.  This only has meaning for scenarios that use blocked visibility darkness or ranged weapons, etc..  Tokens include:
UNBLOCKED: It is possible to see beyond this
BLOCKED: It is NOT possible to see beyond it
CLEAR: Used only for special purposes such as to indicate an invisible tile on the overlay map

- Some commands deal with creature behavior, also sometimes referred to as disposition.  Some of these behaviors use other settings that control related distances, positions, who is considered an enemy, and so on.  Such settings are usually defined in other data files such as objdefs.dat or the map*.dat files, although some can also be controlled with some script commands.  In any case, these include:
STATIC: Do not move
FOLLOW: Follow the PC, usually used in simple scenarios for merchants enclosed behind counters
WANDER: Randomly wander, if any AI distance is defined it will limit movement from the anchor position.  The anchor position may be set explicitly or defaults to the creature's start position.
ATTACK: Try to move towards and attack an enemy
HOSTILE: Behavior becomes ATTACK when an enemy enters the agro/AI distance from the current position.  If a group ID is set then all other members also respond.
RETREAT: Move away from enemies
MERCHANT: Special behavior allowing optimal interaction with a merchant, basically wander within the AI distance from the anchor position until a PC gets close then move to the anchor position and/or across a counter so the PC is on the opposite side [I need to check the code so as to make the text here more exact]

- Some commands deal with increasing, decreasing, or specifying an amount such as HP or SP.  Many such commands use some of the following syntax or often allow a choice between them:
-- A specific value, for example "4" literally means exactly 4
-- [percent]% for percentage of the normal maximum, for example "50%" of a max of 20 would result in 10
-- [amount]d[type]+[bonus] for randomized, a common syntax used in RPG's meaning the amount of dice ('d') of the given number of sides to roll plus a static "bonus" value, for example "2d6+3" would generate a number from 5-15 [I need to check if this is already explained in the main manual so as not to be redundant or at least if the syntax gets used in other places then explained in a more general place]
-- "MAX" for setting to the normal maximum, for example if the max was 20 then the result would be 20.  Using this syntax may be slightly more efficient than using "100%".

- Some commands reference the following terms:
DC: A common term used in many RPG's that stands for "difficulty class" (a parallel to "armor class"), simply meaning a target number to reach.  For example, if a DC is 87 and an associated roll with modifiers is 87 or higher, then the result is true or successful.  [I need to check if this is already defined in the main manual glossary and, if not, consider maybe moving it there depending on if players deal with the term or not.]
ZM: Stands for "zoomed map", meaning a map used in some scenarios such as scenario 2 that has a zoomed in scale during combats, resting, etc., that are initiated on large-scale maps.  Special rules often apply during ZM, for example if started when in a vehicle such as a ship then some functionality will apply to that vehicle even though the PC tile(s) is/are not directly shown or considered as boarded.  There are also special rules for retreating, combat ending when all enemies have been defeated, etc.; refer to the main manual for more details.

- Keep in mind that the script console is a very useful tool for interacting with the game and for testing a single script command.  This is a development/cheat option described in further detail elsewhere, but basically:
-- Development/cheat mode must be activated to use it
-- Shift-F12 will start it
-- An empty line will exit it
-- Special meta-commands are summarized when you start it
-- It otherwise accepts script commands
-- Do not use a proceeding line number
-- To be clear, the development/cheat menu is an entirely separate system so cannot be used there
-- The result of tags can be viewed for informational purposes but are otherwise not functional because only the given command is processed
-- This accepts input prompt advanced editing controls such as right/left arrow, overtype mode, insert mode, copy/paste, etc..  These are particularly useful when used in conjunction with the "e" meta-option.  Anyway, this is mentioned because as of the time of this note, not all input prompts in the game accept those controls yet (simply a matter of risk and testing vs. usefulness).

- Another useful tool for script testing is the development/cheat "run script" command.  The development/cheat system is described in further detail elsewhere, but basically:
-- Development/cheat mode must be activated to use it
-- Control-F12 will start it
-- The instructions are displayed when you start it
-- F1 (the help key) after starting it will display the list of available commands including those for running scripts

- Several script commands such as DBG are intended specifically for debug/development/testing purposes

- It may be worth clarifying that any given term may in some cases have entirely different meaning in different contexts.  For example, the term "condition" sometimes refers to numeric comparisons (==, >, etc.) and other times to a game condition of the PC (wounded, asleep, etc.).  This should be made reasonably clear by the context but still seems worth pointing out explicitly.


Programming terms

More advanced scripts may need to use common programming techniques.  While the basic aspects these subjects are so common as to be beyond the scope of this document, some of them should at least be clarified in the context of this scripting language such as:

- Loops: Repeat the same commands unless/until 1 or more particular conditions become true.  Be sure to allow a way for the loop to end or the loop will cause the safety mechanism to issue an error and stop the script.  A loop can be implemented by going to a tag where the loop starts with a command such as GOTO and one or more commands that do a check, for example:
0 M "Before the loop"
1 CM "Stop loop? "
0 Verify 2
0 GOTO 1
2 "After the loop"


Iterators

Some advanced commands are iterators or serve as a component of an iterator.  This means they are intended to be used as part of a loop that goes through a sequence of values such as all positions in a given pattern from a given starting position, all party members, etc..  For example, the circle iterator goes through all positions in a circular pattern and the party iterator goes through all party members.  Refer to the specific associated commands for details.


The PC and a party:

If a command references "the PC" but there is a party and thus more than one PC it typically uses the active PC, although in some contexts it may use any PC target.


Shortcut command names:

A few commands became common enough that shortcut names were added, for example "M" for "Message" and "CM" for "CMessage".  These command names work exactly as the longer original names.


API evolution:

The earliest script commands were designed very early on in the development of the game.  This would have been somewhere around 2006 or so.  Without digging back through old engine source code to get the exact date, the important point is that it was a long time ago.

The reason why that matters is that the approach to the commands has been evolving over the years since then and so some of the older commands may be reworked at some point to fit the newer approaches.  This means they will probably be replaced by new commands/options.  That said, for the sake of backward compatibility they may potentially not actually be removed or renamed, just superseded, in which case they would simply be moved to the least optimal points in the code in terms of efficiency and no longer maintained (meaning, changed for new features and such, etc.).  That said, eventually removing or renaming in some limited cases after some time has passed is not entirely out of the question.

But regardless of how those old commands are handled, associated documentation such as this document and a dedicated section in a readme file will carefully detail if and when such changes are made.

In fact, some of this work has already been going on for years, for example some of the newer commands or their options overlap the older commands, "complex" or "Ex" versions have been added, etc..  Although no commands or options have been removed or renamed since after the first public release, there are now a number of newer commands and options intended to replace some of those that use older, inferior approaches.

Such old commands and/or options will include details about this where they are described in this document, and those details will of course include what to use instead.  They will still be documented for the sake of completeness, clarity of any older scripts you may decide to analyze, etc..

Just to be clear, many older commands will NOT change because they are either fine as they are or in some cases when there are more complex versions the older versions are still useful as more simple and efficient versions.

A few of the newer approaches include:

- Commands that are more general with various options being specific rather than numerous commands that are very specific

- Fewer required args in favor of multiple optional args

- Option names and tokens and such being more consistent and following the same conventions between commands

- Internal variable names being referenced using more consistent names.  For example currently "TARGET" can mean more than one thing, "0" sometimes means the target, etc..


Conventions used for command descriptions:

- A bracket is used here to indicate the name of what may be used for something like a command option, not to actually use a bracket literally.  For example, Message [text] means use the actual text to display as the option for the command.

- A double bracket means the option/options is/are actually optional (not required).  For example, in SomeCommand [[SomeArg]] the SomeArg is optional.

- A ellipses ("...") in the args, often accompanied by a first arg with the suffix '1' and a last with 'N', means any number of such args where '1' is the first and 'N' the last, although it may only be just 1 if desired.  For example, in SomeCommand [SomeArg1] ... [[SomeArgN]] means there may be 1 or more of the given args, the first required.  This is sometimes instead notated as just a plural, for example SomeCommand [[SomeArgs]] assuming the first of those args is also optional.

- Note that the hyphen used for many command options is part of the option name, NOT a bullet point, for example "-NL", which note has NO space between the hyphen and 'N'.  Any use of a hyphen for a bullet point will always be separated by a space before the text, for example this text ("- Note that ...").


General commands:

M/Message [text]: Display the given text including a new line
Example:
M "Hello, world!"

NOOP: "No operation", do nothing.  Useful for defining a line tag only.

BREAK [[state]]: Stop processing the script (meaning, end the script) with an optional exit state
Examples:
BREAK
BREAK INC

GOTO [TagEx]: Jump to the line with the given tag
Examples:
GOTO 10
GOTO N1
GOTO P10

Verify [TagEx] [[options]]: Input a user keystroke corresponding to "yes" or "no" and if "yes" go to the given tag.  'Y' is "yes" and any other key normally defaults to "no".  Optionally:
-NOT: Go to the tag if NOT "yes" (thus "no")
-ND: "No default", meaning only 'N' is "no"
Example:
0 CM "Do you accept the quest? "
0 Verify 10
0 M "Come back if you change your mind"
0 BREAK
10 M "Thank you!"

Pause [[options]]: Display a message for the user to press any key to continue and do so.  Optionally:
-APINC: "Autopause increment", only needed for special purposes related to interaction with the autopause system
-DONE: Allows -APINC without the additional pause
Example:
0 M "Some text prior to pausing"
0 Pause
0 M "Some more text after pausing"

AddKeyWords  [word1 tag1] ... [wordN tagN]: Define 1 or more word/tag pairs.  This is most often used for complex conversations.  Note that by using this command more than once you CAN change the tag for a given word, which can be useful to change the results of what was said most recently.  When using this more than once, nothing will change beyond what you define/redefine.  Multiple uses can also allow defining keywords only once they are spoken by the NPC, although this can make the script more complicated to implement so usually it is easiest to only do this occasionally and define most keywords initially.  Due to an implementation complication, you cannot currently undefine a keyword but you CAN point it to a tag that displays nothing or the "unknown" response.  This may eventually be addressed but is a rare enough limitation that doing so is not a priority.  Like other various aspects of scripts, keywords only last the duration of the current script.
For example:
0 AddKeyWords bye 2  name  3  job 4
1 DoConvInput "Sorry, I don't know"
2 M "Goodbye"
0 BREAK
3 M "Zaranth"
0 GOTO 1
4 M "A warrior"
0 GOTO 1

DoConvInput [invalid string]: Display a prompt, input a user string, and go to any tag assigned via a keyword.  The "invalid string" is used if no keywords match.  An empty string will cause it to go to the next command.  A string with an underscore prefix ('_', such as "_return1") is ignored so that such keywords are reserved for special purposes only.  This command is the most common and simple way to process user interactions for complex conversations and such.  Refer to AddKeyWords for an example.

DoKeyInput [[options]]: Input a user keystroke and go to any tag assigned via a keyword.  Keywords are either simply the character in question such as "A" or a name such as "RIGHT" for the right arrow key, "UP" for the up arrow key, etc..  This command is only needed for special purposes.  Optionally:
-SHOW: Display text corresponding to the key pressed

DoStringInput [[options]]: Input a user string and go to any tag assigned via a keyword.  Note that DoConvInput is a more simple but less flexible alternative.  This command is intended for more specialized or complex purposes.  Optionally:
-PROMPT: Display the standard prompt
-ITAG [tag]: Go to the given tag if the input is "invalid", meaning the string does not match any keyword
-IMESSAGE [text]: Display the given text if the input is "invalid", meaning the string does not match any keyword
-NNL: "No new line" for IMESSAGE
-IPAUSE: Pause if the input is "invalid", meaning the string does not match any keyword
-ABORTNONE: Do the same as "BREAK ABORT" if an empty string (thus the "none") is entered

DoKeyWord [word]: Go to the tag assigned to the given keyword.  This command is typically only needed for special purposes.

Random [chance] [tag]: Go to the given tag if a random percentage roll (1-100) is within (<=) the given chance
Example:
0 Random 25 1
0 M "You are able to rest safely"
0 BREAK
1 M "You awaken to a goblin ambush!"

CRandom [chance1 tag1] ... [chanceN tagN]: "Complex random", similar to Random but goes to any number of tags based on the total of the chances rather than a percentage.  The hyphen character ('-') can be used instead of a tag to indicate to stop the command, effectively going to the next command. Since it is not based on a percentage, the total does not necessarily have to add up to 100 (chances will still work evenly).
Example:
0 CRandom 50 -  25 1  25 2
0 M "Possibility A"
0 BREAK
1 M "Possibility B"
0 BREAK
2 M "Possibility C"

WaitTime [time] [[options]]: Pause the script for the given time, which is in milliseconds.  Optionally:
-ASYNC: Some aspects of the game keep running such as animation
-SYNCH: Everything pauses, the default

WaitTurns [turns]: This only applies to turn scripts and simply passes turns by the given value before proceeding to the next command

CheckState [state] [tag]: Go to the given tag if the return state of the most recent command matches the given state

SetSafety [value]: Change the safety looping maximum to the given value.  Refer to the section discussing the safety maximum for further details.

InitKWList [value]: "Initialize keyword list" manually.  This is normally done automatically when it is needed by a command such as AddKeyWords but that approach uses a default maximum.  This command allows defining that value manually and must be used BEFORE any other command that would set the value to the default.  The original reason it was implemented was to allow more keywords than are allowed by default (an error was showing up when using AddKeyWords to add to a particularly large number of keywords).

Def [arg1 ... argN]: This special command is used to define args to be referenced by some other particular commands that are intended to do so such as some of the CMessage options.  It does NOT need to actually be run to be effective as such.  However, if it is run it simply behaves like NOOP, meaning it does nothing (this can actually be useful if you would have needed a NOOP, anyway).

DBG [text]: "Debug" message, works just like Message but only is displayed if debug mode is active

Time: A command intended for development/testing such as for efficiency which displays the current real-world time

Ping: A command intended for development/testing which simply issues a message indicating that the script is running


Game-specific commands:

These commands are used in exactly the same way as the general commands but happen to be more closely integrated with the specifics of the game.  They are listed separately simply for organization purposes.

CM/CMessage [options]: "Complex message", displays text like the Message command but uses a more complex approach to allow for various special options.  Plain text will display as given.  Note that a new line will NOT automatically be included unlike Message.  Other options:
-NL: New line
-PCNAME: Name of PC
-CURRENCY: Amount of gold (or other currency type) of PC
-PRICE [value]: Modified purchase price of given value
-SELLPRICE [value]: Modified sell price of given value
-CREDIT: Monetary credit of PC with current creature
-CREATURE: Current creature name
-NAME: Current creature true name
-DIR: PC facing as in NORTH etc.
-DEF [tag]: String defined by the arg of the given definition command
-DEFARGS [tag]: All strings defined by the args of the given definition command
-SPELLNAME [ID]: Name of given spell
-SPCOST [ID[*[value]]]: SP cost of given spell, ID can optionally include a '*' suffix followed by a subsequent multiplier value
-ICOUNT [ID or "TARGET"]: Quantity of given item
-SHM ["NEUSE"]: Shared message string for the sake of consistency.  NEUSE is "no effect for use".
-PARTYONLY: Continue processing only if a party
Debugging options:
-TARGETX
-TARGETY
-TARGETNUMBER
-SFLAG
Example:
CM "I am a player character named " -PCNAME " and I am carrying " -CURRENCY " gold." -NL

Sound [ID] [[options]]: Play the sound of the given ID.  The ID corresponds to that defined in the scenario sound set and referenced as one of a few default tokens for core sounds or as a direct numeric ID that can reference any ID in the set and therefore also any non-core sound.  Optionally:
-ASYNC: Asynchronous, meaning do not wait for the sound to finish before continuing
-CONTINUAL: Repeat until stopped
-STOP: Stop the continual sound
-USYNC: "User synchronize", meaning play then use -WAIT later
-WAIT: Wait for the sound started with -USYNC to finish before continuing
-SYNC: "Synchronous", meaning wait for the sound to finish playing before continuing.  This is the effective default and only an option for the sake of completeness given the way the default is implemented.
ID options:
NPCHIT
NPCMISS
PCHIT
PCMISS
BLIP
INVALID
STEP
[ID]

FX [ID] [[sound]] [[position]]: Do the standard FX of the given ID.  The sound is the ID as described for the Sound command.  Standard FX are built in and include:
1: Screen inversion
2: Standard round
3: White background
4: Red background
5: Green background
6: Blue background
7: White with inversion
8: White unfilled
Position options:
[x y]
-TARGET

TileFX [ID] [repeat] [[options]]: Do a special tile FX.  The ID is that of a tile corresponding to that in the scenario standard tileset.  All frames will be repeatedly animated onto the position(s) in question as per that given value.  The default position is that of the PC.  The default transparency color is black.  Optionally:
-SOUND [ID]: Play the given sound during the FX.  The ID is as described for the Sound command.
-DELAY [ms]: Wait between animating frames by the given time in milliseconds.  Put more simply, this slows down the FX.
-COLOR [R G B]: Set the transparency color.  This can be useful for reusing tiles not originally intended for a tile FX and therefore not using the default (black) as the desired transparency color.
-POS [x y]: Do the FX at the given position
-TARGET: Do the FX at the script target position
-FS: Do a full screen FX instead of a single position
-NOEMPTY: Skip empty tiles for FS FX.  Empty tiles means the built-in tile 0 that is all black and used for various purposes such as blocked visibility.  For example, a rain FX then won't display past a wall.

Teleport [map] [x] [y] [[options]]: Change to the given position for any purpose, not just being teleported, but essentially behave as such.  The map is the ID for the scenario mapset or can be 0 to reference a position local to the current map.  The x and y position may be defined or -1 each to skip those args in favor of default behavior or behavior defined by optional args.  Optionally:
-TARGET: Set the position to the target position
-PC: Set the position to that of the PC
-OFFSET [x y]: Adjust the current position by the given amount
-ENTER: Treat the teleport as if it were an Enter command, meaning it stores data for a subsequent Exit command
-EXIT: Teleport as if were an Exit command.  This will cause the map and position args to be ignored.
-UPMAP or -DOWNMAP: Set the map to the map as defined for the given map.  This also tracks the most recent move type as such.
-DIR [N or E or S or W]: Change direction to north, etc.
-ROTATE [value]: Change direction clockwise by the given value of 1-3 compass directions
-RANDOM: Set the position randomly.  This DOES consider the terrain capability (a standard PC will not appear in a wall, on water, etc.).
-CBUFFERING: "Condition buffering" of the map, which put simply means to treat the teleport like entering a combat map, dungeon room, etc..  As usual, the current map must be set up to support the use of such destination maps.

Autosave: Do an autosave, which put simply means to save the current game progress without being a named game.  One vital purpose of this as well as being the original purpose this command was added is to use after Teleport in cases where that command itself triggers an autosave in a state that is not good to allow the player to later reload from.  Using this afterwards resolves any such problem.  This command may eventually be replaced by a Util option.

AlterTiles [ID] [x y] [[EndX EndY]]: Make the tile at the given position(s) the tile of the given ID as defined in the scenario tileset.  CAlterTiles provides additional options.

MakeMapObj C [ID] [x y] [[NPC ID]] [[options]],
MakeMapObj I [ID] [x y] [[options]],
MakeMapObj V [ID] [x y],
MakeMapObj L [ID] [x y] [destmap] [DestX DestY]:
This command creates a new game object on the map at the given position.  The first arg is the first letter of the type, creature, item, vehicle, or location.  The position for x and also y can be a number or 'T' to use the respective script target position.  Some args differ depending on the type.  For a creature, if the arg in the position of the NPC ID arg doesn't start with a hyphen then that ID will be set up for the given creature, otherwise processing of the remaining args as the options begins with that arg.  For a location there are args to set the destination map and position.
Optionally for a creature:
-D or -DELAY: Set a delay so the creature doesn't act right away
-ENEMY: Makes the creature an enemy, useful if the creature is not so by default
-ID [value]: Set the ID explicitly rather than via the standard automatic assignment
-GROUP [ID]: Make the creature part of the given group
-TEMPDEF: Mark this creature as using a temp definition, necessary when using the respective commands to do so and being used by this creature
Optionally for an item:
-Q [value]: Set the quantity to the given value
-REF [ID]: Set the reference ID, important for some items
-BPARAM [value]: Set the general "byte param", important for some items
-TRAP [ID]: Sets a trap of the given effect ID if the item is a container, the effects as per defined for the scenario
-CONSCRIPT [ID]: Set a container script of the given script ID if the item is a container, the script as per the file defined for the scenario
-TRTAB [size] [definitions]: Define a treasure table of the given size if the item is a container.  Some treasure table entry types such as E and S are NYI for this command option.  What is implemented includes:
TYPE [value]: Sets the treasure table type to the given value, IND (default) or SELECT, only needs to be used if changing to the later
A [ID] [quantity]: Define an "A" (absolute) entry with an item of the given ID and quantity

SetFlag [ID] [[value]]: Set the PC quest/etc. flag of the given ID to 1 or the given value.  If the given value is preceded by a '+' or '-' it will add or subtract the given value from the current value.  This is the standard version of the command.  Use SetBFlag to set bits or Flag for advanced options.

CheckFlag [ID] [value] [TagEx]: If the PC quest/etc. flag equals the given value then go to the given tag (which does support advanced notation).  This is a very simple and limited version of the command but still useful and efficient.  Use CCheckFlag for greater flexibility (including conditions beyond exact equality), CheckBFlag to check bits, CheckFlagSwitch for multiple tags, or Flag for advanced options.

CCheckFlag [ID or "SFLAG"] [[condition]] [value(s)] [TagEx]: As per CheckFlag but with additional flexibility at the cost of being more complicated.  The optional condition arg allows the usual options (==, !=, <, >, <=, >=), the default equal.  The value is allowed to optionally be a range.

CheckFlagSwitch [ID or "SFLAG"] [value1 TagEx1] ... [valueN TagExN]: Similar to CheckFlag but works as a switch to map the given flag's value to multiple possible tags
Example:
CheckFlagSwitch SFLAG  1 10  2 20  3 30
0 CM "ERROR: Unknown SFLAG " -SFLAG -NL
0 BREAK
10 M "First option"
0 BREAK
20 M "Second option"
0 BREAK
30 M "Third option"

SetBFlag [flag] [bit] [[value]]: Works much like SetFlag but operates on the given bit (1-8).  If the value arg is set to an actual value it must be 0 or 1.  If the given value is '!' it will reverse the current value.  The purpose is to save space by using fewer flags when a flag only needs to have 2 states.

CheckBFlag [flag] [bit] [value] [TagEx]: Works much like CheckFlag but operates on the given bit (1-8).  The value must be 0 or 1.

SetSFlag [value]: Explicitly set the internal script flag to the given value.  Note that it is normally set by other mechanisms so this should normally only be needed for special purposes. This command may eventually be replaced by a Util option.

Damage [amount] [options]: Cause damage to the PC.  The given amount can be specified as a specific amount such as 4, the standard random specification [amount]d[type]+[bonus] such as 1d6+1, [percentage]% such as 50%, or "DEATH".  If the PC has boarded a vehicle then it will take the damage instead.  Optionally:
-NOMESSAGE: No default messages
-NOFX: No default FX
-SOUND: Sound only
-ZMVEHICLE: Instead of the PC, affect any vehicle associated with the map if zoomed in, for example the ship you are on when in its combat map
-DEATHCONT: "Death continue", do not end the script upon death

CreatureDamage [ID] [amount] [[options]]: Works like Damage but for a creature other than the PC specified by the given ID.  If the ID is 0 then the current creature object is used.  Optionally -NOMESSAGE, -NOFX,  -SOUND as per Damage plus:
-NOANR: "No attack NPC result", meaning don't resolve the results to the NPC automatically.  This is important if it  will be done later since trying to do it multiple times can lead to errors.

Cure [[options]]: Cure a negative condition of a creature.  The default creature is the PC and condition is poison.
-TARGET: Cure the target creature instead
-SLEEP: Cure sleep instead
-NOMOVE: Cure immobilized movement instead
-NOATTACK: Cure immobilized attacks instead

AbilCheck [ability] [target] [tag] [[options]]: "Ability check", the value of the given PC ability plus a random roll of 1-100 vs. the given target value to determine success, and if so go to the given tag.  Abilities include the 6 ability scores, the 3 saving throws, and others that are often derived from them:
STR: Strength
AGI: Agility/dexterity
STA: Stamina
INT: Intelligence
WIS: Wisdom
CHA: Charisma
F: Fortitude saving throw
R: Reflex saving throw
W: Will saving throw
PER: Perception, a derived ability
PILOT: Vehicle piloting, a derived ability
Optionally:
-S: Secret/silent mode, meaning the check is done without any default messages and such
-V: Verbose messages allowed
-SKILL [ID]: Add to the check any skill of the given value.  This effectively turns the ability check into a skill check.
-SKONLY: "Skilled only", the check automatically fails if the PC does not have the skill defined by -SKILL

CreateFrame [ID] [[options]]: Create a temporary overhead tile frame with the given ID and add it to the scenario frameset.  By default this is automatically reversed (including deletion) when the map ends, just as with all temporarily game objects.  This command is just one example of the commands that use the extensive temporary object system, useful for a number of reasons including saving memory, avoiding diluting primarily object sets with rarely-used content, making subtle changes to existing objects, building composite objects, and so on.  To clarify, standard tile frames should be created using the standard methods for creating scenario content that are completely unrelated to these scripting commands.  Anyway, options for this command include:
-COPY [ID or "PC"]: Copy from the frame of the given ID or that of the PC
-LOAD [file]: Load from the given tile frame file.  Scenario 2 keeps such temporary frames conceptually separated from the standard frames by using ID's in the 1000's range, but this is not required.
-REPLACE: Temporarily replace the existing frame.  This can be useful to temporarily change an existing frame.
-NOREV: Do not automatically reverse the temporary frame.  Manual reversal can be done using DeleteFrame.

EditFrame [ID] [[options]]: Dynamically make changes to the tile frame of the given ID.  This is intended for a temporary object created with CreateFrame; changes made to a standard frame cannot be reversed without reloading.  Options include:
-MIRROR [type]: The entire frame is changed to be mirrored and/or rotated as specified by the type, which can be specified with an ID number but is clearer when done with the following token characters:
R: Right rotate
L: Left rotate
H: Horizontal mirror
V: Vertical mirror
F: Flip
-COPYSEC [SourceID] [DestX] [DestY] [SourceStartX] [SourceStartY] [SourceEndX] [SourceEndY]: "Copy section" of the given source frame and position to the given position of the destination (the destination being the frame being edited).  Put simply, this copies from another frame.
-TCOLOR [R] [G] [B]: Set the transparency color to the given RGB value.  This is used by some other options.
-TCOPY [SourceID or "PC"]: "Transparency copy" from the source frame of the given ID.  All of the source will be copied onto the frame being edited except the transparency color.
-COLOR [R] [G] [B]: Set the drawing color to the given RGB value.  This is used by some other options.
-COPYCOLOR [SourceID] [SourceX] [SourceY]: Set the drawing color from (copy the color from) the source frame of the given ID and position.  This is useful to minimize the number of places that color is defined assuming the basic layout of the source frame is unlike to change.
-PIXELS [x1 y1] ... [xN yN]: Set 1 or more positions (pixels) to the current draw color.  This is intended primarily for making minor changes to a frame such as one that was copied from another.
-REPCOLOR [R] [G] [B]: Replace all instances of the given RGB color with the current drawing color.
-COPY [SourceID]: Do a simple copy from the source frame of the given ID just like the option in CreateFrame
-LOAD [file]: Load the frame from the given file just like the option in CreateFrame

DeleteFrame [ID]: Manually delete the frame of the given ID.  Do not use on a temporary frame that is scheduled to be reversed.

PartyIterator [options]: Iterate through all party members that are alive and not off the map and so on.  To iterate through the party members means to set each in a loop one at a time as the active character.  The script target object is used to save iteration data, which is cleaned up once iteration ends.  A separate instance of this command with the -INIT option is required before the subsequent instance for actual iteration.  The later must use a line tag and the -ETAG option (to a different tag), the former so it can be referenced by a command such as a GOTO to build a loop and the later so it can end that loop.  If there is no party then the singular character is given a single iteration, the command specially designed to do so in order to avoid requiring the caller to implement separately for a singular character vs. a party when those should behave identically and would therefore be redundant.  Once iteration ends the iteration data is cleaned up, freeing up the target object, and the original active character is restored if that character is not disabled (in which case the next appropriate character is used instead).  Options include:
-INIT: "Initialize", prepare for iteration
-ETAG [TagEx]: When iteration is done then go to the given tag
-CHECKSPLIT: If the party is split then iterate only over the original active character.  Similarly to handling a singular character, this is done to avoid redundancy.
-PNAME: Show the name of each PC as they are activated
Example:
0 PartyIterator -INIT
1 PartyIterator -ETAG N2
0 CM "My name is " -PCNAME " and I have " -CURRENCY " gold." -NL
0 GOTO P1
2 M "End of PC list"

Script [name] [[options]]: Call another script by the given name.  By default this script should reside with the scenario data as script-[name].dat.  The status of the current script such as line position is entirely separate from that of the called script and so will not change while the new script runs.  A script may only call another script to a maximum number of nested calls in order to avoid errors such as doing so endlessly, the default being 8 (more than enough for even a complicated scenario such as scenario 2).  To be clear, this limit is only on current nested calls, not total calls after a called script ends and another needs to be called later.  Optionally:
-SFLAG [value]: Set the SFLAG for the called script to the given numeric value or 'C' can be used to pass the "current" value, meaning pass along the value that is set for the current script
-FN: Treat the script name as a filename which should therefore be used directly rather than constructed as per the default behavior described earlier
-GETSTATE: Get the result script state and set as the current script's state

PICMD [command]: "Plugin command", run the given command via an installed plugin made to do so.  This provides a bridge to plugin functionality.

There are a huge number of additional commands where the descriptions here still need some more work to be considered complete.  That said, actually most details have now been added to these and they should be reasonably clear, so it is just a little bit more work on them that still needs to be done (including polishing them up where needed to the level of those that are finished above, largely at this point just making sure the wording and such is consistent and clear enough given those were written quickly, adding examples where it makes sense to do so, maybe adding some text in some cases where the descriptions are a bit too implied only by the names, etc., then the rest of what needs doing in a list of tasks afterwards or via bracketed inline tasks).  In the meantime, refer to scripts in the samples subdirectory or the scenario 2 data for examples that can be used to clarify anything that is still too vague (which actually may be useful for any command, anyway).  The commands that ARE fully detailed above should also help in understanding the similar approaches that these additional commands also use.

The commands in question include:

DrawTiles [options]: Draw immediately but doesn't stick (any redraw overwrites the changes).  It is worth pointing out that using options multiple times allows drawing multiple tiles and/or drawing to multiple positions.  This command is useful for implementing visual scenes that require only temporary changes.
[ID]: Set tile to draw
-PC: Draw at the PC pos
-MPOS [x] [y]: Draw at the given map pos
-SPOS [x] [y]: Draw at the given screen pos
-TARGET: Draw at the script target pos
-NOREDRAW: Do not redraw

CheckPos [map] [x] [y] [tag]: Check PC position vs. the given position.  The map is not compared if the given value is 0.  The x or y is ignored if the given position is negative.

CCheckPos [[options]]: Complex version.  Skipping -MAP or -POS excludes it from being a condition.  Multiple uses of these prior to -TAG are treated as "OR".  This version of the command is very useful for a wide variety of purposes, but one such use is when sharing a startup script between multiple separate but related maps.
-MAP [ID]: Check the given map
-POS [x] [y]: Check the given position, ranges allowed as [StartVal]-[EndVal], use negative to skip x or y [although it appears that there is currently a bug in the use of negative so for now always specify them both]
-NOT
-TAG [tag]: Go to tag and stop processing options if all preceding conditions true, otherwise reset conditions.  Since this may stop processing options, options that relate to it must be specified beforehand (such as -NOT and the conditions).  A false causes the conditions to be reset so that additional options and uses of -TAG afterwards allow checking additional conditions.
Example:
0 CCheckPos -MAP 86 -MAP 87 -TAG 10  -MAP 90 -TAG 11
0 M "ERROR: Unsupported map"
0 BREAK
10 M "Map 86 or 86"
0 BREAK
11 M "Map 90"

CheckMoveAction [action1] ... [[actionN]]: Check most recent PC move type, multiple types are treated as "OR", prefix ! to any type for "not".  To be clear, there are a number of special factors tracked by the game for various reasons and the most recent move action is one of these.  This can be useful for a variety of purposes, but one example is if you want to display a message only when the PC enters a door from the south.
Types:
N E S W: Move from the north, east, south, or west
UP DOWN: Climbed up or down a ladder, stairs, etc.
ENTER: Entered a location
NONE: No move such as passing a turn

CAlterTiles [ID] [position] [[EndX]] [[EndY]] [[options]]: Complex version, position is [x] [y], PC, or TARGET
-OFFSET [x] [y]: Offset the position by the given amount
-OL: Include the changes in the overlay layer of the map (the current map consists of the standard base layer and an overlay layer holding the tile of any game object on top of it, the top one if multiple).  The original purpose of this was when blacking out a section of a view map with tile 0 but the overlay map was still causing tiles to appear.

ReplaceTile [OrigID] [NewID] [[StartX]] [[StartY]] [[EndX]] [[EndY]]: Find and replace all instances of a tile with another tile.  This will be done for the entire map unless limited by the optional start and/or end positions.

CheckTile [ID] [position] [tag] [[options]]: If the position contains the tile of the given ID go to the given tag, position is [x] [y], PC, or TARGET
-NOT
-XOS [value]: X offset to the position
-YOS [value]: Y offset to the position
-NB: "No border", if the position is over the border (off the edge of the map) then done processing options and set the state to incomplete
-EMPTY: If the position is not empty of game objects then done processing options and set the state to incomplete

Pos [position] [options]: Numerous possible operations related to the given position which is [x] [y], PC, or TARGET.  The default tag is 0.  Any condition that is false will stop the processing of options and any condition that is true will cause going to the tag after all options have been processed (this approach better allows for subsequent action-based options such as -MOVEPC).
-TAG [tag]: Define tag
-NOT: Reverse the final check result
-XOS [value]: X offset to position
-YOS [value]: Y offset to position
-CHECKTILE [ID]: Check if the position contains the tile of the given ID.  The CheckTile command may be very slightly more efficient but unless more options are added to it later, this option renders it a bit obsolete.
-CHECKTERRAIN [terrain]: Check if the position contains the given terrain.  The CheckPCTerrain command may be very slightly more efficient but unless more options are added to it later, this option renders it a bit obsolete.
-ALTERTILE [ID]: Alter the tile at the position to the tile of the given ID.  This option is very useful when interacting with the initial position values and/or other options but the standard full commands such as AlterTiles may be better choices under normal circumstances.
-MOVEPC: Move the PC to the position.  Use the standard Move command for more related options.
-SETTARGET: Set the script target to the position
-NB: "No border", if the position is over the border (off the edge of the map) then done processing options and set the state to incomplete
-EMPTY: If the position is not empty of game objects then done processing options and set the state to incomplete
-CHECKMAPOBJ [type] [DefID]: Check if the position on the map contains a game object of the given type and/or definition ID.  The game object type may be the standard C I L V (creature, Item, location, or vehicle) or may be 0 (zero) to mean any (making it optional).  A def may be 0 to mean any (making it optional).
-CHECKITEMCOL [value]: "Check Item collision", meaning if an item is allowed on the position.  The value is 0/1 for false/true.
-CHECKEMPTY [value]: Check if the position is empty of game objects.  The value is 0/1 for false/true.  Note that while this checks the same thing as -EMPTY, the resulting behavior is vastly different (follows the standard check behavior in this case).
-SETTARGETCREATURE: Set the script target creature to any creature on the position AND check if there is none (meaning, it will go to the tag) if a tag was explicitly defined with the -TAG option.  The default tag is ignored for this option but 0 can still be defined explicitly.  Any -TAG must be defined before using this option.

PosItem [position] [options]: Like pos but specific to item objects.  This uses a current item value that persists for the duration of the command.  The default behavior for the results of conditions is the same as for Pos, but options can be used to change it.
-TAG [tag]
-XOS [value]
-YOS [value]
-GET: Get the current item from the position if it contains an item (if multiple, the topmost)
-GETGI: "Get ground item", meaning get the current item from the position if it contains a ground item (if multiple, the topmost)
-VERIFY: Check if current item defined
-CHECKDEF [ID]: Check if current item definition ID  is the same as the given ID
-CHECKUSED: Check if the given item has ever been used by the PC.  To be clear, this is one of a variety of factors that is tracked by the game.
-GSCRIPT: Run any ground script of the current item
-STOPTRUEONLY: Stop processing options only if the result of a condition is true
-NOSTOPFALSE: Do not stop processing options if the result of a condition is false
-STOPTRUE: Stop processing options if the result of a condition is true
-CHECKMATCH [value]: Stop processing if the result of a condition is the same as the given value, which may be 0/1 for false/true

AlterPCTile [tile] [[options]]: Set the PC tile to that of the given ID or "BASE" can be used to set it to the standard base tile.  One example of use is in scenario 2 when a PC falls into water it is changed to the ID of a temp tile then later back via "BASE".  Note that there is currently no option to automatically choose the standard tile when it may have been that of a boarded vehicle (although this may be added in the future).
-SETDEF: Also set the PC creature definition's tile value, useful for changes during party iteration that cause the value to stick when this is not the desired behavior.  This was originally added when in scenario 2 there was a bug where the PC tile would appear as an empty tile after a scene with a temp tile and party iteration because the temp tile value stuck due to party iteration (it showed up as empty because it had already been deleted).

CheckCollision [type] [x] [y] [tag]: Go to the given tag if there is a collision of the given type at the given position.  Currently, the only type is "EMPTY", that meaning a collision is true if it is not empty.

CheckPCTerrainCollision [tile] [TagEx]: Go to the given tag if there is a collision of the PC with the terrain associated with the tile of the given ID

CheckPCTerrain [terrain] [tag] [[options]]: Go to the given tag if the terrain at the PC position matches the given terrain
-XOS [value]: X offset to position
-YOS [value]: Y offset to position

PlaceMapObj [type] [ID(s)]: Place on the map created but unplaced map objects.  Type currently still uses an old convention for type of being fully spelled out: "Creature", "Vehicle", "Location", or "Item" (these are very likely to eventually be changed to standard C, V, L, or I, but all similar commands that already do so actually support C*, V*, etc . to be backwards-compatible before the new convention and so this would do likewise).  This command is in many ways the opposite of RemoveMapObj and is useful if that command was used to remove but not delete a map object.  It is also useful for placing map objects that were initially defined as OFFMAP in the standard map data files.

PlaceMapItem [ID(s)] [options]: Complex PlaceMapObj for items
-POS [x] [y]: Change position to the given values

RemoveMapObj [type] [ID(s) or "CPOS"] [[options]]: Remove map objects, in many ways the opposite of PlaceMapObj.  As with related commands, type may be C, V,  L, or I.  An ID as "CPOS" can be used for the object at the current position.  ID 0 can be used for the script target creature for a creature or the script target object for an item (location and vehicle of 0 not currently supported).  This command is intended for 2 relatively distinct purposes, the first to remove a map object but not delete it so as to allow placing it again later, the second to delete it entirely.  Not deleting is the default.
-DELETE: Delete the map object entirely
-FAILOK: Do not issue an error message if an object cannot be removed, particularly useful if an object may already be gone when using a range

MoveMapObj [type] [ID] [x] [y]: Move a game object that is on the map, the object of the given ID, to the given position.  As with related commands, type may be C, V,  L, or I.

CheckCreature [[[!]]condition] [ID] [tag]: If the given condition related to the given creature is true then go to the given tag.  A prefix of ! ("not") for the condition reverses the result of the check.  This is an old version of the command; use CheckCreatureEx for new scripts.
Conditions:
(refer to CheckCreatureEx for details)
GONE
PEACEFUL
RETREAT

CheckCreatureEx [ID or "TARGET"] [conditions] [TagEx]: New version has args in a better order and supports multiple conditions.  An ID of "TARGET" may be used for the script target position and an ID of 0 may be used for the script target creature.  Each condition may use a prefix of ! for "not".
Conditions:
GONE: It is undefined, meaning if it was there it is now gone
PEACEFUL: It is peaceful in general
ENEMY: It is a PC enemy
RETREAT: It is retreating
FEARLESS: It is fearless
DEFID [ID]: Its definition ID matches the given ID
NPCID [ID]: Its NPC ID matches the given ID
TYPE [value]: Its creature definition type field matches the given value
MET: It has been met in conversation
PC: It is the/a PC

CheckCreatures [IDs] [conditions] [TagEx]: Checks applicable to multiple creatures.  "M" can be used as the range end to indicate to iterate through the max (less efficient than a lower value).  Conditions may use a prefix of ! for "not".  Any match will cause the overall result to be set to true.
Conditions:
ENEMY: Any are PC enemies
ATTACKINGPC: Any are attacking or would attack the PC
RETREAT: Any are retreating
DEFID [ID]: Any with a definition ID that matches the given ID
NPCID [ID]: Any with an NPC ID that matches the given ID
GROUP [ID]: Any with a group ID that matches the given ID
SKIPGONE: Not a condition but rather an instruction to not check any creature that is undefined, meaning if it was there it is now gone.  This must precede the other condition(s) to be skipped.

CheckMapItemEx [ID] [[[!]]condition] [tag]: If the given check type related to an item on the map (the item of the given ID) is true then go to the given tag
Conditions:
GONE: It is undefined or offmap, meaning if it was there it is now gone [the code for other commands with this option needs to be checked for offmap, or at least a task note for this needs to be added]
POS [x] [y]: it is at the given position.  Use -1 to skip either value.
DEFID [ID]: Its definition ID matches the given ID

SetCreature [ID] [[options]]: Set aspects of the given creature.  Use ID 0 for the script target creature.
-BEHAVIOR [type]: STATIC, FOLLOW, WANDER, ATTACK, HOSTILE, RETREAT, MERCHANT
-TARGET [type]: [SETENEMY also increases any ZM enemy count but none of the others do which seems incorrect and may need to be fixed, at least added as a task note to the code, maybe adjustments to that should be an entirely separate option.  Note that not considering 0 is ok because ZM would have then ended.]
PC: Target the PC/allies
NOTPC: Do not target the PC/allies
PCENEMIES: Target PC enemies
NOTPCENEMIES: Do not target PC enemies
SETALLY: Do not target the PC/allies and do target PC enemies
SETENEMY: Target the PC/allies, do not target PC enemies, and increase any zoomed combat enemy count
-GROUP [ID]: Set the group to the given ID, this value entirely optional, used only for special purposes described elsewhere
-TGROUP [ID]: Set the target group to the given ID, this value entirely optional, allows targeting a specific group
-DELAY [[[prefix]]value]: Set or adjust delay, set is the default, optional prefix "+" to increase existing value and "MIN" to set only if existing not already the value
-HP [[[+]]value]: Set HP or use the optional prefix '+' to add to the current value
-MET: Manually set as having been met in conversation

SetMapCreatures [options] [[StartPos]] [[EndPos]]: Set aspects of multiple creatures, position default full map.  Optional StartPos or EndPos are [x] [y] or "TARGET" to use the script target.  Options that change position will skip doing so for any creature that would be off of the border or on a position that is occupied.
RESETPOS: Set positions back to originals
SHIFTPOS [x] [y]: Shift positions by the given amount
BEHAVIOR-STATIC
BEHAVIOR-WANDER

SetItem [TARGET or INV [ID]] [options]: Set aspects of the given item.  Use TARGET for the script target object or INV to use the inventory item of the given ID.
-CHARGES [value or "MAX"]: Set charges to the given value or "MAX" to use the item definition maximum
-QUANTITY [value]: Set the quantity to the given value.  Do NOT use for inventory due to it not doing weight etc. adjustments.

Anger [[CURRENT]],
Anger ID [ID],
Anger DEFENDERS [[ID]]: Make creature(s) hostile.  By default or "CURRENT" is the script target creature, or given ID, or DEFENDERS with an optional ID that indicates a particular group [verify the group is what the ID indicates, don't remember for sure].

CheckCombat [ID] [tag]: Go to the given tag if the creature of the given ID is in combat.  ID 0 can be used for the script target creature.

CheckZoom [[[!]]type] [tag]: Go to the given tag if an issue type related to a zoomed map is true
ATTACKTYPE: Zoomed combat is the attack type
ACTIVE: Zoomed combat currently active

CheckZM [type] [value] [tag]: Go to the given tag if a value related to the current zoomed map matches the given value
Type:
ETerrain: Enemy terrain prior to zoomed combat
PTerrain: PC terrain prior to zoomed combat
TTile: Target tile prior to zoomed combat

InitZMEnemies [number] [[options]]: Manually set up aspects of zoomed combat enemies.  Number can be provided or COUNT to literally iterate through the creature list and count how many, the former more efficient.
-CREATURE [ID]: Also set the group creature used by some other commands by setting the script target number
-TYPECOUNT [amount]: Manually set the number of creature types

ExitZM: Manually exit a zoomed map such as after resting

CreateZMEnemies [[option]]: Manually set up zoomed map enemies.  In the options, "OMAP" means retrieve the value from the original map, meaning the one prior to entering ZM (this can also be thought of as the outer map or the exit map).  The default encounter group table is 0, the default start direction is north, and the default positions are the positions of the standard placement mechanism.  Those defaults allow -CTYPE to be the most minimal use of the command.  The generated creature type (meaning, the def ID) is set into the script target number so that it can optionally be used afterwards by other, associated commands.  If no result (creature type, meaning def ID) is generated then the state is set to incomplete.  [The use of the term "creature type" to mean "definition ID" should really be changed to the later (e.g., -CTYPE -> -CDEFID, etc.) assuming my first doing a more careful analysis of the code confirms that assertion is correct given I don't remember for sure and a light analysis wasn't quite enough to be sure.]
-EGTAB [ID or "OMAP"]: Set the encounter group table to the given value
-ETAB [ID or "OMAP"]: Use the given encounter table to generate the creature type (definition ID).  This is an alternative to -CTYPE unless the later is used in conjunction afterwards to set the default.
-TERRAIN [terrain]: Set to the given value the terrain requirement used by -ETAB, must be specified prior to that
-CTYPE [ID]: Set the creature type (definition ID) to the given value.  It will only do so IF it has not already been set in order to allow it to be used as a default if -ETAB generates no result or if another option such as -NOCDFTYPE unsets the result.  That said, to be clear that is an optional, secondary use, the primary being to use it to set the value directly rather than as a default for other options.
-DIRPOS [dir]: N E S W, set the starting position direction to the given value
-POS [x1] [y1] ... [xN] [yN]: Defined start positions
-POSDEF [tag]: An alternative to -POS, indirectly define start positions via the given Def command which must use the same args syntax as -POS.  This indirection allows for a variety of benefits such as reuse/sharing of the Def command, grouping such position definitions together, etc., at the cost of being more complex to use.
-NOCDFTYPE [value]: Disallow a creature of the given creature definition's type field by unsetting any such result, must be used AFTER it has been set to the creature def to be checked, useful after -ETAB.  -CTYPE can optionally be used afterwards to specify a default.  To be clear, this option is referring to the special type field of the definition, NOT the definition type as the definition ID; the word "type" is overloaded in the context of this option.

VerifyRE [tag] [options]: Verify aspects of the random encounter table such as to make sure a creature of a given definition ID is in it, or instead to make sure that any creatures are in it at all (encounter tables may define other game element types such as scripts or triggers).  For example more specifically with respect to the former, it could be used to make sure a goblin is included if the script intends to subsequently use a goblin.  The current encounter table is the default.  The default check is just if the random encounter table exists at all.  More specific information can be checked if other options are used.  Nothing is checked that isn't defined.  Refer to CreateZMEnemies for some related details such as defining "OMAP".
-ETAB [ID or "OMAP"]: Set the encounter table to the given value
-TYPE [type]: Set a game element type to check.  The game element types is a general category, some of which are potentially used in an RE table.
CREATURE
VEHICLE
LOCATION
ITEM
TRIGGER
SCRIPT
-ID [ID]: Set a definition ID to check
-TERRAIN [terrain]: Set a terrain type to check
-NOT

CheckExitMapBuffer [type] [value] [tag]: Go to the given tag if an aspect of the buffered exit map matches the given value.  The exit map is the map prior to entering zoomed combat and is known as the "original map" or "outer map" in some other commands.  The type may be "ETAB" (encounter table), currently the only choice, true if the random encounter table ID of the exit map matches the given value.  Currently unused for built-in scenarios and may change [not used needs to be verified, only included in case it actually IS used after all].

EnterZM [[options]]: Manually enter a zoomed map such as for an ambush encounter or the rest script.  The default definition file is 0 and the default redraw behavior is not to do so.  Overhead maps use a static ZM while first person use dynamic, but options that are exclusive to one or the other are simply ignored.
-DEFFILE [ID]: Set the scenario's static ZM definition file to that of the given ID
-ETERRAIN [terrain]: Set the enemy terrain potentially used as part of determining a static ZM
-REDRAW: Do redraw

SetZMRetreat [options]: Manually set up aspects of zoomed map retreat tracking (meaning, when the enemies aren't gone after you retreat)
-CREATURE [ID or "TARGET"]: Create and set up retreat tracking of the creature of the given definition ID including adding the group creature to the original map.  "TARGET" uses the script target number as set up by related command(s) [which command(s) to be noted, but I seem to recall at least CreateZMEnemies].

Trap [damage] [[SaveType] [DC]] [[options]]: Causes a simple trap to occur, convenient but limited version of what can be done with Damage plus optionally AbilCheck and/or Check FDTRAP (refer to those for more details).  Save throw types are F, R, W (fortitude, reflex, willpower).  [I need to check the PCMod function to make sure that isn't also applying the primary save modifier a second time in which case only it should be used and the earlier inline code that does so removed since that function at least also applies PCMB and such.]
-DEATHCONT
-FDTRAP [DC]

CreatureAbilCheck [ID] [type] [DC] [tag]: AbilCheck for a creature instead of the PC.  Use ID 0 for the script target creature.
Type:
F, R, W: Saving throws fortitude, reflex, and willpower
POWER: Power definition of the creature type such as for undead vs. turning

Flag [ID or "SFLAG"] [options]: Complex flag options including bit range use of flag.  The minimum value that can be set is always 0 but the maximum value changes depending on context (1 for a single bit, 255 for a full flag, and somewhere between for a bit range).  As with other bit-related flag commands/options, any specified bit must be from 1 to 8.  This command currently needs some work on some of the other options so not used more often yet [I seem to recall the problem is just with using multiple checks and that it works fine for everything else].  Also, some of the more simple flag-related commands may be more concise for what they can do and may be very slightly more efficient (although the difference is likely negligible).
Options:
-TAG [TagEx]: Go to the given tag if the check state is true
-CHECK [condition] [value(s)]: Set the check state to true if the flag value matches the given condition and value, for example "-CHECK == 87" would be true if the flag value were 87.
-SET [[[prefix]]value]: Set the flag to the given value.  Optional prefix of + or - causes said adjustment to the current value.  If a range has been set this will set the value into that range.
-CHECKBIT [bit] [value]: Set the check state to true if the given bit of the flag matches the given value, which may be 0 or 1.  To be clear, this is intended for a single bit and ignores any bit range.
-SETBIT [bit] [value]: Set the given bit of the flag to the given value, which may be 0 or 1.  To be clear, this is intended for a single bit and ignores any bit range.
-BRANGE [LBit] [UBit]: Specify a bit range via a lower and upper bit.  The associated value is immediately extracted from the current value and stored back into the current value so that it can be used by some subsequent options such as -CHECK.  Further, the lower and upper bits are stored so that they can be used by some subsequent options such as -SET.
-NOT
-DISPLAY: Display the value of the flag on screen as per a message command
Bit range max values:
(depends on number of bits)
1: 1
2: 3
3: 7
4: 15
5: 31
6: 63
7: 127
8: 255

SetLightSource [value]: Set the light points to the given value, meaning the internal points that are used up like a timer or counter to allow it to be light for a period of time on maps set as dark such as provided by a torch or light spell.  A value of 0 means no light is being provided while a greater value means light is provided until the points run out.  The value is not changed and an incomplete state set if the value is already equal to the given value or if the power level requirement is greater than 1 (an option to set a power level to potentially meet the requirement corresponding to an existing setting available for item definitions may be a future enhancement).

SetDarkness [type]: Change map darkness type to "DARK" or "LIGHT".  To be clear, this is the darkness state of the map itself (parallel to the map setting) and unrelated to any light source (torch, light spell, etc.), although it does consider light sources if it needs to change the current state of lighting.

CheckDarkness [tag] [[options]]: Go to the given tag if the current map darkness state is dark.  This can change from the initial map setting through script commands such as SetDarkness.  This is unrelated to any current light source, but the CheckVis command can be used if that needs to be checked.
-NOT

CheckVis [tag] [options]: Check aspects of visibility, meaning the PC able to see in the dark, facing the proper direction, etc. (not meaning the mechanism in OH for showing darkness past some barriers).  Multiple conditions must all be true, meaning they are treated as an "and".
-NOT
-NODARK: True if not currently dark
-DARK: True if currently dark
-POS [x] [y]: True if current position
-DIR [dir(s)]: N E S W, may use more than 1 as an "or", true if current FP facing
-DIRPOS [x] [y]: "Direction position", meaning facing the given position (the dir from the current pos to the given pos matches PC facing), intended for a straight line or the result may be unclear, on the given position is also considered true

SetWind [value]: Set to the given direction, only set if the map allows wind
Values:
N E S W
CALM
NONE [This one needs further research, but probably means the wind won't eventually change like it will with CALM.  The base map value is changed for some reason with a comment saying it is because it is temporary, but I don't remember what I meant by that.]
MAP: Reset to the map's definition

SetWindCount [value]: Set to the given value the timer for when there is a check that the wind direction may change, only set if the map allows wind.  [I need to do further research on a comment that says it may be necessary to use Check NOWINDMAP in advance, but I don't see off-hand nor remember why; that comment may be old and no longer true given that there is at least now code in this command checking that the map allows wind.  This research should include checking existing uses in scenario 2.]

Image [filename or "DONE"]: Control the display of an image.  The filename starts the display which persists until "DONE", this required as a second and final step in using this command even if another image is to be displayed immediately afterwards because it cleans up both the display and also allocated memory.

CheckCondition [type] [TagEx]: Go to the given tag if a PC condition is true
Types:
WOUNDED
POISONED
ASLEEP
NOMOVE
NOATTACK
DEAD

Heal [amount] [[options]]: Restore PC HP, amount following the same syntax as Damage except includes "MAX" instead of "DEATH".  A dead PC will be revived unless prevented by a preliminary check using something like CheckCondition [I need to add something like a -NORES option or at least an optional task note for the possibility].
-EXTRA: Allow > max HP
-SKIPNE: Do not display "no effect" message
-TARGET: Heal the script target creature instead
-SHOWHPM: Do not hide max HP in messages when it normally would be by default, currently just when the target is not a/the PC due to -TARGET

HealVehicle [vehicle] [amount] [[options]]: Restore vehicle HP, works like Heal, vehicle may be "PC" (only current choice), if PC but not boarded then will use any ZM vehicle, a vehicle with no HP will be processed the same as no increase
-ITAG [tag]: Tag if incomplete
-MAXP [percentage]: "Max percentage", where the max HP (HPM) is used, consider it to instead be the given percentage of it.  [I need to research if > 100 allowed, would only be to 255 at most, but the original use is for less and as I recall, the purpose to limit vehicle healing items and spells.  May need to add code to prevent >= 100 or 255 become too arbitrary (200 would be better but really that is what -EXTRA is for, so probably just the 100).  Also need at least 1 example.  Also consider and possibly document here or at least as a note in the code why this is needed for vehicles but not for standard healing, although it is mentioned as a side-note that it could be added for Heal.]
-EXTRA: Allow > max HP

SelectTarget [FailTag] [[range]] [[option]]: Interface to graphically select the script target position.  If the command doesn't complete for some reason (such as the player aborting) then it goes to the "fail tag" and the state is set to abort.  If the optional range is given it uses ranged selection, otherwise the default of directional selection.  Use the Ex version for new scripts.
NOZOOM [tag]: Go to the tag if combat on this map would result in a zoomed map.  Note the lack of a '-' prefix (this is an extremely old command so that convention was not yet established).

SelectTargetEx [options]: Improved version.  If the command doesn't complete for some reason (such as the player aborting) then it goes to the tag and the state is set to abort.  The default tag is 0 (as per BREAK).  The default FP mode, mode 0, is to select the position directly ahead.
-TAG [tag]: Set the tag used if the command doesn't complete for reasons such as the player aborting the process or as used by -NOZOOM
-RANGE [value]: Set ranged selection to the given value, not allowed for FP
-NOZOOM [tag]: Go to the tag if combat on this map would result in a zoomed map
-FPMODE [value]: When FP, mode 1 allows a selection process intended specifically for FP where either the current position or the position ahead can be selected rather than the default mode 0 of just directly ahead

RangeFX [type]: Display a ranged FX from the current position to the script target position.  For type, standard colors show as the default roundish (plus sign) graphic, lines are automatically adjusted for direction.  Types are hardwired tokens rather than RGB values because this uses an underlying system shared with other data files where this approach uses less memory and makes things more consistent (that said, a future enhancement to support custom values is possible).  All colors are pure/absolute in the numeric manner, for example red is 255 0 0 (given 255 is the max), numbers less than 255 required for some colors are even increments, etc..
Types:
(listed in order of most standard to least, works the same way in any case; this is just an organizational matter)
WHITE: Default and generic
RED, GREEN, BLUE: RGB standards, good to represent magic/special ammo (perhaps blue as a laser bolt in a sci-fi scenario)
LINEBROWN: Original reason for lines, good to represent arrows and bolts
GREY, LGREY, DGREY: Greyscale options, good to represent rock or metal
LINERED, LINEGREEN, LINEBLUE: RGB parallels for lines
LINEWHITE: Parallel default for lines
LINEGREY, LINELGREY, LINEDGREY: Greyscale parallels for lines
ORANGE, YELLOW, PURPLE, BROWN, BLACK: Unusual options for completeness and special purposes (there are no line parallels for these at this time due to dubious usefulness vs. efficiency and such).

SetAttackTargetCreature [FailTag]: Set the script target creature from the script target position, goes to the fail tag if no creature.  This uses core functionality that includes the usual additional results of an attack such as angering the target, etc..  [I need to take a look at GetPCAttackTarget and maybe also scenario 2 uses to make sure I'm remembering the core behavior correctly and no additional details need to be documented.]

DamageSelectedTarget [amount] [[options]]: Do damage to the creature at the script target position, which can be set using a command such as SelectTarget.  Amount uses [amount]d[type]+[bonus], the same as with many other commands [I need to add an optional task note to the code to implement a shared function that would also support at least some of the other syntax allowed by commands such as Heal to allow a single specific amount and such, also mentioning for any other command to which this would also apply].  If no creature is at the given position it does nothing [I should probably make it also set an incomplete state].
-EFFECT [ID]: Also do the given effect

DoEffectSelectedTarget [ID] [[options]]: Do the given effect to the creature at the script target position, which can be set using a command such as SelectTarget.  If no creature is at the given position it does nothing [I should probably make it also set an incomplete state].
-QUIET: No messages or sounds from the command infrastructure regarding attacking and such, but there may still be from the given effect itself
-CASTERMOD: Apply any PC caster modifier to the process (saving throw, duration), uses any CMTL that has optionally been defined
-CMTL [level]: "Caster modifier taper level", begin tapering off caster mod benefits at the given level, can help game balance, used by the -CASTERMOD option
-SAVEMOD [value]: Direct saving throw modifier, note will override -CASTERMOD
-DURMOD [value]: Direct duration modifier, note will override -CASTERMOD
-DTAG [TagEx]: "Done tag", go to the tag if the NPC attack results are done [I need to investigate this further as I can't remember the details]

SelectCreateAlly [terrain] [FailTag]: Selection process for a player creating an ally such as for summoning, sets the script target position.  The given terrain may be as usual or "C[ID]" where the given ID is of a creature definition.  The later syntax extracts the terrain of the given creature definition, useful in being indirect so as to avoid duplicating terrain information.  The fail tag is used if the command is incomplete such as if the player aborts, the position is blocked, etc..

CreateAlly [ID] [[options]]: Finish creating an ally from SelectCreateAlly, uses the script target position.  This is separate in order to allow for intermediate steps.
-NPC [ID]: Set the creature to the NPC of the given ID
-SETTARGET: Set as script target creature, useful for further commands related to the creature such as SetCreature
-SETHOSTILE: Useful if the creature turns out to not be an ally for whatever reason

Effect [ID] [[options]]: Do the effect of the given ID on the PC
-USER [CREATURE or TARGETPC]: Required for some effect types
CREATURE: Script target creature
TARGETPC: Target object

ScriptVal [options]: Advanced options related to various script values such as the internal script variables, special storage operations, etc..  These are not necessary for most scripts.  It uses a current object and separate current number.  The default for the current object is the script target object and for the current number is the script target number.  As with all commands that use the internal script variables, be careful with the type that is currently being held, but for this command is particularly worth noting.  For example, if the current object is holding a script target creature do not set the active character from it because those are entirely different types and only special options or commands can be used to retrieve one from the other if doing so is even possible.
-GETTARGETVAL: Get script target object into the current object
-SETTARGETVAL: Set script target object from the current object
-GETCREATUREVAL: Get script target creature into the current object
-SETCREATUREVAL: Set script target creature from the current object
-GETACHAR: Get active character into the current object
-SETACHAR: Set active character from the current object
-SETDEFO [tag] [ArgNum]: "Set definition object" (letter O, NOT number 0), store the current object into the given Def command tag and arg number.  The Def command must include a dummy value for each arg to be used, for example "100 Def 0" would allow using tag 100 arg 0.  To be clear, this is temporary; it is only stored for the duration of the script.
-GETDEFO [tag] [ArgNum]: As per -SETDEFO, but get the current object from the given Def command tag and arg number.  The value MUST have been set using -SETDEFO (this is because it is retrieving a memory address, not some value it that may be holding or that may be predefined in the Def command's arg).
-GETARRAYVAL [index]: If the current object is an array of objects then get the object at the given index.  The object from the array will replace the array of objects, but if it is needed later (such as to retrieve another array value) it can first be stored using -SETDEFO then retrieved later with -GETDEFO.  An example of use is how the "SCRIPT" power (an effect that is defined to call a script to implement a more complex effect) sets the script target object to an array of objects and this command is then required in order to retrieve any needed specific object from that.
-CREATURETOPOS: Set from the script target creature's position to the script target position
-POSTOCREATURE: Set from the script target position into the script target creature's position
-SETN [[[prefix]]value]: Set the current number to the given value, optional prefix may be + or - to instead modify the existing value
-GETNUMBERVAL: Get script target number into the current number
-SETNUMBERVAL: Set script target number from the current number
-GETAMOUNTVAL: Get script amount into the current number
-SETAMOUNTVAL: Set script amount from the current number
-SETDEFN [tag] [ArgNum] : "Set definition number", store the current number value into the given Def command tag and arg number.  This otherwise works exactly like -SETDEFO.
-GETDEFN [tag] [ArgNum]: As per -SETDEFN, but get the current number from the given Def command tag and arg number
-GETFLAG [ID]: Get the value of the given flag into the current number
-SETFLAG [ID]: Set the value of the given flag from the current number.  Because of how flags are stored, the number must be from 0-255.
-GETKEYWORD [keyword]: Get the tag of the given keyword into the current number.  An undefined keyword defaults to 0.
-SETKEYWORD [keyword]: Set the tag of the given keyword from the current number.  This can be used to leverage the keyword system to store a number and therefore isn't intended to necessarily store actual tags.  Because of how tags are stored, the number must be from 0-65535.
-CHECKN [condition] [value(s)] [TagEx]: Go to the given tag if the given condition (the standard "==", ">", etc.) is true with respect to the current number vs. the given value(s)
-DISPLAYN: Display the current number on the screen as per a message command

StartCircleIterator [position] [range]: Initialize to start this iterator, a circular pattern.  The position may be "PC" to use the current map position or "TARGET" to use the script target position.  The range is the farthest distance from the position to process  (and thus effectively the radius) and may be 1-5 [the parallel FXCircleIterator allows up to 8; I need to investigate the reason these differ, but likely just needs to be changed here to 8 and tested, not urgent however given over 5 is rare].  The script target object is used to store internal iteration data, therefore do NOT use it until the iterator is done/deallocated (unless the value is carefully moved temporarily).  It is intended for SetTargetCircleIterator and CheckTarget to be used in a subsequent loop afterwards, allowing each position to be processed.  For example, a circle iterator is used in scenario 2 for area effect spells.

SetTargetCircleIterator [tag]: Iterate, meaning to set the next script target position.  To be clear, the script target position (what is being set) is distinct from the script target object (what is being used to store internal iteration data).  StartCircleIterator must have been used previously to initialize the iterator.  Commands such as CheckTarget can be used on the resulting script target position.  Borders are automatically considered.  It will deallocate the internal iteration data held by the script target object and go to the given tag once all positions have been processed.  This means the tag should be used to move beyond the end of the loop (or as usual, 0 can be used to exit the script entirely).  Using the SetSafety command prior to the loop may be required if there are a lot of positions to process.

EndCircleIterator: Manually end the iterator, cleaning up the iteration data and freeing up the script target object.  This is ONLY needed if it is necessary for the iterator to end early since the iterator otherwise ends automatically when using SetTargetCircleIterator and all positions have been processed.

CheckTarget [TagEx] [options]: Check aspects of the script target position, original for iterators but could be used for any target and so eventually related new options more intended for other uses were added.  Checks until a result is false (allows multiple aspects to be checked), if all true go to the tag.
-CREATURE: Check a creature is at the target position
-CILOS: Check line of sight from the start position of the circle iterator (which must be active) to the target position
-PC: Check current position (PC) is the target position
-VIEW [ViewType]: Check the given view type is the same as that of the tile at the target position
-POS [x] [y]: Check the given position is the same as the target position

FXCircleIterator [position] [range] [[options]]: Do an FX using the same pattern (via the same underlying circle iterator mechanism) as the separate circle iterator commands.  This command doesn't itself actually behave as an iterator, meaning no loop is required in order to use it.  The name is just to reflect use of the same underlying mechanism.  The particular FX supported by this command is to display a tile on all the resulting positions.  The given initial position may be "PC" to use the current map position or "TARGET" to use the script target position.  Further, PC will NOT include that position whereas TARGET WILL include it.  Range may be 1-8.  The default tile is 0 therefore the -TILE option is usually necessary.
-TILE [ID]: Set the tile
-SOUND [ID]: Set the sound

FXCircleIteratorEx [position] [range] [[options]]: Advanced version, uses some different underlying mechanisms and has more flexibility.  A major difference is support for standard FX rather than just a tile.
-FXTYPE [type]: Set type of FX; there are multiple separate FX systems.  Those currently available for this option include:
0 (default): Display the given tile.  This is identical to using the standard FXCircleIterator command.
1: Standard FX for advanced functionality (differs from the far more simple and limited FX mechanism used in some other places, although it uses a similar approach and the capabilities overlap).  The separate type option indicates the specific FX (effectively a sub-type to this FX type).  The draw color used by some types defaults to white.
-TYPE [type]: Set the type used by FXType 1 (thus it is effectively a sub-type)
0 (default): None
1: Inverse using b&w
2: White circle under inverse using black
3: Box fill under using the draw color
4: X over using the draw color
5: Grid pattern over using the draw color
6: Overlay
7: Overlay reversed (under)
8: Grid pattern of overlay
-TILE [ID]: Set the tile used in some cases.  This is used by both FXTypes 0 and 1.  For FXType 1 types 6-8 this defines the tile frame to use for the overlay.
-SOUND [ID]: Set the sound
-COLOR [R G B]: Set the draw color used in some cases by FXType 1
-FTYPE [FrameType]: Set the frame type used by FXType 1, overriding what is normally used by default based on the type
0: Default of type
1: None, standard default
2: Inverse using b&w, default of type 1
3: Under inverse using black, black pass-through color, default of type 2
4: Under, black pass-through color, default of type 3

StartSLineIterator [position] [direction] [distance] [[options]]: Initialize to start this iterator, a pattern that is simply a line, otherwise works like StartCircleIterator.  Direction may be N, E, S, or W.  Distance must be a number >= 1 or "MAP" can be used to specify the map size corresponding to the direction (width or height).
-NOSTART: Skip the start position

SetTargetSLineIterator [tag]: Works like SetTargetCircleIterator but for a line iterator started with StartSLineIterator

CheckIncap [tag]: Go to the given tag if the PC is currently incapacitated (delayed or asleep) [it appears that I also need to add dead due to the party system because before with a singular character there was no reason since the game would have ended]

GiveSP [amount] [[options]]: Give spell points.  The given amount can be specified as a specific value, [percent]% for percentage of SPM, [amount]d[type]+[bonus] for randomized, or "MAX" for setting to SPM.  If the current amount is not increased then an INCOMPLETE state is set.
-EXTRA: Allow > SPM
-SHOWNE: If the current amount is not increased then display a message for "no effect"

GiveItem [ID] [[quantity]] [[options]]: Try to give the PC an item.  ID can optionally be "-REFID" to use the reference ID field of the script target object.  Note the hyphen in the previous is documented correctly, but is old syntax that may eventually be fixed so it is correctly just "REFID".  Quantity is optional and defaults to 1.  It can optionally be "-QSA" to use the script amount.  And again, the hyphen is documented correctly, but is old syntax that may eventually be fixed so that it is correctly just "QSA".
MODPRICE: Modify the quantity in the same way as a price.  The lack of a hyphen is documented correctly, but is old syntax that may eventually be fixed so that it is correctly "-MODPRICE".
-QMULT: Multiply quantity by the script amount
-TOTAL: Quantity is the total rather than additional
-SHOW: Display a message about gaining the item

TakeItem [ID] [[quantity]] [[FailTag]] [[options]]: Try to take an item from the PC.  The default quantity is 1 and the default fail tag is 0.  Use TakeItemEx for new scripts.
OFFER: Input quantity.  The lack of a hyphen is documented correctly, but is old syntax that should instead be "-OFFER".
MODPRICE: Same as GetItem
-QMULT: Same as GetItem

TakeItemEx [ID or "TARGET"] [[options]]: Improved version.  The ID can optionally be "TARGET" to use the script target object.  The default quantity is 1 and a tag will only be used if explicitly defined.
-Q [quantity]: Set quantity
-TAG [tag]: Set tag used upon failure
-SHOW: Display a message about losing the item
-MODPRICE: Modify the quantity in the same way as a price
-QMAX: Set Quantity to max
-QSA: Set quantity to script amount
-QSETSA: Set script amount to quantity
-QMULTSA: Multiply quantity by script amount

Pay [cost] [[FailTagEx]] [[options]]: Options for the PC to pay using currency, more specific and advanced than TakeItem.  The default fail tag is 0.  Some default messages are used unless specified otherwise via options.  The message options may be direct message text or alternatively indirect by referencing a Def command using "$[tag]" such as "$100" to use "100 Def [message]".  In either case, the message may for example be something like "I'm sorry, but that costs %d and you only have %d" (for -MLOW).  The cost will be modified as usual unless specified otherwise via an option such as -EXACT.
-BASIC: Basic mode, no default messages
-EXACT: Do not modify price
-QMULT: Multiple quantity (cost) by the script amount.  [I should consider renaming this to something like -CMULTSA as per "cost" and the corresponding "SA" in the TakeItemEx option, although keep the current name as an optional name for backwards compatibility.  Do the same used in PMessage and possibly also anywhere else it may potentially be used.]
-PMP [value]: Price modifier percentage
-MCREDIT [text]: Message for credit, to disable use "NONE".  "%d" can be be used to show several numbers in order as credit and cost.
-MLOW [text]: Message for not enough currency, to disable use "NONE".  "%d" can be be used to show several numbers in order as cost and total currency.
-MPARTIAL [text]: Message for partial payment, to disable use "NONE".  "%d" can be be used to show currency.
-CHECKONLY: Do not actually subtract any currency.  This can be used with the fail tag to allow preliminary verification of enough currency.

PMessage [options]: Display text related to prices, works like CMessage.  The reason for this being separate is to allow for options that are not appropriate for the implementation of CMessage.  The cost will be modified unless specified otherwise via options.
[text]: Display as such
-NL: New line
-PRICE [value]: Display price
-SELL: Use sell price
-EXACT: Do not modify price
-QMULT: Multiple quantity (cost) by the script amount
-PMP [value]: Price modifier percentage

CheckItem [ID] [quantity] [tag]: Go to the given tag if the item of the given ID is in inventory, meaning the quantity is >=.  This is was implemented before more powerful commands but may still be useful for fast and simple use.

CCheckItem [[type]] [ID] [[condition]] [target] [tag]: Complex version, allows different types of checks such as -CHARGES and conditions other than >=.  The default type is -QUANTITY.  The ID can optionally be 0 to use the script target object.  The default condition is >=.  The target arg is the comparison value that is a quantity or number of charges.
Optional type:
(This is old syntax that would have been better as standard options at the end of the args so may be changed at some point [I need to at least add a task note to do this and to also generally clean up the implementation of this command, which may be possible while preserving the existing approach for backwards compatibility or may require a new "Ex" version].)
-QUANTITY: Check quantity, the default and therefore only useful for clarity
-CHARGES: Check charges

AccumOfferItem [ID] [flag] [FailTag]: Input an amount that represents the PC offering an item such as currency then accumulate (add to) any existing value.  The given ID is that of the item in question.  The amount is stored by using 4 adjacent quest/etc. flags starting at the given flag, the multiple flags required in order to store large numbers (be very careful not to accidentally try to use those subsequent 3 flags for other purposes).  It will go to the fail tag if the input is 0/aborted or the quantity is not available in inventory.  An example is using this to track the gold offered at temples.

CheckStoredValue [flag] [condition] [target] [tag]: Check a value stored with the 4 adjacent quest/etc. flags as described for AccumOfferItem.  This means that it will go to the given tag if the given condition is true.

AdjustStoredValue [flag] [amount]: Adjust a value stored with 4 adjacent quest/etc. flags as described for AccumOfferItem.  The amount may be negative, for example to use up the benefit of gold offered at temples.

Treasure [ID]: Give the PC treasure manually.  The given ID is that of the treasure table entry as defined in the scenario data.

Move [direction] [[options]]: Move the PC in the given direction.  A standard move behaves like the player moved and is the default.  Screen locking IS supported such as for dungeon rooms.
Options:
-SIMPLE: No collision checks, no terrain delay, etc..  A border results in an incomplete state.  This mode is useful for example being swept down a river.
-NOTRIG: Don't check resulting triggers
Direction:
N, E, S, or W
BACK: Move back to previous position

Pass [[turns]]: Pass 1 or more turn(s), the default being 1

Win: Cause the scenario to be won

Look: Display an NPC's special text for look, uses the script target creature.  An NPC definition's look field will be used if defined, otherwise the creature definition field.

View [[options]]: Control the view map manually.  The default power level is 0, meaning it will not overcome any resistance to view.  Use -VIEW to start view mode and -DONE to end it.  In most cases -VERIFY should be used prior to -VIEW.  This command can be used for a variety of purposes, but just one example is as part of implementing complex spells to do a view.
-VERIFY: Go to incomplete tag if not allowed.  The -ITAG option must be used prior to this.  The most frequent reason it may not be allowed is if the current map is specifically defined to prevent it.  Further, a map may instead define a power level resistance to view rather than completely disallowing it.  If the power level defined for this command is less than the value defined for the map then the view is not allowed.  For example, in scenario 2 this mechanism is used for some areas being enchanted with various levels of resistance to scrying vs. there being more powerful view spells and items to overcome that.
-VIEW: Start view map
-ITAG [[[!]]tag]: Tag if incomplete.  Use '!' to reverse the result like -NOT used a in many other commands [!!! It appears there is a bug I need to fix for "not", as I don't see any code to actually use it, only to track it was set].
-POWER [value]: Set a power level of overcoming resistance to view
-DONE: End view map
-REDRAW: Redraw view map

Ready [ID]: Do as a Ready UI command.  If the given item unowned or not an appropriate item then does nothing.
ID:
[ID]: Item definition ID, 0 is NW
NW: "No weapon", unready weapon
NS: "No shield", unready shield
NA: "No ammo", unready ammo

Wear [ID]: Do as a Wear UI command.  ID is that of the item definition or 0 to unready.  If the given item unowned or not an appropriate item then does nothing.

Buy [ID] [[options]]: Invoke an NPC's buy interface, uses the script target creature
-BUY
-SELL

Get [[options]]: Do as a Get UI command.  The default position is the current position.  If the item can not be picked up due to max weight and such then the state is set to incomplete.  However, it is an error if the item is not at the given location.  Portable vehicles are supported as usual.  Currently limited from the Get UI command in several ways (these may be added in the future) including no item map stack support (it always takes the top item), no taking part of a quantity due to max weight, and no handling of partial charges.
-POS [x] [y]

SelectAmount [FailTag] [[prompt]]: Input a value into the internal script amount variable.  A prompt will only be displayed if that optional arg is given.  The fail tag is used if the player aborts.  0 is also considered an abort.

UseContainer [ID] [[options]]: Use the container item of the given ID like with a Use UI command
-NOTAKE: Disable the option to take an item
-ALLOWDESTROY: Allow the option to destroy an item

GiveCargo [ID] [quantity] [FailTag] [[options]]: Add the item of the given ID in the given quantity to the cargo of a selected vehicle.  The player is prompted to select the vehicle from a list of vehicles on the current map that have cargo capacity, if any.  If there is no valid vehicle, the player cancels, or the item can not be given then it will go to the fail tag.
-QMULT: Multiply quantity by script amount

SelectCargo [ID1] [tag1] ... [[IDN]] [[tagN]]: Selection process for vehicle cargo based on matching with an entry from the given list of possible items, required before using the separate SellSelectedCargo command.  Each entry must consist of an item as per the given ID, and a tag.  ID 0 is used as a special value to always match and therefore, if defined, should always be last.  The player is prompted to select the vehicle from a list of vehicles on the current map that have cargo capacity, if any.  If there is no valid vehicle or the player cancels then nothing is done.  The player is next prompted to enter an item from the cargo.  If a match between the selected item and an ID from the given list is found then the script amount is set to the quantity, the script target object to the vehicle, the script target number to the item number selected, and it goes to the respective given tag.  If the player cancels or there is no match then nothing is done (which for the later would also mean that ID 0 wasn't defined since that always matches).  Being a separate command from SellSelectedCargo provides more flexibility.

SellSelectedCargo [cost] [FailTag] [[options]]: Sell process for selected cargo, requires first using SelectCargo to set various internal script variables.  The vehicle is set to the script target object, the maximum quantity is set to the script amount, and the item number selected is set to the script target number.  The player is prompted for a quantity to sell.  If the value is invalid or the player cancels then it goes to the fail tag.  The player is next is prompted to verify.  If the player indicates not to proceed then it goes to the fail tag.  The cost is modified by default and there is a default verify prompt message.  If the command completes normally then the script target object and script target number are reset.
-EXACT: Do not modify price
-PMP [value]: Price modifier percentage
-MPROMPT [text]: Message for the verify prompt.  "%d" can be be used to show several numbers in order as base cost, quantity, and total cost.  The message may be direct message text or alternatively indirect by referencing a Def command using "$[tag]" such as "$100" to use "100 Def [message]".  [I need to fix a minor error, the comment heading for this code is wrong, maybe was not changed after a copy/paste.]

GivePCMB [category] [amount] [max]: Give the PC a morale bonus.  Refer to the game manual for more information, but basically this applies a point-based bonus to most checks and when the points run out so do the bonuses.  Only a few points are applied to each check and the amount tapers off.  The defaults are to apply 10% of the remaining points (minimum of 1) with a maximum of 5 points per use, those values designed with respect to this being a d100 system.  The former is called the "use percentage" and the later the "use max".  While the code is designed to allow values other than these defaults, actually allowing this is NYI (there are not currently any settings implemented to do so).  Anyway, the category provides a way to separate the sources of the bonus in order to limit these sources to a given max, for example one category may be drinks, another food better than mere trail rations, another watching entertainment, etc.  The category is an arbitrary ID and the amount how much to add to it up to the given max.

GivePointCM [options]: Give the PC a point counter modifier.  Refer to the game manual for more information, but basically this applies a point-based bonus to checks in a particular category and when the points run out so do the bonuses.  The group provides separate pools of these bonuses to control what does or doesn't "stack", for example one group may be considered luck magic bonuses.  "Stacking" in this context (not to be confused with stacked party members) is a common RPG term for which modifiers will add together rather than not adding together because they overlap as members of the same group.  Higher points in the same group will increase to the given amount but not add.  The use max is how many points can be used at once.  The options using the term "caster" can instead be used for purposes other than casting spells, that just happens to be their primary purpose (when this command is used as part of a spell implementation).  The default group is 0, points and use max is 1, and type is ALL.  The default for the tag, caster modifier, and caster max is undefined, which means not to use them.  Note that this command does not currently fully support a party member casting a spell on another party member (for example, -CAMOD isn't set up to handle this situation) but a subset of the options do allow an NPC in conversation to cast a spell on the current PC (for example, an NPC cleric in scenario 2 can cast Bless) [I need to add a note to the code about adding support for other party members].
-GR [ID]: Set group ID (0-65535)
-PTS [value]: Set points
-UM [value]: Set use max (1-255)
-TYPE [type]: Set type of checks
ALL
AC
AB
FORT
REF
WILL
-TAGNE [TagEx]: Set tag for "no effect" which can happen for various reasons such as already being at the given max of the category or total max
-CAMOD: Apply caster modifier, meaning the benefits are increased if the current PC (as the caster, not the target) is more powerful (such as a higher level).  To be clear, the use of the term "modifier" in "caster modifier" is unrelated to "point counter modifier".  Only use this option when the caster is the PC.
-CAMAX [value or "PC"]: "Caster max", the given value or based on the current PC's power.  This places a limit on the total points allowed on the target (the PC) which is based on the power of the caster (which may or may not be the PC).  Using a given value is useful for NPC casters.

RemovePointCM [options]: Remove from the PC 1 or all point counter modifier(s), for example to cure a penalty or to remove all beneficial enchantments.  The default behavior is to remove just 1 up to a given max points.  Currently, the max points are only used if removing 1 (optionally using this for removing all hasn't seemed necessary yet but is a potential future enhancement such as via adding a "-ALL" and using if not 0 [existing notes in the code touch on this but I need to clarify them regarding what is said here about max points]).  The default for the max points is 0, which results in no effect if removing 1 and should therefore be defined in that case.  The default for the tag is undefined, which means not to use it.
-PTS [value]: Set max points
-TAGNE [TagEx]: Go to the given tag if no effect
-NOMAX [type]: Remove all without restriction of a max, of the given type, which can be "1" for benefit or "-1" for penalty

GiveCSpells [options]: Give the PC a new known spell.  The default ID is 0 so should always be set via -ID.  The default for verification is not to do more than basic error checking, but it is often important to also check the standard requirements, which can be done via -VERIFY.  The default tag is undefined, which means not to use it.
-ID [ID]: Set spell ID
-VERIFY: Do verification that giving the spell to the PC meets all requirements
-TAG [[[!]]TagEx]: Set tag, can use '!' to reverse the result like -NOT in many other commands
-GIVE: Do give
-RESULTFLAG: Set result value into the SFLAG.  Note that most of these require first using -VERIFY.  The SFLAG can then be checked afterwards to respond accordingly.
0: Undefined
1: Given
2: Not allowed due to class
3: Already known
4: Caster not powerful enough

GiveCSpellsEx [options]: Improved version, the original purpose was for any arg other than the options to be processed as an ID which makes the syntax of adding multiple spells less cumbersome.  The default behavior should also be much more intuitive.  The default for each given ID is to both verify and give.
[ID]: Do operation(s) on given spell ID (again, the default to both verify and give)
-VERIFY: Set to verify only
-GIVE: Set to give only
-TAG [[[!]]TagEx]
-RESULTFLAG

CheckSPCost [ID] [condition] [target] [tag] [[options]]: Check the spell point cost of a given spell, meaning go to the given tag if the given condition is true.  The spell is that of the given ID and its cost is compared to the given target value.  The target value can optionally be "SP" or "SPM" rather than a direct value, the former current SP of the PC and the later SP max of the PC.
-MULT [value]: Multiply the spell cost by the given value, which may be a value of 1-255.  This is useful for increasing the SP cost for special purposes, for example in scenario 2 learning a spell from a scroll requires a minimum SPM of 3 times the SP cost (without the assistance of a spell merchant).

GivePCRes [options]: Give the PC a resistance or multiple related resistances.  [The subject of PC resistance is currently missing from the main manual and I need to add, but this is an extremely complex system (meaning, complex in terms of what it can do and all the numerous details addressed in the implementation, not the interface to using it) where resistances may be applied as points such as via spells or through items that are currently in inventory.  The former works a lot like the point counter modifiers but is an entirely separate system due to a variety of differences.  The later is entirely separate from the much more simple and limited original item resistances system, although includes the same capabilities and works similarly in some ways such as the item working automatically when in inventory (the original system remains available given it is the more optimal choice for simple uses).  To be clear, a PC resistance provides an additional protection above and beyond any standard check such as a saving throw; it is NOT a modifier to any existing check.  It may be defined as an absolute immunity or as a potential resistance with a percentage roll.  It is most often temporary, each use causing points to be subtracted and only lasting as long as points remain (just like with PC morale and point counter modifiers).  It has some similarities to the NPC resistance system but differs in many ways and so is entirely separate.  Just as with point counter modifiers, a PC may have multiple resistances at once although similar ones may not stack based on any given tracking ID (much the same as with point counter modifiers and their groups, although slightly different with respect to some technical details).  A spell or other such method of application may apply a set of related resistances at once, for example one of the powerful spells of resistance to fire/heat in scenario 2 creates multiple related resistances including dragon's fire, lava, greater fire, lesser fire, and heat.  As with PC morale and point counter modifiers, current PC resistances can be displayed with the detailed stats (control-Z).  These resistances do NOT currently count against the total limit that can be set for applying new point counter modifiers (such as the enchantment limit for casters).  That said, this may be changed in the future so they ARE included.  Further, the caster max option for this command (-CAMAX) provides a separate limit that is effectively a resistance-specific enchantment limit (meaning, it is the same concept but separate).  An example of use for spells is listed later.  An example of use for items is in scenario 2 the mechanism is used to implement some magic amulets that provide resistance to lava/fire/heat.  A large part of the reason why this feature has not yet been documented is that it is technically still under construction in that some details are still not yet decided for certain (such as the afore-mentioned inclusion in the standard enchantment total, potential changes to resolve some current limitations, always applying 1 point when no pool, etc.).  That said, the system has been tested and used in its current state for quite a while now (as of this text) and so will probably remain as it is for the most part.  A note to myself:  In doing some significant research to correctly document this command, I completely reviewed the main usage function, completely reviewed the extremely useful header comments in script-spell-27 (the unstripped version of course) along with the actual code, completely reviewed the script command implementation including the header comments, and reviewed a few of the lower level components of the implementation (such as GetTotalPointPower and CheckPCResMax).]  This command is only for adding points such as from a spell; resistances from items being in inventory are defined separately as part of the respective item definitions (one of the many things in objdefs.dat).  The former is called a point definition, the later an item definition.  There is also another type called a pool definition, which is discussed later.  Each point definition entry provides a resistance ID as defined in data for the current scenario (in effects.dat), a percentage chance to resist (with 100 not only always successful but also a special value in that no roll is even made, making it an absolute immunity), and either the points available if no pool is being used or the points to use if a pool is being used (the points field having different meanings depending on the context).  As for the afore-mentioned pool, points available can alternatively be mapped to a pool of points using the -POOL option.  If no pool is used then 1 point is used.  The number of points used is variable when using a pool in order to allow distinguishing between differing levels of power multiple pool users may have, meaning a given user that is more powerful may use up more of the points than one that is weaker.  In this context, "pool user" means a resistance entry that uses a pool of points (NOT meaning the caster, the player, etc.).  There are currently some limitations in the system that require using this command carefully in order to prevent incorrect behavior.  One of these is how the command determines which of a set of multiple related entries should potentially be replaced by another set applied later.  More than one version of the same set (such as a lesser or greater version of a spell) can lead to incorrect behavior regarding any caster max, total points, and replacement, so using a tracking ID, and doing so properly, to keep them clear is very important (for example, in scenario 2 all versions of a heat/fire/lava resistance spell use ID 1 and all of cold use 2).  Further, there is an additional issue having to do with the order of multiple definitions that is explained with the -DEF option (basically, the most powerful must be defined first).  Note that the afore-mentioned issues are with respect to point definition entries as applied via this command; these are NOT issues for items.  An example of use is in scenario 2 there are a series of resistance spells that rely on this command.  These include differing levels of power for different types of heat, fire, and/or lava, and for different types of cold.
-POOL [points]: Add a pool of the given points that can then be shared between any multiple point definition entries. More specifically, this will create a pool definition entry that is mapped to all subsequent uses of -DEF.
-DEF [RID] [chance] [points]: Add a point definition entry with the given resistance ID, percentage chance of success, and points.  Refer to the main text of the command for details about these values.  When used multiple times in the same command, always define the more powerful one first so that applying another later will be correct in when and how it may replace any existing ones (this is due to a complication and limitation of the implementation having to do with how it determines which resistance is more powerful and thus should take precedence).
-TAGNE [TagEx]: Go to the given tag if no effect
-CAMOD: This works like in GivePointCM.  It may increase the number of points available.
-CAMAX [value or "PC"]: This works like in GivePointCM.  That said, note that it is currently entirely separate separate from the PCM max (as discussed earlier in the main text of the command).
-TRID [ID]: Set the tracking ID.  Much as with point counter modifier groups (refer to GivePointCM), this controls what stacks, grouping together and separating different types of resistances, and the ID itself is arbitrary (other than needing to be unique between what should be separate, of course).  That said, it differs slightly with respect to some technical details such as that in this context it actually prevents queuing up multiple resistance records rather than preventing stacking bonuses together in a single roll.  It allows properly grouping related entries for being removed, potentially being replaced, potentially being weaker so not being applied, counting points for any caster max, etc..  As noted earlier in the main text of the command, it can be very important in order to prevent incorrect behavior when using multiple related entries.
For example:
0 GivePCRes -CAMOD -CAMAX PC -TRID 1 -POOL 30 -DEF 1000 50 5 -DEF 31 75 4 -DEF 6 95 3 -DEF 5 100 2 -DEF 3 100 1 -TAGNE 10
The preceding gives / notes:
- A shared pool of 100 points
- Heat: ID 3, total immunity (100), uses 1 point
- Small fire: ID 5, total immunity (100), uses 2 points
- Large fire: ID 6, 95% chance, uses 3 points
- Lava: ID 31, 75% chance, uses 4 points
- Dragon fire: ID 1000, 50% chance, uses 5 points
- Points available may actually be higher due to caster power as per -CAMOD or may actually be lower (or even the entire command have no effect) due to total points as per -CAMAX
- Note that the entries are added in the order of the most powerful to the least powerful

PCRes [options]: General options for PC resistance.  Refer to GivePCRes for related details.
-REMOVEDEFS: Remove all definitions; all entries are removed
-TAGNE [TagEx]: Go to the given tag if no effect

Give [type] [amount] [[options]]: General options related to giving something.  Note that while the amount may be negative, this may not work correctly for all types.  [Assuming not already there, I need to add a note to the code of Set to remember Give when adding a new option; I've been thinking just in terms of the Set and Check pair and forgetting this command.  That said, also mention that anything that is more towards having a direct value set is probably best to be in Set even if there is increment/decrement included, this so all of a given type is kept together, making Set a sort of baseline command and Give just for pure increment/decrement as per its existing options.  Note that I looked through the existing options in Set to make sure what is currently there doesn't need to be moved here, but those were all correct to be there.]
XP: XP increase.  The amount must be positive (negative values may potentially allow decreasing the value but this is currently untested and unsupported, plus no reversal of levels is implemented so it would be simply make it more difficult to reach the next level [I need to add a note to the code about potentially at least officially supporting negative without reversing levels but until then issue an error for amount < 1, plus 0 should be an error anyway]).  Optionally:
-SHOW: Display a message about the change
REP: Reputation score increase or decrease (current map).  Note that built-in reputation modifiers check the map for any NOREPGROUP, but this is not done here [I need to add a comment to the code to consider, maybe as a -CHECKNOREPGROUP option or whatever, or as the default but with a -ABSOLUTE option or whatever, in both cases the purpose to still allow the overriding it always does now].  [I need to document how reputation is specifically implemented in some common location for scenario design (the existing main manual explanation for players wouldn't be the correct place), but for now will do so here.  The built-in modifiers are: -1 for ownership vs. Board, Get, Use, or Unlock, and for Steal (although that command currently disabled), and -100 vs. attacking a friendly target.  Reputation is usually checked manually using scripting, but one built-in place is for Talk where < 0 results in being ignored unless the NPC uses NOCHECKREP.  There is a single reputation score so applies equally to a singular PC or all members of a party.  That said, the value may be differ on different maps.]  [While researching, I discovered a minor naming issue found in IncReputation, pAmount -> nAmount and need to fix when I get a chance to work on the code.]
STR, AGI, STA, INT, WIS, CHA: Ability score increase [it appears I DID also implement to also allow a decrease, but I need to test this to be sure and if it doesn't work then for now at least add a note to potentially fix/implement and an error for amount < 1].  Note that these ARE applied fully in that included are any adjustments to downstream values such as attack bonus and such.  [I need to either test 0 or make it an error.]

Check [type] [condition] [target] [TagEx] [[additional args]]: Numerous general options for checking something
GENDER: PC gender of the gIven D as defined for the scenario
RACE: PC race of the given ID as defined for the scenario
CLASS: PC class of the given ID as defined for the scenario
XP: PC XP
LEVEL: PC level
REP: PC/party reputation score on the current map
CREDIT: Monetary credit with the script target creature
DIR: PC direction (for FP).  Use numeric.
ZMDIR: Zoomed map direction, meaning the direction prior to entering.  Use numeric.
FP: 0 false 1 true regarding the map being first person
NOWINDMAP:  0 false 1 true regarding the map not ever having wind (inside and such).  To be clear, this is NOT the same as becalmed.
SAVE: 0 false 1 true regarding the map allowing saving the game
ENCTAB: ID of random encounter table.  0 means none.
TILEDEFINED with [ID]:  0 false 1 true regarding the tile being defined, given via ID in an additional arg
SP: PC spell points
FEATURE-PARTY:  0 false 1 true regarding the party system being activated (now always true so no longer a necessary check type for new scripts)
FDTRAP: Do a find/disarm trap check for the PC.  Unskilled automatically fails.  Criticals are included, hit via an extremely high value.
SKILLVAL with [ID]: The PC skill value of the ID given via an additional arg, no check but rather just the skill value itself, useful to check if the PC has the skill
DIST with [StartX] [StartY] [EndX] [EndY]: Distance from start to end, positions given via additional args, starts may optionally be "PC", ends may optionally be "TARGET"
[Some commands beyond this point still need some additional basic detailing]

CheckVehicle [vehicle] [conditions/options] [tag]: Check aspects of a vehicle, conditions and options may be mixed in terms of arg order, conditions may use a prefix of '!', it will stop and go to the tag if any condition is true
Vehicle:
PC
CURRENT: Script target object
CPOS: From current position
Conditions:
NONE: No vehicle
VTYPE [type]: Type as defined for the vehicle in the scenario data
HASHP: Vehicle uses HP (some do not in scenario 2 and all do not in simple scenarios such as 1 and 3)
HP [[[%]]amount]: Vehicle has >= the given current HP, if optional prefix '%' then a percentage
DEFID [ID]: The given definition ID as per the scenario data
Options:
-FORCEBOARD: The PC boards the vehicle
-INCZM: If no vehicle then try the zoomed map vehicle (any vehicle prior to entering the zoomed map)

CheckScriptType [type] [tag] [[options]]: Many script uses (for example, a conversation, trigger, start script, etc.) define this by setting a type that this command can then subsequently check, which can be useful for sharing a script where the type causes different behavior.  For example, a start script vs. an exit script.
Types:
CONV: Conversation
TRIGGER
START
EXIT
USE
LOOK
RENC: Random encounter
POWER
NONE: Undefined
Options:
-NOT

CheckMapLoadType [type] [tag]: When a map is loaded the reason why is sometimes set (NONE if not set or else STARTGAME or LOADGAME).  Some scripts need to behave differently depending on this.  This command checks that information.

CheckTriggerDone [ID] [tag] [[options]]: Check if the given trigger has been set to done
-NOT

RemoveTrigger [position]: Remove the given trigger.  The position may be [x] [y] or "PC".

SetTrigger [ID] [type] [value]: Set an aspect of a given trigger.  The only type currently supported is "DONE", which may be set to 0 or 1.

CheckTriggers: Process triggers for the current position (as if the PC had just moved), including base map (tile) triggers, map object triggers, and positional triggers, not just the later

PlaceTriggers [ID] [X] [Y] [[EndX]] [[EndY]]: Place a trigger at the given position(s)

Trigger [ID]: Run a given trigger

Set [type] [value] [[options]]: Numerous options for setting various values, very similar and parallel to Check in some ways
-PCDELAY: Set to value
-PCDELAY+: Add to any existing
-PCDELAYMIN: Set if not at least
-SAVEBMAP: Set saving of the base map on/off (1/0), default off, useful if the base map is permanently altered (alternative to redo each time the map loads via start script or trigger) particularly in multiple ways, however won't work for templated maps
-ENEMIESC+: Increase zoomed map count of enemies
-PCHP: Set HP to the given value without any additional behaviors except the minimum such as sidebar display, useful for development/cheat scripts
-PCSPM: Set SP max to the given value without any additional behaviors except the minimum such as sidebar display (for threshold), useful for development/cheat scripts
-SAVE: Set saving the game on the current map on/off (1/0)
-ENCTAB: Encounter table for the map, won't take effect until the next load, useful for increasing map difficulty
-EGTABLE: Encounter group table for the map, won't take effect until the next load, useful for increasing map difficulty
-ZMSTARTSCRIPT: As per the map file setting, useful in a start script that is used to configure generic map files referenced by multiple maps (such as a dungeon with many levels)
-DRAWPC: Set doing so off/on (0/1), useful when displaying a view map for special purposes
-PCSP: PC SP, allows prefixes to the value (yes, the standard value arg) of +, -, and S.  The former 2 modify the existing value or are otherwise absolute.  The syntax S[ID] gets the value from the given spell's cost, useful if subtracting SP.  Optionally:
   -MULT [amount]: Multiply the cost by the given amount
-NOEXITMAPISC: Do not do the normal operation on the map to exit to of the item security checking, useful if there was a map transition for special purposes such as displaying a view map of another map from the one the PC is still supposedly on (without this, items on the ground may disappear)

SetRedraw [value] [[options]]: Set the redraw behavior as given, use 0 or 1, useful to prevent excessive redraws for example when there are multiple calls to AlterTiles, MakeMapObj, etc. since each such command will provoke a redraw
-SETNEED: Also set the need for a redraw to the same value, not typically necessary

NeedRedraw [[value]]: Indicate manually that a redraw is needed, default is 1, optional value also allows for 0.  This is only needed for special purposes since most commands that require a redraw will do this automatically.

SetView [position]: Change the view position, which is NOT actually required to correspond to the PC position.  This can be useful for showing a scene that is not centered on the PC.  Note if screen locking is on it will be turned off.
Position:
[x] [y]: Given position and enables non-PC view mode
PC: Current position and enables PC view (standard) mode, effectively a reset back to normal

TurnResults [[options]]: Explicitly do checks related to those normally done automatically at the end of a turn, useful when a script must resolve these at an earlier time
-WIN
-DEATH

Util [options]: "Utility" options, numerous general options that are better being here rather than being numerous separate commands
-TRIGGERLIST [ID]: Set and load the trigger list of the given ID as with the map file setting, useful in a start script that is used to configure generic map files referenced by multiple maps (such as a dungeon with many levels)
-ENCTABLE [ID]: Set and load the random encounter table of the given ID as with the map file setting, useful in the same way as -TRIGGERLIST
-SETGROUPRETREAT: Set up creature group retreat based on the current creature list such as when setting up an ambush encounter, intended for single use at the beginning and thus for the sake of efficiency stops at the first gap in the list.  This is normally done automatically for zoomed combat but that happens too early if creatures are added later.
-SETBORDERTILE [border] [tile]: As in the parallel setting in mapset.dat.  The border is N for north, NE for northeast, etc..  The tile is the ID as defined for the scenario data tileset.  Useful for many purposes, but the original was to modify a map temporarily for displaying as a special view map.
-SETAMOUNT [value]: Set script amount to the given value
-EXITVEHICLE: Force exit of any vehicle
-SETDISPPOS [pos]: Set display position as given, the possible value currently only "PC" [need to explain when useful, perhaps by example of original use, but generally would have to be when the position has been explicitly moved by special commands, different from "SetView PC" in the underlying functions used so need to also explain that, although one additional difference is no change to PC view mode]

CreateTile [ID] [[options]]: Like CreateFrame but for a tile.  The default number of frames is 1.
-COPY [ID]: Copy from an existing tile of the given ID
-FCOUNT [value]: Set number of frames
-FRAME [frame] [ID]: Set given ID for given frame position
-NAME [value]: Set name
-VIEW [ViewType]: Set view type
-TERRAIN [terrain]: Set terrain
-GID [value]: Set game ID to given numeric value
-REPLACE
-NOREV

DeleteTile [ID]: Like DeleteFrame but for a tile

CreateSound [ID] [[options]]: Like CreateFrame but creates a sound for the sound set
-LOAD [filename]: Load from the given file
-REPLACE
-NOREV

DeleteSound [ID]: Like DeleteFrame but for a sound

CreateCreatureDef [ID] [[options]]: Like CreateFrame but creates a creature definition like those in objdefs.dat.  For such definitions requires a free ID (for example, scenario 2 reserves ID 1-9 for this purpose).
-COPY [ID]: Copy from an existing creature definition of the given ID
-NAME [value]: Set name
-TILE [ID]: Set tile
-VTILE [ID]: Set vector (FP) tile
-TCAP [terrain]: Set terrain capability
-AI [value]: Set behavior.  Note that this is use of the correct, long-standing meaning of "AI" and has absolutely nothing whatsoever to do with the marketing term being used in recent years [that said, I have been thinking about at some point renaming this option to "-BEHAVIOR", anyway].
INACTIVE
STATIC
HOSTILE
FOLLOW
WANDER
RETREAT
ENRAGED
ATTACK
CORNERED
MERCHANT
-HP [value]: Set HP (max and starting)
-AC [value]: Set AC
-AB [value]: Set attack bonus
-DAMAGE [value]: Set damage as per the standard syntax [amount]d[type]+[bonus]
-XP [value]: Set XP for defeating
-TREASURE [ID]: Set treasure to the given ID as per the scenario treasure table
-SAVE [R] [F] [W]: Set saves reflex, fortitude, and will
-RESISTANCE [ID]: Set resistance to the given ID as per the scenario resistance table
-AREFFECT [ID]: Set attack result to the given ID as per the scenario effects table
-RANGE [value]: Set range
-RANGEFX [ID]: Set range to the given ID as per the scenario effects table [verify this is the same as other uses and, if so, the code needs to be changed to use the respective tokens rather than the old approach of the direct numbers]
-ADELAY [value]: Set attack delay
-FEARLESS: Set as fearless
-TYPE [value]: Set general type field
-PLEVEL [value]: Set power level (for example, can be used to define undead resistance to turning)
-EPOWER [ID]: Set effect power to the given ID as per the scenario effects table
-KILLSCRIPT [ID]: Set to run the script of the given ID when killed
-EGROUP [ID]: Set encounter group to the given ID as per the map encounter group table
-TEMPDEF: Set to make all new creatures created with this as a temporary definition
-REPLACE
-NOREV
-NOREPUPDATE: Do not try to update replaced creatures for changes such as HP
-APPLY

DeleteCreatureDef [ID]: Like DeleteFrame but for a creature definition

ApplyCreatureTempDefs: Apply temporary creatures separately from the options built into the create commands, useful so this is only done once after creating multiple temporary definitions (otherwise processes the entire creature list multiple times and is therefore less efficient)

CreateNPCDef [ID] [[options]]: Like CreateCreatureDef but creates an NPC definition
-COPY [ID]: Copy from an existing NPC definition of the given ID
-NAME [value]: Set name
-LOOK [text]: Set look text
-SCONV [text]: Set simple conv text
-CCOMV [ID]: Set complex conv ID
-STORE [ID]: Set store ID
-AI [value]: Same as for CreateCreatureDef
-ANCHOR [value]: Set anchor distance
-NOCHECKREP: Set as no associated reputation checks
-COMBATTALK: Set as allowing Talk even when in combat (default is not allowed)
-NOCOMBAT: Set as can't be attacked
-HIDENAME: Set as do not show NPC name until met
-NOSETMET: Set as do not automatically set as met during conv
-REPLACE
-NOREV
-APPLY

DeleteNPCDef [ID]: Like DeleteFrame but for an NPC definition

CreateVFrame [ID] [[options]]: Similar to CreateFrame but for a vector frame.  The default entity count is 1.
-COPY [ID]: Copy from an existing frame of the given ID
-ECOUNT [value]: Set entity count
-LOAD [filename]: Load from the given file.  It is almost always easier just to define it using other options but there may rarely be times this approach is needed, easier, or useful.  An example of a useful case is testing a frame that will afterwards be integrated as a standard frame using the same VFSET.dat syntax.  [Need to explain this special file, but uses the same as VFSET.dat syntax except only handles a single frame so that initial syntax may diverge, need to check and then document that.]
-REPLACE
-NOREV

EditVFrame [ID] [[options]]: Similar to EditFrame but for a vector frame.  This uses not only a current frame as usual but also a current image, the later because vector frames can reference a raster image via what would normally be an overhead tile frame in that they are loaded from *.til files.  The default colors are black (0 0 0), the default image number is 1 (although not actually loaded until needed for a related option), and transparency is on by default.  [A better default draw color would be white (255 255 255).  Also need to check this issue for the OH version.]
-COLOR [R] [G] [B]: Set draw color to the given RGB value
-TCOLOR [R] [G] [B]: Set transparency color to the given RGB value, default pure black (0 0 0)
-REPCOLOR [R] [G] [B]: Replace given RGB color in the current frame with the draw color
-GETIMAGE [pos]: Get current image from the given frame position
-ILOAD [filename]: "Image load", load the current image from the given file
-REPICOLOR [R] [G] [B]: Replace given RGB color in the current image with the draw color
-ADJICOLORS [type] [R] [G] [B]: This powerful option adjusts ALL colors in the current image in a manner like the parallel UI command in the separate editor program.  Unlike usual, each color value in this option due to being a modifier is allowed to be a floating point number.  Negative values are allowed.  Types include A for "add" and M for "multiply", meaning how to apply the given adjustment colors.  Transparency will be used if it is set on.  The min color will be used if set to anything other than pure black (0 0 0).  Experimenting with the command (such as in a test script) is the best way to find the desired values.  Scenario 2 uses this option to create special wall tiles for locations such as the arctic.  [Further information to be checked and then documented.]
-SETIGREY: Set the current image to greyscale.  [Detailed information and an example of use to be checked and then documented, I seem to recall this was for an experiment in arctic dungeon wall construction but did not end up actually being used by scenario 2.]
-TRANSP [0 or 1]: Turn transparency off or on, default on
-SETMINCOLOR [R] [G] [B]: Set this RGB color that is used by options such as ADJICOLORS, default pure black (0  0 0)
-FRAME [ID]: Add a frame reference entity as per the usual vector syntax.  Could instead have been called "-EFRAME" to be more consistent with the names of other such options.
-ELINE [x1] [y1] [x2] [y2]: Add a line entity as per the usual vector syntax
-ECOLOR [R] [G] [B]: Add a color entity as per the usual vector syntax
-EREV [x1] [y1] [x2] [y2]: Add a reverse entity as per the usual vector syntax
-EBOX [x1] [y1] [x2] [y2]: Add a box entity as per the usual vector syntax
-EVFILL [x1] [y1] [x2] [y2]: Add a vertical fill entity as per the usual vector syntax
-EHFILL [x1] [y1] [x2] [y2]: Add a horizontal fill entity as per the usual vector syntax

DeleteVFrame [ID]: Like DeleteFrame but for a vector frame

CreateVTile [ID] [[options]]: Similar to CreateTile but for a vector frame.  The default frame position count is 1 and the default frame count is 1.
-COPY [ID]: Copy from an existing frame of the given ID
-FPCOUNT [value]: Set frame position count
-FCOUNT [value]: Set frame count
-FRAME [PosNum] [FrameNum] [FrameID]: Set the frame of the given ID for the given position number and frame number
-FRAMES [PosNum] [FrameID1] ... [FrameIDN]: Set all frames of the given position using an option that is less cumbersome for doing so than -FRAME.  If the args are ended early before the number of frames then the last given ID is repeated for the rest.  [Appears need to fix handling if NEVER given due to what would be FrameID1 as '-' by simply init'ing ID to 0, checking number of args gets one issue but wouldn't catch that, right now appears would repeat a garbage value.]
-NAME [value]: Set name
-VIEW [ViewType]: Set view type
-TERRAIN [terrain]: Set terrain
-GID [value]: Set game ID to given numeric value
-CONARRAY [size]: Initialize condition array to given size, any existing (such as from -COPY) will be deleted
-CONDF [type]: Set condition default [I need to detail how this is used / what these mean]
EMPTY
POS
-CONDIR [number] [pos] [Dir1] ... [[DirN]]: Set condition direction(s) for the given condition number and position number.  Directions are N E S W.
-REPLACE
-NOREV

DeleteVTile [ID]: Like DeleteFrame but for a vector tile

SwapCreatureID [ID1] [ID2]: Swap 2 creature ID's, useful for processing them in the creature list in the reverse order

RunCommands [options]: This command runs other commands identified by line tag, the main purpose being to avoid redundancy.  There is only one type of option:
[tag]: Run the command on the line of the given tag

RunTemplateCommands [options]: A complicated, advanced version of RunCommands, this one adding features such as replacement values that work much like variables and the commands therefore acting as a type of template, and a variety of special options.   The default count per set of args is 1.  The original purpose was in implementing a spell merchant for scenario 2 in order to avoid extreme redundancy.
Options:
-SETCOMMAND [tag]: Set the current command to that of the given tag
-ARGS [count] [[value(s)]]: Set count per set of args to use for replacements then the values themselves, which provokes the command to run for each value (or set thereof) given
-COMMAND [tag] [[value(s)]]: Run the command of the given tag with respect to the selected value (or set thereof) such as selected with -PROMPT
-PROMPT [text]: Display the given text then input a value that is then used to select the respective arg (or set thereof)
-GETARGCOMMAND: Only needed for special purposes (not part of the primary usage), this allows leveraging the command by using the script target object for the args and the script target number for the position of the first replacement arg.  One way this can be done is with the InventorySelect command's -SETARGCOMMAND option.  Refer to the later for further details.
Replacement value tokens:
$COUNT: A counter that can be used to build a menu for use with -PROMPT
$ARG[[number]]: The arg number within the set, so for only 1 arg per set is "$ARG1" (note that this can also be shortened to just "$ARG")
Example:
(Allow selecting spell ID's 86, 87, or 90)
0 RunTemplateCommands -SETCOMMAND 21  -ARGS 1 86 87 90  -PROMPT "Which? " -COMMAND 22
0 BREAK
21 CM $COUNT ": " -SPELLNAME $ARG " (" -SPCOST $ARG " SP)" -NL
22 CM "You have selected: " -SPELLNAME $ARG -NL

InventorySelect [options]: A command similar to RunTemplateCommands but that is very specific to interacting with inventory selection.  As with that command, the default count per set of args is 1.  This command uses the concept of flexible fields, the default "ID" first and only, change via -FIELDS.  As with RunTemplateCommands, the original purpose was in implementing a spell merchant for scenario 2 in order to avoid extreme redundancy, but in this case dealing with scroll items rather than directly learning spells.
Options:
-FIELDS [field1] ... [[fieldN]]: Define fields and their order.  The order defines "ARG1", "ARG2", etc..  The fields may be:
   ID: Item ID
   PRICE: Price, adjusted, sell price by default
   QUANTITY: Quantity for sell or buy
   TAG: Tag to use for some operations such as the -GOTOTAG option
-ITAG [tag]: "Incomplete tag"
-BUYPRICE: Set prices based on buying rather than selling
-MENU [format] [prompt] [fields]: Display a sell or buy menu with each entry based on the given text format, display the given prompt, and input the corresponding choice from the player, that choice required for some options that can therefore be used subsequently.  The fields are sets of values that will follow the order defined by -FIELDS.
   Replacement values:
   $ITEM
   $PRICE
   $QUANTITY
-SELL: Sell the selected item, first requires selection via an option such as -MENU
-SETARGCOMMAND: This sets up for subsequent use of the RunTemplateCommand's -GETARGCOMMAND option by setting the script target object to the args and script target number to the position of the first replacement arg.  This first requires selection via an option such as -MENU.
-GOTOTAG: Go to the tag of the selected item, first requires selection via an option such as -MENU
Example:
(Allow selling item ID's 87, 91, or 92)
0 InventorySelect -ITAG 10  -FIELDS ID PRICE  -MENU "$ITEM for $PRICE" "Which? "  87 100  91 100  92 200  -SELL
0 M "Sold!"
10 BREAK
Example:
(Allow selecting an item with a buy cost and associated spell as an example of using -SETARGCOMMAND and then RunTemplateCommands with the -GETARGCOMMAND option)
0 InventorySelect -ITAG 10   -FIELDS ID PRICE SPELLID  -BUYPRICE  -MENU "$ITEM for $PRICE" "Which? "  72 100 86 100  73 100 87  76 200 90  -SETARGCOMMAND
0 RunTemplateCommands -GETARGCOMMAND -COMMAND 20 -COMMAND 21
0 BREAK
20 M "Selection cost: $ARG2"
21 CM "Selection associated spell: " -SPELLNAME $ARG3 -CM

Party [options]: Numerous options related to a party.  Many but not all options are built upon the use of a current character, which defaults to none and only persists for the duration of the current instance of the command.  A starting character number is also used similarly although only rarely.  It defaults to 1.  Options that require a party will check that there is a party before continuing but sometimes it is more efficient or necessary to check explicitly with an option like -STOPNONE or -CHECK.  Some check options automatically stop processing options after if and when the result leads to setting a tag (those for which it made sense to do so for the intended use).  Options that do so are noted as such and those that are not do not.  Option that use the starting character number, a character value arg, etc. are referring to the position within the party.  [As of the time of this writing, the party system was added very recently and as a result this command may end up needing additional options or even slight changes to some existing options (although in which case I'll try to keep things backwards compatible as much as possible and certainly clearly document if something is not; refer to the earlier topic "API evolution").]
-STOPNONE: If there is no party then do not continue processing options
-CHECK [[[!]]TagEx]: Check if there is a party
-CHECKSAVESPC [ID] [TagEx]: Check the creature of the given ID has associated PC data that is saved with a save game, usually meaning it was previously a party member.  ID 0 can be used to indicate the script target creature.
-CHECKSPLIT [[[!]]TagEx]: Check party is split, "STOP" instead of a tag will stop processing options
-CHECKID [ID] [TagEx]: Check PC of the given ID in the party and not disabled in terms of being able to at least converse and such (not dead, asleep, etc.)
-CHECKPC [[[!]]TagEx]: Check current PC is set, useful for after other options that may not set it in particular circumstances, always stops processing options after setting the tag
-CHECKISACHAR [TagEx]: Check current PC is the active character, always stops processing options after setting the tag
-CHECKPCDEAD [TagEx]: Check current PC is dead, always stops processing options after setting the tag
-CHECKITEM [ID] [quantity] [[[!]]TagEx]: Checks for the item of the given ID at >= the given quantity between all party members, always stops processing options after setting the tag
-CHECKCREATUREISACHAR [TagEx]: Check script target creature is the active character, always stops processing options after setting the tag
-GETPPC: Set the current PC to the first party member found that qualifies as the primary PC [characteristics to identify as such to be detailed, but basically the one you created rather than one that joined, which I seem to recall is a matter of if it has an ID of 0]
-GETTARGETPOSPC: Set the current PC to any PC at the script target position
-GETCLASSPC [class]: Set the current PC to the first party member found with the class of the given ID as defined for the scenario
-GETPCTYPE [type]: Set the current PC to the first party member found with the given type.  The only type at this point is "DEAD".
-GETSKILLPC [ID]: Set the current PC to the first party member found with the skill of the given ID
-SETACHAR: Set the active character to any current character.  Note that this does NOT set up any related factors such as current position and so on.
-GETACHAR: Set the current character to the active character
-GETOACHAR: Set the current character to the original active character, meaning the one before any splitting of the party.  If there is a party but doing so is not successful then the current character is set to undefined.
-ACHARTOTARGET: Set the script target object to the active character.  Although used for multiple purposes, something worth mentioning is that using it along with -TARGETTOACHAR is an easy way to temporarily store the current active character if it needs to be used briefly for another character, that is assuming the target object isn't already in use for another purpose or needed for another purpose, in which case another method must be used instead.
-TARGETTOACHAR: Set the active character any script target object.  Note that this does NOT set up any related factors such as current position and so on.
-SETCREATURE: Set the script target creature to any current PC's creature definition.  Every PC has this and it can usually be used anywhere the script target creature normally can.
-SETTARGET: Set the script target object to any current PC
-STARTCHAR [value]: Set the start character value
-SETAMOUNT: Set the script amount to a count of valid party members.  This is only set if there is a party, but if this is called even with a singular character then initialize with Util -SETAMOUNT 1.
-PNAME: If there is a party then display the PC name, which is done in the form of a preliminary label as "[name]:" with a newline
-MOVEBYDEF [tag]: Move all or some party members using positions defined by a separate Def command of the given tag.  The Def command args must consist of positions given in pairs of [x] [y] and is applied to each party member in order.  Moves will start with the party member designed with the command's starting character number.  Moves will end after the last pair and thus may be fewer than the number of party members.  Moves will also end after the last character.  This option is intended for a party; there are more efficient and simple approaches for a singular character.  The Def approach is used for this option instead of directly defining because similar functionality has shown the flexibility of being separated to be the most useful implementation (avoids redundancy if used for other calls, allows grouping multiple different position specifications, etc.); there is no "-MOVE" option nor is one planned for future implementation.
-SPLIT [facing]: Manually split the party using the given facing.  The facing may be the standard numeric direction 0-3 or "BORDER" to use the current border direction.  The later is one of many factors the game tracks, in this case this would for example be the border the PCs are at when entering a dungeon room.
-SETSPLIT [type]: Set the current map split type, meaning when to allow or require split and unsplit.  This is the same as the map file setting but is useful as a script command if various circumstances should lead to differing types.  The default type is ECHECK.  Other circumstances may still prevent split or unsplit, for example party member proximity to each other for unsplit.
Split types:
NEVER: Never may split, always unsplit
ALLOWED: May split or unsplit
ALWAYS: Always must remain split
ECHECK: "Enemy check", meaning only if enemies are nearby is split allowed and only if no enemies are nearby is unsplit allowed
HOSTILE: Hostile map, which means that split is always allowed but only if no enemies are nearby is unsplit allowed
-SPLITENDTURNS: No, this has nothing to do with hair :).  This ends the turns of all split party members.
-SETUPACHAR: Set up aspects of the game based on the active character, for example the current position.  Note that the current position is only done for a split party member since specific party member positions are often not updated when the party is unsplit.
-UPDATEACHAR: Set up the active character based on aspects of the game, for example the current position
-SELECT: Set the current PC based on input from the player using the same selection process as the UI 'P' (Party) command to change the active character, for example '1' for the first party member, '9' for the ninth, 'A' for the tenth, '0' to enter a full number, etc..  Further, other keys will be processed as keywords, in which case it always stops processing options after setting the tag.
-UISETACHAR: Set the active character to the current character and set it up, both in the same manner as the UI Party command by using the same underlying mechanism.  This approach is intended for changing the active character without it being temporary, for example to allow the player to do so as part of a scripted settlement.
-SETCHECKDEATH: Check PC death later sometime after the script has run, useful for a turn script that will not persist until the time this should happen
-SETUPCHARDEATH: Check the current PC is dead and if so then set up related aspects of the game such as setting negative HP to 0, setting the PC to an OFFMAP state, and unsetting conditions such as asleep.  This is useful in scripts that need this before it is normally done automatically.
-CHARDEATHMESSAGE: Check the current PC is dead and if so then display the usual message, useful in scripts that need this before it is normally done automatically
-SWAPPOS [[x] [y] or P[PM]]: Swap the position of the current PC with the given PC, which can be specified by x y map position or by the party position of the given party member by using a prefix of 'P'
-ADDPC [filename] [ID]: Add a party member of the given filename and assigned the given ID.  If the party has not yet been created then does so automatically.  The file should either exist with the scenario data or "SAVED" can be used to reference the script target creature if it has a PC object by having been previously in the party.  The current PC is set as this new party member, which is useful for doing additional setup such as with -CTOPC.
-CTOPC [creature] [PC]: Set up aspects of the given PC based on the creature of the given ID.  A creature ID of 0 causes it to use the script target creature.  The PC is the party member position or 0 to use the current PC.  This is normally used when an NPC joins a party so that the creature and PC are linked together.


The following has been verified for each command with a full description (and I need to verify or finish for those that are still listed as potentially incomplete):
(in the following text, "code" is referring to the engine source code)
- Any args to options all included, look for the setup/verify block of code
- All any-order options listed, compare a count of the code vs. description
- List any tokens used by any args to either the command or any options
- Check if any arg supports the  '!' for NOT such as usually as a prefix.  This is most often for line tags.
- Check for any default values of note
- Check for any other prefix syntax
- If a subject needs more explanation (for example, RGB) then add this as a topic in the earlier text
- Notated support for advanced line syntax (N/P).  Notation is simply "TagEx" in the arg rather than "tag".
- Any other special syntax for any args to the command AND any args to options detailed, check code for string vs. number for a given arg to help find possibilities
- Skim through the code and look for any other nuances that should be included in the text

I still need to at some point add the following subjects and/or address the following tasks:
- Go back through the earlier commands that need more checking and fix up the text as needed.  By the time I got towards the end of those, the text was much more detailed, leaving those earlier on a lot more bare and lacking in detail.
- Go back through the earlier commands and make sure all references to internal vars are phrased correctly, in particular "script target" should be "script target position" if as such (I think I was missing the word "position" in text written earlier on)
- The next bullet point lists going back through for bracketed tasks that still need doing, but before doing those, first do the much quicker process of making sure they are phrased as ME as the developer doing those tasks so it doesn't confuse the reader as something THEY need to do.  I started doing this later on, but the earlier ones may need revising.
- Go back through all commands and options and even the earlier general text and look for bracketed tasks that still need doing such as researching and documenting some sets of tokens
- Go back through all commands and options to verify no special uses of 0 such as to reference the script target creature have been forgotten in the text.  Counterintuitively, this has actually now been done for the commands that otherwise still need some more checking, leaving those listed earlier that are otherwise done.  However, I should still do a quick recheck on those earlier in the list because I got my approach down as I worked down through the list.
- Go back through all commands and options to verify those that allow using optional tokens have not left that out in the text.  This has now been done for terrain, but for example when doing that I looked for the ParseTerrainToken function then simply used "terrain" for the arg instead of trying to list that repeatedly (and changed where that already done).  The actual tokens also need to be detailed somewhere [when I wrote that sentence I may have meant as a general approach or I may have meant needs to be done for terrain].  As with 0 for the script target, this is actually already done for the commands that otherwise need more checking, although do a quick recheck for those earlier on.
- Go back through all commands and options to look for any defaults that have not yet been noted for which it is worth doing so.  This only started being done on a regular basis when I was already almost all the way through the list so may well be necessary for some of the rest earlier on.  For example, there was a default in CreateTile of a frame count of 1.  As with 0 for the script target, this is actually already done for the commands that otherwise need more checking, although do a quick recheck for those earlier on.
- Go back through all commands and options to make sure all numbers args include, when limited, the possible range of values such as due to variable size (byte as much as 0-255, signed byte somewhere around -127-+127, word, etc.) or what is restricted for implementation reasons (1-255, 1-100, 1-8, or whatever).  Note in this context the word "range" means possible values, NOT a range designation as allowed in some args via the "[start]-[end]" syntax.  Anyway, much of this work is already done but there may be more.
- Detail the "include" syntax as per built into the script loader
- Verify no commands or options were forgotten.  As part of this, check for any commands newer than 250322 since those currently included were written against that source code, although the options for those were against newer code 251119.  Aside from that, as with 0 for the script target this is actually already done for the commands that otherwise need more checking, although do a quick recheck for those earlier on.
- Finish detailing how each script use responds to each return state that results in different behavior and the default otherwise.  As part of that, detail any script uses that diverge in that sense from what is already listed.  For example, the script call for Use, locations, and container preprocessing definitely respond to several different return states.
- Find and then detail the max args and nested script calls where those are in some placeholder text, although I'm fairly sure the later of 8 is correct so just need to verify that and update the corresponding text to remove the point of uncertainty.  It may also be worth looking for all other default maximums, as well, such as keywords.
- Go back through all commands and options to verify no special syntax was forgotten in the text such as how a token or prefix (various prefixes but one of the most common being '!' for line tags) can optionally be used for some args.
- Maybe skim through the source code command header comments for anything that should be added to the corresponding text here.  Maybe also check all other comments, as well.  This is a "maybe" and in any case delayed due to those comments often being extremely numerous, detailed, and lengthy, so a gigantic task.  Hopefully the information here is already complete in terms of what is needed for scenario design and yet more concise by avoiding the implementation details and such included with the comments.
- Related to notating each command that supports advanced line syntax (N/P), consider enhancing some of those that do not yet.  While this is a code issue rather than just documentation, it still seems appropriate to list here anyway given it is closely related.
- Another related code issue is to add a script console control command to display internal script vars
- Another is that there's at least one name text mismatch error in an error message, SellSelectedCargo, but that demonstrates that all of those need to be checked throughout the various commands
- Another are various tasks listed or implied throughout the various commands, need to go through them all (text here and code) and check for anything that needs to be cleaned up in the code, not getting too deep but just obvious things and little things here and there given I was noticing some as I was going through documenting
- Another is RemoveMapObj has a note about a possible "all" enhancement that made me realize the idea detail there about tracking the highest value may be of value for existing all/max scans in other commands such the recent enhancement in CheckCreatures of "M" for "max" (and there may be others).  Or it seems like this should at least be added as an optional task note there.
- Another is at least a task note in the code to check all commands with respect to how return states are set and try to make them more consistent
- Of course, the separate but related task of a guide for all the other data file types including the few that have been documented before but where that likely needs to be updated.  Along with this, all such detailed scenario creation documentation (beyond the editor) should be moved into a single document separate from the main manual ("scenario.txt" or something).  This should also have at least 1 tutorial that is for creating a simple scenario, maybe others to add slightly more complex details to that first one for a few subjects such as a new tile (assuming the first one simply had tile data copied from a built-in scenario), a complex conv, a trigger, etc..
- Some of the topics addressed early in this guide are general enough to multiple data file types that they be better in a more centralized location, for example RGB, transparency, etc..  There are also some commands and/or options that do or will theoretically eventually duplicate information for other data file settings due to using the same tokens and such just for one setting where the real home of the information really belongs to the given setting rather than the script functionality that allows access to changing it dynamically, for example the party split/unsplit setting for map files that can also be set dynamically with a Party command.
