Sophie

Sophie

distrib > Mandriva > 2010.0 > i586 > media > contrib-release > by-pkgid > 74fbd0eb33bb08f719b79951bc4e329e > files > 100

xconq-7.5.0-1.20050612.5mdv2009.1.i586.rpm

<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.39
     from ./xcdesign.texi on 12 June 2005 -->

<TITLE>Designing Games with Xconq - Backdrop</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_50.html">previous</A>, <A HREF="xcdesign_52.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC261" HREF="xcdesign_toc.html#SEC261">Backdrop</A></H2>

<P>
This section describes the parameters affecting backdrop computations.

</P>

<UL>
<LI><A HREF="xcdesign_51.html#SEC262">Years and Days</A>
<LI><A HREF="xcdesign_51.html#SEC263">Temperature Variation</A>
<LI><A HREF="xcdesign_51.html#SEC264">Temperature Effects</A>
<LI><A HREF="xcdesign_51.html#SEC265">Wind Variation</A>
<LI><A HREF="xcdesign_51.html#SEC266">Unit Production and Consumption</A>
<LI><A HREF="xcdesign_51.html#SEC267">Terrain Production and Consumption</A>
<LI><A HREF="xcdesign_51.html#SEC268">Supply Lines</A>
<LI><A HREF="xcdesign_51.html#SEC269">Side Research</A>
<LI><A HREF="xcdesign_51.html#SEC270">Unit Research</A>
<LI><A HREF="xcdesign_51.html#SEC271">Terrain Attrition</A>
<LI><A HREF="xcdesign_51.html#SEC272">Terrain Accident</A>
<LI><A HREF="xcdesign_51.html#SEC273">Unit Revolt</A>
<LI><A HREF="xcdesign_51.html#SEC274">Unit Surrender</A>
</UL>



<H3><A NAME="SEC262" HREF="xcdesign_toc.html#SEC262">Years and Days</A></H3>

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

</P>
<P>
<U>WorldProperty:</U> <B><CODE>year-length</CODE></B> <I>n</I><P>
<A NAME="IDX880"></A>
This property is the number of turns in an annual cycle.  If less than
<CODE>2</CODE>, then no seasonal effects will be calculated.

</P>
<P>
<U>WorldProperty:</U> <B><CODE>day-length</CODE></B> <I>n</I><P>
<A NAME="IDX881"></A>
This property is the number of turns in a single day.  If less than
<CODE>2</CODE>, then day and night will not be calculated.

</P>
<P>
Note that <CODE>year-length</CODE> and <CODE>day-length</CODE> are completely
independent of each other, and it is possible to have days that are
longer than years.

</P>
<P>
<U>AreaProperty:</U> <B><CODE>initial-year-part</CODE></B> <I>n</I><P>
<A NAME="IDX882"></A>
This property is the season of the first turn in the game.  This affects the 
sun position, if the sunlit region is dynamically changing.  In particular, 
this can be used to start the sun somewhere other than one of the equinoxes.

</P>
<P>
<U>AreaProperty:</U> <B><CODE>initial-day-part</CODE></B> <I>n</I><P>
<A NAME="IDX883"></A>
This property is the hour of the first turn in the game, in 100ths of a
day part.  This affects the sun position, if the sunlit region is 
dynamically changing.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>season-names</CODE></B> <I>list</I><P>
<A NAME="IDX884"></A>
This global is a list of which turns in a year should be called which
seasons.  It has the form <CODE>(... (n1 n2 name) ...)</CODE>.  Defaults to
<CODE>()</CODE>.

</P>
<P>
A twelve-turn year with four seasons would be

<PRE>
((0 2 "winter") (3 5 "spring") (6 8 "summer") (9 11 "autumn"))
</PRE>

<P>
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.

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>acp-season-effect</CODE></B> <I>interpolation-list</I><P>
<A NAME="IDX885"></A>
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
<CODE>acp-per-turn</CODE>.  Defaults to <CODE>()</CODE>.

</P>
<P>
<U>WorldProperty:</U> <B><CODE>daylight-fraction</CODE></B> <I>n%</I><P>
<A NAME="IDX886"></A>
This property is the percentage of the world's circumference that has
daylight.  Defaults to <CODE>50</CODE>.

