URL:
  <http://gna.org/bugs/?21470>

                 Summary: [metaticket] Fix non-nested requirement ranges
                 Project: Freeciv
            Submitted by: jtn
            Submitted on: Sat Jan 11 19:11:05 2014
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: None
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
                 Release: 
         Discussion Lock: Any
        Operating System: None
         Planned Release: 

    _______________________________________________________

Details:

Current code is inconsistent whether REQ_RANGE_ADJACENT/CADJACENT looks at the
centre tile (the one checked by REQ_RANGE_LOCAL) or *just* the surrounding
ones.

The following do include the centre tile;
* SPECIAL (up to 2.5)
* TERRAIN (at least 2.3+)
* RESOURCE (2.5+)

The following do not:
* TERRAINCLASS (at least 2.3+)
* BASE (at least 2.3 - 2.5)
* CITYTILE (2.4+)
* ROAD (2.5)
* TERRFLAG (2.5+)
* BASEFLAG (2.6+)
* ROADFLAG (2.6+)
* EXTRA (2.6+)
* MAXTILEUNITS (2.6+)

(Where supported, REQ_RANGE_CITY always does include the centre tile, I
think.)

I think there are a few reasons that we should make it a general principle
that requirement ranges should be strictly nested (e.g. adjacent implies
centre), wherever it makes sense:
* Various code treats the ranges as a total order, with higher-numbered ranges
enclosing lower-numbered ones.
* When multiple ranges of effect are available, the AI will pick the highest
range to consider.
* For ADJACENT, centre+surroundings is more likely to be what the ruleset
author wanted, and we can't usually express 'or' in requirements lists;
however, with centre+surrounding semantics, the ruleset author can obtain a
just-the-surroundings effect with range=ADJACENT + range=LOCAL|present=FALSE.

(The nesting is probably not completely precise; I wouldn't be surprised if
there are corner cases as you move from tile-based ranges to player-based
ones, or for requirement types like DIPLREL. I don't think that matters
hugely.

Another example of this principle (to which I think we do already adhere) is
that a requirement in the ALLIED range should be satisfied if we ourselves
have the thing (as for PLAYER), not just if one of our allies does.




    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?21470>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to