TUV for Units That Have consumesUnits Property
-
@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