</P>
<P>
<U>WorldProperty:</U> <B><CODE>twilight-fraction</CODE></B> <I>n%</I><P>
<A NAME="IDX887"></A>
This property is the percentage of the world's circumference that has
daylight and twilight.  Defaults to <CODE>60</CODE>.

</P>
<P>
<U>AreaProperty:</U> <B><CODE>sun</CODE></B> <I>x y</I><P>
<A NAME="IDX888"></A>
This property is the initial position of the sun over the area.
Defaults to the exact middle of the area.

</P>



<H3><A NAME="SEC263" HREF="xcdesign_toc.html#SEC263">Temperature Variation</A></H3>

<P>
<U>TerrainTypeProperty:</U> <B><CODE>temperature-average</CODE></B> <I>n</I><P>
<A NAME="IDX889"></A>
This property is the average temperature for each type of terrain.

</P>
<P>
<U>TerrainTypeProperty:</U> <B><CODE>temperature-variability</CODE></B> <I>n</I><P>
<A NAME="IDX890"></A>
This property is the amount of totally random variation in the
temperature in each cell.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>temperature-year-cycle</CODE></B> <I>((x y) interpolation-list)...</I><P>
<A NAME="IDX891"></A>
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
<VAR>x</VAR>,<VAR>y</VAR>.  Then for each point in the area, its temperature is
the interpolation of the temperature at the two nearest given points.
Defaults to <CODE>()</CODE>.

</P>
<P>
<U>TerrainTypeProperty:</U> <B><CODE>temperature-moderation-range</CODE></B> <I>distance</I><P>
<A NAME="IDX892"></A>
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.

</P>



<H3><A NAME="SEC264" HREF="xcdesign_toc.html#SEC264">Temperature Effects</A></H3>

<P>
<U>UnitTypeProperty:</U> <B><CODE>acp-temperature-effect</CODE></B> <I>interpolation-list</I><P>
<A NAME="IDX893"></A>
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 &#60; 100 reduces acp, an effect of
100 has no effect, and an effect &#62; 100 increases acp.  Defaults to
<CODE>()</CODE>.

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>consumption-temperature-effect</CODE></B> <I>interpolation-list</I><P>
<A NAME="IDX894"></A>
This property is the effect of temperature on material consumption.
Defaults to <CODE>()</CODE>.

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>temperature-attrition</CODE></B> <I>interpolation-list</I><P>
<A NAME="IDX895"></A>
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 <CODE>()</CODE>.

</P>
<P>
Transports can protect their occupants from temperature extremes.

</P>
<P>
<U>TableUU:</U> <B><CODE>temperature-protection</CODE></B> <I>u1 u2 -&#62; t/f</I><P>
<A NAME="IDX896"></A>
This is true if transports of type <VAR>u1</VAR> protect occupants of type
<VAR>u2</VAR> from the effects of the cell's temperature.

</P>



<H3><A NAME="SEC265" HREF="xcdesign_toc.html#SEC265">Wind Variation</A></H3>

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

</P>
<P>
<U>TerrainTypeProperty:</U> <B><CODE>wind-force-average</CODE></B> <I>n</I><P>
<A NAME="IDX897"></A>
This property is the average wind force in a type of terrain.

</P>
<P>
<U>TerrainTypeProperty:</U> <B><CODE>wind-force-variability</CODE></B> <I>n%</I><P>
<A NAME="IDX898"></A>
This property is the chance that the wind in a cell will increase or
decrease in force each turn.

</P>
<P>
<U>TerrainTypeProperty:</U> <B><CODE>wind-variability</CODE></B> <I>n%</I><P>
<A NAME="IDX899"></A>
This property is the chance that the wind in a cell will change
direction each turn.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>wind-mix-range</CODE></B> <I>n</I><P>
<A NAME="IDX900"></A>
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.

</P>



<H3><A NAME="SEC266" HREF="xcdesign_toc.html#SEC266">Unit Production and Consumption</A></H3>

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

</P>
<P>
<U>TableUM:</U> <B><CODE>base-production</CODE></B> <I>u m -&#62; n</I><P>
<A NAME="IDX901"></A>
This table is the basic amount of each material <VAR>m</VAR> produced by a
unit of type <VAR>u</VAR> in each turn.

