Adding haveResources and checkAIPlayer to RulesAttachment

[WCSumpton]

Change Summary & Additional Notes

Adding haveResources to allow map makers to check if a player has resources available.
Adding checkAIPlayer to allow map makers to check for an AI controlled player.
A new file RulesAttachmentTest is added to test haveResources.

Release Note

haveResources allows maker to check the amount of resources available. "value" is the resources being checked, and may contain multiple resources. "count" is the amount of resources that must be equal to the of greater then for haveResouces to return true. "count" must be greater then "0", since a count of "0" would always be true, and players cannot have a negative resource. The use of "sum" or "add" as the first "value" will sum all resources together. "players" option will allow multiple players to be checked.

<option name="haveResouces" value="PUs" count="100"/>

Will check the attachTo player for a resource of "PUs" for a value equal to or greater than "100".

<option name="haveResouces" value="add:PUs:Ore" count="100"/>

Will sum "PUs" and "Ore" together.
haveResources can be entered multiple times to check for different values.

<option name="haveResouces" value="PUs" count="100"/>
<option name="haveResouces" value="Ore" count ="5"/>

Both "PUs" and "Ore" must be true for this statement to be true.
Add the "players" option will check those players for a true statement.

checkAIPlayer will only check for an AI player if the value is "true".
"players" option can be used to check multiple players.

NEW|Adding haveResources and checkAIPlayer

[Cernelius]

Even if count 0 is always true, why not allowing this setting? I'm not sure, just wondering. It might have some use in case something is always allowed at some point in the game before or after a trigger changes the count.

---

Why not having

<option name="haveResouces" value="add:PUs:Ore" count="100"/>

simply as

<option name="haveResouces" value="PUs:Ore" count="100"/>

?

Is such simple listing reserved or meant to be reserved for something else?

If we want the "add", shouldn't it rather belong to some other thing than the "value"? For example:

<option name="haveResouces" operator="add" value="PUs:Ore" count="100"/>

I really think that packing an operator in what is the value list is not right. Your formulation logically reads as if there are three resources, called "add", "PUs" and "Ore". Besides, how about if a mapmaker has a resource actually called "add" (possibly an acronym)?

In this case, this coding would be functionally equivalent to my previous proposal if we have "add" as the default (and possibly the only available) operator.

[WCSumpton]

I don't see any more formatting during the last check. Do not understand ':game-app:game-relay-server:test' error.
Maybe lobby is down?

[TheDog-GH]

Not knowing how the process works, so might be a distraction, I notice
file:///home/runner/work/triplea/triplea/game-app/game-relay-server/build/reports/tests/test/index.html

The same folder name, might that be it?

[WCSumpton]

@Cernelius

Even if count 0 is always true, why not allowing this setting? I'm not sure, just wondering. It might have some use in case something is always allowed at some point in the game before or after a trigger changes the count.

Triggers, purchases, etc... may change the amount of resources, but what does that have to do with checking the amount? If something is always true, then use "switch". I don't understand the reasoning here.

haveResources also uses the players option.

<option name="haveResources" value="PUs" count="100"/>
<option name="players" value="Germany:Italians:Japanese"/>

Here it is checking for Germany or Italians or Japanese for 100 PUs to satisfy the condition. Yes this can be done with 3 separate conditions, which can then be OR'ed together in a separate condition/trigger.

But saying:

<option name="haveResources" value="sum:PUs" count="100"/>
<option name="players" value="Germany:Italians:Japanese"/>

Will add the PUs when checking for 100. The action is explicit; or/add.
Also, there is only "name", "value" and "count", if more are need, the count is usually dropped and the rest, besides name, are entered as "value".

But I'm happy either way.

[asvitkine]

What's the difference between add and sum?

It seems pretty confusing, since they sound like synonyms.
I guess you're saying sum says add the resources for all players while add says add all the resource types together.
But their names don't make that very obvious. And what if you want both behaviors (e.g. players A,B,C have a resource X and Y total of 123?).

I wonder if we can do something like:
<option name="haveResources" value="PUs+Ore" count="100"/>
to indicate your add semantics. (And : can continue to specify one of).
(Only one type of delimiter for a given value.)

As to how to handle multiple players, I'm wondering if we could just make it use sum by default.
That is, if you want the other behavior of checking N different specific players, you can just have combine them already.

