alienvalkyrie Reply To cazfi
Haven't investigated any more, e.g., to see if reqtext.c has been overlooked in general when introducing REQ_RANGE_TILE.
It has not been overlooked, but I may have missed or messed up some individual requirement types. I'm currently going over the diff to check if anything else is affected.
alienvalkyrie So here's the deal: For VUT_DIPLREL_TILE and VUT_DIPLREL_UNITANY, the "tile owner" and "owner of a unit on the tile" part, respectively, clearly comes from the requirement type and is present at all ranges, the ranges being Player/Team/Alliance relative to the tile/unit owner; with the Local range being special in that instead of being "tile/unit owner (or someone in the given range) has this relationship with anyone", it's "tile/unit owner has this relationship with the target player".
For VUT_DIPLREL_TILE_O and VUT_DIPLREL_UNITANY_O (which are currently only valid at Local range), there is an argument to be made that the same thing applies – the requirement type fundamentally applies to the owner of the target tile (or a unit therein), and the local-ranged _O requirement perfectly mirrors the local-ranged non-_O requirement, except against the other player instead of the target player.
However, given that this ticket exists, there is clearly an argument to be made that this is unintuitive and should be moved from the Local to the Tile range (perhaps for the non-_O requirements as well?), with subsequent expansion potential to (C)Adjacent ranges in the future.
Really, thinking about it, there are three-ish potential questions:
And there are between two and three places where ranges could play into it:
Obviously, we don't have a mechanism to pass multiple ranges for one requirement, but this might still be worth thinking about to decide what we want each thing to mean. In particular, it shines a light on the fact that the non-_O reqs currently serve two very different purposes (only one of which can be mirrored by the _O reqs).
Reply To alienvalkyrie
However, given that this ticket exists, there is clearly an argument to be made that this is unintuitive
Before you put too much weight on that, be aware of the route I came to question it, while working on translation. So I only saw this "blah blah TILE blah blah" -string in the .po file, and wanted to check something about it from the source code (probably #45514 - to see if one of the strings in the .po file was supposed to be negated version of the other), and then noticed that in the source code the previous line was "case req_range_LOCAL:"
Noticed in master reqtext.c handling of VUT_DIPLREL_UNITANY_O that text related to REQ_RANGE_LOCAL says "...the tile should...". Something is wrong here; likely that should have been moved to REQ_RANGE_TILE when the new range was introduced.
Haven't investigated any more, e.g., to see if reqtext.c has been overlooked in general when introducing REQ_RANGE_TILE.