</P>
<P>
<U>TableUM:</U> <B><CODE>occupant-base-production</CODE></B> <I>u m -&#62; n</I><P>
<A NAME="IDX902"></A>
This table is the base production of each material <VAR>m</VAR> by a unit
of type <VAR>u</VAR> when it is an occupant of any other unit.  The default of
<CODE>-1</CODE> means to use the number from <CODE>base-production</CODE>.

</P>
<P>
<U>TableUT:</U> <B><CODE>productivity</CODE></B> <I>u t -&#62; n%</I><P>
<A NAME="IDX903"></A>
This table is the percentage productivity of a unit of type <VAR>u</VAR> when
on terrain of type <VAR>t</VAR>.  This is multiplied with the basic
production rate to get actual material production, so productivity of
<CODE>0</CODE> completely disables production on that terrain type, and
productivity of <CODE>100</CODE> yields the rate specified by
<CODE>base-production</CODE>.  Defaults to <CODE>100</CODE>.

</P>
<P>
<U>TableUT:</U> <B><CODE>productivity-adjacent</CODE></B> <I>u t -&#62; n%</I><P>
<A NAME="IDX904"></A>
This table is the percentage productivity of a unit of type <VAR>u</VAR>
when adjacent to terrain of type <VAR>t</VAR>.  The actual productivity
of a unit is a max of its productivity on its own cell and the adjacent
cells.

</P>
<P>
<U>TableUM:</U> <B><CODE>productivity-min</CODE></B> <I>u m -&#62; n</I><P>
<A NAME="IDX905"></A>
<U>TableUM:</U> <B><CODE>productivity-max</CODE></B> <I>u m -&#62; n</I><P>
<A NAME="IDX906"></A>
These tables are the lower and upper bounds on actual production after
multiplying by productivity.  Default to <CODE>0</CODE> and <CODE>9999</CODE>,
respectively.

</P>
<P>
<U>TableUM:</U> <B><CODE>base-consumption</CODE></B> <I>u m -&#62; n</I><P>
<A NAME="IDX907"></A>
This table sets the amount of materials consumed by the unit in a turn,
even if it doesn't move or do anything else.  This is a minimum rather than
an amount added to others, so movement will not cause the unit to consume
extra material until it reaches the base consumption.

</P>
<P>
<U>TableUM:</U> <B><CODE>hp-per-starve</CODE></B> <I>u m -&#62; .01hp</I><P>
<A NAME="IDX908"></A>
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.

</P>
<P>
<U>TableUM:</U> <B><CODE>consumption-as-occupant</CODE></B> <I>u m -&#62; n%</I><P>
<A NAME="IDX909"></A>
This table is the consumption by a unit of type <VAR>u1</VAR> when it is an
occupant, expressed as a percentage of its <CODE>base-consumption</CODE>.
This is useful for units such as planes which always consume fuel in the
air but not on the ground.  Defaults to <CODE>100</CODE>.

</P>
<P>
<U>TableUM:</U> <B><CODE>gives-to-treasury</CODE></B> <I>u m -&#62; t/f</I><P>
<A NAME="IDX910"></A>
This table is true if units of type <VAR>u</VAR> are able to transfer
material of type <VAR>m</VAR> to the side's treasury.

</P>



<H3><A NAME="SEC267" HREF="xcdesign_toc.html#SEC267">Terrain Production and Consumption</A></H3>

<P>
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.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-production</CODE></B> <I>t m -&#62; n</I><P>
<A NAME="IDX911"></A>
This table is the amount of each material <VAR>m</VAR> produced by a cell of
the given type <VAR>t</VAR> in each turn.  This refers to the material actually
produced by the cell itself, which goes into the cell's own materials store
and may be available through extraction actions or the backdrop economy.
Production by advanced units that use the cell is determined by the
<CODE>production-from-terrain</CODE> table.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-consumption</CODE></B> <I>t m -&#62; n</I><P>
<A NAME="IDX912"></A>
This table is the amount of material <VAR>m</VAR> consumed by a cell of type
<VAR>t</VAR> each turn.  If insufficient material is available, then the
terrain may change type.

