Follow-up Comment #5, patch #4671 (project freeciv):

Thanks for the deeper expansion of my suggestion, yes that was what I meant,
although I hadn't thought it through as completely.  Having read that,
Alternative 1 looks very tempting, except for the complexity.  Looking through
the various call stacks for attack testing, it seems that many of the
historical developers got lost: there is multiple repetition of tests, with
different early shortcuts in different views, depending on who thought what
was a good idea.  The logic in unit_move_handling() differs somewhat, but both
the client (in can_units_attack_at()) and the AI (all over the place) seem to
rely on can_unit_attack_tile(), which requires:

1) The unit is not UTYF_CIVILIAN
2) The unit has an attack strength greater than 0
3) The unit can reach a target unit (depending on unreachable protects)
4) The unit owner is at war with all owners of all units on the destination
5) The unit is on native ground or has UCF_ATT_FROM_NON_NATIVE or
6) The target tile is native to the attacking unit, or the unit has
7) The target unit can be targeted by the attacking unit
*) Some other stuff about cities and unit counts and whatnot that isn't that

    I tried to break this down into requirements vectors for a hypothetical
action enablement, and ended up with far too many different sets (because of
the ORs involved, and the variances depending on server settings). 
(1),(2),&(7) ended up duplicated in all lists, I wasn't sure how to structure
(3), (4) ended up being a list of present=FALSE conditions for every non-war
state (because testing for war would early-terminate on the first matching
unit), even adjusting the semantics for easiest application, and nativity
broke into 4 cases (native->native, native->non-native, non-native->native,
non-native->non-native).  This entirely ignores the different server rules for
diplomats, capturers, bombarders, (as these end up being different sorts of
actions than the classic "Combat Attack").

    So, while it may be interesting to try to solve the general problem (for
which something extending from Alternative 1 is likely the best solution), I
suspect this is very messy, and would end up with at least 4 clauses for every
action enablement (which seems a high burden and prone to mistakes), which
returns me to a preference for Alternative 3 for the medium-term.

    It occurs to me that a possible future alternative to avoid hacks would be
to have a general reqs framework for units taking generic actions against
tiles, which would default to 8 clauses (nativity x unreachable-setting) (or
more), and which could be extended by ruleset authors to impose slightly
different rules on an action-specific basis.  I've not thought this through
completely, but suspect that it would result in overall less duplication in
the ruleset, although it may be a bit more difficult to explain in the ruleset
author guidance.

    When looking at this, the concept of targeting reminded me of bug #20711:
it may be that one only needs 4 clauses (nativity), rather than 8, because
units may be able to communicate without being able to engage in combat
(potentially depending on technology, etc.).


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to