Navigation

    TripleA Logo

    TripleA Forum

    • Register
    • Login
    • Search
    • TripleA Website
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    • Tags

    Review of haveResources

    Feature Requests & Ideas
    6
    22
    4374
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wc_sumpton last edited by wc_sumpton

      @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. 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. 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.

      Putting multiple resources in value will add those resources together, <option name="haveResources" value="Coal:Oil" count="7"> will add Coal and Oil.

      Having multiple haveResources in a condition creates an "and" condition.

      If "players" is used, then their resources are added together, <option name="haveResources" value="100"> <option name="players" value="German:Japan"> will add the PUs of German and Japan together.

      Thoughts?

      Cheers...

      P.S. value changed to count. Thanks @TheDog 👍

      Cheers...

      TheDog C 3 Replies Last reply Reply Quote 4
      • TheDog
        TheDog @wc_sumpton last edited by

        @wc_sumpton
        Looking good, however...
        <option name="haveResources" value="Coal:Oil" value="7">
        should be
        <option name="haveResources" value="Coal:Oil" count="7">
        Yes?

        1 Reply Last reply Reply Quote 3
        • TheDog
          TheDog @wc_sumpton last edited by TheDog

          @wc_sumpton
          I have an unreleased map that is waiting for this, Im almost excited 🙄

          With isAI it will now be able to auto-sell its excess Resources 👏 👏

          RogerCooper 1 Reply Last reply Reply Quote 3
          • RogerCooper
            RogerCooper @TheDog last edited by

            @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.

            1 Reply Last reply Reply Quote 2
            • C
              Cernel Moderators @wc_sumpton last edited by

              @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 to value="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)?

              W 1 Reply Last reply Reply Quote 2
              • W
                wc_sumpton @Cernel last edited by

                @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...

                C 1 Reply Last reply Reply Quote 2
                • VictoryFirst
                  VictoryFirst last edited by

                  @wc_sumpton @Cernel

                  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 😀

                  W 1 Reply Last reply Reply Quote 1
                  • W
                    wc_sumpton @VictoryFirst last edited by

                    @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...

                    VictoryFirst 1 Reply Last reply Reply Quote 2
                    • VictoryFirst
                      VictoryFirst @wc_sumpton last edited by

                      @wc_sumpton

                      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.

                      1 Reply Last reply Reply Quote 1
                      • C
                        Cernel Moderators @wc_sumpton last edited by

                        @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".

                        RogerCooper 1 Reply Last reply Reply Quote 2
                        • RogerCooper
                          RogerCooper @Cernel last edited by

                          @cernel I would prefer hasResources for clarity.

                          W 1 Reply Last reply Reply Quote 3
                          • W
                            wc_sumpton @RogerCooper last edited by

                            @rogercooper

                            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...

                            TheDog 1 Reply Last reply Reply Quote 1
                            • TheDog
                              TheDog @wc_sumpton last edited by

                              @wc_sumpton
                              My 2p I prefer hasResource (no s)

                              W 1 Reply Last reply Reply Quote 1
                              • W
                                wc_sumpton @TheDog last edited by

                                @thedog said in Review of haveResources:

                                @wc_sumpton
                                My 2p I prefer hasResource (no s)

                                Thank you!

                                Cheers...

                                1 Reply Last reply Reply Quote 1
                                • VictoryFirst
                                  VictoryFirst last edited by VictoryFirst

                                  @wc_sumpton

                                  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.

                                  1 Reply Last reply Reply Quote 1
                                  • W
                                    wc_sumpton last edited by

                                    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...

                                    VictoryFirst 1 Reply Last reply Reply Quote 2
                                    • VictoryFirst
                                      VictoryFirst @wc_sumpton last edited by

                                      @wc_sumpton

                                      Hmm, you have convinced me. You can see it as "has(enough of that)Resource". So go with "hasResource". It's also shorter lol 🙂

                                      1 Reply Last reply Reply Quote 1
                                      • W
                                        wc_sumpton last edited by

                                        PR has been submitted for hasResource

                                        Cheers...

                                        1 Reply Last reply Reply Quote 3
                                        • W
                                          wc_sumpton last edited by

                                          DOA

                                          PR has been pulled.

                                          Cheers...

                                          B 1 Reply Last reply Reply Quote 1
                                          • B
                                            beelee @wc_sumpton last edited by beelee

                                            @wc_sumpton

                                            pulled as in merged ? or as in no longer there ?

                                            🙂

                                            who or what is DOA 🙂

                                            W 1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post
                                            Copyright © 2016-2018 TripleA-Devs | Powered by NodeBB Forums