</P>
<P>
<U>TableTM:</U> <B><CODE>change-on-exhaustion-chance</CODE></B> <I>t m -&#62; n%</I><P>
<A NAME="IDX913"></A>
This table is the chance that a cell of type <VAR>t</VAR>, with no supply of
material of type <VAR>m</VAR>, will become exhausted and change to its
exhausted type.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-exhaustion-type</CODE></B> <I>t1 m -&#62; t2</I><P>
<A NAME="IDX914"></A>
If <VAR>t2</VAR> is not <CODE>non-terrain</CODE>, then this table says that any
cell with terrain <VAR>t1</VAR> that is exhausted will change to <VAR>t2</VAR>.
If several materials are exhausted in the same turn, then the
lowest-numbered material type will determine the new terrain type.
Defaults to <CODE>non-terrain</CODE>.

</P>
<P>
<U>TableMM:</U> <B><CODE>people-consumption</CODE></B> <I>m1 m2 -&#62; n</I><P>
<A NAME="IDX915"></A>
This table is the base consumption per turn by people of type <VAR>m1</VAR>
of each other material type <VAR>m2</VAR>.

</P>
<P>
<U>TableMM:</U> <B><CODE>people-production</CODE></B> <I>m1 m2 -&#62; n</I><P>
<A NAME="IDX916"></A>
This table is the people of type <VAR>m1</VAR> base production per turn of
each other material type <VAR>m2</VAR>.

</P>



<H3><A NAME="SEC268" HREF="xcdesign_toc.html#SEC268">Supply Lines</A></H3>

<P>
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, <I>Xconq</I>
provides a <STRONG>backdrop economy</STRONG>, which moves materials around
automatically.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>backdrop-model</CODE></B> <I>n</I><P>
<A NAME="IDX917"></A>
Two models (potentially more in the future) are available for deciding
when and where to transfer materials in the backdrop economy, and they
support different features.  This variable chooses among the available
models.

</P>
<P>
The default, model <CODE>0</CODE>, supports only transfers among units
and between units and treasuries, according to <CODE>in-length</CODE>,
<CODE>out-length</CODE>, and the treasury settings configured elsewhere.  It uses
a complicated set of rules to determine which units need supplies, based on
their consumption, production, doctrine, and other factors; and it tries to
keep material in treasuries instead of units to the extent possible.

</P>
<P>
Model <CODE>1</CODE> has a much different philosophical basis.  Instead of trying
to divine the designer's intent by examining the game rules, it attempts to be
as simple and predictable as possible; its basic rule is that materials
always flow wherever they can, from things that have more to things that
have less, in such a way as to level out any differences in material supply.
It treats treasuries simply as additional units with large capacity, linked
to all units that can access the treasuries.  If there are two
material-handling things (units, treasuries, or terrain cells) that
can transfer material, then model <CODE>1</CODE> will keep roughly the same amount
of material in each of them, unless that would see one filled beyond its
capacity or emptied below its resupply doctrine level, in which case they
will be as close to equal as possible given the limitations of the game rules.

</P>
<P>
<U>TableUM:</U> <B><CODE>in-length</CODE></B> <I>u1 m -&#62; dist</I><P>
<A NAME="IDX918"></A>
<U>TableUM:</U> <B><CODE>out-length</CODE></B> <I>u2 m -&#62; dist</I><P>
<A NAME="IDX919"></A>
These two tables together determine the length of supply lines between
units.  The given type of material can only be transferred from unit
type <VAR>u1</VAR> to unit type <VAR>u2</VAR> if the distance is less than the
minimum of the <CODE>in-length</CODE> of <VAR>u1</VAR> and the <CODE>out-length</CODE> of
<VAR>u2</VAR>.

</P>
<P>
For instance, the <CODE>in-length</CODE> for a fighter's fuel might be 3
cells, while the <CODE>out-length</CODE> 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.

</P>
<P>
An in- or out-length of <CODE>0</CODE> means that the two units must be in the
same cell, while a negative length disables the automatic transfer
completely.  Large <CODE>out-length</CODE> values should be used sparingly in model
<CODE>0</CODE>, since the algorithm uses the <CODE>out-length</CODE> to define a
radius of search for units to be resupplied; and model <CODE>0</CODE> ignores
<CODE>out-length</CODE> anyway in the case of materials its rules decide are
"scarce".  Model <CODE>1</CODE> always obeys <CODE>out-length</CODE>, and large values
make no significant difference to its running time.  Both tables default to
<CODE>0</CODE>.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>backdrop-ignore-doctrine</CODE></B> <I>t/f</I><P>
<A NAME="IDX920"></A>
In model <CODE>1</CODE>, setting this variable <CODE>true</CODE> will allow the
algorithm to move material away from units even when the units are already
below the minimum levels set by their resupply doctrine.  Ignoring doctrine
is arguably the approach most consistent with the philosophy of model
<CODE>1</CODE>, which is to not attempt to judge which units are or are not needy
and only look at their current supply levels as raw numbers.  Nonetheless,
the default is <CODE>false</CODE>: material will never be moved away from a unit
already below its resupply level, to avoid surprising game designers or
players who might set a doctrine level and then wonder why units are being
drained below that level in the backdrop economy.  Which setting works best
in a given game design may have to be determined by trial and error.  Note
that this setting is specific to model <CODE>1</CODE>, and will have no effect in
model <CODE>0</CODE>.

