Follow-up Comment #4, patch #4988 (project freeciv):
Yes, this stomps all over the meaning of "RPT_CERTAIN": on the unit side, it's
just a generalisation of an existing hack, but the addition of OutputType and
Specialist make it more glaringly obvious that the hack is to support a
feature we don't properly support. At least for the callers in question,
RPT_POSSIBLE is too likely to return success, even when it shouldn't.
I suspect the right API is one with much heavier use of metaknowledge and
abstracted question types, so that the callers aren't interacting with the raw
requirements at such a low level. Designing it properly means reviewing all
the cases where the code is either using RPT_CERTAIN/RPT_POSSIBLE or raw
requirements_vector iteration, and understanding what is being asked clearly
(if nothing else, we need to differentiate between uses of "NULL" for "I don't
know" and "I don't care").
In the special case of "OutputType", it may be that this shouldn't properly be
used in this context, and we should have separate information on the type
stored at a higher level (either in the effect, or as a separate class of
objects, specifically for Output modifiers).
I've nothing depending on this patch: it only improves the accuracy of AI and
advisor requirements analysis (but in a way orthogonal to other patches in
this direction), so if there is objection to this landing (as it extends a
kludge), rather than just a wish that this be resolved properly in the future,
I'm happy to repurpose this patch (although I won't get to it soon in that
case).
_______________________________________________________
Reply to this item at:
<http://gna.org/patch/?4988>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev
