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

On Alternative 1:
    My fear here is that the logical conclusion to a patch series along that
line ends up causing the ruleset to need to duplicate the entirety of the
nativity rules that are in the engine (unless "move" also ends up using this
enablement framework, in which case it all gets pulled out of the engine). 
Given the deep complexity of this, and the number of issues we've encountered
dealing with it, I'm not sure it ought be exported to rulesets.  That said,
when extending the testable conditions for units, being able to test nativity
seems reasonable.

    I suppose the deeper philosophical issue is whether the entirety of
requirements to perform an action belong in the ruleset.  In favour is the
fact that ruleset authors may be confused by hardcoded engine restrictions
(e.g. can only be performed from native tile).  In opposition is the potential
complexity involved and the need to duplicate significant logic in multiple
rulesets or lose the features entirely.

On Alternative 2:
    So, an alternate way of thinking about the current "attack" semantics
might be that one considers them as "action" semantics, where "attack" is one
of many possible actions (side note: I'd like this, as it enables units that
can both attack and bribe, for example, or allows much more interestingly
complex solutions for "capture" than the current arrangement).  This makes the
less correct, but they provide for per-unit specification of nativity concerns
in a way that avoids needing to indicate this in the action enabler

    This model fails to handle the case where a Diplomat can "Establish
Embassy" from a non-native tile, but only "Incite Revolt" from a native tile,
but does handle the case where a Spy can "Establish Embassy" from a non-native
tile but a Diplomat cannot (precisely the opposite from what is possible with
the use of an "IsAttack" flag).  That said, I believe that whether something
can be done from/into a non-native tile is more about the nature of the unit
(can it start there?  can it reach there?) than about the nature of the
action, but I can see the counterarguments.  In the event that this needs to
be about *both* action and unit, then it probably makes sense to have yet
another data structure of some sort to deal with the interaction (an example
of such a thing would be the combat bonus system, which deals with unit/unit
interactions), rather than duplicating things.

On Offensive Trade Routes:
    I've played games where my opponent repeatedly canceled all the trade
routes to my city with Copernicus' Observatory by creating new trade routes to
any trading partners I had: this had the combined effect of reducing my
research speed (lower Copernicus' Observatory bonus), and increasing my
opponents (multiple new traderoute bonuses).  While such tactics may be rare,
I suspect that any Action could be used in an offensive way, regardless of how
peaceful it might seem.

On Complex Action definitions:
    Do I understand correctly that one cannot currently define multiple Action
Enablers for the same action, or when suggesting a workaround for dealing with
allowing spies to establish embassies from transport, while diplomats required
native terrain did you mean something else (e.g. different engine
implementations of the actions)?

    My naive expectation was that action enablers were like effects: one could
define as many sets of requirements for an Action as one wished, so as to get
the semantics right.  Disjunctive requirements would obviate the need for this
feature, but that depends on lots of other things, and may not be possible
within the 2.6 development window (requires completing nreqs removal, dealing
with ruleset_cache, unifying uses of requirement vectors, etc.).


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to