</P>
<P>
The following six tables control automatic transfers involving terrain.
These tables are meaningful only in model <CODE>1</CODE> at present, although it
is possible that some future new model or enhancement to model <CODE>0</CODE> might
also use them.  There are two tables for each of three kinds of transfers:
terrain to unit, unit to terrain, and terrain to terrain.  Terrain to unit
transfers are similar to <CODE>extract</CODE> actions, but happen automatically
and without expenditure of any ACP, during the economy phase at the start
of each turn.  Unit to terrain transfers operate in the reverse direction,
with material automatically transferred from the unit's store to terrain;
such transfers are intended for special effects like poison gas.  Terrain to
terrain transfers allow material to diffuse across the landscape.

</P>
<P>
At present, there is no feature provided to limit terrain transfers according
to control or ownership, so if unit to terrain transfers are permitted, it is
entirely possible that a unit will transfer material to terrain and then
some other unit from some other side may pick it up by means of other
features, automatically or not, and either directly or after the material
has diffused through other intervening cells.

</P>
<P>
<U>TableUM:</U> <B><CODE>terrain-to-unit-in-length</CODE></B> <I>u m -&#62; dist</I><P>
<A NAME="IDX921"></A>
Sets the maximum distance at which a unit can receive materials from
terrain in the backdrop economy, according to unit and material type.
Note that these transfers occur automatically and without expenditure of
ACP; deliberate transfers, possibly with an ACP cost, are handled by
<CODE>extract</CODE> actions and configured elsewhere.  Default is <CODE>-1</CODE>,
which disables backdrop terrain to unit transfers.
Large values may
result in slow computation, but currently-planned, not yet implemented,
optimizations should eliminate that issue as long as no very-long-distance
transfers are actually permitted by the other tables.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-to-unit-out-length</CODE></B> <I>t m -&#62; dist</I><P>
<A NAME="IDX922"></A>
Sets the maximum distance for terrain to unit transfers according to terrain
type of the cell the material is taken from, and material type.  For the
transfer to be allowed, the distance must be less than or equal to the
smaller of the relevant <CODE>terrain-to-unit-in-length</CODE> and
<CODE>terrain-to-unit-out-length</CODE> values.  At present, only the cell terrain
type is examined (other kinds of terrain are ignored).  The default is the
maximum table value, so that terrain type has no effect on terrain to unit
transfers.  To make it impossible for units to receive a given material from
a given terrain type by automatic backdrop economy transfers, set the
relevant <CODE>terrain-to-unit-out-length</CODE> value to <CODE>-1</CODE>.

</P>
<P>
<U>TableUM:</U> <B><CODE>unit-to-terrain-out-length</CODE></B> <I>u m -&#62; dist</I><P>
<A NAME="IDX923"></A>
Sets the maximum distance for unit to terrain transfers according to unit
type and material type.  As with <CODE>terrain-to-unit-in-length</CODE>, these
transfers occur automatically without player control.  Remember that
materials once transferred to cells are not automatically owned by any side,
and may be picked up by other sides.  Default is <CODE>-1</CODE>, which disables
such transfers.  Large values may result in slow computation, but
currently-planned, not yet implemented, optimizations should eliminate
that issue as long as no very-long-distance transfers are actually
permitted by the other tables.

