Re: Important changes in the Xconq API

[Hans Ronne <hronne at telia dot com>]

>Another approach might be to make the terrain incapable of holding a
>unit (i.e. set unit-size-in-terrain to 99) and set exclusive capacity
>via terrain-capacity-x.  It would probably be the best solution for
>trains on railroads, trucks on highways, etc., unless more than one type
>of unit is supposed to use the connection.

Yes. I believe terrain-capacity-x was originally introduced in order to
make it possible for aircraft to enter any cell, even if full with ground
units. Which does make sense. But you could of course also use it for
trains etc. In that case, you would provide extra dedicated space for
trains in every cell, just like the for aircraft, and then let
mp-to-enter-terrain and mp-to-traverse restrict movement to railroads. The
benefit would be that trains could move unimpeded by ground units (and also
by each other if the dedicated space is big enough).

What will not work after my latest changes is to use terrain-capacity-x to
restrict trains to cells with railroads, since connections no longer have
their own space (and capacities). You can still define capacity and
capacity-x for auxiliary terrain types, but these are now just dummy
numbers that are not used by the code. So you would have to use
mp-to-enter-terrain to keep the trains on the tracks.

BTW, each unit type can have its own dedicated space, so you can certainly
use this feature with more than one type.

Hans