requiresUnits values: is a list of units required to be present in the territory in order for you to build this unit there. Can have multiple instances. Only one instance needs to be true in order to build. examples: <option name="requiresUnits" value="CombatEngineer:Truck"/> would mean we need at least one CombatEngineer AND at least one Truck in order to build there. If after that line we had a second line saying <option name="requiresUnits" value="SuperEngineer"/> then it would mean OR we need at least one SuperEngineer.
Don't you think this behaviour is logically wrong, or at least odd, and also very complex to change with triggers, during the game, if you want the alternative behaviour.
About anything else I can think of, in the units attachments, is additive, comprising the related "consumesUnits" option (conceptually similar options going the opposite way is seriously annoying, as it is very hard to remember what is the one that behaves one way or the other), if it is not supposed to be present in a single instance (practically substitutive).
I would rather support the OR possibility by simply giving the option a count, representing how many different type of units you need, among those in the list, defaulting to the number of them listed.
<option name="requiresUnits" value="2:CombatEngineer:Truck"/>
that (as per the default count generation) would be the same as just:
<option name="requiresUnits" value="CombatEngineer:Truck"/>
means that you need 2 types of units amongst CombatEngineer and Truck (so, all of them).
<option name="requiresUnits" value="1:CombatEngineer:Truck"/>
means that you need at least 1 type of units amongst CombatEngineer and Truck.
This last case would be the same as currently coding:
<option name="requiresUnits" value="CombatEngineer"/>
<option name="requiresUnits" value="Truck"/>
That I would deprecate as a practice, if it is not feasible to rewrite all games having it and remake the option as additive, when present in multiple istances.
I want to add that, for what this feature request would actually change, I don't think I need it, and this is more like a suggestion from me, for something that I feel it has been implemented the wrong way. Also curious if anyone else shares, at least partially, my point of view on this matter, especially any developers.
@Cernel I would tend to agree but the big problem is existing maps. If there weren't any maps using this then I would consider changing it but dealing with updating all of them is more work than I think changing this is worth.