Update of bug #21992 (project freeciv):
Status: None => Ready For Test
Assigned to: None => jtn
Operating System: None => Any
Follow-up Comment #1:
Lightly tested patch attached.
(I suspect this isn't amenable to autogame testing, since the AI is expected
to improve. Probably the correct test is against unmodified code and
This shows up the one place where present=FALSE and nreqs were arguably not
entirely equivalent: they could be used by ruleset authors to represent the
distinction between a simple negated term in a boolean expression, and a
requirement where something's presence is semantically an 'impediment' or
'block' to the effect, because is_effect_disabled() (and hence the UI and AI)
would only take notice of the latter.
In my patch, it looks at both (and is renamed to is_effect_prevented()).
For most requirement types ("is this building present") you're unlikely to
have wanted the former sense, but for numeric effects like MinSize it's more
arguable. That said, I've failed to think of a realistic example where the new
logic will prevent ruleset authors expressing something interesting.
This does mean we should take care to define new requirements with the right
sense in future, because if ruleset authors are forced to routinely negate
them, it might confuse the AI. I think defining numeric requirements in line
with causality/progress -- e.g. MinYear, MinSize, MinCulture tend to become
truer over time -- helps with that.
This might form an argument for keeping 'nreqs' around; but if it is one, then
we'll have to reverse most of our translation of rulesets, since most of our
current use of negation is in the 'impediment' sense. I'll assume we won't do
that for now.
Additional Item Attachment:
File name: trunk-preventing-reqs-present.patch Size:9 KB
Reply to this item at:
Message sent via/by Gna!
Freeciv-dev mailing list