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.
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).
control.c:quickselect()
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.
editor.c:editor_grab_tool()
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.
--
Emmet HIKORY
___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
