This section describes the parameters affecting backdrop computations.
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. 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.
AreaProperty: initial-day-part n
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.
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.
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.
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.
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.
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 by a unit
of type u when it is an occupant of any other unit. The default of
-1 means to use the number from base-production.
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. 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.
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 are able to transfer material of type m to the side's treasury.
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. 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
production-from-terrain table.
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.
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 a backdrop economy, which moves materials around automatically.
GlobalVariable: backdrop-model n
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.
The default, model 0, supports only transfers among units
and between units and treasuries, according to in-length,
out-length, 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.
Model 1 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 1 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.
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. Large out-length values should be used sparingly in model
0, since the algorithm uses the out-length to define a
radius of search for units to be resupplied; and model 0 ignores
out-length anyway in the case of materials its rules decide are
"scarce". Model 1 always obeys out-length, and large values
make no significant difference to its running time. Both tables default to
0.
GlobalVariable: backdrop-ignore-doctrine t/f
In model 1, setting this variable true 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
1, 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 false: 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 1, and will have no effect in
model 0.
The following six tables control automatic transfers involving terrain.
These tables are meaningful only in model 1 at present, although it
is possible that some future new model or enhancement to model 0 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 extract 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.
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.
TableUM: terrain-to-unit-in-length u m -> dist
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
extract actions and configured elsewhere. Default is -1,
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.
TableTM: terrain-to-unit-out-length t m -> dist
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 terrain-to-unit-in-length and
terrain-to-unit-out-length 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 terrain-to-unit-out-length value to -1.
TableUM: unit-to-terrain-out-length u m -> dist
Sets the maximum distance for unit to terrain transfers according to unit
type and material type. As with terrain-to-unit-in-length, 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 -1, 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.
TableTM: unit-to-terrain-in-length t m -> dist
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 terrain-to-unit-out-length, only the cell type is considered.
The default is the maximum table value, and setting a value to -1
disables automatic unit-to-terrain transfers of that material into that
terrain.
TableTM: terrain-to-terrain-out-length t1 m -> dist
Maximum distance for automatic terrain to terrain transfers (diffusion) of
material m out of terrain type t1. Default value -1, which disables
diffusion. At present, only cell terrain is considered; however, a planned
enhancement will change the default value to 0 (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.
TableTM: terrain-to-terrain-in-length t2 m ->dist
Maximum distance for automatic terrain to terrain transfers (diffusion) of
material m into terrain type t2. Default value is 1, allowing
transfers only between adjacent cells. As with
terrain-to-terrain-out-length above, this presently only considers
cell type but a planned enhancement will make it consider borders,
connections, and coatings as well.
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 supply variant, and runs completely separately from the model
0 or model 1 economy system described above.
Table: supply-capacity-deterioration
Table: supply-capacity-threshold
Table: supply-enemy-interdiction
Table: supply-interdiction-adjacent
Table: supply-interdiction-adjacent-for-material
Table: supply-interdiction-at-for-material
Table: supply-neutral-interdiction
Table: supply-potential-terrain-effect
Table: occupant-supply-potential
Sides may achieve advances by researching them.
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-precludes-advance a1 a2 -> t/f
True, if researching a1 prevents a2 from being researched.
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.
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.
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.
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
The HP that will be lost in an accident.
This is a Type 1 dice table.
Dice rolls less than 0 are treated as 0.
TableUT: accident-vanish-chance u t -> .01n%
This table is the chance of the unit simply vanishing while in the given terrain.
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.
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.