Regarding the original ticket, a simple implementation would be to have a vector for roads/bases that made a given terrain non-native for a set of unit classes, so that, for example, "Big Land" would not be native to "Grassland" if there was a "River" present. In a first-brush attempt to do this as a quick evening patch, I realise that it is complicated by interaction between multiple roads/bases.

If you have a road "River", and a road "Bridge", and a unit class "Large Boat" that is native to the NativeTile road "River", you could presumably define a "blocks_native" vector for "Bridge" that includes "Large Boat" so that the unit class cannot enter the tile. At first, this seems sensible.

Now, consider the case where there is a road "River", a base "Fortress", a unit class "Big Land", and a terrain "Grassland". If "River" has "blocks_native" "Big Land", and "Fortress" is native_to "Big Land", can the "Big Land" unit use the "Fortress"? Given the logic for "Bridge"/"Large Boat", the answer would be no, but the ruleset author may expect that Fortresses are useful for Big Land even on Rivers.

Whether the implementation waits for extras or not, there would be value in discussion of a sufficiently flexible ruleset notation to provide the described behaviours, and greater specificity about the specific behaviours desired.

> I'm playing with the idea of retiring simple specials
> completely. They all could be made in to bases (ones that cover
> single tile) or roads (ones that connect between tiles).

That's the mid-term plan. But as everything is just transitional phase to next, in a decade we may be able to combine bases and roads back to one "specials" concept. ;-)

Splitting bases and roads from specials to separate concepts instead of developing all specials at once was simply necessary for the size of the task. Dragging all aspects of all specials along would have made every single step too huge to control.

> You should take gen-roads in to account in the design, not to
> speak about just two specific road types.

Yes, I had half an eye on gem-roads.
Although I'm not sure whether it should be just road-like specials for this feature or any kind of special; it wouldn't be much more work to allow e.g. units that can't move into fallout/pollution squares.

> I take it that you just wrote this down so it's not forgotten.
> Or are you going to implement it soon?

Mostly the former, although I don't promise not to get round to it ;) Do your thing first, I reckon. (Yours also enables RailNative, it sounds like.)

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 terrain.
• 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}