This is ./xcdesign.info, produced by makeinfo version 4.8 from
./xcdesign.texi.

INFO-DIR-SECTION Games
START-INFO-DIR-ENTRY
* Xcdesign: (xcdesign.info).	Designing Games with Xconq.
END-INFO-DIR-ENTRY
   This file documents the design of games for Xconq.

   Copyright (C) 1987-1989, 1991-2000 Stanley T. Shebs

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "GNU General Public License" is included
exactly as in the original, and provided that the entire resulting
derived work is distributed under the terms of a permission notice
identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "GNU General Public
License", and this permission notice, may be included in translations
approved by the Free Software Foundation instead of in the original
English.


File: xcdesign.info,  Node: Terrain and Materials,  Next: Units and Advances,  Prev: Units and Materials,  Up: Static Relationships Between Types

3.14.4 Terrain and Materials
----------------------------

 -- TableTM: `terrain-storage-x' t m -> n
     This table is the maximum amount of a material M that may be
     present in a cell with terrain T.


File: xcdesign.info,  Node: Units and Advances,  Prev: Terrain and Materials,  Up: Static Relationships Between Types

3.14.5 Units and Advances
-------------------------

 -- TableUA: `advance-needed-to-build' u a -> t/f
     This table is true whenever the side must have achieved advance A
     before it can being to construct units of type U.

 -- UnitTypeProperty: `obsolete' a
     This property is the type of advance that makes a unit obsolete,
     meaning that units of that type may longer be constructed
     (existing units are unaffected though).  Defaults to
     `non-advance', meaning that the unit type is never obsolete.


File: xcdesign.info,  Node: Vision,  Next: Game Initialization,  Prev: Static Relationships Between Types,  Up: Reference Manual

3.15 Vision
===========

The parameters in this section define how sides get information about
the world, units, and other sides.

* Menu:

* Basic Vision::
* Line of Sight::
* Tracking::
* Spying::


File: xcdesign.info,  Node: Basic Vision,  Next: Line of Sight,  Up: Vision

3.15.1 Basic Vision
-------------------

 -- GlobalVariable: `see-all' t/f
     This variable is `true' if everything in the world, units, terrain,
     etc, is always visible at all times, including initially.  It takes
     precedence over all other visibility and spying parameters.
     Defaults to `false'.

 -- GlobalVariable: `see-terrain-always' t/f
     If this variable is `true', then any side that has seen the terrain
     of a cell will be informed if that terrain ever changes.  Defaults
     to `true'.

 -- UnitTypeProperty: `see-always' t/f
     This property is `true' when a unit is always visible after it has
     been seen once, so that side changes, movements, etc will be seen
     forever afterwards.  If the unit moves into terrain that has not
     been seen, then that terrain also becomes seen as well.  Defaults
     to `false'.

 -- UnitTypeProperty: `see-occupants' t/f
     This property is `true' when a unit's occupants are also seen
     whenever the unit itself is under observation.  Defaults to
     `false'.

 -- UnitTypeProperty: `spot-action' t/f
     If this property is `true', then the unit's chance to be seen by
     other sides will be tested each time the unit acts in any way.
     This property is in addition to the check at the beginning of each
     turn.  Defaults to `true'.

   The people in a cell effectively view (for their side) all units in
that cell.  Some units can hide from the people.

 -- TableUM: `people-see-chance' u m -> n%
     This table is the chance that the people of the given type M will
     see a unit of type U.  This will be evaluated for each people type
     individually, once at the beginning of each turn, and once for each
     populated cell that the unit enters during the turn.  Defaults to
     `100'.

 -- UnitTypeProperty: `vision-range' dist
     This property is the maximum range of vision coverage by the unit.
     A value of `-1' disables all vision, `0' means only units in the
     same cell may be seen, and `1' means units in adjacent cells may be
     seen.  Defaults to `1'.

 -- TableUU: `see-chance-at' u1 u2 -> n%
     This table is the chance that a unit U1 will see another sides's
     unit of type U2 when both are in the same cell.  Defaults to `100'.

 -- TableUU: `see-chance-adjacent' u1 u2 -> n%
     This table is the chance that a unit U1 will see another sides's
     unit of type U2 when the two are in adjacent cells.  Defaults to
     `100'.

 -- TableUU: `see-chance' u1 u2 -> n%
     This table is the base chance that a unit U1 will see a unit U2 in
     cells at distance 2 or greater.  Defaults to `100'.

 -- TableUT: `visibility' u t -> n
     This table is the effect of terrain T on a unit U's chances of
     being seen.  Values less than 100 are reduced visibility, values
     greater than 100 increase the unit's chances to be seen.  Defaults
     to `100'.

 -- TableUT: `vision-night-effect' u t -> n
     This table is the multiplier for unit U's vision at night in each
     type of terrain T.  Effect is to multiply with both vision range
     and see-chance.  Defaults to `100'.

 -- TableTM: `see-material-always' t m -> t/f
     Defaults to `true'.

 -- GlobalVariable: `see-weather-always' t/f
     If true, then weather changes (in cells that have been seen) will
     always be reported.  Defaults to `true'.

 -- TableUU: `see-mistake-chance' u1 u2 -> .01n%
     This is the chance that a unit of type U1 will see a unit of type
     U2 as some other type.  The type of unit seen instead is
     determined by the table `looks-like'.

 -- TableUU: `looks-like' u1 u2 -> n
     This table is the set of weights indicating which type U2 a unit
     of type U1 is most likely to be mistaken for.  When a unit makes a
     viewing mistake, then the program adds up all the weights and
     chooses randomly according to weight.  Defaults to `0', which
     means that U2 never looks like U1.


File: xcdesign.info,  Node: Line of Sight,  Next: Tracking,  Prev: Basic Vision,  Up: Vision

3.15.2 Line of Sight
--------------------

 -- UnitTypeProperty: `vision-bend' n
     This property is the amount by which a unit can see "around
     corners".  0 means that vision is strictly line-of-sight, while
     100 means that elevations never obstruct vision.  Defaults to
     `100'.

 -- TableUT: `eye-height' u t -> elev
     This property is the additional elevation above the unit's
     position that a unit can see with, when in the given terrain.

 -- TableUT: `body-height' u t -> elev
     This property is the effective height of the main visible part of a
     unit, when in the given terrain.

 -- TerrainTypeProperty: `thickness' elev
     This property is the thickness of the terrain, which is the
     difference between the "ground" of the terrain and its top.


File: xcdesign.info,  Node: Tracking,  Next: Spying,  Prev: Line of Sight,  Up: Vision

3.15.3 Tracking
---------------

When is unit is being tracked, then the sides doing the tracking can see
the unit move around, even if the cell is not being covered by any of
the sides' own units.  If this is enabled, then particular units enable
tracking, and the chance of losing track depends on the terrain.

 -- TableUU: `track-chance' u1 u2 -> .01n%
     This table gives the chance that U1's side will be able to track a
     unit of type U2 that is within range (same or adjacent cell).

 -- TableUT: `lose-track-chance' u t -> .01n%
     This table gives the chance that each side tracking a unit will
     lose that track when the unit enters terrain of type T.


File: xcdesign.info,  Node: Spying,  Prev: Tracking,  Up: Vision

3.15.4 Spying
-------------

A unit type can also be specified to do spying automatically.  The
outcome of spying is calculated once/unit/turn, at the beginning of the
turn (after move calculation but before any players can do anything).
Spying can happen to any unit not on the spying unit's side.

 -- UnitTypeProperty: `spy-chance' .01n%
     This property is the chance that the unit will be successful at
     spying.

 -- UnitTypeProperty: `spy-range' dist
     This property is the maximum distance at which the unit will find
     out something by spying.

 -- TableUU: `spy-quality' u1 u2 -> n%
     This table gives the chance that U1's spying will return
     information about a unit of type U2 that is within the spying
     range.  Defaults to `100'.

 -- TableUU: `spy-track-chance' u1 u2 -> .01n%
     This table is the chance that if U1's spies return information
     about a unit of type U2, the unit will also become tracked by the
     spy's side.


File: xcdesign.info,  Node: Game Initialization,  Next: Synthesis Methods,  Prev: Vision,  Up: Reference Manual

3.16 Game Initialization
========================

Game initialization always starts by resetting all the game-defining
data structures to an empty state.  This means no types, no world, etc.
Then Xconq reads and interprets all of the game modules that have been
requested.  These modules may overwrite each other arbitrarily.  Then
any command line or startup options are processed (this may involve an
interactive dialog), and the random number generator is initialized.
and players are matched with sides (any sides needed for players will be
created and named at this time).  Xconq then executes a number of
synthesis methods to do various kinds of setup.

   (Some interfaces might allow for confirmation of the setup before
launching into the game proper, but this cannot be assumed.)

   Since the details of good game synthesis can be complicated,
synthesis methods are simply wired-in pieces of code.  Each method is
self-contained; it assumes the game state to be valid, it will determine
its own applicability and produce a valid result.  It will also acquire
any data that it needs, so does not require any special setup; however,
a method may fail to run if it cannot find that data.  For instance, the
usual fractal terrain generator needs percentiles for each terrain type,
and will not function without them.  It may be that all the requested
synthesis methods fail; this is OK if Xconq's data is present and
consistent, but otherwise Xconq will shut itself down, since it has no
remaining alternatives (think of this as a serious programming error
and fix the game design).


File: xcdesign.info,  Node: Synthesis Methods,  Next: Setup Postprocessing,  Prev: Game Initialization,  Up: Reference Manual

3.17 Synthesis Methods
======================

The synthesis method list specifies which methods will be run, and in
what order.  After they have all been run, Xconq runs a consistency and
completeness check.  For instance, there should be a world with terrain
everywhere.  Failure at this point is fatal; Xconq will either exit or
return to a game setup dialog.

* Menu:

* Synthesis Method List::
* Fractal World::
* Maze World::
* Random World::
* Earthlike World::
* Random Terrain Changes::
* Making Rivers::
* Making Roads::
* Making Countries::
* Making Independent Units::
* Making Weather::
* Making Initial Supply::
* Naming Geographical Features::
* Naming Units::
* Making a Random Date::


File: xcdesign.info,  Node: Synthesis Method List,  Next: Fractal World,  Up: Synthesis Methods

3.17.1 Synthesis Method List
----------------------------

 -- GlobalVariable: `synthesis-methods' method-list
     This variable is a list of synthesis methods.  If the list is
     empty, no synthesis methods will be run.

   The list of synthesis methods is ordered, and many contain
duplicates, so that a method can be run multiple times during setup.
Note that most of the existing methods will simply return if they
detect that their work has already been done, so multiple runs will
have no effect.

   The default synthesis method list is effectively
     (make-fractal-percentile-terrain
      make-countries
      make-independent-units
      make-roads
      make-rivers
      make-weather
      init-supplies
      name-geographical-features
      )

 -- GlobalVariable: `synthesis-done' list
     This variable is a list of what methods were used, and how many
     times.  This is for the use of the save/restore machinery, should
     not normally be manipulated by game designers.


File: xcdesign.info,  Node: Fractal World,  Next: Maze World,  Prev: Synthesis Method List,  Up: Synthesis Methods

3.17.2 Fractal World
--------------------

The fractal world synthesizer can make a variety of natural-looking
terrain.  It relies on a number of parameters to govern a single
algorithm.

 -- SynthesisMethod: `make-fractal-percentile-terrain'
     This method generates the terrain layer of a world.  It works by
     generating two distinct layers of random blobs, known as the "alt"
     and "wet" layers, then decides on a terrain type for each cell.  If
     elevations are defined, then this method will use the "alt" layer
     to produce elevations.

 -- GlobalVariable: `alt-blob-density' n

 -- GlobalVariable: `wet-blob-density' n
     These variables are the number of blobs to put down, expressed as
     number per 10,000 cells.  Defaults to `500'.

 -- GlobalVariable: `alt-blob-size' n.f%

 -- GlobalVariable: `wet-blob-size' n.f%
     These variables are the average number of cells in a blob,
     expressed as number per 10,000 cells.  Defaults to `100'.

 -- GlobalVariable: `alt-blob-height' n

 -- GlobalVariable: `wet-blob-height' n
     These variables are the amounts by which to increment or decrement
     within a blob.  Defaults to `1000'.

 -- GlobalVariable: `alt-smoothing' n

 -- GlobalVariable: `wet-smoothing' n
     These variables specify the number of averaging steps to perform
     after the blobs have been generated.  Defaults to `2'.

 -- TerrainTypeProperty: `alt-percentile-min' n%

 -- TerrainTypeProperty: `alt-percentile-max' n%

 -- TerrainTypeProperty: `wet-percentile-min' n%

 -- TerrainTypeProperty: `wet-percentile-max' n%
     These properties are the percentiles of elevations and moistures
     that result in the given terrain type.  Percentile ranges may
     overlap, in which case the earlier-defined terrain type will be
     used.  If a cell has a alt and wet that does not fall in any of
     the ranges, then terrain type 0 will be used there and players
     will be warned.  Mins defaults to `0', maxes to `100'.

   After the terrain has been assigned types, the method will give a
single type to all the cells on the edge of the area.

 -- GlobalVariable: `edge-terrain'
     This variable is the type of terrain to fill in on all the edges
     of a world.  The edges of a world have little or no effect on the
     game, but the terrain type should be something distinctive, so
     that players can recognize the edges easily.  (For instance, ice
     is usually a good choice for edges, but probably not on a map of
     Antarctica!)  Defaults to terrain type 0 (the first defined type).


File: xcdesign.info,  Node: Maze World,  Next: Random World,  Prev: Fractal World,  Up: Synthesis Methods

3.17.3 Maze World
-----------------

A maze consists of a set of randomly placed "rooms" connected by random
passages.

 -- SynthesisMethod: `make-maze-terrain'
     This method creates terrain that looks like a maze.  It starts by
     randomly assigning terrain according to its `occurrence', similarly
     to `make-random-terrain' below, then carves out rooms and passages,
     filling each of those with terrain types according to their
     respective occurrences.

 -- TerrainTypeProperty: `maze-room-occurrence' n
     This property is the weighted amount of this terrain type in rooms
     in the maze.

 -- TerrainTypeProperty: `maze-passage-occurrence' n
     This property is the weighted amount of this terrain type in
     passageways in the maze.

 -- GlobalVariable: `maze-room-density' n
     This variable is the fraction of the maze that is room, expressed
     as the number of cells per 10,000 cells in the area.  Defaults to
     `1000'.

 -- GlobalVariable: `maze-passage-density' n
     This variable is the fraction of the area that is passageway,
     expressed as the number of cells per 10,000 cells in the area.
     Defaults to `3000'.

   This method will apply edge terrain as a last step.


File: xcdesign.info,  Node: Random World,  Next: Earthlike World,  Prev: Maze World,  Up: Synthesis Methods

3.17.4 Random World
-------------------

The random world generator just assigns terrain and elevations randomly.

 -- SynthesisMethod: `make-random-terrain'
     This method generates completely random terrain.  It uses a simple
     weighting to govern how much of each terrain type appears, and
     makes random elevations as well.

 -- TerrainTypeProperty: `occurrence' n
     This property is the percentage of the world that will be of this
     type, if the terrain is cell terrain.  If the terrain is border or
     connection, it is the probability (expressed as .01% increments)
     that any direction of any cell will have that border or
     connection.  Defaults to `1'.


File: xcdesign.info,  Node: Earthlike World,  Next: Random Terrain Changes,  Prev: Random World,  Up: Synthesis Methods

3.17.5 Earthlike World
----------------------

Earthlike generation uses algorithms that more closely approximate
realistic terrain.

 -- SynthesisMethod: `make-earthlike-terrain'
     This method generates terrain that approximates what actually
     appears on Earth.


File: xcdesign.info,  Node: Random Terrain Changes,  Next: Making Rivers,  Prev: Earthlike World,  Up: Synthesis Methods

3.17.6 Random Terrain Changes
-----------------------------

Terrain generation methods may postprocess the generated terrain by
randomly changing cells of some types.

 -- TableTT: `terrain-density' t1 t2 -> .01n%
     This table is the .01% chance that a cell of type T1 will be
     changed to type T2.


File: xcdesign.info,  Node: Making Rivers,  Next: Making Roads,  Prev: Random Terrain Changes,  Up: Synthesis Methods

3.17.7 Making Rivers
--------------------

Rivers are borders or connections consisting of "watery terrain" that
run downhill to regions of water.

 -- SynthesisMethod: `make-rivers'
     This method looks for a border or connection terrain type with a
     `subtype-x' of `river-x'.  then uses the world's elevation data to
     run rivers downhill (always choosing the lowest of possible
     adjacent locations) until they reach cell terrain with a `subtype'
     > 0.  This method will not run if there are no appropriate terrain
     types, nor if there is no elevation data.

 -- TerrainTypeProperty: `river-chance' n%
     This property is the chance that a river will start in or around a
     cell of this terrain type.

 -- GlobalVariable: `river-sink-terrain' t
     If the value of this variable is a terrain type, then a cell
     completely surrounded by river will be changed to be this type.
     Defaults to `non-terrain'.

   Note that the algorithm computes rivers in a deterministic way, so
