Review of haveResources
-
@thedog My thought is to use ir to randomly shift alliances during a game with the nations tending to declare war on the anyone with too many PU's.
-
@wc_sumpton said in Review of haveResources:
@RogerCooper, @beelee, @VictoryFirst, @Cernel, @TheDog
Because of the interest in this, I have reviewed my coding and created testing. What I would like is suggestions, since the PR has not yet been submitted, even the name can change. The format is:
haveResources checks the amount of player resources.For consistency, I would have it called "resources" instead of "haveResources". In none of the similar cases, we have anything starting from "have". For example, we have the condition "techs" not "haveTechs". However, if "resources" alone may be confusing, it can be "resourcesPossession" (which is practically an other way to say "have resources") so possibly using "resourcesProduction" for the total capability of adding resources, further divisible between "territoriesResourcesProduction" and "unitsResourcesProduction", the former possibly further divisible between "landTerritoriesResourcesProduction" and "seaTerritoriesResourcesProduction" (the latter referring to convoy zones).
value is the resource(s) to check, count is the amount of resources to check. <option name="haveResources" value="PUs" count="20"> will check if the player has 20 or more PUs.
To be clear, do you intend to support the code
<option name="haveResources" value="20:PUs">
as being equipollent to
<option name="haveResources" value="PUs" count="20">
as well as
<option name="haveResources" value="7:Coal:Oil">
being equipollent to
<option name="haveResources" value="Coal:Oil" count="7">If not, what else?
Count can be omitted if checking PUs with value equal to the amount. Thus, <option name="haveResources" value="20> is the same as the previous example.
Personally, I would prefer omitting the value so having
<option name="haveResources" count="20>
being equipollent to
<option name="haveResources" value="PUs" count="20">,
so that an absent "value" would default tovalue="PUs",
but I realize that this is not how TripleA always handles such things (meaning that I suppose that it is currently never possible to have a "count" without an explicit "value").Moreover, is "each" going to be supported for the "count"?
Putting multiple resources in value will add those resources together, <option name="haveResources" value="Coal:Oil" count="7"> will add Coal and Oil.
Are you sure about having this capability (of having more than one resource per option)? I see this as being scarcely valuable. Maybe better leaving it out from the initial PR so reserving it to a future expansion of this feature request. No problem for me having a more capable feature anyway.
Will it be also possible to have something like
<option name="haveResources" value="Coal:Oil:Oil" count="7">
to have 7 of total Coal and Oil but with every Oil counting twice (every Oil being valued at 2 Coal)? -
@cernel said in Review of haveResources:
For consistency, I would have it called "resources" instead of "haveResources". In none of the similar cases, we have anything starting from "have". For example, we have the condition "techs" not "haveTechs". However, if "resources" alone may be confusing, it can be "resourcesPossession" (which is practically an other way to say "have resources")
"resources" is already used, both in territoryAttachment and triggerAttachment. "resourcesPossession" would be ok, but as you stated, it's just another way of saying "haveResources". As I have not yet submitted the PR, changing the name would be quite easy.
@cernel said in Review of haveResources:
so possibly using "resourcesProduction" for the total capability of adding resources, further divisible between "territoriesResourcesProduction" and "unitsResourcesProduction", the former possibly further divisible between "landTerritoriesResourcesProduction" and "seaTerritoriesResourcesProduction" (the latter referring to convoy zones).
This is something completely different, as it has nothing to do with production. As I already have something related to this, I will open a separate discussion.
@cernel said in Review of haveResources:
To be clear, do you intend to support the code
<option name="haveResources" value="20:PUs">
as being equipollent to
<option name="haveResources" value="PUs" count="20">
as well as
<option name="haveResources" value="7:Coal:Oil">
being equipollent to
<option name="haveResources" value="Coal:Oil" count="7">This is how TripleA handles value and count, so all are valid.
@cernel said in Review of haveResources:
Moreover, is "each" going to be supported for the "count"?
No. "each" is a count, and this returns a sum. You could use it as a condition in another condition/trigger which could use "each" since conditions can be compounded, but natively, no.
@cernel said in Review of haveResources:
Are you sure about having this capability (of having more than one resource per option)? I see this as being scarcely valuable. Maybe better leaving it out from the initial PR so reserving it to a future expansion of this feature request. No problem for me having a more capable feature anyway.
This is already done, so it does not make sense to remove it just to reintroduce later.
@cernel said in Review of haveResources:
Will it be also possible to have something like
<option name="haveResources" value="Coal:Oil:Oil" count="7">
to have 7 of total Coal and Oil but with every Oil counting twice (every Oil being valued at 2 Coal)?I going to say that yes this is possible since each resource is summed separately. But I will test to be sure.
Thank you for your questions and suggestions. I hope that I have answered everything.
As I have stated, this is done, and the PR is waiting to be submitted.
Cheers...
-
Regarding the name, I would go for "haveResources". Even though it's not a general way of naming it, "resourcesPossession" is unnecessarily longer and still conveys the same meaning. I don't see any advantage in calling it "resourcePossession".
Optionally, you could even rename it to "hasResources" which would be even shorter and more fitting since more often than not you will check for only one player at a time.
However, that last argument might be not completely true as the players in this game are often called by a plural form ("Germans", "Americans"), although still, I think it's the most clear and concise description. Those are just my thoughts...
@wc_sumpton Awesome this will get implemented, amazing work! Will you take a look at "totalTerritoryProduction" too? No rush, just wondering
-
@victoryfirst said in Review of haveResources:
Optionally, you could even rename it to "hasResources" which would be even shorter and more fitting since more often than not you will check for only one player at a time.
Sure "hasResources" if that is what is wanted?
@victoryfirst said in Review of haveResources:
@wc_sumpton Awesome this will get implemented, amazing work! Will you take a look at "totalTerritoryProduction" too? No rush, just wondering
"estimatedResourceProduction" is what I have right now. It only accounts territory that are owned by the player. There will be a discussion opened for that one.
Cheers...
-
Yes, now I have thought more about it, I would go for "hasResources" if everyone agrees.
"estimatedResourceProduction" sounds good! I am interested to see how that will unfold!
I'm learning Java now
It is pretty similar to Python in a lot of areas which is great because I already know how to program in Python. -
@wc_sumpton said in Review of haveResources:
@cernel said in Review of haveResources:
For consistency, I would have it called "resources" instead of "haveResources". In none of the similar cases, we have anything starting from "have". For example, we have the condition "techs" not "haveTechs". However, if "resources" alone may be confusing, it can be "resourcesPossession" (which is practically an other way to say "have resources")
"resources" is already used, both in territoryAttachment and triggerAttachment. "resourcesPossession" would be ok, but as you stated, it's just another way of saying "haveResources". As I have not yet submitted the PR, changing the name would be quite easy.
This is one more reason for having "resources" instead of "haveResources" (I mean the fact that the trigger option is
<option name="resource" value="PUs"/> <option name="resourceCount" value="6"/>instead of
<option name="addResource" value="PUs"/> <option name="resourceCount" value="6"/>.)
(I don't understand why having a "resourceCount" as a separate option instead of the given number being the count for the primary option.)
There is no problem having a conditions option with the same name as a triggers option, is there? Actually, the triggers option is "resource" (not "resources"). Maybe the conditions option should be "resource" too for consistency.
To be clear, my primary suggestion was to call it just "resources". "resourcesPossession" was the didascalic alternative.
Thinking again about it, I guess it should better be named "resource" instead of "resources".
-
@cernel I would prefer hasResources for clarity.
-
Thank you!
Cheers...
@cernel said in Review of haveResources:
(I don't understand why having a "resourceCount" as a separate option instead of the given number being the count for the primary option.)
Many have complained about this. I have "changeResources" which will look at this. (Yes, I have many modifications done.)
@cernel said in Review of haveResources:
There is no problem having a conditions option with the same name as a triggers option, is there? Actually, the triggers option is "resource" (not "resources"). Maybe the conditions option should be "resource" too for consistency.
Because this adds different resources, and can use the "players" option, I think "resources" with an "s" is still better. Conditions/triggers/objectives at times use the same "library" of files, so I try to stay away names that have already been used.
@cernel said in Review of haveResources:
To be clear, my primary suggestion was to call it just "resources". "resourcesPossession" was the didascalic alternative.
Understood, again thank you for your time and suggestions.
Cheers...
-
@wc_sumpton
My 2p I prefer hasResource (no s) -
@thedog said in Review of haveResources:
@wc_sumpton
My 2p I prefer hasResource (no s)Thank you!
Cheers...
-
I would prefer "hasResources" actually since "hasResource" could also mean just one of a type. If you have one Iron you would have that resource, but "hasResources" would be clearer as you are checking how many resources of a type a player has.
-
At the present time I have change it to "hasResource"
The question the trigger is asking is "Has this player have enough oil/fuel/PUs (not oils/fuels/PUss resource) to do something?".
Cheers...
-
Hmm, you have convinced me. You can see it as "has(enough of that)Resource". So go with "hasResource". It's also shorter lol
-
PR has been submitted for hasResource
Cheers...
-
DOA
PR has been pulled.
Cheers...
-
-
@beelee said in Review of haveResources:
who or what is DOA
"Dead On Arrival"
@beelee said in Review of haveResources:
pulled as in merged ?
No sorry.
Cheers...
-
oh yea
bummer
kinda doesn't make one want to help Be nice if someone would try and help with your work instead of just saying no.
idk maybe they do and I'm just reading it wrong.
You're good at what you do and more devs are always wanted.
idk not enough time for them to teach I guess
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login