TUV for Units That Have consumesUnits Property
-
@redrum I believe (or at least I've a strong feeling) the "tuv" option should not belong to the unitAttachments, but rather to the productionRules.
Example:
<productionRule name="buyFusiliers">
<cost resource="PUs" quantity="8"/>
<value resourceOrUnit="Fusiliers" quantity="8"/>
<result resourceOrUnit="Fusiliers" quantity="1"/>
</productionRule>(the value would refer to a single "Fusiliers", no matter the number in the "result")
Also, it can be taken into account the possible need of assigning different values for different players for the same unit. This would not be possible if this is a unit option.
It is important to be considered that you can have different values for different players for the same unit (think about Shipyard tech or different frontiers, like in the case of Napoleonic Empires, with UnitedKingdom having cheaper costs for Encampment and General).
This may matter also for the necessity of valuing units that cannot be bought. For example, in "Napoleonic Empires" there is the "Capital" unit. The "Capital" unit is exactly the same thing as the "Encampment" unit, thus it would be reasonable the most to assign the "Capital" (you can't buy) a value equal to 10 (same as the Encampment), which is already possible (the "Capital" has currently value 15, that I believe should be changed to 10). However, the Encampment costs 8 for the UnitedKingdom; so it would be advisable that, either, for consistency:
- The "Capital" is valued 8 for UnitedKingdom only.
- The "Encampment" is valued 10 for UnitedKingdom too, despite costing only 8, for it.
This depends if we intend the TUV to represent what we believe it is a value of the unit or to represent the actual costs.
I tend to believe that 1 is more consistent. In the moment in which if we get JetPower, the TUV doesn't increase, despite now the unit having more value for that player than the others, then it makes sense that, in the moment in which we get Shipyard, the TUV decreases by the costs, despite the unit having still the same value for everyone.
For point 1, I think this would be better achieved by assigning, in the "productionFrontier", a productionRule that is meant to assign the value only, and it doesn't show up at all in the production window. I'm thinking of something like:
<productionRule name="buyCapitalUnitedKingdom">
<value resourceOrUnit="Capital" quantity="8"/>
</productionRule>That you then assign in:
<productionFrontier name="productionUnitedKingdom">
<frontierRules name="buyCapitalUnitedKingdom"/>
...Since having no "result" it won't be displayed, but will serve just to tell the game to value the "Capital" unit owned by the UnitedKingdom at 8.
-
In particular, if we would go with the "TUV" being a unit option (but I feel strongly it is not the right place for it), thus forcing the same value for any players, then it would be almost a necessity to allow for relating it to the technology, and maybe even support, because, in the moment you say that a same unit must absolutely have the same "statistic" value for everyone, then if a tech makes it better for a player only, it would make the only sense that the value for that player increases.
The matter is still deciding if, with the "TUV", we mean to capture the supposed value of the unit or we merely intend to report the sum of their current costs.
We may also consider having separate "TUV" and "TUC", so that, for example, in the moment in which a player gets "Shipyard", the "TUC" decreases but the "TUV" remains the same, while, in the moment in which a player gets "SuperSubs", the "TUC" remains the same but the "TUV" increases (of course, in this case, we would need to define a separate value for a submarine benefitting from the SuperSub tech, higher than the normal value assigned to the same unit).
-
The matter if the TUV should represent strictly the sum of the current costs or should be used to picture a total estimated value has been discussed already in this Feature Request ticket:
https://sourceforge.net/p/triplea/feature-requests/216/
I believe, in the moment in which you put a "TUV" option inside the unitAttachments, thus forcing it to be the same for any players having that unit, you are going in the direction of the "TUV" being meant to represent the value, which would be a change of direction from the past, that may be good or bad, but has to be pondered, and preferably made consistent amongst games and dynamics.
-
To clarify, the reference to support was that maybe a player has a same unit having a stronger support ability than what another player gets. However, this may be a not relevant matter, as it may be argued this being bad practice, and the mapmaker should rather take care to have two different units, if having different support abilities, even if all remaining stats would be the same. The matter would, however, be definitely relevant in case of supports assigned via tech, or underlying it (for example, players starting the game at different tech levels), but I guess this can be comprised in the, already made, reference to tech-based actual "value" differences for a same unit owned by technologically different players.
-
@Cernel TUV should represent "value" rather than "cost" so it can be used to compare strength of nations/alliances, battle calc casualties, and AI calcs. If you want "value" to adjust based on techs then you'd probably already have a fairly complex map and would have separate units per nation like TWW does. This would allow different TUV for units based on technology using triggers I believe.
Example (tech that improves German infantry and trigger to increase TUV):
<attachment name="unitAttachment" attachTo="germanInfantry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="1"/>
<option name="attack" value="2"/>
<option name="defense" value="3"/>
<option name="transportCost" value="2"/>
<option name="tuv" value="3"/>
</attachment>
<attachment name="unitAttachment" attachTo="russianInfantry" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="1"/>
<option name="attack" value="2"/>
<option name="defense" value="3"/>
<option name="transportCost" value="2"/>
<option name="tuv" value="3"/>
</attachment>
<attachment name="triggerAttachmentGermanInfantryUpgrade" attachTo="Germany" javaClass="games.strategy.triplea.attachments.TriggerAttachment" type="player">
<option name="trigger" value="conditionAttachmentGermanInfantryUpgrade"/>
<option name="unitType" value="germanInfantry"/>
<option name="unitProperty" value="tuv" count="4"/>
<option name="uses" value="1"/>
<option name="when" value="before:germanCombatMove"/>
</attachment> -
I would like to test this out. I just want to be sure that I understand the purpose of this new feature. If the battle window and its default casualty selection is silly, like if expensive units with specual abilities tends to be selected instead of the "obvious choice", then I can play around with this tuv stat, raising it to the first number that makes it not default selected by the engine, which instead selects a more appropriate unit to die first. Right?
If this is the case, then maybe this new feature can prevent Iron War battles select SS-Infantry over normal infantry? (as SS right now are selected as casualties before normal infantry, even though they are like infantry, but also give negative support to enemies.)
-
@frostion The casualty selection does take tuv into account but only after attack/defense/etc. I think its used as mostly a tie breaker so if 2 units have equal attack/defense then it kills off the cheaper unit first.
Edit: Also since TUV is only done in PUs, it would probably be useful to manually give units that cost other resources an adjusted TUV.
-
@redrum That is another reason for having that setting in the production rules, instead of in the unit attachments, so that you can also give a PUs value to the resources, the same way you assing it to units. However, that is already possible, since you can have a production rule for buying a resource with PUs, no matter if actually supposed to happen, just not assigning it to any players' frontiers. It would be advisable that, in this case, the engine sums up automatically all resources that have a PUs value assigned (the mapmaker can still define a different TUV, of course).
-
I'm also curious if it is only me that has the feeling that the unit attachment is not the right place for defining the UV of a unit.
Ah, rite: it should be called "UV" (unit value), not "TUV".
-
@redrum Actually, I don't think so. Usually, complex tech maps unlock units. It is more a thing for small/simple maps to have silly technologies like that in the moment you get JetPower all your Fighters magically turn into JetFighters. A more advanced map would probably, instead, unlock an additional JetFighter unit. So, I think the unit upgrade, meaning a same unit that becomes better thanks to tech, I believe it is relevant for simple maps not less than more complex ones.
But, what I was saying, the matter is that the thing should better be consistent.
If you decide that TUV should represent the value, then the TUV should stay the same when you get Shipyard and should increase when you get SuperSub (it would be up to the mapmaker to assingn a referring value, there).
If you decide that the TUV should represent the cost, the TUV should decrease when you get Shipyard and should stay the same when you get SuperSubs.
So far, the second has been true, as the TUV, up until now, has never been anything related to any kind of value, but just the picture of the total current costs (thus TUC would have been a better name for it), as Veqryn confirmed when he said that he is perfectly fine with your TUV sinking in the moment in which you get Shipyards (I agree that is kinda silly).
-
@redrum
As I understand, the TUV unit option is a working feature now. But I can’t see it described anywhere in the pact_of_steel_2.xml (is it?) Will it be written into the xml with an explanation?This makes me wonder is any other newer or older xml working features are missing from the xml “bible”. It would be a shame if good features risk being unknown and unused by some mapmakers.
Also, I can see that many of the Sub XML Properties described here - https://forums.triplea-game.org/topic/355/sub-xml-properties?page=1 - do not have an explanation in the pact_of_steel_2.xml.
I know that I am maybe annoyingly calling for someone else than me to edit and update the pact_of_steel_2.xml, but I can’t see this being done by anybody else than the persons with the most insight. It’s a pretty important xml and the instructions there must be correct to the word
We cant have amateurs editing that file. -
@frostion Yeah, I haven't added a few of the most recent features to the POS2 XML yet. I would encourage others to help improve POS2 XML though as well as I'm only human
-
@redrum @Frostion It could use some more descriptive explanations in some areas too. I would be willing to keep it updated. But it would be helpful for the keeper to be in the loop for all new features. Or maybe setup one topic that only lists the final changes only and the link to the discussions. So hunting the details isn't a pain.
-
@general_zod The vast majority of recent features are listed here: https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list
For the most part, I think developers are on the hook for adding the new stuff. But I think many of the existing areas could use improvement and map makers may actually know the existing XML options better than anyone
-
@All
Maybe a forum stiky thread concerning the POS2 xml and possible updates and edits? -
@frostion good idea. Here's a thread to start it off: https://forums.triplea-game.org/topic/566/map-making-reference-guide-pos2-xml
-
Can I set the "tuv" to 0 for a unit?
When I do so, it seems the option is ignored. Is it impossible to set the "tuv" as 0? Why?
(By the way, I think it should have been written "tUV" instead of "tuv".)
-
@cernel said in TUV for Units That Have consumesUnits Property:
Can I set the "tuv" to 0 for a unit?
The actual default setting for "tuv" is -1, but any value can be used. The problem is when calculating the tuv, the value checked for has to be greater than "0", otherwise the value is calculated.
Its really a simple change, check for greater than or equal to "0".
Cheers...
-
@wc_sumpton I think it would be worthwhile supporting assigning value 0 (or maybe even negative) to units. Definitely a value 0 should be in the cards since cost 0 is supported too. Unfortunately, I don't know how to do it. Else, PoS2 should tell that only positive values are supported.
Another thing is that I believe this option should better be per player: TripleA allows having different costs per player on the same unit, so I'm thinking something like
<option name="tuv" value="6" count="Carthage:Rome:Parthia"/>with the ability to have multiples of this option per unit.
-
@wc_sumpton
For
<option name="tuv" value="6"/>Is this true;
Currently tuv to be useable/meaningful has to be greater than the current units purchase PU value?
eg. if a unit costs 6pu then only tuv of 7+ will override the purchase cost of 6pu
