Review of "estimatedResourceProduction"
-
@TheDog, @VictoryFirst, @Cernel, @beelee, @RogerCooper
"estimatedResourceProduction" uses the same calculations that are use for the "Resources" tab. Only territory production is accounted for. Territories which are contested and property "Contested Territories Produce No Income" is true are not counted. Blockaded territories with property "Convoy Blockades Roll Dice For Cost" is true are not counted. The testing has not been completed, so there is no PR as of yet.
The format is similar to haveResources:
estimatedResourceProduction checks the amount of resources the player can generate for controlled territories. value is the resource(s) to check, count is the amount of resources to check. <option name="estimatedResourceProduction " value="PUs" count="20"> will check if the player can produce 20 or more PUs. Count can be omitted if checking PUs with value equal to the amount. Thus, <option name="estimatedResourceProduction " value="20> is the same as the previous example.Putting multiple resources in value will add those generated resources together, <option name="estimatedResourceProduction " value="Coal:Oil" count="7"> will add Coal and Oil.
Having multiple estimatedResourceProduction in a condition creates an "and" condition.
If "players" is used, then their generated resources are added together, <option name="estimatedResourceProduction " value="100"> <option name="players" value="German:Japan"> will add the PUs of German and Japan together.
Should this return the endTurn value instead of "Resources" as the endTurn takes into account objectives and unit information. Or should there be two different options.
Thank you for your participation!
Cheers...
-
@wc_sumpton "Estimated" sounds like we don't really know what is, and this does not make sense to me. The only case I can think of is the "war bonds" tech of V3, giving you additional PUs equal to the result of a dice roll, but even in this case I would rather call it "average" instead of "estimated". Moreover, I think it would be good that the name clarifies that we are only accounting the production of resources from (land and sea) territories as this is what is actually being accounted (because units and tech can produce or consume PUs or other resources too).
If that is meant to clarify that we are not talking of actual production, then "Production" can be changed to "ProductionCapability" or "ProductionCapacity" instead of adding "estimated", but I think that this is uncalled for as we just use "production" in the territory option.
I'll quote what I've already said at
@cernel said in Review of haveResources: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).
However, on a second thought, I would go with the singular for "resource". This means that I would call your "estimatedResourceProduction" as "territoriesResourceProduction" (or "territoriesResourceProductionCapability" to be didascalic).
-
@wc_sumpton This looks good. I like how you changed it to "estimated" since it is not the total amount as you are discluding income from contested and blockaded territories, which is logical.
However while writing this I just noticed Cernel's post, and he has a point that "estimated" might still be a bit confusing. I propose to call it "effectiveTerritoryProduction" since we are looking at the effective total amount of production of all territories a player owns (so not including production a player controls but doesn't collect).
-
I would perhaps use "effectiveResourceProduction" to check for a player's base income plus any bonuses from "objectives" or "unit bonuses".
-
@victoryfirst said in Review of "estimatedResourceProduction":
(so not including production a player controls but doesn't collect).
There are only three cases I know of. Not controlling the required number of capitals (usually 1), controlling non-original sea territories (convoy zones) or the player being something like Chinese in V3. Is it your intention to exclude all these cases?
To be clear, are you including sea territories (commonly known as convoy zones) or only land ones for the option?
-
@cernel Thank you for your thoughts. In my opinion, "effectiveTerritoryProduction" should assess a player's strength based on its overall territory control, and trigger events if this strength exceeds/deceeds a certain value. I think convoy zones should be part of this as a country that is convoyed to death could be considered weak and therefore more susceptible to triggers that handle things like surrender, uprisings, and economic collapse. I think that would also be the main reason to implement this feature.
I see that in that case the word "territories" might be confusing... so if you have any suggestions that would be great.
I will think about the scenarios you mentioned. Arguments can be made to both include and exclude them. I'll come back to that later.
-
@cernel said in Review of "estimatedResourceProduction":
To be clear, are you including sea territories (commonly known as convoy zones) or only land ones for the option?
At the moment, all territories, land or sea, which have a "production", "productionOnly" or "resources" that the player is the "territoryOwner" at the point the condition is checked by a calling trigger. Contested territories which cannot collect income and not counted. Territories which are considered blockaded are not counted. "convoyRoute", "convoyAttached" which are not owned are not counted.
At present, units which have "createsResourcesList" are not considered. Triggers and objectives which grant resources and not considered.
Cheers...
-
@wc_sumpton
estimatedResourceProduction is too longI prefer resourceProduction or productioResource
The above will depend on what properties are set/true.
If Sea Zones generate resources, then they too should be included, yes?As to when to use the above, I think it needs another variable resourceProductionEndTurn
So the coder knows that objectives and unit resource generation/loss are included if that is what they want. Maybe this, resourceProductionEndTurn should be a separate PR to keep it simple, because its not. -
@thedog said in Review of "estimatedResourceProduction":
If Sea Zones generate resources, then they too should be included, yes?
Yes.
@thedog said in Review of "estimatedResourceProduction":
As to when to use the above, I think it needs another variable resourceProductionEndTurn
As of now, there are 2 different processes. The one use under the "Resources" tab and is pictured in brackets. Then there is the endTurn process, which calculates all resources to be given at the end of the players turn. They are different process and are calculated differently.
Cheers...
-
I've thought about it and to reply to the scenarios you mentioned, I prefer to reserve "resourceProduction", "effectiveTerritoryProduction" or whatever we are going to call it, for referring to the values stated under the "production" column in the "players" tab.
It is information directly displayed by the game and I rather don't want players to have to add/subtract territory production values themselves to see if they are in a position to trigger events.
I am not exactly sure which territories the game uses to calculate this number or if there are any exceptions, but I've checked some situations, and as far as I know the game excludes contested territories if the corresponding property "Contested territories produce no income" is set to true, so therefore the condition shouldn't check for these. Other than that, it counts up the production values of all territories under a player's control.
On the flip side, territories of players not controlling their capital(s) and the Chinese in World War II v3 are included in this column by the engine with a non-zero value, so therefore my preference is that territories in these scenarios are included (that image I attached is from V3 and you see a 7 for China, which is the value you get if you sum all of their territories).
I am not sure about the sea zones and I have never come across a game where the scenario you described comes up, so I can't give a comment on that. However the Original Europe game has special sea zones (convoy zones) that produce income and can be captured like territories and these too are included in the "production" column by the game, so if that is what you meant, I would include that too.
So long story short, I propose to have a condition that checks these exact total production values that are calculated by the game. Variations of this condition can be used to check for a player's total income including any bonuses from objectives and unit bonuses.
-
@Cernel, @TheDog, @VictoryFirst
Within the game engine there are only territories. There are no sea zones, only territories marked as water="true". This tells the engine that this territory may not have an attachment. When the game engine calculates resources, it is checking the territoryAttachment for production/resource options. If the territory has an attachment water or not, it is checked.
Cheers...
-
this post is deleted
-
@wc_sumpton said in Review of "estimatedResourceProduction":
This tells the engine that this territory may not have an attachment.
Reread what I wrote, they may not have one. If a territory is not mark it must have an attachment.
Cheers...
-
Ah I see, that's the double meaning of "may not"
Lol. Sorry was just confused for a second. I will delete my post. -
@wc_sumpton said in Review of "estimatedResourceProduction":
@wc_sumpton said in Review of "estimatedResourceProduction":
This tells the engine that this territory may not have an attachment.
Reread what I wrote, they may not have one. If a territory is not mark it must have an attachment.
Cheers...
Is English your first language?
As @VictoryFirst pointed out, "may not" is ambiguous.
"May not" means either "not allowed to" or "allowed not to", but the former is prevalent, so, if you say "they may not have one", it will commonly be understood as if you are saying "they are not allowed to have one", which is here the same as saying "they cannot have one".
I'm just saying that @VictoryFirst did not misunderstand what you said.
(I'm talking about what I know of English English: I don't know about American English.)
-
You are correct. So, I offer my apologies to @VictoryFirst. There have been many discussions about the proper terms used when describing zones/territories/areas and I was only trying to point out how these are interpreted by the game engine.
Again, I am very sorry to @VictoryFirst, and any others that I may have offended.
Cheers...
-
No need for apologies, I am not offended at all
Actually I have an interest in languages and seeing the ambiguity of "may not" come up in practice was quite funny 
However, we are digressing. We still need to have good names for the condition attachment options. I have some suggestions.
The sum of the "production" values of all territories a player controls:
"territoryProduction"The estimated amount of resources a player receives at the end of his turn (including territory production values, objectives, unit bonuses, etc.)
"resourceProduction" -
@victoryfirst said in Review of "estimatedResourceProduction":
The estimated amount of resources a player receives at the end of his turn (including territory production values, objectives, unit bonuses, etc.)
"resourceProduction"This might be undoable. If "resourceProduction" were to account for objectives/triggers that itself was part of the process, might cause the engine to get caught in a circular reference. Still working on it.
Cheers...
-
@wc_sumpton Whoa! I didn't say or mean that you offended anyone or had to apologize for anything.
-
@cernel said in Review of "estimatedResourceProduction":
@wc_sumpton Whoa! I didn't say or mean that you offended anyone or had to apologize for anything.
Understood.
I did come down kind of hard on @VictoryFirst. And then I just blew him off. You pointed this out.
The last 5 - 7 years have been quite trying. With only recently thing have been improving. What I'm trying to say, both with this comment and the above apology, is that they are geared more towards myself. Self-growth and self-improvement.
Cheers...
