Allow income levels to be checked in conditions.
-
Thank you. It's true that "resourceLevel" might be indeed confusing. I suggest calling it "totalTerritoryProduction" because I think it's the clearest description.
So "totalTerritoryProduction" should only include the sum of all production values of all territories a player controls, not including any kind of bonus income from objectives or units.
I guess "value" can be "production" then instead? So that it looks like this?
<attachment name="conditionAttachmentGermanyProductionCheck" attachTo="Germans" javaClass="RulesAttachment" type="player"> <option name="totalTerritoryProduction" value="production" count="20"/> <!-- Checks if Germany's income level is 20 or higher --> <option name="invert" value="true"/> <!-- You can optionally flip it to check if the income level is 19 or lower --> </attachment>@Cernel You are right, it is indeed 19 or lower... I had a math exam once where my only mistake was exactly that, an error with the boundaries

I edited my top post to include these changes.
-
@victoryfirst I don't understand why you chanced "PUs" to "production". I think that you should not have.
-
Do you think "PUs" is better? I thought "production" would be better suited as it is also called this way by TripleA. "PUs" would be the resources in your hand, "production" the production level of a nation. Why do you think "PUs" is better?
-
Only one value is being checked, so, in essence, name="totalTerritoryProduction" value="20" would work.
As an aside note, creating the condition, adding the process to read and write the condition, and developing the method that evaluates the condition is not that hard to do.
But creating the internal testing environment is quite a bit more involved. This is the main reason "haveResources", and many of my "improvements" have not been submitted.
Cheers...
-
@wc_sumpton I forgot that "production" is hardcoded to PUs. My previous posts were based on the wrong assumptions that you could set "production" for any resource.
I would actually consider "production" as a legacy option for territory attachments, which should be deprecated.
I believe that this feature should apply to any resources (not just PUs), so I would have this looking at the "resources" option for territories and have every instance of
<option name="production" value="*"/>
be read as
<option name="resources" value="PUs" count="*"/>
.I also believe that calling this option "resources" was a case of bad naming. Something like "resourcesProduction" would have been better in my opinion, but this is how it is.
-
Sure, why not. As it sets right now "haveResources" takes a default value or "PUs", so name="haveResources" value="PUs" count="20" is the same as name="haveResources" value="20".
Creating a new condition like "estimatedResourceProduction" would operate in the same manner, the default value would be "PUs". A "value" with more the one resource would add those resources together. And using the "players" option would add the values together of all the players.
Again, creation of this condition is very strait forward. It is the internal testing that would cause the delay in submitting a PR.
Cheers...
-
@wc_sumpton said in Allow income levels to be checked in conditions.:
Only one value is being checked, so, in essence, name="totalTerritoryProduction" value="20" would work.
Thanks, I thought you had to include "count" for the numbers. This is indeed better.
I wondering what it takes to implement feature requests. I assume you have to write some Java code, but where are the game files stored that you need to modify? Does it work that way?
I have no experience with Java, but I'd be eager to learn it. If there is any way I could be of assistance, that would be great.
-
I use IntelliJ IDEA for editing and GitHub Desktop to help manage files. I'm an "old" basic programmer so would be of little help. I just jump in with both feet and try not to drown.
Cheers
-
What I was saying is that I think it is needlessly limiting and backward to do anything which refers only to PUs: it should rather be something which refers to any resource so possibly PUs too. However, it is good to have PUs as default if a resource is not specified.
-
@cernel said in Allow income levels to be checked in conditions.:
However, it is good to have PUs as default if a resource is not specified.
Yes, this is how both conditions would/have been designed. "haveResources" is already set up in this manner. Whatever the other condition would be called would follow.
Cheers...
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