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