On 21 April 2013 00:21, Emmet Hikory <per...@shipstone.jp> wrote:

>     The client code seems to use UMT_*, TC_OCEAN, is_foo_unit(), and
> is_ocean() in several places for which I don't really understand the
> correct behaviour to support complex unit nativity.  Suggestions,
> opinions, and pointers to open bugs or patches welcome.
> climisc.c:unit_color_type()
>     This function uses UMT_* as a guide to set the correct background
> color for a unit, which seems only to be used in the Xaw client.  I
> would think that with complex nativity, it makes sense to assign the
> background color for tiles based on terrain, player knowledge, etc.  I
> don't have much familiarity with Xaw, so I don't understand if we can
> use logic like that used for the gtk2/3 clients' create_overlay_unit()
> (or some analog thereto) to initialise to black and then modify based on
> terrain/tileset definitions.

 This was used in other clients too, but has now been cleaned away from all
but xaw-client.

> unitselect_common.c:usdlg_check_unit_location()
>     This function has support for selecting units based on move_type
> explicitly.  I've never used this feature, so don't know common use
> cases. For complex nativity, I suspect that these become less useful:
> various amphibious units are inherently excluded, which may be
> unfortunate for rulesets with many ocean depths that allow most land
> units on the shallowest of oceans (which might not be particularly deep,
> and may not permit access by most seaworthy units).  Units with
> restrictions within classic nativity (only some land, only some oceanic,
> only roads, etc.) may be selected inappropriately, as they might be
> unsuitable for use for the intended purpose (e.g. cannot move to some
> target).

 patch #3721?

>     Those client uses of is_ocean() and TC_OCEAN not mentioned above
> seemed sane to me (and safe for complex nativity), although I wonder if
> the code ought standardise on one or the other representation of this
> idea (changelogs suggest general migration to is_ocean(), but some of
> the calls that use TC_OCEAN might need refactoring for this).  The idea
> of selecting coastal cities may also be slightly less useful for
> rulesets with particularly complex nativity, as some "coastal" cities
> might not support many "sea" units, etc.  Similarly, the current
> "coastal" check happens to also select all Oceanic cities that aren't
> built on a lake.

 The differences are probably explained by what the terrain code has been
like at the time of writing the code in question. Terrain class in its
current form (where it's sensiblle thing to check TC_OCEAN directly) is
just a couple of months old, is_ocean() used to check for terrain flag.
With the idea that we may some day have more terrain classes than just
"Land" and "Ocean", I think boolean is_ocean() should be avoided in new

 - ML
Freeciv-dev mailing list

Reply via email to