(Also, I'm confused why you say that you'd want it to be OR semantics otherwise, since for your AI check you did AND semantics...)

[Cernelius]

@Cernelius

Even if count 0 is always true, why not allowing this setting? I'm not sure, just wondering. It might have some use in case something is always allowed at some point in the game before or after a trigger changes the count.

Triggers, purchases, etc... may change the amount of resources, but what does that have to do with checking the amount? If something is always true, then use "switch". I don't understand the reasoning here.

As I said (whereas indeed statically having zero can be exchanged for simply a true "switch"), just like you can use triggers to change the "switch" of a condition during the game, you could use them to set the value in question, zero being functionally the same as "true" in the "switch". You can refer to my "270BC Wars" game for some examples of changing the setting of "switch" options in conditions during the game.

haveResources also uses the players option.

<option name="haveResources" value="PUs" count="100"/>
<option name="players" value="Germany:Italians:Japanese"/>

Here it is checking for Germany or Italians or Japanese for 100 PUs to satisfy the condition. Yes this can be done with 3 separate conditions, which can then be OR'ed together in a separate condition/trigger.

In theory or principle, I would disagree with the relation being OR, affirming it should be AND. That condition logically is the same as making 3 different conditions, one per player. If, then, you use those 3 conditions in a trigger without specifying the operator (called "type" in TripleA), the default operator is AND. Hence, in order for that condition to be the same as having one condition per player with the default AND operator, it should check that each of the players has at least 100 PUs. For coherency, the default operator in case of multiple "players" for the same "haveResources" condition should be AND, possibly allowing operators (like OR) to be set.

In practice, however, I do agree with the relationship being rather OR than AND, because I think this is more like the established practice in other cases like directOwnershipTerritories (when having multiple players for the option).

However, pushing it further that way, I argue that the default relationship would be your "sum" case for coherency with other things like directOwnershipTerritories. For example, in case of directOwnershipTerritories, if I make a condition which checks for two or more territories and set it for multiple players, the condition is true looking at how many of those territories are indifferently owned by any players in the list. For example, if I have a directOwnershipTerritories which checks for at least 3 territories to be owned by players "Germany:Italians:Japanese" and each of these players has only 1 of these territories, the condition is true, so (for coherency), if I have a condition which checks for at least 3 PUs to be owned by players "Germany:Italians:Japanese" and each of these players has only 1 PUs, I would say the condition should be true as well.

But saying:

<option name="haveResources" value="sum:PUs" count="100"/>
<option name="players" value="Germany:Italians:Japanese"/>

Will add the PUs when checking for 100. The action is explicit; or/add. Also, there is only "name", "value" and "count", if more are need, the count is usually dropped and the rest, besides name, are entered as "value".

But I'm happy either way.

As said, I believe that this should rather be the default on even only behaviour for when you set multiple players in the same option so no need having the "sum:" part in the "value" at all. Besides, I'm strongly against having operators in the value (and how about if the game has a resource called "sum"?). Moreover, I also definitely believe here the operator should be on the "players" (not on the "haveResources"). Hence, (if not default) I rather definitely suggest having a code like

<option name="haveResources" value="PUs" count="100"/>
<option name="players" operator="sum" value="Germany:Italians:Japanese"/>

[Cernelius]

What's the difference between add and sum?

It seems pretty confusing, since they sound like synonyms. I guess you're saying sum says add the resources for all players while add says add all the resource types together. But their names don't make that very obvious. And what if you want both behaviors (e.g. players A,B,C have a resource X and Y total of 123?).

I also do understand that "add" and "sum" are the same operator but "add" is on the resources and "sum" is on the players. Also in my opinion, this makes no sense, so they should rather be called with the same "xxx" ("xxx" being whatever) name and applied accordingly. For example,

<option name="haveResouces" operator="xxx" value="PUs:Ore" count="100"/>

would sum "PUs and "Ore", and

<option name="haveResources" value="PUs" count="100"/>
<option name="players" operator="xxx" value="Germany:Italians:Japanese"/>

would sum the PUs of Germany, Italians and Japanese.

[Cernelius]

I hope you have not given up because being able to test for resources and AI control would be important features. By the way, I would suggest each of them having its own PR (instead of a same PR for both).