Summary: Generalise RoadNative/RiverNative
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Sun Sep  4 00:49:08 2011
                Category: general
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: 



In bug #16383, tirolalira requests:

"1- I'm testing also the "big land" units that can't move to some terrain
unless roaded (using roadnative), and I would like to be able to create a land
class that can't cross rivers unless roaded (to recreate the importance of
bridges for tanks in ww2).

I think it would also be realistic to have sea units that can enter rivers
except if roaded (to recreate big ships stoped by bridges)."

Another, simpler thing that's missing is RailNative (not that anyone's asked
for it).

Here's a sketch of a design that would allow the above rulesets and more:
* Retire RoadNative/RiverNative unit class flags.
* Instead, have a unit class parameter in the ruleset which consists of an
ordered list of terrain features, each possibly negated. When determining
whether terrain is native to a unit, the list is scanned from left to right,
with the underlying terrain "native_to" being considered after all features in
the list. Examples:
** "Big Land" units that can't cross rivers unless roaded: "road,!river".
This means: native if roaded, else *not* native if river, else check
underlying terrain (plains, !mountain, etc).
*** (If road weren't implicit in rail, this would be "rail,road,!river", with
the order of "road" and "rail" not mattering.)
** Riverboats that can't pass under bridges: "!road,river": *not* native if
roaded, else native if river, else check underlying terrain (oceanic).
** RailNative is just "rail".
* Could possibly include bases in this list, moving them out of
terrain.ruleset. Otherwise they'll be considered at the end of the list, like
* An arbitrarily long list is awkward to send over the network and search in
the code. If that's an issue, we could retain the expressiveness of the
ruleset definition, but implement it with a small number of "layered"
bitmasks, which could be expanded in future if necessary.
** To implement the above examples would require just three such bitmasks:
"POS1", "NEG", "POS2".
*** Land example: POS1={ROAD}, NEG={RIVER}, POS2={} (or {ROAD|RAIL}, {RIVER},
*** Sea example: POS1={}, NEG={ROAD}, POS2={RIVER}


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to