Allow income levels to be checked in conditions.

VictoryFirst

Similar to "haveResources", it would be nice to have a way to check a player's income level in a condition attachment. Game events could be triggered when a nation's income level is higher or lower than a specific value. How it could look like is as follows:

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

Edit: made some changes:
"resourceLevel" -> "totalTerritoryProduction"
"PUs" -> "production"

The income levels of all nations are directly displayed in the "Players" tab under the column "Production", so it might be possible to use this information in the XML.

Cernel

@victoryfirst My understanding is that your proposed "resourceLevel" option is equipollent to the already proposed "haveResources" option at the
https://forums.triplea-game.org/topic/2617/haveresources-as-a-condition-option
topic. What am I missing if anything?

If it is, I would close this topic as duplicate.

CC @wc_sumpton

VictoryFirst

@cernel

I believe "haveResources" deals with the amount of resources currently in a player's hand. This corresponds to the "PUs" column in the "Players" tab. However, I am talking about the "Production" column which is the sum of the production values of all territories the player controls. This is you amount of PUs you will get at the end of your turn.

VictoryFirst

Now I am not sure... I've taken a closer look at the thread you linked and it is not clear if "haveResources" deals with income or resources in a player's hand... I also don't know if it has been implemented yet actually.

Cernel

@victoryfirst said in Allow income levels to be checked in conditions.:

@cernel

I believe "haveResources" deals with the amount of resources currently in a player's hand. This corresponds to the "PUs" column in the "Players" tab. However, I am talking about the "Production" column which is the sum of the production values of all territories the player controls. This is you amount of PUs you will get at the end of your turn.

Yes, that is the per player stock of the resource at the moment, which needs to be equal or greater than the count to satisfy the condition if @wc_sumpton can confirm it.

I suggest to change "resourceLevel" to either "production" or "totalTerritoryProduction" or "income".

If you intend to ignore units generating resources, it would be good to clarify this.

The opposite of 20 or more in the discrete is 19 or less (not 20 or less).

wc_sumpton

@cernel

Yes, haveResources would only check the currently held resource. As to production, I will check the engine to see how that is done.

Cheers...

wc_sumpton

@wc_sumpton

I believe that the "production" value that @VictoryFirst is talking about is only calculated for territories. It does not look like other sources of PUs, units plus or minus/ objectives plus or minus/ etc... are not included.

Cheers...

VictoryFirst

@Cernel @wc_sumpton

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.

Cernel

@victoryfirst I don't understand why you chanced "PUs" to "production". I think that you should not have.

VictoryFirst

@cernel

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?

wc_sumpton

@victoryfirst, @Cernel

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

Cernel

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

wc_sumpton

@cernel

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

VictoryFirst

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

wc_sumpton

@victoryfirst

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

Cernel

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.

wc_sumpton

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