high values of `river-chance' do not result in tangled rivers.


File: xcdesign.info,  Node: Making Roads,  Next: Making Countries,  Prev: Making Rivers,  Up: Synthesis Methods

3.17.8 Making Roads
-------------------

The road generation method makes networks of connection terrain between
particular unit types, usually those resembling cities.

 -- SynthesisMethod: `make-roads'
     This methods synthesizes roads for an area.  For any connection
     type of terrain, if no layer has been created for it already, and
     the type has a `subtype-x' of 3, put down roads between any pair
     of units whose `road-chance' is nonzero.  The method will attempt
     to share road routes whenever possible, and choose terrain
     according to `road-into-chance'.  In addition, the method may also
     generate spur roads connecting units to existing roads, and run
     roads from one edge of the area to another.

 -- TableUU: `road-chance' u1 u2 -> n%
     This table is the chance that a road will be laid, running from a
     unit of type U1 to one of type U2.  Note that is not a symmetrical
     relationship; since roads follow random paths, if the
     `road-chance' causes a road to be laid from U1 to U2, and another
     from U2 to U1, it is quite possible that the result will be two
     different roads connecting the two units.

 -- TableTT: `road-into-chance' t1 t2 -> n%
     This table is the chance that a road will be chosen to pass from
     terrain of type T1 into terrain of type T2.  Defaults to `100'.

 -- UnitTypeProperty: `spur-chance' n%
     This property is the percentage chance that the unit will get a
     spur road running from the unit to the nearest existing road.

 -- UnitTypeProperty: `spur-range' dist
     This property is the radius of the area that will be searched for
     an existing road.  Defaults to `1', which results in spurs
     connecting only to roads in adjacent cells.

 -- UnitTypeProperty: `road-to-edge-chance' n%
     This property is the percentage chance that the unit will have a
     road running from the unit to some edge of the area.

 -- GlobalVariable: `edge-road-density' n
     This variable is the density of roads that run from one area edge
     to another, expressed as the number per 10,000 cells in the area.
     (note, not counting just edge cells).


File: xcdesign.info,  Node: Making Countries,  Next: Making Independent Units,  Prev: Making Roads,  Up: Synthesis Methods

3.17.9 Making Countries
-----------------------

The `make-countries' method sets up the starting units for each side,
placing them in a confined area, separated from the starting units of
other sides and taking terrain preferences into account.  If requested,
this method will also expand the country outwards by a specified
amount, possibly placing additional units in the process.

 -- SynthesisMethod: `make-countries'
     This method works by looking for a likely place for the country,
     randomly places a basic set of starting units within that area,
     then expands the country outwards.  The parameters give you
     control over the mix of terrain types in the country, as well as
     the size and relative positions of the different countries.  This
     method runs on any side with fewer units than it is supposed to
     start with, as given by the parameters below.  It places groups of
     units at locations separated from each other by specified
     distances.

 -- GlobalVariable: `country-radius-min' dist
     This variable is the radius of the country's initial area.
     Defaults to `-1', which allows the algorithm to calculate a
     "reasonable" country size appropriate to the given number of units.

 -- GlobalVariable: `country-separation-min' dist

 -- GlobalVariable: `country-separation-max' dist
     These variables are the minimum and maximum distances of country
     centers from each other, in cells.  If small, countries will
     mostly overlap; if very large, then attempts to use small worlds
     will fail; if the max and min are too close to each other,
     placements can also fail.  For both of these, a value of `-1'
     disables their effect.  Both default to `-1'.

   The max separation bound needs to be satisfied for a country with
respect to only one other country, so for instance the final layout may
involve a long "string" of countries where the first and last countries
are very far apart from each other.  The minimum bound must be
satisfied for all pairs of countries.

 -- TerrainTypeProperty: `country-terrain-min' n
     This property is the minimum amount of terrain that must be within
     the country's initial radius.

 -- TerrainTypeProperty: `country-terrain-max' n
     This property is the most terrain of the given type that may
     appear.  If `-1', then any amount may be present.  Defaults to
     `-1'.

 -- UnitTypeProperty: `start-with' n

 -- UnitTypeProperty: `independent-near-start' n
     These properties set the number of units of the given type in a
     player's country.  These units are randomly scattered within the
     initial radius, and the `favored' table (see below) decides which
     terrains will be used.  Units may be placed inside each other; in
     fact, units with no favored terrain will be made into occupants if
     possible.

     The independent units will be placed after the ones belonging to
     the side, so on the average they will get the less desirable
     locations in the country.  Unlike the randomly-scattered
     independent units, these will be named using the side's namers.

     Both default to `0'.

 -- TableUT: `favored-terrain' u t -> n%
     This table sets the probability of the unit type being on the
     given type of terrain at the outset.  A value of `0' is an absolute
     prohibition against placing the unit on that type of terrain, thus
     every game must specify at least one non-zero value for some
     terrain type and some initial unit type.  Defaults to `100'.

   Once the initial country area has been set up, then you can allow the
countries to expand outwards.  Expansion occurs at the same rate for all
countries.  Countries may expand into and through each other.  Expansion
occurs as a number of STEPS, each step increasing the radius of
countries by 1 all around.

 -- TerrainTypeProperty: `country-growth-chance' n%
     This property is the chance that a country will expand onto an
     unclaimed cell of the given terrain type.  Defaults to `100'.

 -- TerrainTypeProperty: `country-takeover-chance' n%
     This property is the chance that a country will expand onto another
     country's cell of the given terrain type.

 -- UnitTypeProperty: `unit-growth-chance' n.f%
     This property is the chance that a unit of the given type will be
     placed when the country expands onto a cell.  The unit will only
     be placed if the `favored' chance is also true.

 -- UnitTypeProperty: `independent-growth-chance' n.f%
     This property is the chance that an independent unit of the given
     type will be placed when the country expands onto a cell.  The
     `favored' chance is also evaluated.

 -- UnitTypeProperty: `unit-takeover-chance' n.f%
     This property is the chance that a unit of the given type in
     another country and belonging to another side will be given to the
     growing side.

 -- UnitTypeProperty: `independent-takeover-chance' n.f%
     This property is the chance that an independent unit of the given
     type in another country will be given to the growing side.

 -- GlobalVariable: `country-radius-max' dist
     This variable is a cap on the country growth process.  Values
     between `0' and `country-radius-min' prevent country growth
     entirely, while a value of `-1' allows growth to encompass the
     entire world.

 -- UnitTypeProperty: `country-units-max' n
     This property is a cap on the number of units given to the side's
     country.  Defaults to `-1', which disables any limit.

 -- GlobalVariable: `growth-stop-chance' n%
     This variable is the chance that a country's growth will stop, if
     during the current step no new cells were added to the country.

 -- TerrainTypeProperty: `country-people-chance' n%
     This property is the chance that the people's side will be changed
     to match that for the country they are in.  Defaults to `100'.


File: xcdesign.info,  Node: Making Independent Units,  Next: Making Weather,  Prev: Making Countries,  Up: Synthesis Methods

3.17.10 Making Independent Units
--------------------------------

 -- SynthesisMethod: `make-independent-units'
     This method scatters independent units randomly over the world.
     This method will not run if the specified density of independent
     units has already been achieved, for instance from a predefined
     world or from country placement.  Independent units that should be
     inside other independents will be handled correctly.

 -- TableUT: `independent-density' u t -> .01n%
     This table is the probability that an independent unit of type U
     will be placed on a empty cell with terrain of type T.

 -- TerrainTypeProperty: `independent-people-chance' .01n%
     This property is the chance that the people of a cell with this
     terrain type will be made independent.


File: xcdesign.info,  Node: Making Weather,  Next: Making Initial Supply,  Prev: Making Independent Units,  Up: Synthesis Methods

3.17.11 Making Weather
----------------------

Weather synthesis sets up an initial state for the weather.

 -- SynthesisMethod: `make-weather'
     This method sets up weather-related layers, including temperature,
     winds, and clouds.


File: xcdesign.info,  Node: Making Initial Supply,  Next: Naming Geographical Features,  Prev: Making Weather,  Up: Synthesis Methods

3.17.12 Making Initial Supply
-----------------------------

By default, all units start out empty of materials.  The supply
initialization method gives each unit a starting supply, according to
the initial supply tables.

 -- SynthesisMethod: `make-initial-materials'
     This method fills unit and cell supplies to specified levels.  It
     will fill all units in existence at the moment it runs, including
     units that have not appeared yet.  Similarly, all cells will be
     filled.

 -- TableUM: `unit-initial-supply' u m -> n
     This table is the amount of each material that each unit will
     start out with.  If the initial supply is greater than unit's
     capacity, then the unit will just be filled to capacity.

   Terrain cells may also have initial material levels.

 -- TableTM: `terrain-initial-supply' t m -> n
     This table is the amount of material M that each cell with terrain
     T will start out with.  This will be limited by the cell's
     capacity.

   Sides with treasuries may start with an initial amount.

 -- MaterialTypeProperty: `initial-treasury' n
     This is the amount of each material type that a side's treasury
     will start with.

 -- GlobalVariable: `indepside-has-treasury' t/f
     This is true if the independent units have a common treasury.
     (This may be necessary if indeps may construct units, and those
     units need treasury material.)


File: xcdesign.info,  Node: Naming Geographical Features,  Next: Naming Units,  Prev: Making Initial Supply,  Up: Synthesis Methods

3.17.13 Naming Geographical Features
------------------------------------

Although named geographical features don't affect the outcome of a game
in any way, they are useful for "color" and for identifying locations
more readably.

 -- SynthesisMethod: `name-geographical-features'
     This method identifies and names regions as geographical features,
     such as mountain ranges and islands.

 -- GlobalVariable: `feature-namers' feature-namer-list
     This variable is a list of feature types and their associated
     namers.  This is used for features not intersecting any country
     with a namer for the feature's type.  Defaults to `()'.

 -- GlobalVariable: `feature-types' feature-expr-list
     This variable is a list of feature types that may be identified.
     Each list element has the form `(typename [name] [parameters])',
     where TYPENAME is from the list given below, NAME is the specific
     name of the type (which is used in `feature-namers', and
     PARAMETERS is any optional parameters describing how to identify
     features of that type.  Defaults to `()'.

   * `peak' [name] [density] This type causes the synthesizer to look
     for high points, at a density of DENSITY per 10,000 cells
     (defaulting to 50).

   * `island' [name] [sizemax] This type identifies areas of non-liquid
     terrain surrounded by liquid terrain, up to SIZEMAX (default 30)
     cells in size.

   * `lake' [name] [sizemax] This type identifies areas of liquid
     terrain surrounded by non-liquid terrain, up to SIZEMAX (default
     30) cells in size.

   * `bay' [name] This type identifies cells that are liquid but at
     least 2/3 surrounded by non-liquid terrain.



File: xcdesign.info,  Node: Naming Units,  Next: Making a Random Date,  Prev: Naming Geographical Features,  Up: Synthesis Methods

3.17.14 Naming Units
--------------------

 -- SynthesisMethod: `name-units-randomly'
     This method gives names to previously-unnamed units, using their
     usual namers.


File: xcdesign.info,  Node: Making a Random Date,  Prev: Naming Units,  Up: Synthesis Methods

3.17.15 Making a Random Date
----------------------------

For extra color, games can be set up to start at a random date within a
given range.  If day or year effects are defined, this also has the
effect of making the game start at a random time of day or year.

 -- SynthesisMethod: `make-random-date'
     This method generates a random starting date, within specified
     bounds.

 -- GlobalVariable: `initial-date-min' date
     This variable is the earliest possible date for the game.
     Defaults to `""'.

 -- GlobalVariable: `initial-date-max' date
     This variable is the latest possible date for the game.  Defaults
     to `""'.


File: xcdesign.info,  Node: Setup Postprocessing,  Next: Naming and Text Generation,  Prev: Synthesis Methods,  Up: Reference Manual

3.18 Setup Postprocessing
=========================

Some initialization steps will be done after all synthesis methods have
been run.  Xconq will always do these.

* Menu:

* Initial View::


File: xcdesign.info,  Node: Initial View,  Up: Setup Postprocessing

3.18.1 Initial View
-------------------

By default, each side starts out knowing only what its units can
normally see at the beginning of the first turn.  These parameters add
to that initial view.

 -- GlobalVariable: `terrain-seen' t/f
     This variable is `true' if all the terrain of the world is known
     initially.  Defaults to `false'.

 -- UnitTypeProperty: `initial-seen-radius' dist
     This property specifies the radius of the area seen around each of
     the starting units.  It computes visibility of terrain (cells and
     borders) only.  Defaults to `1' (which is a no-op if the unit's
     `vision-range' is greater than or equal to 1).

 -- UnitTypeProperty: `already-seen' n%
     This property is the chance to see units of this type at the
     beginning of the game.  This applies only to units belonging to
     another side, and on known terrain.  The effect is one-time, so if
     an `already-seen' unit changes sides later on, other players will
     not see the change unless they have the unit under observation for
     themselves.  Note that `see-always' implies `already-seen'.

 -- UnitTypeProperty: `already-seen-independent' n%
     This property is like `already-seen', but applies to independent
     units specifically.


File: xcdesign.info,  Node: Naming and Text Generation,  Next: Actions,  Prev: Setup Postprocessing,  Up: Reference Manual

3.19 Naming and Text Generation
===============================

Xconq can generate names for sides, units, and geographical features.
Although most naming happens during game setup, names may be assigned
throughout the course of a game, both automatically and by player
request.

* Menu:

* Naming Sides::
* Namers::
* Naming Methods::
* Notices and Narratives::


File: xcdesign.info,  Node: Naming Sides,  Next: Namers,  Up: Naming and Text Generation

3.19.1 Naming Sides
-------------------

Side naming is special, because several different but related names
have to be produced.

 -- GlobalVariable: `side-library' side-info...
     This variable is a weighted list of groups of side properties,
     each of which may be used to fill in a side.

   The form of each side name entry is basically a subset of the side's
properties:
     ([ weight ] ... (name <name>) ... (color <colors>) ...)
   Each entry can include as many or as few of the attributes as
desired; any missing will be filled in from the usual defaults.  The
optional WEIGHT is a number that adjusts the probability of selection of
the given side name set; it defaults to 1, and the probability is scaled
according to the sum of the weights for all the sides listed.  If any
property value is a namer, then the namer will be run.  (Note that if
multiple namers are specified, they cannot be guaranteed to coordinate
with each other, so you can end up with a side noun that is
inappropriate for its corresponding side name.)

 -- GlobalVariable: `side-color-library' side-info...
     This variable is a weighted list of side color schemes, each of
     which may be used to fill in a side's color scheme.  The values
     from this list are only used if the entry from `side-library' does
     not supply a color scheme.


File: xcdesign.info,  Node: Namers,  Next: Naming Methods,  Prev: Naming Sides,  Up: Naming and Text Generation

3.19.2 Namers
-------------

Since one of the purposes of naming is to identify objects uniquely, any
name generator should be able to maintain some memory as to what has
been generated already.  The objects that do this are "namers".

 -- Form: `namer' symbol/id method
     This form defines an instance of a namer, with either the symbolic
     name or numeric id.  If either matches the name or id of an
     existing namer, then the old namer will be overwritten, otherwise
     a new one will be created.  The METHOD must be one of the naming
     methods listed below.

 -- GlobalVariable: `default-namer' str
     This namer may be used when another namer can no longer produce
     names, such as a random namer that exhausts its list of
     possibilities.  At present, it is used only with the `junky' and
     `random' naming methods (presumably the `grammar' is
     inexhaustible!).


File: xcdesign.info,  Node: Naming Methods,  Next: Notices and Narratives,  Prev: Namers,  Up: Naming and Text Generation

3.19.3 Naming Methods
---------------------

