TUV for Units That Have consumesUnits Property
-
@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 -
I'm going to answer the easier question first.
@thedog said in TUV for Units That Have consumesUnits Property:
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 6puThe TripleA engine defines "tuv" as a number '-1', but there are no checks on how the value is entered in the xml. So, in theory any value is good as long as it's a number. To calculate 'tuv', the engine only checks if 'tuv' is greater than '0'. To do as you describe, 'tuv' would need to be calculated first, then compared to the entered value. Doable, yes, but not how the engine is coded.
@cernel said in TUV for Units That Have consumesUnits Property:
@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.
As I stated above, it would be easy to allow a value of '0' to be excepted. For a negative value, just for the unit's 'tuv' value would also be relatively easy. But the question arises on how to treat such a 'tuv' when combined with other units' 'tuv' as in 'destroyedTUV''.
@cernel said in TUV for Units That Have consumesUnits Property:
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"/>As of now, no 'unitAttachment' allows for a player value. Doing as you describe would change a lot of the basic engine workings and would be too much to ask from the few developers. One option would be to allow 'tuv' to be set the same as cost, but this again would require a large change. The simplest answer would be to use 'techAbilityAttachment', which already uses the unit's owner to make changes. I've even created a few, 'bonusHitPoints', 'bonusIsMarine', 'bonusNonCombatMovement', etc... The trick to creating these is to ensure that the owning player is passed with every call. In most cases the player is available, just not passed. The underlining calculations are already present with things like 'bonusMovement', ''bonusAttack', 'bonusDefense', etc....
@cernel said in TUV for Units That Have consumesUnits Property:
(By the way, I think it should have been written "tUV" instead of "tuv".)
Right now, setting "<option name=" is strict, in that the 'name' must equal how the value is defined. Could this be changed? Sure, but again we run into the "Developer Resource" problem.
Hope this has been helpful.
Cheers...
-
@Cernel
If Im understanding wc_sumpton correctly, currently the best you can do with what we have is have a tuv of 1, overriding its current tuv, that is its purchase pu tuv. -
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