Logic keywords inside unique filters

[avdstaaij]

This was inspired by #4708 and the discussion in #4697.

Some unique filters already support "and" logic by concatenating two filters, e.g. "[{Military} {Water}] units". It would be useful to have access to more kinds of logic, by means of "logic keywords" inside unique filters. The ones I have in mind specifically are:

• "without"
  Examples: "[{filter1} without {filter2}]", "[{filter1} {filter2} without {filter3} {filter4}]"
• "and"
  This would logically behave like "or", but "and" makes more sense for natural language.
  Examples: "[{filter1} and {filter2}]", "[{filter1} {filter2} and {filter3} {filter4}]"
• "non-"
  Examples: "[non-{filter1}]"

Ideally, these keywords would be implemented at a low level, so that they can be used for every filter type. This would immediately open up many new options for uniques.

Examples of uniques that would be made possible with this system:

• "... for every [{Forest} without {improvement}]" (needed by Implements the Celtic people according to fandom wiki #4658)
• "... for every [{Forest} and {Hill}] tile"
• "... [{in this city} and {in the capital}]"
• "... for every [non-{Forest}] tile"

This system would also remove the need for hard-coded logic uniques like "[stats] from [tileFilter] tiles without [tileFilter] [cityFilter]" (which was used in #4708).

I can however think of a few disadvantages as well:

• The keywords may cause problems for translation. Some languages may be structured differently and may lack equivalents for the keywords.
• Hardcoded logic uniques may have slightly preferable wording to uniques with logic keywords inside filters. For example, "... from [Desert] tiles without [Floodplains] ..." reads better than "... from [Desert without Floodplains] tiles ...".
• It would be necessary to specify precedence rules for the keywords to solve some cases of ambiguity, and this ambiguity may still remain in the strings that are shown to the user. For example: "[Forest and Hill without improvement]".

I'm leaving this idea here as an issue, because I'm not sure whether there are any more glaring disadvantages that I've missed and I'm also not currently planning to implement this system myself.

[yairm210]

I'm against this.
The only way that this could be OK is if we had nested templates, like "[stats] from [[Desert] without [Floodplains]]"
But that would require some non-trivial work

[avdstaaij]

I see. I'll close this then, and maybe re-open it if nested templates are ever implemented.

[SomeTroglodyte]

Nesting is already used by the "and" (expressed as blank) variant? tr() does not support free nesting by matching brackets that belong together in a way a typical lexer does, but it does (and has for a long time) support a single level of {} within [] simply because the [] code comes first, resolves its []'s and recurses the rest back into the function where then {} can be picked up because no [] are left.......

Reaching a point where all translations can be made to read nicely is beyond what the current system can do anyway - that would at least need a provision for gendered nouns. So, perfection is out of reach, and the movement into the unique system has very slowly deteriorated translated readability in the past months. Another hit to that wouldn't really weigh in much. Once it gets too bad that could be some next little project / challenge. (I can even imagine a system to allow distinguishing genders that wouldn't need changing any english in code or templates, just a lot more code in the i10n file reader and a little more in the tr engine...)

Small point: complex possibilities in filters wouldn't force us to use them, if we see in any specific case that resulting language sounds nicer with an extra unique - why not, and leave the combined filters for modders and cases where they help without incurring hickups.

I suggest we all let the idea stew in our brainboxes for a while. If we go that way, I'd tend to a very limited syntax - one operator only, and " " plus whatever we choose for "or" allowed to chain, only with itself.

[SomeTroglodyte]

See also #4712

[xlenstra]

I feel like at some point we have to bite the bullet and just start using uniqueText for almost all uniques anyway. These should be translatable into all languages without gender/case problems, and we then don't have to worry about translating uniques at all, as they should never be shown to the user anyway. Then all these logic components can just be added without loss of readability.

[ajustsomebody]

I feel like at some point we have to bite the bullet and just start using uniqueText for almost all uniques anyway. These should be translatable into all languages without gender/case problems, and we then don't have to worry about translating uniques at all, as they should never be shown to the user anyway. Then all these logic components can just be added without loss of readability.

this would be great