As with general synthesis, Xconq has a number of "naming methods"
available.

 -- NamingMethod: `random' names ...
     This method picks a name from the given list of names and removes
     that name from the list.

 -- NamingMethod: `junky'
     This method produces a gobbledy-gook name, very techy-looking.

 -- NamingMethod: `grammar' root max-length rules...
     This method defines a grammar, where ROOT is the root symbol,
     MAX-LENGTH is a limit on the length of the generated names (in
     characters), and RULES is a list of rules of the form
          (SYMBOL RULE-BODY)
     The RULE-BODY can have the following forms:
          (RULE-BODY RULE-BODY ...)
          (or [ WEIGHT ] RULE-BODY [ WEIGHT ] RULE-BODY ...)
          (capitalize RULE-BODY)
          (reject RULE-BODY string-or-sym ...)
          symbol
          string

     The generation process for `or' works by substituting one of the
     rule's alternatives for the symbol.  The probability of an
     alternative being selected is arrived at by adding up the optional
     weights WEIGHT (assuming missing weights to be `1'), and choosing
     with a probability of the weight divided by the total sum of
     weights.  Thus the weights need not add up to any particular value.

     If the list is not prefixed by any of the special symbols, then
     each rule body in the list is expanded, and the results
     concatenated.

     Strings and symbols that are not terminals get used directly.  If a
     symbol in the rule's chosen expansion does not appear as the
     lefthand side in any rule, then it will be handled as a string,
     otherwise it will be expanded in turn.  If the symbol matches a
     namer's name, then that namer will be run and its result
     incorporated.

 -- GlobalConstant: `or'
     This designates a list of alternatives.

 -- Symbol: `capitalize'
     Directs capitalization of the result generated by the rule body.

 -- Symbol: `reject'
     A rule body headed by `reject' includes a list of substrings that
     should not appear in a generated name; this is a convenient way to
     filter out particularly unlovely results.  This works by retrying
     generation if one of the listed strings appears in the name
     generated by the rule body in the form.


File: xcdesign.info,  Node: Notices and Narratives,  Prev: Naming Methods,  Up: Naming and Text Generation

3.19.4 Notices and Narratives
-----------------------------

 -- GlobalVariable: `action-notices' patterns
     This variable is a list of patterns that an interface may use to
     generate textual notices of unit actions.  Defaults to `()'.

 -- GlobalVariable: `action-movies' patterns
     This variable is similar, but instead of generating text, the
     result of a match is a designation of a movie (an animation or
     sound).  Defaults to `()'.

 -- GlobalVariable: `event-notices' patterns
     This variable is a list of patterns that an interface may use to
     generate textual notices of historical events.  Defaults to `()'.

 -- GlobalVariable: `event-narratives' patterns
     This variable is similar, but its text is in the past tense.
     Defaults to `()'.

 -- GlobalVariable: `event-movies' patterns
     This variable is similar, but instead of generating text, the
     result of a match is a designation of a movie (an animation or
     sound).  Defaults to `()'.


File: xcdesign.info,  Node: Actions,  Next: Backdrop,  Prev: Naming and Text Generation,  Up: Reference Manual

3.20 Actions
============

The parameters in this section define and regulate the various actions
that are available to units during a game.

   Actions always start and complete (including all of their effects)
within the same turn, and a unit can only do one at a time.

   All actions are potentially available to all units, but the
parameters can be set so as to deny any action type to any unit type.
See the descriptions with each action type.

   All action is limited by action points.  Each unit gets a certain
number at the beginning of each turn and expends them in the course of
doing things.  The usual expenditure is one point per action, but may
be more, as defined for each type of action.  A unit action must always
consume at least one action point.  Units can accumulate acp from turn
to turn, and they can also reduce acp below zero.

* Menu:

* Actions in General::
* Action Ordering::
* Movement Action::
* Entry Action::
* Develop Action::
* Toolup Action::
* Unit Creation Actions::
* Unit Completion Action::
* Repair Action::
* Material Production Action::
* Material Extraction Action::
* Material Transfer Action::
* Side Change Action::
* Disband Action::
* Part Transfer Action::
* Type Change Action::
* Combat Actions::
* Capture Action::
* Detonation Action::
* Terrain Alteration Actions::


File: xcdesign.info,  Node: Actions in General,  Next: Action Ordering,  Up: Actions

3.20.1 Actions in General
-------------------------

 -- UnitTypeProperty: `acp-per-turn' acp
     This property is the basic allowance of action points that a unit
     gets each turn.

 -- UnitTypeProperty: `acp-min' acp
     This property specifies how far into "action debt" a unit can go
     during a turn before it is prevented entirely from acting.  A unit
     with acp < 1 at the beginning of a turn cannot do anything at all.

 -- UnitTypeProperty: `acp-max' acp
     This property is the maximum number of action points that a unit
     can save up.  The value `-1' means that `acp-max' is equal to
     `acp'.  Extra acp is silently lost.  Defaults to `-1'.

 -- UnitTypeProperty: `free-acp' acp
     This property is the value is the amount by which the action
     points for some action can exceed the unit's currently available
     acp and still allow that action.  Defaults to `-1', which means
     enough free acp to allow any action.

   Note that a unit with an acp of 0 and an acp-min of 0 is completely
unintelligent, about like a cow patty.  Cow patties can be useful for
blocking paths, hiding behind, and suchlike, and have the advantage that
once they're in place, you don't have to manage them.  Other units will
have to pick them up and put them down, of course.

 -- TableUM: `material-to-act' u m -> n
     This table is a minimum amount of M needed for U to be able to
     act.  The material is not consumed.

 -- UnitTypeProperty: `acp-damage-effect' interpolation-list
     This property is the effect of a unit's hp on its acp.  The input
     value is hp, while the output value is the acp to be added instead
     of `acp-per-turn'.  This list does not extrapolate.  Defaults to
     `()'.

 -- TableUT: `acp-night-effect' u t -> n
     This table is the multiplier for unit's acp at night in each type
     of terrain.  Defaults to `100'.

 -- TableUU: `acp-occupant-effect' u1 u2 -> n
     This table specifies the effect of occupants on the unit's acp.
     The effect of each occupant is multiplied with the acp and divided
     by 100.  Defaults to `100'.

 -- UnitTypeProperty: `acp-morale-effect' interpolation-list
     This property is the effect of morale on acp.  The input value is
     morale, and the result value is multiplied with acp, after it has
     been modified for night effect, but before modification for
     temperature.  The result is divided by 100, so an effect < 100
     reduces acp, an effect of 100 has no effect, and an effect > 100
     increases acp.  Defaults to `()'.

 -- UnitTypeProperty: `acp-per-turn-min' acp
     This property sets a lower limit on the effect of occupants,
     damage, and other modifiers on the acp to be added at the
     beginning of the turn.

 -- UnitTypeProperty: `acp-per-turn-max' acp
     This property sets the upper limit on the effect of occupants and
     other modifiers to the acp added at the beginning of the turn.
     Defaults to `-1', which indicates that there is no limit.

 -- UnitTypeProperty: `acp-independent' t/f
     This property indicates that the unit's actions are to be limited
     by materials, rather than by a fixed number of acp each turn.


File: xcdesign.info,  Node: Action Ordering,  Next: Movement Action,  Prev: Actions in General,  Up: Actions

3.20.2 Action Ordering
----------------------

 -- GlobalVariable: `use-side-priority' t/f
     This variable is `true' if the sides may only act one at a time;
     otherwise, all sides and units may move simultaneously during a
     turn.  Defaults to `false'.  This variable is also set by the
     `sequential' variant.

 -- UnitTypeProperty: `action-priority' n
     This property is the order in which units of this type will act.
     Higher numbers act earlier.  If the difference between the
     priority of one type and another is greater than 100, then the
     earlier-acting units must finish acting before the later-acting
     units, otherwise a player can rearrange the actual acting order as
     desired.


File: xcdesign.info,  Node: Movement Action,  Next: Entry Action,  Prev: Action Ordering,  Up: Actions

3.20.3 Movement Action
----------------------

Movement is the most common sort of action.  This section covers
movement over open terrain; the next section discusses interaction with
transports.

   The general theory of movement is that a unit not in a transport
crosses its current cell terrain to the edge of the cell, crosses any
border terrain, and then moves into the destination cell, OR it moves
onto connection terrain, travels along connection terrain to the new
cell, and maybe moves off the connection.  If the unit starts in a
transport, then the transport may ferry the unit over some of the
intervening terrain, possibly as far as the unit's destination.

   A unit's basic movement rate is defined by its "speed", which is a
ratio of the the unit's acp.  A speed of 100% means that the unit can
potentially enter as many cells as it has acp, while a speed of 20%
means that the unit uses at least 5 acp to enter a cell.

   Movement can only succeed if several conditions are met: the unit
must be able to cross the border terrain, the destination must be
inside the world (but see below), it must be able to exist on the
terrain of the destination.

 -- ActionType: `move' x y z
     This is the action that a unit performs to go from its current
     location to the cell at X,Y at altitude Z.  The destination must
     be within the `move-range' of the unit.

 -- UnitTypeProperty: `acp-to-move' acp
     This property is the number of acp a unit uses to do one move
     action.  Defaults to `1'.

 -- UnitTypeProperty: `speed' n
     This property is the basic multiplier relating acp to the number
     of cells that may be entered during a turn.  Defaults to `100'.

 -- UnitTypeProperty: `speed-damage-effect' interpolation-list
     This property is the unit's speed if it is damaged.  The input
     value is the unit's hp, while the result value is the unit speed
     to use instead of `speed'.  Defaults to `()'.

 -- TableUU: `speed-occupant-effect' u1 u2 -> n%
     This table is the percent change in the speed of type U1 for each
     occupant of type U2.  If the basic speed of U1 is `0', then the
     multiplication is performed as if the speed were `1' instead.
     Defaults to `100'.

 -- UnitTypeProperty: `speed-wind-effect' list
     This property is a list that describes the effect of wind on the
     unit's speed.  The effect is calculated using a combination of the
     cells being left and entered.  The format of the list is
          `((ANGLE-LIST {No value for `value'}) ...)'
     where angle-list is a single number, list of number, or the symbol
     `all', and the VALUE is either a number, or a list of the form
          `((FORCE NUMBER) (FORCE NUMBER) ...)'
     For hex areas, the angles are 0 for downwind (same direction), 1,
     2, and 3 for directly upwind (opposite direction).  The force is
     the wind force in the cell, and number is the multiplier for the
     speed, with `100' having no effect, numbers less than `100'
     decreasing the unit's speed, and numbers greater than `100'
     increasing it.  Defaults to `()'.

 -- UnitTypeProperty: `speed-min' mp
     This property is the worst-case speed of a unit.

 -- UnitTypeProperty: `speed-max' mp
     This property is the upper bound on a unit's movement in one turn.
     (?)

 -- UnitTypeProperty: `move-range' n
     This property is the maximum distance allowed to the destination
     cell.  Defaults to `1'.

   The product of a unit's acp and its speed is its available "movement
points".  Any move between cells will cost at least one movement point.
Some mp costs may be negative, but the total mp for a move will always
be at least 1.

 -- TableUT: `mp-to-leave-terrain' u t -> mp
     This table is the mp cost to leave a cell of type T.  If T is a
     border type, this cost is never used.  If T is a connection type,
     this cost is the cost of leaving the connection terrain for the
     open terrain of the cell.  If T is a coating type, then this value
     adds to the cost of leaving the cell.

 -- TableUT: `mp-to-enter-terrain' u t -> mp
     This table is the mp cost to enter a cell of type T.  If T is a
     border type, this cost is the cost of crossing the border.  If T
     is a connection type, this cost is the cost of entering the
     connection terrain from the open terrain of the cell.  If T is a
     coating type, then this value adds to the cost of entering the
     cell.  Defaults to `1'.

 -- TableUT: `mp-to-traverse' u t -> mp
     This table gives the cost to travel along a connection or border
     of the given type.  (note that the other costs are irrelevant if
     unit starts and ends its movement on the connection).

     A special type of move known as a "border slide" can occur when the
     endpoints of a border touch on the start and destination cells.
     Sliding works like normal movement that happens to end up on a
     nonadjacent cell.  Same rules for permissibility apply.  If the
     value is negative, then border sliding is not possible.

     Defaults to `-1'.

   If both enter/traverse/leave and enter/leave movement is possible,
then Xconq will automatically choose the cheapest alternative.

   Each unit type has a range of altitudes within which it normally
operates.

 -- TableUT: `altitude-min' u t -> n
     This table is the minimum altitude possible for each type of unit
     on each type of terrain.

 -- TableUT: `altitude-max' u t -> n
     This table is the maximum altitude possible for each type of unit
     on each type of terrain.

 -- UnitTypeProperty: `mp-to-leave-world' mp
     This property is an additional move cost to leave the world
     entirely.  To leave, the unit must be within its `move-range' of
     an edge, and have sufficient mp to move into the terrain in the
     edge cell designated as the destination of the move.  If the value
     is `-1', then the unit may never leave.  Defaults to `-1'.

 -- UnitTypeProperty: `free-mp' mp
     This property is the amount by which the move points can "go into
     the red" and still allow one more move.

   ZOC is exerted only over units out in the open, has no effect on
occupants, unless they leave their transport.  Occupants can themselves
exert a ZOC, if `occupant-can-fight' is true.  ZOC applies to all units
on a hostile side.

 -- TableUU: `zoc-range' u1 u2 -> dist
     This table is the maximum distance at which type U1 exerts a ZOC
     over type U2.  A value of `0' means that the unit controls only
     its own cell, and a value of `-1' means that the unit does not
     exert a ZOC at all.  Defaults to `0'.

 -- TableUT: `zoc-into-terrain' u t -> t/f
     This table is `true' if the unit exerts its ZOC into terrain T.
     Defaults to `true'.

 -- TableUT: `zoc-from-terrain-effect' u t -> n
     Defaults to `100'.

 -- TableUU: `mp-to-enter-zoc' u1 u2 -> mp
     This table specifies extra movement points needed to enter the ZOC.
     `-1' prevents entry entirely.  Defaults to `-1'.

 -- TableUU: `mp-to-leave-zoc' u1 u2 -> mp
     This table specifies extra movement points needed to leave the ZOC.
     `-1' prevents departure entirely.

 -- TableUU: `mp-to-traverse-zoc' u1 u2 -> mp
     This table specifies extra movement points needed to move within
     the ZOC.  `-1' prevents traversal entirely.

   If multiple units exert a ZOC into the same cell, then the mp cost is
the maximum of the different ZOC costs.

 -- TableUU: `mp-to-enter-own' u1 u2 -> mp
     This table specifies extra movement points needed to enter a
     unit's own cell, irrespective of ZOC.  `-1' prevents entry
     entirely.  Defaults to `-1'.

   Units may use up some of their materials when they move.  Consumption
happens after the move action, and only for successful moves.

 -- TableUM: `material-to-move' u m -> n
     This table is the amount of each material that a unit of type U
     must have in order to be able to move.

 -- TableUM: `consumption-per-move' u m -> n
     This table is the amount of each material used by a unit to do one
     move action.  The amount taken is independent of terrain.  If the
     unit has less than the required amount of any of these materials,
     it is immobilized until it gets more (this is tested before each
     move action; note that this does not affect any other action,
     including entering and leaving transports).

 -- TableUT: `control-range' u t -> dist
     This table is the distance out to which a unit's entry into a cell
     changes control of the surrounding terrain.  A distance of 0 means
     that the unit only changes control for its own cell, while a
     distance of -1 means that the unit does not affect control.
     Defaults to `-1'.

     At present, the maximum value for this is 0 (in other words, a unit
     cannot change control in adjacent cells).


File: xcdesign.info,  Node: Entry Action,  Next: Develop Action,  Prev: Movement Action,  Up: Actions

3.20.4 Entry Action
-------------------

Units can be inside other units, and have units inside them, in a
tree-like fashion.  There is no limit on the depth of the tree, but most
occupant-transport relationships have other limits.

 -- ActionType: `enter' unit
     This is the action to enter the given UNIT.

 -- UnitTypeProperty: `acp-to-enter-unit' acp
     This property is the number of acp a unit uses to do one entry
     action.  Defaults to `1'.

 -- TableUU: `can-enter-independent' u1 u2 -> t/f
     This table is true if a unit U1 can enter an independent unit U2.
     Defaults to `false'.

   Entering and leaving incur mp costs as does movment, but units with a
speed of 0 may enter and leave transports.

 -- TableUU: `mp-to-enter-unit' u1 u2 -> n
     This table is the extra movement points required for U1 to enter
     the transport U2, and vice versa (i.e. how much of transport's
     time is consumed by the process).

 -- TableUU: `mp-to-leave-unit' u1 u2 -> n
     Similar to entry cost.

   Note that these mp consumptions need not be symmetrical between
occupant and transport, so for instance a passenger can use 2 of its mp
to get on a transport, while costing the transport only one of its mp.

 -- TableUU: `ferry-on-entry' u1 u2 -> ferry-type

 -- TableUU: `ferry-on-departure' u1 u2 -> ferry-type
     This table specifies how much intervening terrain the unit U2
     entering or leaving transport U1 will have to cross on its own
     (and thus incur the terrain's mp costs and limitations).  Defaults
     to `over-border'.

 -- GlobalConstant: `over-nothing'
     This constant indicates no ferrying, occupant must pay all costs
     to go to destination cell.

 -- GlobalConstant: `over-own'
     This constant indicates that the transport ferries over terrain of
     its own cell.

 -- GlobalConstant: `over-border'
     This constant indicates that the transport ferries over any border
     terrain also.

 -- GlobalConstant: `over-all'
     This constant indicates that the transport ferries to destination
     cell, effectively putting occupant on middle of cell, on
     connection terrain if necessary.


File: xcdesign.info,  Node: Develop Action,  Next: Toolup Action,  Prev: Entry Action,  Up: Actions

3.20.5 Develop Action
---------------------

Development is an action performed by a unit with the sole effect of
increasing its side's tech level.  Development cannot be performed by
independent units.

 -- ActionType: `develop' u
     This is the action of developing the unit type U.  If the action
     is valid, then the tech level of the side will increase.  Unit
     types with any tech crossover will also have their tech levels
     adjusted.

 -- UnitTypeProperty: `acp-to-develop' acp
     This property is the number of action points used up by one develop
     action.  Defaults to `0', which disallows development.

 -- TableUU: `tech-per-develop' u1 u2 -> .01n
     This table is the gain in tech level resulting from a develop
     action, expressed as 1/100 of a level.  This value is stochastic.

 -- UnitTypeProperty: `tech-per-turn-max' tl
     This property is a ceiling on the total gain of tech level
     possible in one turn for each side and this unit type.  Defaults
     to `9999'.

 -- TableUM: `material-to-develop' u m -> n
     This table is the amount of each material a unit must have in
     order to do any development.


File: xcdesign.info,  Node: Toolup Action,  Next: Unit Creation Actions,  Prev: Develop Action,  Up: Actions

3.20.6 Toolup Action
--------------------

There are several stages in the construction of a unit: tooling up,
creation, and completion.  Tooling up is where the building unit
prepares to build, creation is the step where the new unit comes into
existence, and completion is where the new unit is brought up to being
operational.

   For the player, this is mostly automatic; if tooling must be done
first, a user command to build will generate the appropriate actions.

   Once the technology has been achieved, a unit that intends to
construct other units may need to tool up.  This is expressed as "tool
points" or "tp".  Tool points start at zero, can be increased by tooling
actions, and may gradually decline (representing wear and tear on the
equipment).

 -- ActionType: `toolup' u
     This is the action of tooling up to build a unit of type `u'.  The
     result is an increase in the tp for the acting unit.

 -- UnitTypeProperty: `acp-to-toolup' acp
     This property gives the number of acp needed to do a toolup action.
     Defaults to `0', which disallows tooling up.

 -- TableUU: `tp-per-toolup' u1 u2 -> tp
     This table is the number of tp gained by one tooling action.

 -- TableUU: `tp-to-build' u1 u2 -> tp
     This table is the number of toolup points needed before a unit of
     type U1 can create or build a unit of type U2.

 -- TableUU: `tp-max' u1 u2 -> tp
     This table is the maximum possible tooling.

 -- TableUU: `tp-attrition' u1 u2 -> tp
     This table is the number of .01 tool points automatically lost at
     the end of each turn.

 -- TableUU: `tp-crossover' u1 u2 -> n%
     This table is the number of tool points for U2 that is guaranteed
     to exist, expressed as a percentage of the tool points for U1.

     For instance, if `tp-crossover' is 80, and a unit's tool points for
     U1 is 10 out of a max of 20, and the max for U2 is also 20, then
     the unit will have tool points for U2 at least 8.


File: xcdesign.info,  Node: Unit Creation Actions,  Next: Unit Completion Action,  Prev: Toolup Action,  Up: Actions

3.20.7 Unit Creation Actions
----------------------------

When a constructing unit is tooled up, the build action creates a unit
immediately and puts it in its designated location, whether inside the
unit doing the building or somewhere nearby.  This new unit, however, is
incomplete, representing the keel of the ship or the surveyor's lines
for an airstrip.  Incomplete units are thus basically skeletons, with
some unit characteristics, but unable to move or act in any way.  They
also cannot have any occupants, unless the occupants are of a type that
can complete the unit.  Those occupants do not derive any protection or
other advantages from occupying the incomplete unit, and they are not
affected by the `occupant-can-build' limitation.

 -- ActionType: `create-in' u unit
     This action creates a new unit of type U occupying the given unit
     UNIT.  The unit UNIT must have room for the new unit.

 -- ActionType: `create-at' u x y z
     This action creates a new unit of type U in the open at X,Y,Z.
     The cell must have room for this new unit.

 -- TableUU: `acp-to-create' u1 u2 -> acp
     This table is the acp used by a unit of type U1 to create a a unit
     of type U2.  If zero, then U1 cannot create a U2.

 -- TableUU: `create-range' u1 u2 -> dist
     This table is the maximum distance at which a unit of type U1 can
     create a unit of type U2.

 -- TableUU: `cp-on-creation' u1 u2 -> cp
     This table is the completeness of a unit of type U2 when created
     by a unit of type U1.  Defaults to `1'.

 -- TableUM: `material-to-create' u m -> n
     This table is the total amount of a material type M needed to
     create a unit of type U.

 -- TableUM: `consumption-on-creation' u m -> n
     This table is the amount of a material type M consumed to create a
     unit of type U.

 -- TableUM: `takes-from-treasury' u m -> t/f
     This table is true if a constructing unit of type U can take
     material M if its own supply is insufficient to meet the
     `consumption-on-creation' or `consumption-per-build' (see below)
     requirements.

 -- TableUM: `supply-on-creation' u m -> n
     This table is the amount of supply of each material type M to give
     a newly created unit of type U.  This supply is newly generated,
     does not come from anywhere else.  (Note that players could cheat
     by creating units, taking their supply, and never completing them.)

 -- TableUU: `morale-on-creation' u1 u2 -> n
     This table is the ratio of morale of a unit of type U2 to the
     morale of its creator U1, with 100 meaning that the new unit has
     the same morale as its creator.  Defaults to `100'.

 -- TableUU: `opinions-on-creation' u1 u2 -> n
     This table is the ratio of the opinions of a unit of type U2 to
     the opinions of its creator U1, with 100 meaning that the new unit
     has the same opinions as its creator.  Defaults to `100'.


File: xcdesign.info,  Node: Unit Completion Action,  Next: Repair Action,  Prev: Unit Creation Actions,  Up: Actions

3.20.8 Unit Completion Action
-----------------------------

Once an incomplete unit has been created, other units can help to
complete it.

 -- ActionType: `build' unit
     This action adds to the completeness of UNIT.  If the unit becomes
     complete, it will be given its initial supply, acp, name, etc.

 -- TableUU: `acp-to-build' u1 u2 -> acp
     This table is the acp used up by one build action by a unit of type
     U1 when buiding a unit of type U2.

 -- TableUU: `cp-per-build' u1 u2 -> cp
     This table is the amount of completeness of a unit of type U2
     added by each completion action performed by a unit of type U1.
     If `0', then U1 cannot contribute to completing U2.  Defaults to
     `1'.

 -- TableUM: `material-to-build' u1 m -> n
     This table is the amount of each material type M that U1 must have
     in order to build anything at all.

 -- TableUM: `consumption-per-build' u2 m -> n
     This table is the total amount of each material type M consumed by
     the completion of a unit of type U2.  To calculate the consumption
     of a single build action, this amount is divided by U2's cp and
     multiplied by the number of cp added by the action.  Fractions
     round up when the unit's cp is low, so that the full consumption
     happens.

 -- TableUU: `build-range' u1 u2 -> dist
     This table is the maximum distance allowed between a unit of type
     U1 and the incomplete unit of type U2 it is working on.  Defaults
     to `0', which requires the two units to be in the same cell.

   At a given point, incomplete units can make progress towards
completion on their own.  This is automatic because incomplete units
are unable to act, and occurs at a constant specified rate.  Automatic
completion always occurs, even if other units are doing build actions
at the same time.  The incomplete unit must have any necessary supplies.

 -- UnitTypeProperty: `cp-to-self-build' cp
     This property is the minimum completeness of the unit necessary
     before it can work on itself.

 -- UnitTypeProperty: `cp-per-self-build' cp
     This property is the completeness added each turn when a unit
     works on itself.

 -- TableUM: `supply-on-completion' u m -> n
     This table is the minimum amount of supply of each material type M
     guaranteed to a newly completed unit of type U.  If not already
     available to the unit, it will be newly generated.

 -- UnitTypeProperty: `cp-attrition' .01n%
     This property is the chance that an incomplete unit will lose cp.
     If the unit loses all of its cp, it vanishes.

   Cancelled build tasks can result in the disbanding of the incomplete
unit and recovery of the cp and materials in the unfinished unit.

 -- GlobalVariable: `disband-unfinished-units' t/f
     This variable is true if incomplete units not being worked on are
     automatically disbanded.

 -- GlobalVariable: `salvage-unfinished-cps' t/f
     This is true if the disbanded incomplete unit returns its
     completeness points.

 -- UnitProperty: `cpstash' n
     This property records unused completeness points.

 -- TableUU: `builder-can-reuse-cp' u1 u2 -> t/f
     This is true if a builder of type U1 can use its cpstash to add to
     the completeness of a unit of type U3.

 -- GlobalVariable: `salvage-unfinished-materials' t/f
     This is true if the disbanded incomplete unit returns the
     materials used while building it.


File: xcdesign.info,  Node: Repair Action,  Next: Material Production Action,  Prev: Unit Completion Action,  Up: Actions

3.20.9 Repair Action
--------------------

Units can restore their own and each other's hp by doing repairs.
Repair requires a repair action.  The action points for this action are
taken from both the unit being repaired and the repairer (using the
same table `acp-to-repair').  When a unit repairs itself, the action
cost is counted once only.

 -- ActionType: `repair' unit
     This is the action of repairing the given UNIT.

 -- TableUU: `acp-to-repair' u1 u2 -> acp
     This table is the number of action points used up by a unit of
     type U1 doing one repair action on a unit of type U2.  Defaults to
     `0', which disallows the action.

 -- TableUU: `hp-per-repair' u1 u2 -> .01hp
     This table is the hundredths of a hp that a single repair action
     by a unit of type U1 restores to a unit of type U2.  The fraction
     of this over 100 is added to hp directly, while the < 100 fraction
     is added probabilistically.  (For example, a value of 160 means
     that 1 hp will be added for each action, and there is a 60% chance
     that a second hp will be added also.)

   Materials may be needed and/or consumed during repair.  The
materials will be taken from the unit being repaired, then from the
repairer.

 -- TableUM: `material-to-repair' u m -> .01n
     This table is the amount of each material type M needed for one
     repair action.  As with `hp-per-repair', the < 100 part is
     average, and > 100 is guaranteed.

 -- TableUM: `consumption-per-repair' u m -> .01n
     This table is the amount of each material type M used up by a
     repair action.

   The repairing unit must also not be too damaged itself to do repairs.

 -- TableUU: `hp-to-repair' u1 u2 -> hp
     This table is the minimum hp level required of a unit of type U1
     to repair a unit of type U2.  If less, then U1 is too damaged to
     do any repairing.  Defaults to `1', which allows repair always.

   The following are not really part of the repair action definition,
since they occur automatically, but they share many of the tables above.

 -- TableUU: `auto-repair' u1 u2 -> .01hp
     This table is the amount of repair (in 1/100 hp) that U1 will do
     on any unit of type U2 within range (`auto-repair-range').  As
     with `hp-per-repair', the < 1.00 part is average, and > 1.00 is
     guaranteed.  Material requirements and usage are as for repair
     actions.  Defaults to `0', which disallows auto-repair.

 -- TableUU: `auto-repair-range' u1 u2 -> dist
     This table is the distance out to which U1 will auto-repair any
     damaged U2.  A value of `0' requires the two units to be in the
     same cell, while a value of `-1' means that U2 must be either an
     occupant or transport of U1.


File: xcdesign.info,  Node: Material Production Action,  Next: Material Extraction Action,  Prev: Repair Action,  Up: Actions

3.20.10 Material Production Action
----------------------------------

Units can produce materials by explicit action.

 -- ActionType: `produce' m
     This action results in a quantity of material M coming into
     existence.

 -- TableUM: `acp-to-produce' u m -> acp
     This table is the acp used up by one `produce' action.

 -- TableUM: `material-per-production' u m -> n
     This table is the amount of material produced by U when acting to
     produce type M.

 -- TableUM: `material-to-produce' u m -> n
     This table is the amount of each material a unit must have in
     order to produce any material.  This material is not consumed by
     the production action.


File: xcdesign.info,  Node: Material Extraction Action,  Next: Material Transfer Action,  Prev: Material Production Action,  Up: Actions

3.20.11 Material Extraction Action
----------------------------------

Units can extract materials from the terrain or from nearby units.

 -- ActionType: `extract' x y m n
     This action results in the transfer of a quantity N of material M
     from the cell at X,Y.

 -- TableUM: `acp-to-extract' u m -> acp
     This table is the acp used up by one action to extract material of
     type M.

 -- TableUM: `material-to-extract' u m -> acp
     This table is the material required to do any extraction actions.


File: xcdesign.info,  Node: Material Transfer Action,  Next: Side Change Action,  Prev: Material Extraction Action,  Up: Actions

3.20.12 Material Transfer Action
--------------------------------

Although most movement of materials between units happens automatically
(see backdrop economy description), players can also do it explicitly.
Players can both take materials from other units, and give a unit's
materials to others.

 -- ActionType: `transfer' unit m n
     This is the action of transferring supply to the given unit UNIT.
     The desired amount is N; if M is a valid material type, then only
     that type will be transferred, otherwise the action will transfer
     all types of materials possible.  The actual transfer amounts may
     be less than N.

 -- TableUM: `acp-to-unload' u1 m -> acp

 -- TableUM: `acp-to-load' u1 m -> acp
     These tables are the number of action points used up by one
     material transfer action from U1 to U2.  The amount is independent
     of the material type being transferred.  If either value is `0',
     then the material cannot be transferred.

 -- TableUM: `unload-max' u1 m -> n

 -- TableUM: `load-max' u2 m -> n
     These two tables determine how much of material M can be
     transferred out of a unit of type U1 and into one of type U2 in
     one transfer action.  The actual quantity transferred by the action
     is the minimum of these two values.  A value of `0' disallows
     manual transfer.  Both default to `-1', which allows any amount to
     be transferred.


File: xcdesign.info,  Node: Side Change Action,  Next: Disband Action,  Prev: Material Transfer Action,  Up: Actions

3.20.13 Side Change Action
--------------------------

 -- ActionType: `change-side' side
     This is the action of changing the unit's side to SIDE.  The SIDE
     can be any allowable side, and the unit may be any unit controlled
     by the actor's side.

 -- UnitTypeProperty: `acp-to-change-side' acp
     If the value of this property is greater than 0, then this type of
     unit can be ordered to change to another given side.  If the unit
     is not a type that can act, then the side change happens
     immediately, instead of as an action, and no acp cost is incurred.
     The type must also be allowed to be on the new side.


File: xcdesign.info,  Node: Disband Action,  Next: Part Transfer Action,  Prev: Side Change Action,  Up: Actions

3.20.14 Disband Action
----------------------

Disbanding is the voluntary and controlled destruction of a unit,
performed by the unit itself or another unit.  A disbanded unit always
vanishes, rather than changing to its `wrecked-type'.

 -- ActionType: `disband' unit
     This is the action of removing hp from UNIT.  The unit will vanish
     if all its hit points are gone.

 -- UnitTypeProperty: `acp-to-disband' acp
     If the value of this property is greater than 0, then this is the
     acp that will be used up to do one disband action.  If the unit is
     not a type that can act, then the disband happens immediately,
     instead of as an action, and no acp cost is incurred.

 -- UnitTypeProperty: `hp-per-disband' hp
     This table is the number of hp lost in a disband action.  Defaults
     to `0', which disallows disbanding.

   A disbanded unit can be scavenged for materials.

 -- TableUM: `supply-per-disband' u m -> n%
     This table is the percentage of the unit's supply that is
     recovered from a single disband action.  If the value is zero,
     then the unit's supply will not be recovered by the disbanding
     process, and be lost permanently.  If any supply remains when the
     unit's hp is 0, then that supply will be lost also.  Defaults to
     `100', which means that the entire supply will be recovered on the
     first disband action.

   Note that if an essential supply is 100% recovered before the unit is
completely disbanded, then it may die from starvation first.  A
partly-disbanded unit may still acquire supply from nearby units, via
the backdrop economy.

 -- TableUM: `recycleable-material' u m -> n
     This table is the quantity of each type of material that becomes
     available when a unit is completely disbanded.  The materials go to
     transports, occupants, and nearby units, in that order.  Any
     materials exceeding capacities of these units will be discarded.
     These materials become available only when the unit vanishes.


File: xcdesign.info,  Node: Part Transfer Action,  Next: Type Change Action,  Prev: Disband Action,  Up: Actions

3.20.15 Part Transfer Action
----------------------------

Units of variable size can transfer parts of themselves to other units,
or create a new unit.

 -- ActionType: `transfer-part' n unit
     This action moves N parts of the actee to UNIT, or creates a new
     unit if UNIT is omitted.  If N is negative, this takes from UNIT
     instead.  If the action takes all the parts of any involved unit,
     then it vanishes.

 -- UnitTypeProperty: `acp-to-transfer-part' acp
     This property is the number of acp used up by the unit when doing
     a part transfer action.  If 0, then part transfer is not allowed.


File: xcdesign.info,  Node: Type Change Action,  Next: Combat Actions,  Prev: Part Transfer Action,  Up: Actions

3.20.16 Type Change Action
--------------------------

Units may change their type.

 -- ActionType: `change-type' u
     This action changes the type of the actee unit to the type U.
     Upon changing, the relationships of the unit with the world and
     with other units will be recalculated; occupants that can no longer
     stay in the unit will be ejected or disappear.  The unit itself
     may vanish or wreck, if it is in the open on a terrain type that
     will cause units of the new type to vanish or wreck.

 -- TableUU: `acp-to-change-type' u1 u2 -> acp
     This table is the number of acp needed to change a unit of type U1
     into a unit of type U2.  If the value is 0, then the change is
     never possible.

 -- TableUM: `material-to-change-type' u m -> n
     This is the amount of each material type M required for a unit to
     change into a unit of type U.


File: xcdesign.info,  Node: Combat Actions,  Next: Capture Action,  Prev: Type Change Action,  Up: Actions

3.20.17 Combat Actions
----------------------

Xconq combat is somewhat abstract; the attacking player decides what
sort of attack to mount and perhaps when to retreat, but all else
happens automatically.

   The attacker/defender distinction applies only to a single action.

 -- ActionType: `attack' unit commit
     This action is a direct attack on the given UNIT, at a commitment
     level of COMMIT.  The UNIT must be known to the attacking unit's
     side.

 -- ActionType: `overrun' x y z commit
     This action is a combined attack/capture/move action.  The basic
     theory of an overrun is that the actor will attack, capture, or
     co-occupy the cell at X,Y, elevation `z', with a commitment of
     COMMIT.  The exact effects depend on the types and sides of units
     in the destination.

   [The commitment levels are currently ignored.]

 -- TableUU: `acp-to-attack' u1 u2 -> acp
     This table is the number of action points used up by a unit U1
     when attacking a unit of type U2.  If the value is 0, attack is
     not allowed.  Defaults to `1'.

 -- TableUU: `acp-to-defend' u1 u2 -> acp
     This table is the number of action points used up by a unit U1
     when defending against an attack by a unit of type U2.  If the
     value is 0, attack is not allowed.  Defaults to `1'.

 -- TableUU: `attack-range-min' u1 u2 -> dist
     This table is the minimum distance at which a unit can attack
     another.  A value of 0 means that units in the same cell can fight.

 -- TableUU: `attack-range' u1 u2 -> dist
     This table is the maximum distance at which a unit can attack
     another.  A value of 1 means that units in adjacent cells may
     fight, while a value of 0 means that only units in the same cell
     may fight.  Defaults to `1'.

 -- GlobalVariable: `combat-model' n
     This variable specifies the algorithm used for combat resolution.

     A value of 0 specifies single attack/counterattack with odds
     determined by the `hit-chance' table.

     A value of 1 specifies multi-round combat with odds computed from
     attack and defend strength, combat continuing until a participant
     is destroyed.

   One round of combat consists of an attack, a reaction, and a
calculation of effects.

   The defender's reaction is completely automatic, and occurs as part
of the combat round.  The defender's side does not get a chance to
decide what to do until the next round, although doctrine may constrain
the set of reactions.

 -- TableUU: `surrender-chance-per-attack' u1 u2 -> n%
     This table is the chance that U2 will surrender to U1 immediately
     upon being attacked.

 -- TableUU: `withdraw-chance-per-attack' u1 u2 -> n%
     This table is the chance that U2 will retreat from U1 immediately
     upon being attacked.

 -- TableUU: `acp-for-retreat' u1 u2 -> acp
     This table is the extra acp that U2 can get in order to make a
     withdrawal possible.

 -- TableUU: `counterattack' u1 u2 -> n
     This table is the strength of a defender's reaction to an attack.
     If 0, the defender does not counterattack; if 100, the defender
     counterattacks at the same level as if it attacked normally.
     Defaults to `100'.

   In an overrun action, if all the defending units are destroyed, the
attacker has sufficient acp and mp, and the destination is safe to
enter, then the attacker can move into the defenders' cell.

   Firing is a kind of attack that can take place at a distance,
involves no commitment or counterattack, and for which the type of ammo
may be selected.

 -- ActionType: `fire-at' unit m
     This is the action of firing at a given UNIT.  If M is a valid
     material type, then that type will be used as ammo, otherwise all
     available types will be used together.

 -- ActionType: `fire-into' x y z m
     This is the action of firing into the cell at X,Y.  If Z is a
     valid altitude, then the fire will be concentrated on units at that
     elevation.  If M is a valid material type, then that type will be
     used as ammo, otherwise all available types will be used together.

 -- UnitTypeProperty: `acp-to-fire' acp
     If this property is greater than 0, this type may attack by firing.

 -- TableUU: `acp-to-be-fired-on' u1 u2 -> acp
     This table is the acp lost when a unit is being fired upon.
     Defaults to `1'.

 -- UnitTypeProperty: `range' dist
     This property is the maximum distance in cells to which a unit can
     fire.  Defaults to `1'.

 -- UnitTypeProperty: `range-min' dist
     This property is the minimum distance in cells to which a unit can
     fire.

 -- UnitTypeProperty: `fire-angle-max' n%
     This property is the highest angle at which a unit may fire,
     expressed as a percentage of 45 degrees.  The default of `0' means
     that the unit's fire has a flat trajectory and that the target
     must be on an unobstructed straight line from the firing unit.
     For values greater than 0, this angle is used to calculate whether
     the parabolic trajectory clears all intervening terrain.

 -- TableUT: `weapon-height' u t -> elev
     This property is the effective height of a unit's weapons when in
     the given terrain.

   Both attack and fire combat calculate hits and damage in a similar
way, although they may use different tables.

 -- TableUU: `hit-chance' u1 u2 -> n%
     This table is the basic chance that a unit of type U1 will
     actually hit a unit of type U2.  If the hit chance is `0', then
     the unit may never attack a unit of that type.

 -- TableUU: `fire-hit-chance' u1 u2 -> n%
     This table is the basic chance that fire from a unit of type U1
     will actually hit a unit of type U2.  If the hit chance is `0',
     then the unit may never fire at a unit of that type.  If the value
     is `-1', then the value of this is the same as the value of
     `hit-chance'.  Defaults to `-1'.

 -- TableUT: `attack-terrain-effect' u1 t -> n%

 -- TableUT: `defend-terrain-effect' u2 t -> n%

 -- TableUT: `fire-attack-terrain-effect' u1 t -> n%

 -- TableUT: `fire-defend-terrain-effect' u2 t -> n%
     These tables specify the effect of attacker's and defender's
     respective terrains on `hit-chance' or `fire-hit-chance'.  These
     chances are multiplied with the basic hit chance.  Default to
     `100'.

 -- TableUU: `hit-cxp-effect' u1 u2 -> n
     This table is the effect of combat experience on hit chance.  Its
     value is interpolated according to actual experience (N is the
     effect when U1 is at its maximum possible experience), then
     multiplied with the hit chance.  Defaults to `100'.

   The effectiveness of fire may be less at long ranges.  If the range
to the target is greater than `hit-falloff-range', the chance of
hitting it will be reduced by the interpolation between the short-range
chance and that chance multiplied by the value of
`hit-at-max-range-effect'.  For example, if a unit's range is 4, its
hit falloff range is 1, the basic hit chance is 60%, and the max range
effect is 50%, then its hit chance at range 2 is 50%, at range 3 is
40%, and at range 4 is 30%.

 -- TableUU: `hit-falloff-range' u1 u2 -> n
     This table is the maximum range at which the effectiveness of
     combat is not affected by distance.  Defaults to `1'.

 -- TableUU: `hit-at-max-range-effect' u1 u2 -> n%
     This is the multiplier for the effectiveness of firing at the
     maximum range possible.  Defaults to `100'.

 -- TableUU: `damage' u1 u2 -> hp
     This table is the basic amount of damage caused by a successful
     attack.  The value is a dice spec.  Defaults to `1'.

 -- TableUU: `fire-damage' u1 u2 -> hp
     This table is the basic amount of damage caused by a successful
     firing.  The value is a dice spec.  If the value is `-1', then it
     is the same as `damage'.  Defaults to `-1'.

 -- TableUU: `tp-damage' u1 u2 -> tp
     This table is the amount of damage to a unit's tooling caused by a
     successful attack.  The value is a dice spec.

 -- TableUU: `damage-cxp-effect' u1 u2 -> n
     This table is the effect of combat experience on damage.  Its
     value is interpolated according to actual experience (so that N is
     the effect when U1 is at its maximum experience), then multiplied
     with both the dice size and the addend of the damage spec.
     Defaults to `100'.

 -- TableUU: `hp-min' u1 u2 -> hp
     This table is the lowest hp possible for U1 from attacks by U2.
     Further attacks by U2 are still valid, but can do no further
     damage.

   You can set a unit to use a material as ammo.

 -- TableUM: `consumption-per-attack' u1 m -> n

 -- TableUM: `consumption-per-fire' u1 m -> n

 -- TableUM: `hit-by' u2 m -> n
     These tables specify material consumption in combat.  For each
     material `m', the min of these two values is the amount of u1's
     supply used up in an attack on u2.  Both default to `0'.

 -- TableUM: `material-to-attack' u m -> n
     This table is a minimum of each material type M that a unit must
     have to engage in direct attack or to defend against it.  This
     minimum is not necessarily used up in combat, it just needs to be
     present.

 -- TableUM: `material-to-fire' u m -> n
     This table is a minimum of each material type M that a unit must
     have to fire.  This minimum is not necessarily used up, it just
     needs to be present.

   Transports can protect their occupants, and vice versa.

 -- TableUU: `protection' u1 u2 -> n%
     This table gives the effect of occupants of type U1 on the chance
     of another unit's attack hitting their transport U2, as well as
     the effect of the transport U1 on the chance that occupants of
     type U2 will be hit.

     For the transport, this is a multiplier, where 100 has no
     protection, values less than 100 decrease hit chance, and values
     greater than 100 increase it.  Each occupant will be taken into
     account when computing transport's protection.

     If the transport is the unit being hit, then the value of this
     table is the probability that an occupant of type U2 will be hit.

     Defaults to `100'.

   A transport's destruction may leave occupants stranded on hex, will
do some sort of auto-escape or die if terrain is hostile.

   Units stacked together can protect each other.

 -- TableUU: `stack-protection' u1 u2 -> n%
     This table is the effect of units of type U1 on attacks on units
     of type U2 that are in the same cell.  The effect is similar to
     that described for the `protection' table.  Defaults to `100'.

   Units may also act to protect every other unit in a cell, whether
occupant, transport, or stack.

 -- TableUU: `cellwide-protection-for' u1 u2 -> n%
     This table is the effect of any unit of type U1 in the same cell
     on attacks against any unit of type U2 in the cell.  Defaults to
     `100'.

 -- TableUU: `cellwide-protection-against' u1 u2 -> n%
     This table is the effect of any unit of type U1 on any attack on
     any unit in the cell by units of type U2, expressed as a
     percentage multiplier.  Defaults to `100'.

   Several other side-effects of combat may also be defined.

   Units can retreat if they are about to be damaged; the retreat
attempt is automatic, and will be in a valid direction that is away
from the attacker.  The retreat attempt will fail if there is no
direction that the unit may move, or if has insufficient materials,
acp, etc to do the movement.  If the attempt is successful, then the
unit will not be damaged; otherwise it must take the hit.

 -- TableUU: `retreat-chance' u1 u2 -> n%
     This table is the chance that U2 will attempt to retreat if it is
     hit by U1.

   Units may gain experience as a result of combat.

 -- TableUU: `cxp-per-combat' u1 u2 -> cxp
     This table is the number of combat experience points gained by U1
     by surviving a combat round with U2.  Both attackers and defenders
     gain experience equally.

   Unit morale may change as a result of combat, either positively or
negatively.

 -- TableUU: `morale-hit' u1 u2 -> .01n
     This table is the 100ths of morale gained as the result of a unit
     of type U1 successfully hitting a unit of type U2.  The part of
     the number > 100 is gained always, the part modulo 100 is the
     probability of gaining 1.

 -- TableUU: `morale-hit-by' u1 u2 -> .01n
     This table is the 100ths of morale lost as the result of a unit of
     type U1 being hit by a unit of type U2.

   In combat model 1, the outcome is determined by relative attack and
defense strengths.

 -- UnitTypeProperty: `attack' n

 -- UnitTypeProperty: `defend' n
     These values represent the relative attack and defense strengths
     of a unit type.

 -- UnitTypeProperty: `encounter-result' list
     This property specifies other possible outcomes of an attack.  The
     LIST is an optionally weighted list of the form
          `( [ WEIGHT ] RESULT ... )'
     Each RESULT has one of the following forms:
          `(unit TYPE MESSAGE)'
          `(unit (TYPE SIDE) MESSAGE)'
          `(vanish nil MESSAGE)'
     If the chosen RESULT starts with `unit', then the encountered unit
     changes type to the given type, and if the SIDE is specified (as a
     side id), then it will change side also.

     If the chosen result starts with `vanish', then the encountered
     unit simply vanishes permanently.

     At present, this property is only used in model 1 combat, where its
     results are checked before combat.  Defaults to `()'.

 -- Symbol: `vanish'
     This keyword indicates that the encounter result is for the
     encountered unit to vanish.


File: xcdesign.info,  Node: Capture Action,  Next: Detonation Action,  Prev: Combat Actions,  Up: Actions

3.20.18 Capture Action
----------------------

A unit may attempt to capture another unit directly.  If successful,
the captured unit's side changes to that of the capturing unit.

 -- ActionType: `capture' unit
     This is the action of capturing the given UNIT.

 -- TableUU: `acp-to-capture' u1 u2 -> acp
     This table is the number of acp used up by a `capture' action.
     Defaults to `0', which disallows capture.

 -- TableUU: `bridge' u1 u2 -> t/f
     This table is true if a unit of type U1 can be captured by a unit
     of type U2 even if U1 is on a type of terrain impassable to the
     capturing unit.  Defaults to `false'.

 -- TableUU: `capture-chance' u1 u2 -> n%
     This table is the basic chance for U1 to capture U2.

 -- TableUU: `independent-capture-chance' u1 u2 -> n%
     This table is the basic chance for U1 to capture an independent
     unit of type U2.  If the value is `-1', then the chance of capture
     is given by the `capture-chance'.  Defaults to `-1'.

 -- TableUT: `scuttle-chance' u t -> n%
     This table is the chance that a unit whose capture is guaranteed
     will destroy itself instead.  Scuttling is destructive, so unit
     changes to `wrecked-type'.  Occupants of an about-to-be-captured
     unit will also attempt to scuttle.

 -- TableUU: `occupant-escape-chance' u1 u2 -> n%
     This table is the chance that an occupant U1 will escape during
     the capture of a unit of type U2.  Occupants that do not escape
     are either captured themselves or destroyed, depending on their
     type and the capturing unit's side.

 -- TableUU: `hp-to-garrison' u1 u2 -> n
     This table is the number of hp that will be taken from the
     capturing unit U1 in order to guard a captured U2.  If the amount
     is the unit's full hp, then the unit will vanish and any occupants
     will be distributed to the captured unit, to open terrain, or will
     vanish themselves if there is no other option.

 -- TableUU: `countercapture' u1 u2 -> n
     This table defines the defending unit's reaction to the capture
     attempt.  If 0, then the unit does not react to the capture
     attempt.

   Captures can also affect combat experience, but has different
effects on the capturing and captured units.

 -- TableUU: `cxp-per-capture' u1 u2 -> cxp
     This table is the number of combat experience points gained by U1
     for capturing U2.

 -- UnitTypeProperty: `cxp-on-capture-effect' n
     This property gives the change in a unit's cxp due to being
     captured, expressed as a multiplier.  Defaults to `100'.

   Capture of a unit may also yield an extra dividend of knowledge, in
the form of information known to the other side.

 -- UnitTypeProperty: `see-terrain-if-captured' n%
     If the world's terrain is not already seen, this property is the
     chance that the capturing side will get all of the terrain view
     collected by the former side of the captured unit.  This does not
     apply to any unit views, just terrain.

 -- TableUU: `see-others-if-captured' u1 u2 -> n%
     This table is the chance that the capturing side will get a view
     of a unit of type U2 belonging to the other side.  The chance
     applies to each unit of that type when a unit of type U1 is
     captured.


File: xcdesign.info,  Node: Detonation Action,  Next: Terrain Alteration Actions,  Prev: Capture Action,  Up: Actions

3.20.19 Detonation Action
-------------------------

Detonation is an action and/or behavior that causes damage
indiscriminately.  The action specifies the location of the detonation,
which may be in the unit's cell or an adjacent one.  A unit that
detonates loses hp, changing to its `wrecked-type' if it loses all of
its hp.  It also hits every unit within a specified radius.  Detonation
may also affect terrain within a specified radius.

 -- ActionType: `detonate' x y z
     This action detonates the actee at the given location X,Y,Z.

 -- UnitTypeProperty: `acp-to-detonate' acp
     This property is the number of action points used by one detonate
     action.  Defaults to `0', which disallows detonation.

 -- UnitTypeProperty: `hp-per-detonation' hp
     This property is the number of hp lost in each detonation.

 -- TableUU: `detonation-unit-range' u1 u2 -> dist
     This table gives the range of effect from detonation of U1.  The
     severity falls off according to the inverse square law
     extrapolated from the adjacent cell damage.  (1/4 severity at
     range 2, 1/9 at 3, etc.)

 -- TableUU: `detonation-damage-at' u1 u2 -> hp
     This table is the severity of U1's hit on a unit U2 in the same
     cell.

 -- TableUU: `detonation-damage-adjacent' u1 u2 -> hp
     This table is the severity of U1's hit on a unit U2 in an adjacent
     cell.

 -- TableUT: `detonation-terrain-range' u t -> dist
     This table specifies the maximum distance at which a detonation
     will affect terrain of type T.

 -- TableUT: `detonation-terrain-damage-chance' u t -> n%
     This is the chance that the detonation will have an effect on the
     terrain.

 -- TableTT: `terrain-damaged-type' t1 t2 -> n
     Relative chance that terrain of type T1 damaged by a detonation
     will change into another type T2.

   The following tables and properties can be used for units that cannot
detonate deliberately by doing a detonate action.

 -- TableUU: `detonate-on-hit' u1 u2 -> n%
     This table is the chance that a hit on U1 by a unit of type U2
     will cause it to detonate (once).  Noncombat reductions in hp,
     such as attrition, have no effect.

 -- UnitTypeProperty: `detonate-on-death' n%
     This property is the chance that if this type is about to die from
     a combat hit, it will detonate first.

 -- TableUU: `detonate-on-capture' u1 u2 -> n%
     This table is the chance that a unit of type U1 will detonate if a
     capture by a unit of type U2 is about to succeed.

 -- TableUU: `detonate-on-approach-range' u1 u2 -> dist
     When a unit of type U2 on a non-trusted [?] side appears at a
     distance of DIST or less, then U1 will detonate.  If `-1', then
     unit will not detonate upon approach.  Defaults to `-1'.

 -- TableUT: `detonation-accident-chance' u t -> n.f%
     This table is the chance that the unit will detonate spontaneously.
     This is checked once/turn, at the beginning of the turn, and also
     upon each entry to a cell, if moving.


File: xcdesign.info,  Node: Terrain Alteration Actions,  Prev: Detonation Action,  Up: Actions

3.20.20 Terrain Alteration Actions
----------------------------------

 -- ActionType: `alter-terrain' x y t
     This action changes the type of the cell at X,Y to T.

 -- ActionType: `add-terrain' x y dir t
     This action adds a connection or border of type T to the cell at
     X,Y, in direction DIR.

 -- ActionType: `remove-terrain' x y dir t
     This action removes a connection or border of type T to the cell
     at X,Y, in direction DIR.

 -- TableUT: `acp-to-add-terrain' u t -> n

 -- TableUT: `acp-to-remove-terrain' u t -> n
     For auxiliary terrain types, these tables are the costs to add or
     remove.  For cell terrain, the costs of removing the old type and
     adding the new type are added together.  If the value is 0, then
     that type of terrain may not be added or removed.  As a special
     exception, cell terrain may have a cost to remove of 0, so that
     the sum of add and remove costs can be as low as 1; in that case,
     a value of -1 disallows removal.  Both default to `0'.

 -- TableUT: `alter-terrain-range' u t -> n
     This table is the maximum distance at which a unit can alter
     terrain T.  Defaults to `0', which means that the unit can change
     only the terrain in its own cell.

   Note that if `see-terrain-always' is false, then other sides will
not see the terrain change unless they are viewing the altered terrain.

 -- TableUM: `material-to-add-terrain' u m -> n
     This table is the amount of material necessary to perform an
     `add-terrain' or `alter-terrain' action.

 -- TableUM: `material-to-remove-terrain' u m -> n
     This table is the amount of material necessary to perform a
     `remove-terrain' action.

 -- TableTM: `consumption-per-add-terrain' t m -> n
     This table is the amount of material M necessary for any unit to
     add terrain of type T.

 -- TableTM: `material-per-remove-terrain' t m -> n
     This table is the amount of material of type M that becomes
     available as the result of removing terrain T.


File: xcdesign.info,  Node: Backdrop,  Next: Behavior,  Prev: Actions,  Up: Reference Manual

3.21 Backdrop
=============

This section describes the parameters affecting backdrop computations.

* Menu:

* Years and Days::
* Temperature Variation::
* Temperature Effects::
* Wind Variation::
* Unit Production and Consumption::
* Terrain Production and Consumption::
* Supply Lines::
* Side Research::
* Unit Research::
* Terrain Attrition::
* Terrain Accident::
* Unit Revolt::
* Unit Surrender::


File: xcdesign.info,  Node: Years and Days,  Next: Temperature Variation,  Up: Backdrop

3.21.1 Years and Days
---------------------

Cyclic changes in the environment are governed by a yearly cycle or a
daily cycle whose length must be defined.

 -- WorldProperty: `year-length' n
     This property is the number of turns in an annual cycle.  If less
     than `2', then no seasonal effects will be calculated.

 -- WorldProperty: `day-length' n
     This property is the number of turns in a single day.  If less than
     `2', then day and night will not be calculated.

   Note that `year-length' and `day-length' are completely independent
of each other, and it is possible to have days that are longer than
years.

 -- AreaProperty: `initial-year-part' n
     This property is the season of the first turn in the game.

 -- AreaProperty: `initial-day-part' n
     This property is the hour of the first turn in the game, in 100ths
     of a day part.

 -- GlobalVariable: `season-names' list
     This global is a list of which turns in a year should be called
     which seasons.  It has the form `(... (n1 n2 name) ...)'.
     Defaults to `()'.

     A twelve-turn year with four seasons would be
          ((0 2 "winter") (3 5 "spring") (6 8 "summer") (9 11 "autumn"))
     If any number ranges overlap, then the first match will be used,
     while if a particular turn has no named season, then it will go
     unnamed in the display.

 -- UnitTypeProperty: `acp-season-effect' interpolation-list
     This property is the effect of the seasons on acp.  The input
     value is the year part, and the result value is added to the basic
     `acp-per-turn'.  Defaults to `()'.

 -- WorldProperty: `daylight-fraction' n%
     This property is the percentage of the world's circumference that
     has daylight.  Defaults to `50'.

 -- WorldProperty: `twilight-fraction' n%
     This property is the percentage of the world's circumference that
     has daylight and twilight.  Defaults to `60'.

 -- AreaProperty: `sun' x y
     This property is the initial position of the sun over the area.
     Defaults to the exact middle of the area.


File: xcdesign.info,  Node: Temperature Variation,  Next: Temperature Effects,  Prev: Years and Days,  Up: Backdrop

3.21.2 Temperature Variation
----------------------------

 -- TerrainTypeProperty: `temperature-average' n
     This property is the average temperature for each type of terrain.

 -- TerrainTypeProperty: `temperature-variability' n
     This property is the amount of totally random variation in the
     temperature in each cell.

 -- GlobalVariable: `temperature-year-cycle' ((x y)
          interpolation-list)...
     This global is a list of interpolation lists used to set basic
     temperatures at given points in the area.  The input value for
     each list is the current year part, while the result is the
     temperature at X,Y.  Then for each point in the area, its
     temperature is the interpolation of the temperature at the two
     nearest given points.  Defaults to `()'.

 -- TerrainTypeProperty: `temperature-moderation-range' distance
     This property is the radius of the area whose raw temperatures
     will be averaged to get the actual temperature.  This can be very
     time-consuming to calculate, so only values of 0 (no averaging)
     and 1 (average with adjacent cells) are recommended.


File: xcdesign.info,  Node: Temperature Effects,  Next: Wind Variation,  Prev: Temperature Variation,  Up: Backdrop

3.21.3 Temperature Effects
--------------------------

 -- UnitTypeProperty: `acp-temperature-effect' interpolation-list
     This property is the effect of temperature on acp.  The input
     value is temperature, and the result value is multiplied with acp,
     after it has been modified for night effect, but before
     modification for season.  The result is divided by 100, so an
     effect < 100 reduces acp, an effect of 100 has no effect, and an
     effect > 100 increases acp.  Defaults to `()'.

 -- UnitTypeProperty: `consumption-temperature-effect'
          interpolation-list
     This property is the effect of temperature on material consumption.
     Defaults to `()'.

 -- UnitTypeProperty: `temperature-attrition' interpolation-list
     This property is the effect of temperature on a unit's hp.  The
     input value is temperature, and the result value is the number of
     hp that the unit will lose each turn at that temperature.
     Defaults to `()'.

   Transports can protect their occupants from temperature extremes.

 -- TableUU: `temperature-protection' u1 u2 -> t/f
     This is true if transports of type U1 protect occupants of type U2
     from the effects of the cell's temperature.


File: xcdesign.info,  Node: Wind Variation,  Next: Unit Production and Consumption,  Prev: Temperature Effects,  Up: Backdrop

3.21.4 Wind Variation
---------------------

The following parameters control random variation of the prevailing
winds in each cell.

 -- TerrainTypeProperty: `wind-force-average' n
     This property is the average wind force in a type of terrain.

 -- TerrainTypeProperty: `wind-force-variability' n%
     This property is the chance that the wind in a cell will increase
     or decrease in force each turn.

 -- TerrainTypeProperty: `wind-variability' n%
     This property is the chance that the wind in a cell will change
     direction each turn.

 -- GlobalVariable: `wind-mix-range' n
     This variable is the radius out to which winds interact.  If 0,
     then winds in adjacent cells can vary independently of each other,
     and do not interact in any way.


File: xcdesign.info,  Node: Unit Production and Consumption,  Next: Terrain Production and Consumption,  Prev: Wind Variation,  Up: Backdrop

3.21.5 Unit Production and Consumption
--------------------------------------

Units can be set to always produce some amount of material without
taking explicit action.

 -- TableUM: `base-production' u m -> n
     This table is the basic amount of each material M produced by a
     unit of type U in each turn.

 -- TableUM: `occupant-base-production' u m -> n
     This table is the base production of each material M when a unit
     of type U is an occupant.

 -- TableUT: `productivity' u t -> n%
     This table is the percentage productivity of a unit of type U when
     on terrain of type T.  This is multiplied with the basic
     production rate to get actual material production, so productivity
     of `0' completely disables production on that terrain type, and
     productivity of `100' yields the rate specified by
     `base-production'.  Defaults to `100'.

 -- TableUT: `productivity-adjacent' u t -> n%
     This table is the percentage productivity of a unit of type U when
     adjacent to terrain of type T.  The actual productivity of a unit
     is a max of its productivity on its own cell and the adjacent
     cells.

 -- TableUM: `productivity-min' u m -> n

 -- TableUM: `productivity-max' u m -> n
     These tables are the lower and upper bounds on actual production
     after multiplying by productivity.  Default to `0' and `9999',
     respectively.

 -- TableUM: `base-consumption' u m -> n
     This table sets the amount of materials consumed by the unit in a
     turn, even if it doesn't move or do anything else.

 -- TableUM: `hp-per-starve' u m -> .01hp
     If the unit runs out of a material that it must consume, this table
     specifies how many 1/100 hp it will lose each turn that it is
     starving.  If starving for several reasons, loss is max of
     starvation losses, not the sum.  This value is stochastic.

 -- TableUM: `consumption-as-occupant' u m -> n%
     This table is the consumption by a unit of type U1 when it is an
     occupant, expressed as a percentage of its `base-consumption'.
     This is useful for units such as planes which always consume fuel
     in the air but not on the ground.  Defaults to `100'.

 -- TableUM: `gives-to-treasury' u m -> t/f
     This table is true if units of type U always immediately transfer
     any accumulated material of type M to the side's treasury.


File: xcdesign.info,  Node: Terrain Production and Consumption,  Next: Supply Lines,  Prev: Unit Production and Consumption,  Up: Backdrop

3.21.6 Terrain Production and Consumption
-----------------------------------------

Materials may be produced by cells, redistributed, and also taken up by
units.  Some amount of material may need to stay in the cell's storage,
or the type of terrain might change.  Exhaustion is tested after all
consumption has been accounted for.

 -- TableTM: `terrain-production' t m -> n
     This table is the amount of each material M produced by a cell of
     the given type T in each turn.

 -- TableTM: `terrain-consumption' t m -> n
     This table is the amount of material M consumed by a cell of type
     T each turn.  If insufficient material is available, then the
     terrain may change type.

 -- TableTM: `change-on-exhaustion-chance' t m -> n%
     This table is the chance that a cell of type T, with no supply of
     material of type M, will become exhausted and change to its
     exhausted type.

 -- TableTM: `terrain-exhaustion-type' t1 m -> t2
     If T2 is not `non-terrain', then this table says that any cell
     with terrain T1 that is exhausted will change to T2.  If several
     materials are exhausted in the same turn, then the lowest-numbered
     material type will determine the new terrain type.  Defaults to
     `non-terrain'.

 -- TableMM: `people-consumption' m1 m2 -> n
     This table is the base consumption per turn by people of type M1
     of each other material type M2.

 -- TableMM: `people-production' m1 m2 -> n
     This table is the people of type M1 base production per turn of
     each other material type M2.


File: xcdesign.info,  Node: Supply Lines,  Next: Side Research,  Prev: Terrain Production and Consumption,  Up: Backdrop

3.21.7 Supply Lines
-------------------

In real life, material production and consumption rarely occur in the
same place at the same time.  For some games, the player must transfer
materials manually, by loading and unloading from units.  However, this
can be time-consuming and difficult, and is best reserved for scarce
and/or valuable materials.  For more common materials, Xconq provides
"supply lines".

 -- TableUM: `in-length' u1 m -> dist

 -- TableUM: `out-length' u2 m -> dist
     These two tables together determine the length of supply lines
     between units.  The given type of material can only be transferred
     from unit type U1 to unit type U2 if the distance is less than the
     minimum of the `in-length' of U1 and the `out-length' of U2.

     For instance, the `in-length' for a fighter's fuel might be 3
     cells, while the `out-length' of fuel from a city is 4 cells.  Then
     the fighter will be constantly supplied with fuel when within 3
     cells of a city.  If the fighter's out-length is -1, it will never
     transfer any fuel to the city.

     An in- or out-length of `0' means that the two units must be in the
     same cell, while a negative length disables the automatic transfer
     completely.  Long `out-length' lines should be used sparingly,
     since the algorithm uses the `out-length' to define a radius of
     search for units to be resupplied.  Both default to `0'.

   The following tables control an advanced supply line algorithm that
is implemented, but does not seem to work correctly.  They are listed
here for completeness.

 -- Table: `supply-capacity-deterioration'

 -- Table: `supply-capacity-threshold'

 -- Table: `supply-deterioration'

 -- Table: `supply-enemy-interdiction'

 -- Table: `supply-importance'

 -- Table: `supply-in-max'

 -- Table: `supply-interdiction-adjacent'

 -- Table: `supply-interdiction-adjacent-for-material'

 -- Table: `supply-interdiction-at'

 -- Table: `supply-interdiction-at-for-material'

 -- Table: `supply-in-threshold'

 -- Table: `supply-in-weight'

 -- Table: `supply-neutral-interdiction'

 -- Table: `supply-out-max'

 -- Table: `supply-out-threshold'

 -- Table: `supply-potential'

 -- Table: `supply-potential-terrain-effect'

 -- Table: `supply-starve-weight'

 -- Table: `occupant-supply-potential'


File: xcdesign.info,  Node: Side Research,  Next: Unit Research,  Prev: Supply Lines,  Up: Backdrop

3.21.8 Side Research
--------------------

Sides may achieve advances automatically.

 -- GlobalVariable: `side-can-research' t/f
     This variable is true if the side can do research.

 -- GlobalVariable: `indepside-can-research' t/f
     This variable is true if the independent side can do research.

 -- TableAA: `advance-needed-to-research' a1 a2 -> t/f
     This table indicates whether advance A1 needs A2 to have been
     achieved first.

 -- TableAA: `advance-consumption-per-rp' a m -> n
     This table is the amount of material type M consumed to add one
     research point for A.


File: xcdesign.info,  Node: Unit Research,  Next: Terrain Attrition,  Prev: Side Research,  Up: Backdrop

3.21.9 Unit Research
--------------------

Units may work on advances as a backdrop activity, without expending
action points.

 -- UnitTypeProperty: `can-research' t/f
     This property is true if the unit can work on advances in the
     background.


File: xcdesign.info,  Node: Terrain Attrition,  Next: Terrain Accident,  Prev: Unit Research,  Up: Backdrop

3.21.10 Terrain Attrition
-------------------------

Attrition is the automatic loss of hit points due to being in certain
types of terrain.  This runs once for each unit at the beginning of
each turn.

 -- TableUT: `attrition' u t -> .01hp
     This table is the rate of loss of hp per turn.  The terrain used
     is cell or connection terrain as appropriate for the unit's
     position.


File: xcdesign.info,  Node: Terrain Accident,  Next: Unit Revolt,  Prev: Terrain Attrition,  Up: Backdrop

3.21.11 Terrain Accident
------------------------

Accidents result in the damage or disappearance of a unit in the open
in some kinds of terrain.  This runs once at the beginning of each
turn, on each unit not in a transport.

 -- TableUT: `accident-hit-chance' u t -> .01n%
     This table is the chance of the unit being hit while in the given
     terrain.

 -- TableUT: `accident-damage' u t -> hp
     This table is the hp that will be lost in an accident.  The value
     is a dice spec.

 -- TableUT: `accident-vanish-chance' u t -> .01n%
     This table is the chance of the unit simply vanishing while in the
     given terrain.


File: xcdesign.info,  Node: Unit Revolt,  Next: Unit Surrender,  Prev: Terrain Accident,  Up: Backdrop

3.21.12 Unit Revolt
-------------------

Revolt is a spontaneous change of side, occurring in place of a
side-given unit action.  The new side may be none (independence) or
another side.

 -- UnitTypeProperty: `revolt-chance' .01n%
     This property is the chance for the unit to revolt spontaneously.

 -- UnitTypeProperty: `revolt-at-opinion-min' .01n%
     This property is the chance for the unit to revolt when its
     opinion of its current side is at its lowest possible level.  The
     chance is interpolated for opinions between zero and the minimum.


File: xcdesign.info,  Node: Unit Surrender,  Prev: Unit Revolt,  Up: Backdrop

3.21.13 Unit Surrender
----------------------

 -- TableUU: `surrender-chance' u1 u2 -> .01n%
     This table is the chance that a unit of type U1 will change its
     side to match the side of a unit U2 that is within the
     `surrender-range' for the two types.

 -- TableUU: `surrender-range' u1 u2 -> dist
     This table is the distance out to which a unit of type U1 will
     surrender to a unit of type U2.  Defaults to `1'.


File: xcdesign.info,  Node: Behavior,  Next: Game End,  Prev: Backdrop,  Up: Reference Manual

3.22 Behavior
=============

The AIs normally make their own decisions about how to play a game, but
they can also follow hints provided by the game design.

 -- GlobalVariable: `ai-may-resign' t/f
     This variable is true if the AI can evaluate whether to resign and
     then resign if it likes.  Otherwise, it will play until it wins or
     loses.  Defaults to `true'.

 -- GlobalVariable: `units-may-go-into-reserve' t/f
     This variable is true if AI or plan execution can put a unit into
     reserve for the remainder of a turn.  This can prevent unit
     confusion, but can also put the side at a disadvantage if too many
     of its units spend turns in reserve rather than doing something
     useful.  Defaults to `true'.

 -- GlobalVariable: `ai-tactical-range' n
     This is the range out to which AI and/or plan execution will look
     for tactical opportunities, such as captures.  Defaults to `4'.

 -- UnitTypeProperty: `ai-peace-garrison' n
     This is the number of occupants the AI should have as garrison for
     the unit if there are no threats nearby.

 -- UnitTypeProperty: `ai-war-garrison' n
     This is the number of occupants the AI should have as garrison for
     the unit if there are threatening units nearby.  Defaults to `1'.

 -- GlobalVariable: `ai-advanced-unit-separation' n
     This is the recommended distance between advanced units, ideally
     used when constructing units are deciding where to build.
     Defaults to `3'.

 -- GlobalVariable: `ai-badtask-max-retries' n
     This is the maximum number of times that task execution will be
     retried when a task fails.  Defaults to `6'.

 -- GlobalVariable: `ai-badtask-remove-chance' n
     This is the probability that a failing task will be removed from
     the task agenda.  Defaults to `20'.

 -- GlobalVariable: `ai-badtask-reserve-chance' n
     This is the probability that a unit whose task is failing will go
     into reserve and try the task on the following turn.  Defaults to
     `6'.

 -- GlobalVariable: `minimal-size-goal' n
     This variable is used by colonizers to identify locations that can
     support an advanced unit growing to this size.  Defaults to `12'.

 -- UnitTypeProperty: `ground' t/f

 -- UnitTypeProperty: `naval' t/f

 -- UnitTypeProperty: `air' t/f

 -- UnitTypeProperty: `colonizer' t/f

 -- UnitTypeProperty: `facility' t/f
     These properties identify a unit type as having particular uses
     and/or characteristics.


File: xcdesign.info,  Node: Game End,  Next: Dates and Time,  Prev: Behavior,  Up: Reference Manual

3.23 Game End
=============

When a side loses, its units may suffer a variety of fates, including
revolt, surrender, wrecking, or disappearance.  Disappearance is the
default fate.  Each type of test is independent, but run in the order
wreck, vanish, surrender, revolt.

 -- UnitTypeProperty: `lost-wreck-chance' .01n%
     This property is the .01% chance that a unit will be wrecked, as
     if it had been hit in combat.  Once a unit is wrecked, it will not
     be re-wrecked, even if the wrecked type has itself a nonzero
     `lost-wreck-chance' property.  The other loss chances still apply,
     however.

 -- UnitTypeProperty: `lost-vanish-chance' .01n%
     This property is the .01% chance that a unit will vanish when the
     side loses.  Defaults to `10000'.

 -- TableUU: `lost-surrender-chance' u1 u2 -> .01n%
     This table is the .01% chance that a unit of type U1 on a losing
     side will surrender to an adjacent unit of type U2.

 -- UnitTypeProperty: `lost-revolt-chance' .01n%
     This property is the .01% chance that a unit on a losing side will
     revolt and go over to some other side, as per the backdrop
     activity.


File: xcdesign.info,  Node: Dates and Time,  Next: Image Families,  Prev: Game End,  Up: Reference Manual

3.24 Dates and Time
===================

 -- GlobalVariable: `turn' n
     This variable is the number of the current turn.

   Note that the first turn of a game is actually turn 1.  Pre-game
activities happen during "turn 0".

* Menu:

* Game Length::
* Calendar::
* Real Time::


File: xcdesign.info,  Node: Game Length,  Next: Calendar,  Up: Dates and Time

3.24.1 Game Length
------------------

 -- GlobalVariable: `last-turn' n
     This variable is the number of the last turn.  Defaults to `-1',
     which means that there is no limit on the number of turns.

 -- GlobalVariable: `extra-turn-chance' n%
     This variable is the chance that the game will go one more turn
     after the `last-turn'.

   Xconq is currently limited to games of 32,767 turns.


File: xcdesign.info,  Node: Calendar,  Next: Real Time,  Prev: Game Length,  Up: Dates and Time

3.24.2 Calendar
---------------

You can make Xconq display game time as a calendar date, rather than as
a simple turn number.

 -- GlobalVariable: `calendar' type data...
     This variable is the description of the calendar type that will be
     used.  If the variable is `()' or the type is `number', then turns
     will be reported numerically starting from `1'.  If `usual', then
     the standard Gregorian calendar will be used.  Defaults to `()'.

     If the numeric or `number' calendar is in use, then a DATA of
     `"cycle"' will yield `"cycle 1"', `"cycle 2"', etc.

   For the `usual' calendar, the DATA defines how long a turn is, in
terms of the calendar.  For instance, a time measure of `day' (and a
base date of `"1 Jan 1900"') will result in turns `"1 Jan 1900"', `"2
Jan 1900"', etc, while a date unit of `year' will yield just `"1900"',
`"1901"', and so forth.

   The full form of the DATA is
     (DATE-STEP-RANGE1 DATE-STEP-RANGE2 ...)
   where each DATE-STEP-RANGE has the form
     ( [ START END ] TYPE [ MULTIPLE ] )
   where TYPE has the values SECOND, MINUTE, HOUR, DAY, WEEK, MONTH,
SEASON, or YEAR, where MULTIPLE is the number of that type in eah turn,
and where START and END define the ranges of turns to use for the given
type and multiple of the date.  (The ranges are useful for telescoping
time periods, such as in civilization-building games where early turns
might advance by 50 years each, and later turns by only a year.)

 -- Symbol: `number'

 -- Symbol: `usual'

 -- GlobalVariable: `initial-date' str
     This variable is the date, in the specified calendar system, of the
     first turn.  Defaults to `""', which has the effect of setting the
     initial date to be whatever the calendar does with turn number 1.


File: xcdesign.info,  Node: Real Time,  Prev: Calendar,  Up: Dates and Time

3.24.3 Real Time
----------------

A game may also be limited in real time.

 -- GlobalVariable: `real-time-for-game' seconds

 -- GlobalVariable: `real-time-per-turn' seconds

 -- GlobalVariable: `real-time-per-side' seconds

 -- GlobalVariable: `elapsed-real-time' seconds
     This is the difference in real time between the start of the game
     and its current state.


File: xcdesign.info,  Node: Image Families,  Next: Other Forms,  Prev: Dates and Time,  Up: Reference Manual

3.25 Image Families
===================

The `imf' form defines graphical images in a platform-independent way.
An image family is a named collection of images of varying sizes and
depths.

 -- Form: `imf' name [ properties ] [ images ]
     This form declares an image family to exist, with the name NAME
     and PROPERTIES, and consisting of the specified IMAGES.  Each
     image has the form
          `((W H SPECIAL) [ PROPERTIES ] (TYPE DATA...) ...)'
     where W and H are its width and height, respectively, SPECIAL
     indicates special characteristics of the image, the TYPE may be
     one of `color', `mono', `mask', or `file', and the DATA consists
     of strings of hexadecimal digits.  The data strings may include
     slashes, which have no effect on interpretation, but are useful to
     indicate each row of an image.  Color images may also have
     additional properties, which come between the TYPE and the DATA.

     The family's NAME may consist only of alphabetic characters,
     decimal digits, and hyphens or underscores.  Upper- and lower-case
     characters are equivalent, as are hyphens and underscores.  The
     canonical form of the name is lowercase with hyphens.

     Multiple forms with the same name may occur, and each adds to the
     family, overwriting individual image parts that are of the same
     size and depth.

 -- Symbol: `tile'
     If this symbol appears following the dimensions of an image, it
     indicates that the image is a pattern tile rather than a single
     image.

 -- Symbol: `border'
     If this symbol appears following the dimensions of an image, it
     indicates that the image is a set of images for border terrain.
     Borders have 16 subimages, each showing a different sort of
     junction between cells.

 -- Symbol: `connection'
     If this symbol appears following the dimensions of an image, it
     indicates that the image is a set of images for connection terrain.
     Connections have 64 subimages, each for a different pattern of
     connectons to adjacent cells.

 -- Symbol: `transition'
     This symbol indicates that the terrain is a transition pattern
     used to blend two types of terrain.  Transitions consist of at
     least 4 subimages, and may have several variants that can be
     chosen randomly.

 -- ImageProperty: `actual' w h
     This property is the actual size of the image data.

 -- ImageProperty: `embed' name
     This property specifies that another image, similar to the image
     family named by NAME, is already embedded within the image, and so
     Xconq need not superimpose such an image itself.  This may occur
     when an image has a "builtin" side emblem, or is readily
     identifiable as belonging to a particular side, and it would be
     redundant for Xconq to add an emblem when displaying a unit.

 -- ImageProperty: `embed-at' x y
     This property specifies that the area of the image at x,y is
     suitable for the display of an emblem.

 -- ImageProperty: `embed-size' w h
     This property specifies the dimensions of the area available for an
     emblem.

 -- ImageProperty: `x' n [ x y ]
     This property specifies that the image includes N variant
     subimages, any of which may be randomly chosen by an interface.
     The optional numbers X and Y indicate the offset of each subimage,
     so for instance an x of 32 and a y of 0 indicates a horizontal
     strip of images, each 32 pixels apart.  Their values default to the
     width of the image and 0, respectively.

 -- ImageProperty: `notes' list
     This property is for designer notes about the image.

 -- ImageProperty: `mono' data ...
     This property indicates that the data represents a monochrome
     image.

 -- ImageProperty: `mask' data ...
     This property indicates that the data represents a mask.

 -- ImageProperty: `color' [ properties ] data ...
     This property indicates that the data represents a color image.

 -- ColorImageProperty: `pixel-size' n
     This property is the number of bits used to encode each pixel.

 -- ColorImageProperty: `palette' [ (index r g b) ... ]
     This property is the color palette that should be used with the
     image.

 -- ImageProperty: `file' filename [ `std' ] [ x y ]
     This property indicates that the image data is in a file named
     FILENAME.  FILENAME must contain a recognized type of image (GIF
     only, at present).  The optional X and Y indicate the position of
     the upper left corner of the image within the larger picture
     contained in the file.

     If the optional symbol `std' precedes the position values, then the
     numbers are relative positions in a file image that is assumed to
     be a grid of images all the same size.  It is also assumed that
     images are separated by two pixels on all sides, so the pixel
     position is `2 + (x * (img_width + 2))'.

     File images do not have explicit masks, but may instead have key
     colors that will be used to compute the mask.  Key colors are
     indicated by 2x2 pixel blocks in the upper left corner of the file
     image.  Any number of key colors may be defined; the end of the
     list is indicated by a block of the same color as the first block.
     (See `images/river44x48.gif' for an example with many key colors.)

 -- Symbol: `std'
     This symbol, when in a `file' property, indicates that the file
     image is laid out in a standard grid pattern. (see above)

   Note that for the purposes of stability and change tracking, tools
that generate image families use a more restricted format.  This format
requires a separate imf form for each size of image, the size is on the
same line as the imf name, and each image/mask is on a separate line,
indented by 2. (See the existing library imf files for further detail.)


File: xcdesign.info,  Node: Other Forms,  Next: Files and Directories,  Prev: Image Families,  Up: Reference Manual

3.26 Other Forms
================

GDL forms in this section are those that do not really fit anywhere
else.

* Menu:

* Default Display Style::
* The Random State::
* Debugging Support::


File: xcdesign.info,  Node: Default Display Style,  Next: The Random State,  Up: Other Forms

3.26.1 Default Display Style
----------------------------

The exact style of display depends on the user interface and on user
preferences, but for some games, you may want to encourage a particular
style by making it be the default.

 -- GlobalVariable: `unseen-char' str
     This variable is a string whose first character will be used to
     represent unexplored terrain.  If the string consists of two
     characters, the second char will be scattered throughout a field
     of the first char.  Defaults to `" ?"'.  (At present, this is used
     only by the curses interface.)

 -- GlobalVariable: `unseen-color' str
     This variable is the name of a color that will be used to represent
     unexplored terrain.  Defaults to `"black"'.

 -- GlobalVariable: `grid-color' str
     This variable is the name of a color to use to draw the
     cell-separating grid.  Defaults to `"dark-gray"'.

 -- GlobalVariable: `unit-name-color' str
     This variable is the name of a color to use when drawing unit
     names and numbers.  Defaults to `"white"'.

 -- GlobalVariable: `contour-color' str
     This variable is the name of a color to use to draw the elevation
     contour lines.  Defaults to `"saddle-brown"'.

 -- GlobalVariable: `meridian-color' str
     This variable is the name of a color to use to draw meridians of
     latitude and longitude.  Defaults to `"black"'.

 -- GlobalVariable: `frontline-color' str
     This variable is the name of a color to use to draw country borders
     against other countries.  Defaults to `"red"'.

 -- GlobalVariable: `country-border-color' str
     This variable is the name of a color to use to draw country borders
     against unpopulated areas.  Defaults to `"pink"'.

 -- GlobalVariable: `shoreline-color' str
     This variable is the name of a color to use to draw shorelines
     (liquid adjacent to non-liquid terrain).  Defaults to `"blue"'.

 -- GlobalVariable: `bigicons' t/f
     When true, this variable says to draw unit images to fill the
     entire cell rather than the "unit box" within the cell.

 -- TableTT: `drawable-terrain' t1 t2 -> t/f
     This table is true when terrain of type T1 should be drawn over
     terrain of T2.  In practice, you would set this to `false' to
     suppress the drawing of terrain that extends into an inappropriate
     types, such as river connections protuding into lakes or seas.
     Defaults to `true'.

 -- MaterialTypeProperty: `resource-icon' n
     This is a value between 1 and 4 that indicates that a material
     type is to be drawn in each cell indicating that an advanced unit
     is producing material in that cell.  The value is used by the Mac
     interface to select one of several icons.


File: xcdesign.info,  Node: The Random State,  Next: Debugging Support,  Prev: Default Display Style,  Up: Other Forms

3.26.2 The Random State
-----------------------

It is useful to be able to restart the random number generator
consistently.

 -- GlobalVariable: `random-state' n
     This variable is the state of the random number generator.  If
     this is not used, then the initial state of the random number
     generator will be set in a system-dependent way.


File: xcdesign.info,  Node: Debugging Support,  Prev: The Random State,  Up: Other Forms

3.26.3 Debugging Support
------------------------

 -- Form: `print' value
     This form prints to a console or file (depending on the interface)
     the object VALUE, in GDL syntax.


File: xcdesign.info,  Node: Files and Directories,  Prev: Other Forms,  Up: Reference Manual

3.27 Files and Directories
==========================

This section defines file and directory structure for using GDL.  This
is not required; for instance, an implementation may choose to handle
GDL by reading it from strings compiled into the program.  However, the
standard Xconq library and implementation does adhere to the
conventions described here.

   A game module is a set of forms in a text file, which has an
extension of `.g'.

   By convention, the first form in the file is a `game-module' form
that defines properties of the module.  If the interface has any sort of
preview for a particular module, it can then read only the first form,
rather than the entire file.

   Some interfaces include a game selection dialog, which lists a set of
games from which to choose, along with a little information about each.
The file `game.dir' in the library directory contains this list, which
is simply a list of module name strings:
     (  ;; games that should appear in new game selection dialogs
     "1756"
     "cave"
     "cherbourg"
     "classic"
     "coral-sea"
     "crater-lake"
     )

   Xconq does not currently enforce any sort of standard on file names,
but for maximum portability, the file name should not include mixed
case, it should consist only of alphabetic and numeric characters and
hyphen, and should be less than 12 characters in length, with 8 of those
distinct from any other name in the same directory.  Since Xconq
implementations typically use the file name as a way to find modules,
these restrictions should apply to module names as well.

   Image files are library files with the extension `.imf'.  Usually
each image file contains a group of images related in some way, perhaps
by a common theme or by use in a particular game. Xconq implementations
find images either by a method specific to the platform (such as
resource files), or by looking up the image's location in the image
directory `imf.dir'.  The image directory is just a set of pairs of
image name and imf file, with markers at beginning and end of the file:
     ImageFamilyName FileName
     amulet fantasy.imf
     ant insects.imf
     anvil-and-crown fantasy.imf
     ap standard.imf
     archer ancient.imf
     . .
   Note that while `game.dir' is a GDL-syntax form, `imf.dir' is not.
It should rarely be necessary to modify `imf.dir' directly; the scripts
`makedir.sh' and `makedir.pl' in the standard library directory are
Unix shell and Perl scripts, each of which will generate `imf.dir' from
a given list of files, such as `*.imf' in the library.  You should run
one of these after adding a new image to a library image file.


File: xcdesign.info,  Node: Summary of GDL Syntax,  Next: Permuted Index of GDL Symbols,  Prev: Reference Manual,  Up: Top

Appendix A Summary of GDL Syntax
********************************

Whitespace is never significant, except to separate two symbols or
within a string or escaped symbols.

   Regular expression for symbol is `[-a-z0-9A-Z]*' or `|[^|]*|'.

   Number is `[-]*[0-9][0-9]*' optional `[d]*[0-9][0-9]*',
`[+]*[0-9][0-9]*'.

   String is `"[^"]*"'.

   Comments extend from `;' to end of the line, or may be everything
enclosed between `#|' and `|#' (which nest properly).

     form ::= module-form
             | ( include module-name [ variant-setting ]* )
             | ( if test-form [ symbol ] )
             | ( else [ symbol ] )
             | ( end-if [ symbol ] )
             | world-form
             | area-form
             | side-form
             | side-defaults-form
             | independent-units-form
             | doctrine-form
             | player-form
             | agreement-form
             | unit-form
             | unit-defaults-form
             | scorekeeper-form
             | exu-form
             | evt-form
             | unit-type-form
             | terrain-type-form
             | material-type-form
             | advance-type-form
             | namer-form
             | table-form
             | add-form
             | imf-form
             | palette-form
             | color-form
             | ( define symbol value )
             | ( set symbol value )
             | ( undefine symbol value )
             | ( print value )
             | value

     module-form ::= ( game-module [ module-name ]
             [ game-module-property-binding ]* )

     module-name ::= string

     game-module-property-binding ::= ( game-module-property-name value )

     game-module-property-name ::=
               base-game | title | blurb | picture-name | instructions
             | notes | design-notes | program-version
             | base-module | default-base-module | variants | version

     variant-definition ::=
             ( [ string ] var-type [ var-default ] [ var-range ] [ var-clause ]* )

     var-type ::= world-size | world-seen | see-all
             | sequential | real-time | symbol

     var-default ::= value

     var-range ::= ( value value )

     var-clause ::= ( [ string ] value [ form ]* )

     variant-setting ::= ( var-type value )

     world-form ::= ( world [ circumference ] [ world-property-binding ]* )

     world-property-binding ::= ( world-property-name value )

     world-property-name ::=
             axial-tilt | circumference | day-length | year-length

     circumference ::= value

     area-form ::= ( area [ width [ height ] ] [ area-restriction ]
             [ area-property-binding ]* )

     area-restriction ::= ( restrict width height a-x a-y )

     area-property-binding ::= ( area-property-name value )
             | ( terrain [ layer-subform ]* [ string ]* )
             | ( aux-terrain terrain-type [ layer-subform ]* [ string ]* )
             | ( features feature-list [ layer-subform ]* [ string ]* )
             | ( material material-type [ layer-subform ]* [ string ]* )
             | ( people-sides [ layer-subform ]* [ string ]* )
             | ( control-sides [ layer-subform ]* [ string ]* )
             | ( elevations [ layer-subform ]* [ string ]* )
             | ( temperatures [ layer-subform ]* [ string ]* )
             | ( winds [ layer-subform ]* [ string ]* )
             | ( clouds [ layer-subform ]* [ string ]* )
             | ( cloud-bottoms [ layer-subform ]* [ string ]* )
             | ( cloud-heights [ layer-subform ]* [ string ]* )

     area-property-name ::= width | height | latitude | longitude | cell-width

     layer-subform ::= ( constant n )
             | ( subarea a-x a-y width height )
             | ( xform mul add )
             | ( by-bits )
             | ( by-char string )
             | ( by-name name-list )

     width ::= value

     height ::= value

     a-x ::= value

     a-y ::= value

     n ::= value

     mul ::= value

     add ::= value

     side-form ::= ( side [ side-id ] [ side-property-binding ]* )

     side-defaults-form ::= ( side-defaults [ side-property-binding ]* )

     side-property-binding ::= ( side-property-name value )

     side-property-name ::=
               name | long-name | short-name | noun | plural-noun
             | adjective | color | emblem-name | names-locked
             | class | active | status
             | advantage | advantage-min | advantage-max
             | controlled-by | trusts | trades | next-numbers | unit-namers
             | feature-namers | tech | init-tech | terrain-view | unit-view
             | unit-view-dates | turn-time-used | total-time-used | timeouts
             | timeouts-used | finished-turn | willing-to-draw
             | doctrines | doctrines-locked
             | self-unit | priority | scores | ui-data | ai-data | player

     doctrine-form ::= ( doctrine ... )

     player-form ::= ( player [ player-id ] [ player-property-binding ]* )

     player-id ::= number

     player-property-binding ::= ( player-property-name value )

     player-property-name ::= name | config-name | display-name | ai-type-name
             | password | initial-advantage

     agreement-form ::= ( agreement [ agreement-id ] [ agree-prop-bdg ]* )

     agreement-id ::= value

     agree-prop-bdg ::= ( agreement-property-name value )

     agreement-property-name ::= type-name | title | terms | drafters
             | proposers | signers | willing-to-sign | known-to | enforcement
             | state

     unit-form ::= ( unit [ unit-id ] [ unit-property-bdg ]* )
             | ( unit-type-name u-x u-y u-side [ unit-property-bdg ]* )

     unit-defaults-form ::= ( unit-defaults [ reset ] [ unit-property-bdg ]* )

     unit-property-bdg ::=
               ( unit-property-name value )
             | ( act action-type-name [ action-property-binding ]* )
             | ( plan plan-type-name [ plan-property-binding ]* )
             | ( task task-type-name [ task-property-binding ]* )
             | ( x [ unit-x-property-binding ]* )

     unit-property-name ::=
               @ | # | cp | cxp | hp | in | m | mo | n | nb
             | opinions | s | tp | z

     unit-id ::= value

     u-x ::= value

     u-y ::= value

     u-side ::= value

     unit-x-property-binding ::=
               ( unit-x-property-name value )
               ( symbol value )

     unit-x-property-name ::= appear | disappear

     action-type-name ::=
               add-terrain | alter-terrain | attack | build
             | capture | change-side
             | change-type | create-at | create-in | detonate | disband
             | enter
             | fire-at | fire-into | move | none | overrun | produce
             | remove-terrain | repair | research | toolup | transfer
             | transfer-part

     action-property-binding ::=
               ( action-property-name value )

     action-property-name ::= a | aa | acp | acp0 | am

     plan-type-name ::=
               defensive | exploratory | none | offensive | passive | random

     plan-property-binding ::=
               ( plan-property-name value )
             | ( goal goal-type-name ... )

     plan-property-name ::=
               ai-control | asleep | delayed | formation | goal | reserve
             | supply-alarm | supply-is-low

     goal-type-name ::=
               cell-is-occupied | has-material-type | has-unit-type
             | has-unit-type-near | keep-formation | lost-game
             | no-goal | positions-known | vicinity-is-held
             | vicinity-is-known | won-game | world-is-known

     task-type-name ::=
               build | capture | do-action | hit-position | hit-unit
             | move-dir
             | move-to | none | occupy | pickup | repair | research
             | resupply | sentry

     scorekeeper-form ::= ( scorekeeper [ sk-id ] [ sk-property-binding ]* )

     sk-id ::= value

     sk-property-binding ::= ( sk-property-name value )

     sk-property-name ::=
               applies-to | do | initial | known-to | messages | title
             | trigger | triggered | when

     sk-when ::= after-action | after-event | after-turn | before-turn

     exu-form ::= ( exu id type x y side [ exu-property-binding ]* )

     exu-property-binding ::= ( exu-property-name value )

     exu-property-name ::= n | nb | z

     evt-form ::= ( evt turn evt-type-name observers [ value ]* )

     evt-type-name ::=
               action-done | action-error | action-ok
             | cannot-do | cannot-leave-world | capture-failed
             | capture-succeeded | destination-full | fire-into-outside-world
             | game-ended | game-restarted | game-saved
             | game-started | insufficient-acp | insufficient-material
             | insufficient-mp | log-ended | log-started
             | overrun-failed | overrun-succeeded | side-joined
             | side-lost | side-withdrew | side-won
             | too-far | too-near | unit-acquired
             | unit-assaulted | unit-captured | unit-completed
             | unit-created | unit-damaged | unit-disbanded
             | unit-garrisoned | unit-killed | unit-left-world
             | unit-moved | unit-name-changed | unit-started-with
             | unit-starved | unit-type-changed | unit-vanished
             | unit-wrecked

     unit-type-form ::=
             ( unit-type unit-type-name [ unit-type-property-binding ]* )

     unit-type-name ::= symbol

     unit-type-property-binding ::= ( unit-type-property-name value )

     unit-type-property-name ::=
               acp-damage-effect | acp-max | acp-min
             | acp-per-turn | acp-per-turn-max | acp-per-turn-min
             | acp-season-effect | acp-temperature-effect
             | acp-to-change-side
             | acp-to-detonate | acp-to-disband | acp-to-fire
             | acp-to-move | acp-to-transfer-part | action-priority
             | already-seen | already-seen-independent | assign-number
             | available | can-be-self | capacity | char | color
             | consumption-temperature-effect | country-units-max
             | cp | cp-per-self-build | cp-to-self-build | cxp-max
             | cxp-on-capture-effect
             | description-format | detonate-on-death | direct-control
             | elevation-at-max-range | free-acp
             | free-mp | generic-name | has-opinions | help
             | hit-falloff-range
             | hp-max | hp-per-detonation | hp-per-disband | hp-recovery
             | image-name
             | independent-growth-chance | independent-near-start
             | independent-takeover-chance | initial-seen-radius | long-name
             | move-range | mp-to-leave-world | name | name-internal | namer
             | notes | occupant-total-max | parts-max | point-value
             | possible-sides | range | range-min
             | revolt-chance | see-always | see-occupants
             | self-changeable | self-resurrects | short-name
             | speed | speed-damage-effect | speed-max
             | speed-min | speed-wind-angle-effect | speed-wind-effect
             | spot-action | spy-chance | spy-range
             | stack-order | start-with | tech-from-ownership
             | tech-leakage | tech-max | tech-per-turn-max
             | tech-to-build | tech-to-own | tech-to-see
             | tech-to-use | temperature-attrition | type-in-game-max
             | type-per-side-max | unit-growth-chance | unit-takeover-chance
             | vision-bend | vision-range | wrecked-type
             | zz-b | zz-bb | zz-bw | zz-c | zz-cc | zz-cm | zz-transport

     terrain-type-form ::=
             ( terrain-type terrain-type-name [ terrain-type-property-bdg ]* ) )

     terrain-type-name ::= symbol

     terrain-type-property-bdg ::= ( terrain-type-property-name value )

     terrain-type-property-name ::=
               alt-percentile-max | alt-percentile-min
             | capacity | char | clouds-max | clouds-min
             | country-growth-chance
             | country-people-chance | country-takeover-chance
             | country-terrain-max | country-terrain-min
             | elevation-max | elevation-min
             | help | image-name | independent-people-chance
             | liquid | maze-passage-occurrence | maze-room-occurrence
             | name | notes | occurrence | people-max
             | river-chance | subtype | subtype-x
             | temperature-average | temperature-max | temperature-min
             | temperature-variability | thickness | wet-percentile-max
             | wet-percentile-min | wind-force-average | wind-force-max
             | wind-force-min | wind-force-variability | wind-variability
             | zz-fr

     material-type-form ::=
             ( material-type material-type-name [ m-type-property-binding ]* ) )

     material-type-name ::= symbol

     m-type-property-binding ::= ( m-type-property-name value )

     m-type-property-name ::=
               char | help | image-name | initial-treasury
             | name | notes | people | resource-icon | treasury

     advance-type-form ::=
             ( advance-type advance-type-name [ m-type-property-binding ]* ) )

     advance-type-name ::= symbol

     a-type-property-binding ::= ( a-type-property-name value )

     a-type-property-name ::=
               char | help | image-name | name | notes | occurrence | rp

     namer-form ::= ( namer [ namer-id ] naming-method state )

     namer-id ::= value

     naming-method ::=
               junky
             | ( random [ string ]* )
             | ( grammar symbol number [ grammar-rule ]* )

     grammar-rule ::= ( symbol ( [ rule-type ] [ weight ] data )

     rule-type ::= any | or | reject | capitalize

     state ::= value

     table-form ::= ( table table-name [ add ] [ table-clause ]* )

     table-clause ::=
               value
             | ( type-or-types type-or-types value )

     table-name ::=
               uu-table-name | ut-table-name | um-table-name
             | tt-table-name | tm-table-name | mm-table-name

     uu-table-name ::=
             | acp-for-retreat | acp-occupant-effect | acp-to-attack
             | acp-to-be-fired-on | acp-to-build | acp-to-capture
             | acp-to-change-type | acp-to-create | acp-to-defend
             | acp-to-enter-unit | acp-to-repair | acp-to-research
             | acp-to-toolup | attack-range | attack-range-min
             | bridge | build-range | can-enter-independent
             | capture-chance | control-chance | control-chance-adjacent
             | control-chance-at | control-range | cp-on-creation
             | cp-per-build | create-range | cxp-per-capture
             | cxp-per-combat | damage | damage-cxp-effect
             | detonate-on-approach-range | detonate-on-capture
             | detonate-on-hit | detonation-damage-adjacent
             | detonation-damage-at | detonation-unit-range
             | ferry-on-departure | ferry-on-entry | hit-at-max-range-effect
             | hit-chance | hit-cxp-effect | hp-min
             | hp-per-repair | hp-to-garrison | hp-to-repair
             | independent-capture-chance
             | mp-to-enter-unit | mp-to-enter-zoc
             | mp-to-leave-unit | mp-to-leave-zoc | mp-to-traverse-zoc
             | occupant-can-construct | occupant-can-have-occupants
             | occupant-combat | occupant-escape-chance | occupant-max
             | occupant-vision | protection | retreat-chance | road-chance
             | scuttle-chance | see-chance | see-chance-adjacent
             | see-chance-at | speed-occupant-effect | spy-quality
             | stack-protection
             | surrender-chance | surrender-chance-per-attack
             | surrender-range | tech-crossover | tech-per-research
             | temperature-protection | tp-attrition | tp-crossover
             | tp-max | tp-per-toolup | tp-to-build
             | unit-capacity-x | unit-size-as-occupant
             | withdraw-chance-per-attack
             | zoc-range | zz-basic-capture-worth | zz-basic-hit-worth
             | zz-basic-transport-worth

     ut-table-name ::=
               accident-damage | accident-hit-chance | accident-vanish-chance
             | acp-night-effect | acp-to-add-terrain | acp-to-remove-terrain
             | alter-terrain-range | altitude-max | altitude-min
             | attack-terrain-effect | attrition | defend-terrain-effect
             | detonation-accident-chance
             | detonation-terrain-damage-chance | detonation-terrain-range
             | eye-height | favored-terrain | independent-density
             | mp-to-enter-terrain | mp-to-leave-terrain | mp-to-traverse
             | people-surrender-chance | productivity | terrain-capacity-x
             | unit-size-in-terrain | vanishes-on | visibility
             | vision-night-effect | wrecks-on | zoc-from-terrain-effect
             | zoc-into-terrain

     um-table-name ::=
               acp-to-load | acp-to-produce | acp-to-unload
             | base-consumption | base-production | consumption-as-occupant
             | consumption-on-creation
             | consumption-per-attack | consumption-per-build
             | consumption-per-move | consumption-per-repair | hit-by
             | hp-per-starve | in-length | load-max
             | material-per-production | material-to-act | material-to-build
             | material-to-change-type | material-to-create
             | material-to-fight
             | material-to-move | material-to-produce | material-to-repair
             | occupant-base-production | out-length | people-see-chance
             | people-surrender-effect | productivity-max | productivity-min
             | recycleable-material
             | supply-on-completion | supply-on-creation
             | supply-per-disband | unit-initial-supply | unit-storage-x
             | unload-max

     tt-table-name ::=
               adjacent-terrain-effect
             | coating-depth-max | coating-depth-min
             | drawable-terrain | road-into-chance | terrain-damaged-type

     tm-table-name ::=
               change-on-exhaustion-chance | consumption-per-add-terrain
             | material-per-remove-terrain | see-material-always
             | terrain-consumption | terrain-exhaustion-type
             | terrain-initial-supply | terrain-production
             | terrain-storage-x

     mm-table-name ::= people-consumption | people-production

     add-form ::= ( add type-or-types property-name value )

     imf-form ::= ( imf string [ imf-property-binding ]* [ image ]* )

     imf-property-binding ::= ...

     image ::= ( ( w h [ tile ] ) [ image-property-binding ]*
             [ subimage * ] )

     image-property-binding ::= ( image-property-name value )

     image-property-name ::= actual | embed | embed-at | palette | pixel-size
             | row-bytes

     subimage ::= ( subimage-type string * )

     subimage-type ::= color | mono | mask

     palette-form ::= ( palette ... )

     color-form ::= ( color string r g b )

     type-or-types ::= type | symbol | ( [ type | symbol ]* )

     value ::=
               number
             | symbol
             | global-variable
             | predefined-symbols
             | ( [ value ]* )
             | ( operation-name [ value ]* )

     operation-name ::=
               quote | list | append | remove | /= | < | <= | = | > | >=

     global-constant ::=
               true | false
             | u* | t* | m*
             | non-unit | non-terrain | non-material
             | border | cell | coating | connection
             | over-all | over-border | over-nothing | over-own
             | no-x | river-x | road-x | valley-x

     global-variable ::=
               action-messages | advantage-default | advantage-max
             | advantage-min | alt-blob-density | alt-blob-height
             | alt-blob-size | alt-smoothing | calendar
             | country-radius-max | country-radius-min
             | country-separation-max
             | country-separation-min | edge-terrain | elapsed-real-time
             | event-messages | extra-turn-chance | feature-namers
             | feature-types | grid-color | growth-stop-chance
             | initial-date | initial-day-part | initial-year-part
             | last-turn | maze-passage-density | maze-room-density
             | player-sides-locked | random-events | random-state
             | real-time-for-game | real-time-per-side | real-time-per-turn
             | river-sink-terrain | scorefile-name | season-names
             | see-all | see-terrain-always | see-weather-always
             | self-required | side-library | sides-max
             | sides-min | synthesis-methods | temperature-floor
             | temperature-floor-elevation | temperature-moderation-range
             | temperature-year-cycle
             | terrain-seen | turn | units-in-game-max
             | units-per-side-max | unseen-char | unseen-color
             | unseen-image-name | use-side-priority | wet-blob-density
             | wet-blob-height | wet-blob-size | wet-smoothing
             | wind-mix-range

     synthesis-methods ::=
               make-countries | make-earthlike-terrain
             | make-fractal-percentile-terrain | make-independent-units
             | make-initial-materials | make-maze-terrain
             | make-random-date | make-random-terrain | make-rivers
             | make-roads | make-weather | name-geographical-features
             | name-units-randomly

     random-event-method ::=
               accidents-in-terrain | attrition-in-terrain
             | units-revolt | unit-surrender

