Unit type, unit class, and unit class flag requirements evaluate to TRI_YES when no target unittype is given. Unit flag requirements evaluate to TRI_MAYBE when no target unittype is given. This disparity was introduced fifteen years ago and apparently never documented in the code.

We should probably...

...figure out whether unit type, class and class flag requirements still need to be true when in doubt – this is apparently a workaround introduced before requirement problem types (and later, tristate logic) were a thing, so it might not be necessary anymore
...if yes, figure out whether unit type flag requirements still need to not be true when in doubt
...if also yes, document the reasons in the code

Ticket History (3/5 Histories)

2022-01-26 04:10 Updated by: alienvalkyrie

New Ticket "Different handling of unitflag requirements with missing target unittype" created

2022-01-31 06:12 Updated by: alienvalkyrie

Milestone Update from (None) to S3_1 d3f (closed)

Comment

Reply To alienvalkyrie

* ...figure out whether unit type, class and class flag requirements still need to be true when in doubt – this is apparently a workaround introduced before requirement problem types (and later, tristate logic) were a thing, so it might not be necessary anymore

Haven't tried it yet, but after some history-poking, I think this workaround is no longer necessary. The original workaround was apparently only relevant for whether to draw city walls based on defend bonus effects, which has since been superseded by the Visible_Wall effect. So it should be fine to make those three also give TRI_MAYBE for a missing unittype.

Targetting this to S3_1, since technically – if there are any effects that are ever evaluated with an optional target unit (which I can't with certainty say there aren't) – this is a semantic change to the data file format.