Important changes in the Xconq API

[Hans Ronne <hronne at telia dot com>]

I have just checked in some changes in the Xconq API that may break
existing games or cause them to work differently. It has to do with the
role of connections and how they affect the ability of a unit to sit in a
cell. There used to be "extra" space for units available in cells that had
connections, since the connections also could store units. Unfortunately,
this caused serious problems with restoring saved games that could not
easily be solved. Saved units that had been sitting on a connection would
end up on the ground, thus blocking other saved units from access to the
spot where they had been sitting.

In an attempt to fix this problem once and for all, I have removed the
extra space within connections. This means that you must now have room for
a unit in a cell if you want it to enter that cell. unit-size-in-terrain
must therefore be set to something reasonable for the cell terrain, and
there must be free space in the cell, whether or not there is a connection
present. Setting unit-size-in-terrain to something larger than that
terrain's capacity (e.g. 99) should only be used for terrain that you don't
want a unit to be able to enter even if there is a connection.

So how do you prevent a unit from entering a certain terrain type but
permit it to do so if there is a connection? Just use a large
mp-to-enter-terrain (e.g. 99) for that unit and terrain type, but make
mp-to-traverse small (e.g. 1) for the same unit and the connection. The
unit will then use the latter smaller mp value if a connection is present
and thus be able to enter the cell. It is also important that
mp-to-enter-terrain is zero or small for the connection.

Game designers sometimes try to limit unit movement by setting vanishes-on
or wrecks-on to 1 for certain terrains and unit types. Please be aware,
however, that this does not prevent a unit from entering the terrain. It
just kills the unit if you do so. In most of the existing games, you never
see this happen since movement into hostile terrain is blocked by
mp-to-enter-terrain being high. However, there are exceptions. One is if
you give the "Disembark" command to a unit thsat sits on a transport in the
standard game. The unit will then jump overboard and drown, since it
doesn't have to move into another cell. On the other hand, trying to jump
overboard by clicking on an adjacent sea cell will not work, since this
move is blocked by a high mp-to-enter-terrain for land units.

Another example where you can wreck a unit by moving into hostile terrain
is in the Voyages/Magellan game. Here, ships can enter land cells (unlike
most other games) but since wrecks-on is true for ships and land, they will
wreck and form a fort (presumably built by the shipwrecked crew).

To sum things up, here are the three most important points:

1. The recommended way to restrict unit movement is to use a high
mp-to-enter-terrain to block movement and a low mp-to-traverse to permit it
in the presence of a connection. This will prevent both the human player
and the AI from accidentally moving units into terrain where they will
perish.

2. The terrain capacity and unit-size-in-terrain should now only be used to
control the total number of units that can sit in a cell, but not to
prevent a specific unit type from entering that terrain. Do that with
mp-to-enter-terrain instead.

3. The vanishes-on and wrecks-on tables should only be used if you want a
unit to be able to enter a terrain, but then vanish (or wreck). They are
unnecessary in most games and can be left at their default values. Don't
try to use these tables to limit unit movement. Do that with
mp-to-enter-terrain instead.

I think most of the games in the library conform to these rules, but I have
not had time to check all of them yet. Bug reports are welcome.

Hans