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.

    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 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 

    This function has different heuristics for different environments. 
In rulesets that might have land transporters that carry land units, or 
sea transports that only carry sea units, or land units that can't move 
because they require roads, or similar complexities, I'm not sure that 
these heuristics are sufficient, nor that there aren't assumptions about 
available terrains and unit classes built into the heuristics.  That 
said, I don't use this, so hesitate to apply a patch that might break 
someone's gameplay.

    Naively, I would think the following might work sensibly for 
arbitrary terrains and units:

1) Native military attack units
2) Native transports
3) Other native units
4) Non-native units

    On the other hand, ordered like that, for the classic ruleset (as an 
example), Air, Helicopter, and Missile units might be selected much more 
often than was intended.  Perhaps reachability ought be added to the 
criteria checked, to decrease the chance of selection.  Given that this 
feature is most useful when the player has no time to think, it is 
somewhat important not to be surprising, either by selecting the wrong 
unit or by failing to select the expected unit because of the current 
nativity restrictions.

    This just chooses ground units before sea units: I presume the 
intent is to deprioritise sea units in port (given the score reduction 
for transported units which adjusts this).  My thought here is to 
prioritise native units over non-native units (so that the order depends 
on terrain), but I don't remember using this tool either (unless it is 
responsible for unit ordering in the unit pane in the editor), so don't 
know if this would break someone's workflow.

    Separately, this function seems to use UCF_UNREACHABLE as a proxy 
for aerial units, and selects them first.  If the sorting is somewhat 
intended to describe altitude, this wouldn't work for Burrowing units 
from the alien ruleset, for example.  If the intent is to prioritise 
"important" units somehow, where aerial==important, there's no need to 
adjust it, as most unreachable units are likely to be of particular 
interest in most rulesets.  If I'm incorrect about the proxy use here, 
then nothing needs be done for UCF_UNREACHABLE.

    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.


Freeciv-dev mailing list

Reply via email to