</P>
<P>
<U>TableTM:</U> <B><CODE>unit-to-terrain-in-length</CODE></B> <I>t m -&#62; dist</I><P>
<A NAME="IDX924"></A>
Sets the maximum distance for unit to terrain transfers according to cell
terrain type of the cell the material is transferred into, and material type.
As with <CODE>terrain-to-unit-out-length</CODE>, only the cell type is considered.
The default is the maximum table value, and setting a value to <CODE>-1</CODE>
disables automatic unit-to-terrain transfers of that material into that
terrain.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-to-terrain-out-length</CODE></B> <I>t1 m -&#62; dist</I><P>
<A NAME="IDX925"></A>
Maximum distance for automatic terrain to terrain transfers (diffusion) of
material m out of terrain type t1.  Default value <CODE>-1</CODE>, which disables
diffusion.  At present, only cell terrain is considered; however, a planned
enhancement will change the default value to <CODE>0</CODE> (still disabling
diffusion by default, because diffusion from a cell to itself has no effect)
and treat border, connection, and coating terrain as modifiers, so that the
actual out-length used will be the sum of the table values for the cell,
each coating, and each border or connection on the side nearest the
destination cell.

</P>
<P>
<U>TableTM:</U> <B><CODE>terrain-to-terrain-in-length</CODE></B> <I>t2 m -&#62;dist</I><P>
<A NAME="IDX926"></A>
Maximum distance for automatic terrain to terrain transfers (diffusion) of
material m into terrain type t2.  Default value is <CODE>1</CODE>, allowing
transfers only between adjacent cells.  As with
<CODE>terrain-to-terrain-out-length</CODE> above, this presently only considers
cell type but a planned enhancement will make it consider borders,
connections, and coatings as well.

</P>
<P>
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.  The advanced supply line algorithm is activated by
the <CODE>supply</CODE> variant, and runs completely separately from the model
<CODE>0</CODE> or model <CODE>1</CODE> economy system described above.

</P>
<P>
<U>Table:</U> <B><CODE>supply-capacity-deterioration</CODE></B><P>
<A NAME="IDX927"></A>
<U>Table:</U> <B><CODE>supply-capacity-threshold</CODE></B><P>
<A NAME="IDX928"></A>
<U>Table:</U> <B><CODE>supply-deterioration</CODE></B><P>
<A NAME="IDX929"></A>
<U>Table:</U> <B><CODE>supply-enemy-interdiction</CODE></B><P>
<A NAME="IDX930"></A>
<U>Table:</U> <B><CODE>supply-importance</CODE></B><P>
<A NAME="IDX931"></A>
<U>Table:</U> <B><CODE>supply-in-max</CODE></B><P>
<A NAME="IDX932"></A>
<U>Table:</U> <B><CODE>supply-interdiction-adjacent</CODE></B><P>
<A NAME="IDX933"></A>
<U>Table:</U> <B><CODE>supply-interdiction-adjacent-for-material</CODE></B><P>
<A NAME="IDX934"></A>
<U>Table:</U> <B><CODE>supply-interdiction-at</CODE></B><P>
<A NAME="IDX935"></A>
<U>Table:</U> <B><CODE>supply-interdiction-at-for-material</CODE></B><P>
<A NAME="IDX936"></A>
<U>Table:</U> <B><CODE>supply-in-threshold</CODE></B><P>
<A NAME="IDX937"></A>
<U>Table:</U> <B><CODE>supply-in-weight</CODE></B><P>
<A NAME="IDX938"></A>
<U>Table:</U> <B><CODE>supply-neutral-interdiction</CODE></B><P>
<A NAME="IDX939"></A>
<U>Table:</U> <B><CODE>supply-out-max</CODE></B><P>
<A NAME="IDX940"></A>
<U>Table:</U> <B><CODE>supply-out-threshold</CODE></B><P>
<A NAME="IDX941"></A>
<U>Table:</U> <B><CODE>supply-potential</CODE></B><P>
<A NAME="IDX942"></A>
<U>Table:</U> <B><CODE>supply-potential-terrain-effect</CODE></B><P>
<A NAME="IDX943"></A>
<U>Table:</U> <B><CODE>supply-starve-weight</CODE></B><P>
<A NAME="IDX944"></A>
<U>Table:</U> <B><CODE>occupant-supply-potential</CODE></B><P>
<A NAME="IDX945"></A>

</P>



<H3><A NAME="SEC269" HREF="xcdesign_toc.html#SEC269">Side Research</A></H3>

<P>
Sides may achieve advances by researching them.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>side-can-research</CODE></B> <I>t/f</I><P>
<A NAME="IDX946"></A>
This variable is true if the side can do research.

