requiresUnits and consumesUnits - AND / OR possibilities

Frostion

Right now I am working my Warcraft map, and I am implementing hero units. I really look forward to having a working test map to share. But right now it is just sneak previews

Here is the situation and problem:
The cow-like Tauren race hero is a druid. One of his specialties is that he can shapeshift into different animals; Cat, Owl and Bear (units called Cat-Form, Owl-Form and Bear-Form).

Gart is in his normal form called “Gart”

The shape shifting technically works like this: The player purchases a unit from purchase screen called for example “Cat-Form” and then places it on “Gart”. It consumes Gart and therefor at the end of Tauren turn he is a Cat.

Next turn he can shift back to normal form by purchasing “Gart-Form”. Place it on “Cat-Form” and it consumes it, and at end of turn it createsUnitsList 1 “Gart”. So at the end of turn he is again normal Gart.

Triggers remove the “Gart-Form” dummy unit and ensures that the player can only buy the unit type needed to shift back and forth.

So the question is:
I can see by the description in PoS2.xml that requiresUnits practically supports an AND / OR system. So this works well taking into account that “Gart-Form” is a unit that has several different units (Cat, Owl, Bear) that it needs to be placed on and replace.

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.

But the consumesUnits, on the other hand, seems only to support being placed on a single unit type. This is strange. This is the description:

consumesUnits

values: requires that a unit be present in a territory, then when this unit is placed the other units are destroyed / upgraded into this unit.

Can have multiple instances of this, which means it consumes multiple types of units.

I can only get something like this to work, where the placement needs this 1 unit to be present:
<option name="consumesUnits" value="1:Cat-Form"/>

I cannot get this to work. I mean I can, but then I guess I need ALL of the bellow to be present:
<option name="consumesUnits" value="1:Cat-Form"/>
<option name="consumesUnits" value="1:Owl-Form"/>
<option name="consumesUnits" value="1:Bear-Form"/>

There seems to be AND / OR support for requiresUnits, but only AND support for consumesUnits? Is this true? Why is that? Can there be made an update to begin supporting OR here also?

Cernel

@Frostion Yeah, I think this is a case of very confusing coding on the part of the "requiresUnits" option, that it was made so that multiple options mean you need only one of them, while logically it should mean you require all of them (which is, instead, done with multiple instances on the same option). Then you have "consumesUnits" that, instead, works the opposite way but, as much as I like consistency, I would leave "consumesUnits" working as it is, since I like logic more (I guess we are stuck with both of them anyways, due to the massive maps' games updates that would require changing any).

In my opinion, you can move this to feature requests, as I'm fairly sure this is how it works, confusing as it may be.

On top of that, this would not be a problem in your case, as you always have only one of the various consumables, but, more in general, such a feature would require a prompt for picking what you want to consume, and this would become maybe a bit challenging in case you can have multiple consumables per upgraded unit.

I support this feature request, if so. Several times I though it would be cool if you can "retrain" units to be something else, upgrading from several starting choices (especially if the game has upkeep costs). However, as I said, I really don't like the idea of "consumesUnits" being made as illogical as "requiresUnits" already is, but I guess it's a logic against consistency trade-off.

Cernel

@Frostion Assuming this will go to Feature Requests, my suggestion for the feature is going exactly the opposite way as "requiresUnits" currently works (likely causing much confusion in mapmaking), and having the OR behaviour if listed in the same option and the AND if multiple options in the same attachment.

So in your case (consume 1 of Cat or Owl or Bear), it would be this one:

<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>

In case you have multiple types of the instances called by "consumesUnits" in the territory, you would get a prompt to pick what you are consuming. In case of multiple "consumesUnits" prompting you to do so, you would be asked for in sequence, and the consummation happening when all prompts are satisfied.

So, for example, this one:
<option name="consumesUnits" value="3:Cat-Form:Owl-Form:Bear-Form"/>

would mean that you need either 3 cats, 3 owls, or 3 bears, while this one:

<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>

would mean that you need 3 of cats, owls, or bears, in any possible combinations.

Of course, this would not support a game in which, for example, you must consume different numbers of units, or combinations thereof, but, for linear substitutivity, you could add an option on the consumable units, working akin as to the transport cost/capacity system currently available. This would still not support cases of non-linear isoquants in factors' substitution, though, that is normally the most realistic case (or virtually the only realistic one) of substitution of factors. So maybe one wants to think about a different and more complex system for consumables, to support such matters.
https://www.britannica.com/topic/theory-of-production/Substitution-of-factors#ref167909

Frostion

@Cernel Yea it would be nice to have a more flexible system with more options when it comes to the unitAttachment, but fortunately (for me) my case is not that complex.

I have overcome the problem by triggers that change the ”unitProperty” ”consumesUnits” of the Gart-Form unit (the unit that is uplifting the shapeshifting Gart has doing on.

So now I have conditions and triggers looking like this, triggers that were already there but now with some new extra code at the end:

    <attachment name="conditionAttachment_Gart_has_shapeshifted_into_Cat-Form" attachTo="Tauren" javaClass="games.strategy.triplea.attachments.RulesAttachment" type="player">
        <option name="directPresenceTerritories" value="map" count="1"/>
        <option name="unitPresence" value="Cat-Form" count="1"/>
    </attachment>
    <attachment name="triggerAttachment_Tauren_can_no_longer_buy_Cat-Form" attachTo="Tauren" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
        <option name="conditions" value="conditionAttachment_Gart_has_shapeshifted_into_Cat-Form"/>
        <option name="productionRule" value="production_Tauren:-buyCat-Form"/>
        <option name="productionRule" value="production_Tauren:-buyOwl-Form"/>
        <option name="productionRule" value="production_Tauren:-buyBear-Form"/>
        <option name="unitType" value="Gart-Form"/>
        <option name="unitProperty" value="consumesUnits" count="-reset-1:Cat-Form"/>
        <option name="when" value="before:TaurenPurchase"/>
    </attachment>

Cernel

@Frostion said in requiresUnits and consumesUnits - AND / OR possibilities:

@Cernel Yea it would be nice to have a more flexible system with more options when it comes to the unitAttachment, but fortunately (for me) my case is not that complex.

I suppose it practically has to be that complex, because, while in your map it will factually never happen than more than one of the upgradable units are going to be present in the same eligible territory at the same time, this can just not be supposed to happen in general, I tend to think (or, what is it going to happen if a player of your map will do some messy edits causing that to happen?). The only sensible way to limit almost to your case I can think of would be to make the unit upgradable on priority list, so that, for example:
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>

would upgrade 1 cat if present, otherwise would upgrade 1 owl if present, otherwise would upgrade 1 bear if present.

On top of that, you already have multiple options per attachment supported; so you'll have to keep supporting anyways cases like:
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>
<option name="consumesUnits" value="1:Cat-Form:Owl-Form:Bear-Form"/>

just because someone could code it that way.

This behaviour would be actually consistent with my proposal here:
https://forums.triplea-game.org/topic/1580/support-priority-definition

Cernel

I've detailed my perplexities about the current behaviour of the "requiresUnits" option in here:
https://forums.triplea-game.org/topic/1633/rework-requiresunits