</P>
<P>
<U>GlobalVariable:</U> <B><CODE>indepside-can-research</CODE></B> <I>t/f</I><P>
<A NAME="IDX947"></A>
This variable is true if the independent side can do research.

</P>
<P>
<U>TableAA:</U> <B><CODE>advance-needed-to-research</CODE></B> <I>a1 a2 -&#62; t/f</I><P>
<A NAME="IDX948"></A>
This table indicates whether advance <VAR>a1</VAR> needs <VAR>a2</VAR>
to have been achieved first.

</P>
<P>
<U>TableAA:</U> <B><CODE>advance-precludes-advance</CODE></B> <I>a1 a2 -&#62; t/f</I><P>
<A NAME="IDX949"></A>
True, if researching <VAR>a1</VAR> prevents <VAR>a2</VAR> from being researched.

</P>
<P>
<U>TableAA:</U> <B><CODE>advance-consumption-per-rp</CODE></B> <I>a m -&#62; n</I><P>
<A NAME="IDX950"></A>
This table is the amount of material type <VAR>m</VAR> consumed
to add one research point for <VAR>a</VAR>.

</P>



<H3><A NAME="SEC270" HREF="xcdesign_toc.html#SEC270">Unit Research</A></H3>

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

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>can-research</CODE></B> <I>t/f</I><P>
<A NAME="IDX951"></A>
This property is true if the unit can work on advances in the
background.

</P>



<H3><A NAME="SEC271" HREF="xcdesign_toc.html#SEC271">Terrain Attrition</A></H3>

<P>
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.

</P>
<P>
<U>TableUT:</U> <B><CODE>attrition</CODE></B> <I>u t -&#62; .01hp</I><P>
<A NAME="IDX952"></A>
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.

</P>



<H3><A NAME="SEC272" HREF="xcdesign_toc.html#SEC272">Terrain Accident</A></H3>

<P>
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.

</P>
<P>
<U>TableUT:</U> <B><CODE>accident-hit-chance</CODE></B> <I>u t -&#62; .01n%</I><P>
<A NAME="IDX953"></A>
This table is the chance of the unit being hit while in the given terrain.

</P>
<P>
<U>TableUT:</U> <B><CODE>accident-damage</CODE></B> <I>u t -&#62; hp</I><P>
<A NAME="IDX954"></A>
This table is the hp that will be lost in an accident.  The value is a dice spec.

</P>
<P>
<U>TableUT:</U> <B><CODE>accident-vanish-chance</CODE></B> <I>u t -&#62; .01n%</I><P>
<A NAME="IDX955"></A>
This table is the chance of the unit simply vanishing while in the given terrain.

</P>



<H3><A NAME="SEC273" HREF="xcdesign_toc.html#SEC273">Unit Revolt</A></H3>

<P>
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.

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>revolt-chance</CODE></B> <I>.01n%</I><P>
<A NAME="IDX956"></A>
This property is the chance for the unit to revolt spontaneously.

</P>
<P>
<U>UnitTypeProperty:</U> <B><CODE>revolt-at-opinion-min</CODE></B> <I>.01n%</I><P>
<A NAME="IDX957"></A>
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.

</P>



<H3><A NAME="SEC274" HREF="xcdesign_toc.html#SEC274">Unit Surrender</A></H3>

<P>
<U>TableUU:</U> <B><CODE>surrender-chance</CODE></B> <I>u1 u2 -&#62; .01n%</I><P>
<A NAME="IDX958"></A>
This table is the chance that a unit of type <VAR>u1</VAR> will change its side
to match the side of a unit <VAR>u2</VAR> that is within the <CODE>surrender-range</CODE>
for the two types.

</P>
<P>
<U>TableUU:</U> <B><CODE>surrender-range</CODE></B> <I>u1 u2 -&#62; dist</I><P>
<A NAME="IDX959"></A>
This table is the distance out to which a unit of type <VAR>u1</VAR>
will surrender to a unit of type <VAR>u2</VAR>.
Defaults to <CODE>1</CODE>.

</P>

<HR>
Go to the <A HREF="xcdesign_1.html">first</A>, <A HREF="xcdesign_50.html">previous</A>, <A HREF="xcdesign_52.html">next</A>, <A HREF="xcdesign_61.html">last</A> section, <A HREF="xcdesign_toc.html">table of contents</A>.
</BODY>
</HTML>