Unit Option When Damaged Change Into Different Unit (Weakened Battleships)
-
It may be unrelated to this feature actually. Looks like the prerelease is very buggy, but, since I'm not playing available maps, currently, I don't think I can really bug report (you would be unable to reproduce specifically). I can run a AI only couple rounds now and paste here all the errors I get.
-
@Cernel the error you posted is related to the new unit scroller and there is already a github issue open for it
-
In a case like this one:
<attachment name="unitAttachment" attachTo="fort" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="3"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsDamagedChangesInto" value="1:true:fort_fallen"/> </attachment> <attachment name="unitAttachment" attachTo="fort_damaged" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="3"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsRepairedChangesInto" value="0:false:fort"/> </attachment>What I understand is that I don't need to have a unit called "fort_damaged" in the folder, because the fort_damaged exists in game only when damaged.
Thus, I only need having three images, in the folder, called "fort", "fort_hit" and "fort_damaged_hit" (as the "fort_damaged" (that would be actually undamaged) would be never called for drawing, in the course of the game), correct?
The main reason why I like not having "fort_damaged" in the folder is that, this way, it won't be called by Unit Help and edit mode, as that would not be helpful to be shown, nor it should ever be edited into any territories, in the game, since all units repair for free at the start of Non Combat Move.Also, can I properly use "unit_hit" (for example, in this case, calling the second one "fort_hit", instead of "fort_damaged") as the when-damaged-changed-into unit that i get when the unit "unit" is damaged? In this case, the three images I need are only "unit", "unit_hit" and "unit_hit_hit" ("unit_hit" would serve both as the damaged "unit" as well as the undamaged "unit_hit")?
Also, is there any reason for having the "whenHitPointsRepairedChangesInto" as "0:true", instead of "0:false"? If not, what should I pick, of the two, in a case like the one I made.
-
@Cernel By testing, I see that when the unit, that has already turned, is killed, the image for the "fort_damaged" is called.
So, to answer one of my own questions, in this case, I actually need 4 images, the "fort", the "fort_hit", the "fort_damaged" and the "fort_damaged_hit" (with the "fort_damaged" actually preferably displaying an undamaged fort, and, in this case, preferably the exactly same image as the "fort").
Can the current behaviour be changed so that if a unit has "whenHitPointsRepairedChangesInto" it gets immediately repaired in the moment it is destroyed, so that, in this case, you will see the "fort" image, instead of the "fort_damaged" one, amongst the removed units? I think that would make more sense, as I don't think different images should be shown if I assign 2 hits to a fort on the same combat round with respect of assigning the second one on a following combat round. After all, it is the original image, the "fort", that it is destroyed, at the end, no matter the permutations.
Or, even better, I think it would be cleaner if the image system gets simplified only to require having the "fort" and "fort_damaged_hit" images (and not "fort_hit" and "fort_damaged"), in this cases, using the "fort_damaged_hit" image in all places where the "fort_hit" one is used (practically, if a unit has, in the game file (xml), a "whenHitPointsDamagedChangesInto" entry, and it is currently damaged of those specified hitpoints, the program would call the "hit" image for that other unit, instead of the one for the unit itself) and using the "fort" image for the undamaged "fort_damaged" (same deal as before, but reversed, for the "whenHitPointsRepairedChangesInto" being equal to the current damage).
That is something that I strongly advise, really. I think it would be much cleaner, for mapmaking, being able to limit yourself to only images for the undamaged unit and only one for each level of damage, instead of having to populate the folders with most likely just duplicates with a different name (and I actually expect, in a case like this, some mapmakers providing a damaged-looking unit for the "fort_damaged", despite the fact that currently calls that unit only when it is actually undamaged (and only when it is destroyed not in the same combat round as the damaging, since otherwise that never happens, as the "fort_damaged" is turned into "fort" as soon as it is at his own default undamaged state, that never actually exists). -
Also, just discovered an actual problem.
If you edit the damage, the unit doesn't change to the one it should.
-
There is another problem. In a game not currently available in the repository, I did this battle:
Battle in Seleucia Parthia attack with 2 archers, 1 cataphract, 1 horsearcher, 1 horseman and 4 spearmen Syria defend with 2 forts, 3 skirmishers and 1 territory Parthia roll dice for 2 archers, 1 cataphract, 1 horsearcher, 1 horseman and 4 spearmen in Seleucia, round 2 : 4 Units damaged: 2 forts owned by the Syria Syria roll dice for 2 forts and 3 skirmishers in Seleucia, round 2 : 3 2 spearmen owned by the Parthia lost in Seleucia 2 forts owned by the Syria lost in Seleucia 2 fort1s owned by the Syria added in Seleucia Parthia roll dice for 2 archers, 1 cataphract, 1 horsearcher, 1 horseman and 2 spearmen in Seleucia, round 3 : 5 Syria roll dice for 2 fort1s and 3 skirmishers in Seleucia, round 3 : 3 2 spearmen owned by the Parthia and 2 skirmishers owned by the Syria lost in Seleucia Parthia roll dice for 2 archers, 1 cataphract, 1 horsearcher and 1 horseman in Seleucia, round 4 : 6 Syria roll dice for 2 fort1s and 1 skirmisher in Seleucia, round 4 : 6 1 archer owned by the Parthia and 1 skirmisher owned by the Syria lost in Seleucia Parthia roll dice for 1 archer, 1 cataphract, 1 horsearcher and 1 horseman in Seleucia, round 5 : 3 Syria roll dice for 2 fort1s in Seleucia, round 5 : none 2 fort1s owned by the Syria and 1 archer owned by the Parthia lost in Seleucia Parthia takes Seleucia from Syria Parthia converts territory into different units Parthia win Battle casualty summary: Battle score (TUV change) for attacker is 10In that battle, Parthia lost 4 spearmen and 2 archers, while Syria lost 3 skirmishers and 2 forts.
The total tuv difference, should have been 3*2+2*6-(4*3+2*4)=18-20=-2
Instead, the game gives it as +10.
I guess here the problem is that the fort is accounted twice, somehow, the forts being valued at 12 PUs each, instead of 6 PUs each, as they should.This is the full code for the "fort" and "fort1" (formerly called "fort_damaged") unit attachments:
<attachment name="unitAttachment" attachTo="fort" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="3"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsDamagedChangesInto" value="1:true:fort1"/> <option name="isConstruction" value="true"/> <option name="constructionType" value="fortification"/> <option name="constructionsPerTerrPerTypePerTurn" value="1000"/> <option name="maxConstructionsPerTypePerTerr" value="1000"/> <option name="consumesUnits" value="1:legionary"/> </attachment> <attachment name="unitAttachment" attachTo="fort1" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="3"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsRepairedChangesInto" value="0:true:fort"/> <option name="isConstruction" value="true"/> <option name="constructionType" value="fortification"/> <option name="constructionsPerTerrPerTypePerTurn" value="1000"/> <option name="maxConstructionsPerTypePerTerr" value="1000"/> <option name="consumesUnits" value="1:legionary"/> </attachment>And here it is how the costs are determined:
<productionRule name="buyFort"> <cost resource="PUs" quantity="2" /> <result resourceOrUnit="fort" quantity="1"/> </productionRule> <productionRule name="buyFort1"> <cost resource="PUs" quantity="2" /> <result resourceOrUnit="fort1" quantity="1"/> </productionRule><productionRule name="buyLegionary"> <cost resource="PUs" quantity="4" /> <result resourceOrUnit="legionary" quantity="1"/> </productionRule>The "buyFort1" production rule is assigned to no production frontiers (it is just there to value the Fort1).
This is a pretty major statistical issue, actually, as it largely destroys the utility of giving a TUV swing.
The battlecalculator is affected, by this issue, as well. What I believe it is happening it is when the unit is changed into the other one, the removed one is being accounted as TUV loss. Instead, the statistics are fine if you remove the unit within a same combat round, the unit not transforming at 1 damage, since you directly go from 0 to 2 (the maximum assignable) damage.
-
@Cernel to be sure we are looking at the same problem, and that it is fixed after we patch it, we will want a copy of the map and a save game that demonstrates the problem. Could you add links and/or attachments and file a bug report so that we may track and fix this problem: https://github.com/triplea-game/triplea/issues/new?assignees=&labels=Problem&template=bug_report.md&title=
Without a ticket in the proper bug reporting queue, I can almost guarantee this report will be lost to time in the discussion threads here.
-
@LaFayette That will have to wait until I'm releasing the map to the public. Also I suppose no public maps are yet using this feature, or at least none in the repository.
@redrum My suggestion for fixing the issue is to keep accounting the TUV loss of the unit transformed into another, but discounting it by the TUV value of the unit created, in its stead.
So, in this case, since we are losing 1 unit of TUV value 6 in exchange of another unit of TUV value 6, the TUV loss of that would be 0. Both units have TUV value 6 because they cost 2 and require consuming a unit that costs 4 and doesn't consume any other units upon placement.
If, for example, we would have an armour unit with 2 hit points that turns into an infantry unit when 1 hit point damaged (and there's no way to turn back into an armour), and for the remaining part the units are like in "WWII Revised", then the TUV loss of the conversion should be 2 (5-3). So, you can either have a direct TUV loss of 5, if assigning 2 hits to the armour at once, or a TUV loss of 5 over two combat rounds, if first assigning only 1 hit to the armour, then assigning 1 hit to an infantry, thereafter (at this point, there would be no distinction between the infantry changed into from the armour and any other infantries of the same owner).
On the other hand, if the unit would turn into another one having higher TUV value, damaging such unit to that point should increase the TUV swing in favour of that side (someone could make a map with units that just get stronger and stronger when damaged (though, this cannot be an infinite process, as eventually you will either have to reach a final unit or have a looping dynamic)).
The two easiest examples are, either, cases of units that can never
whenHitPointsRepairedChangesIntoand units that immediately repair for free andwhenHitPointsRepairedChangesIntoback to the original, after combat. In the first case, the mapmakers should be sure to assign a good value to the various units, while in the second case all units should have exactly the same value (as you are not really losing any TUV). -
@Cernel said in Unit Option When Damaged Change Into Different Unit (Weakened Battleships):
@LaFayette That will have to wait until I'm releasing the map to the public. Also I suppose no public maps are yet using this feature, or at least none in the repository.
TWW uses the feature already.
-
@Hepps Ah, so this feature is already supported in TripleA 1.9.0.0.13066. TWW players must be hitting those problems, then, at least sometimes (wrong TUV results and inability to edit properly), I suppose.
I guess I could test this on TWW, if no TWW player does, since I don't intend releasing my map until after the new stable is out. -
@Cernel You can do the edit... I just can't remember the steps needed to do it and haven't had a game where I have had to edit one since it is (apparently) a very rare occurrence.
TUV I have never looked at since it is not very relevant in TWW. I additionally never look at TUV anyways as I play the game by feel and not by statistical analysis.
-
There is a major problem, I would say actually bigger than all the ones I've reported so far, especially for playing with AI (as I tested the AI exploits it): a damaged unit that is repaired and changed to another with the "whenHitPointsRepairedChangesInto" before Non Combat Move, on the same turn (you can do this assigning the proper step to that phase) has its movement reset too. This means, for example, that such a unit will be able to move after having been part of an attacking force that conquered a territory, if damaged during that battle, then repaired before the next movement phase on the same turn, as said. This happens both with a "true" and a "false" setting, in the option.
This is my full unit attachment where the issue happened:
<attachment name="unitAttachment" attachTo="warelephant1" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="1"/> <option name="transportCost" value="6"/> <option name="attack" value="4"/> <option name="defense" value="4"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsRepairedChangesInto" value="0:true:warelephant"/> <option name="isAAforCombatOnly" value="true"/> <option name="AttackAA" value="1"/> <option name="AttackAAmaxDieSides" value="1"/> <option name="offensiveAttackAA" value="1"/> <option name="offensiveAttackAAmaxDieSides" value="1"/> <option name="maxAAattacks" value="-1"/> <option name="maxRoundsAA" value="-1"/> <option name="damageableAA" value="false"/> <option name="typeAA" value="besiege"/> <option name="targetsAA" value="wall"/> <option name="willNotFireIfPresent" value="archer:ballista:cataphract:catapult:chariot:fort:fort1:horsearcher:horseman:irregular:legionary:phalangite:skirmisher:spearman:swordman:warelephant:warelephant1"/> <option name="requiresUnits" value="metropolis"/> </attachment>And this is a turn in which it happened:
<step name="Syria0EndTurn" delegate="endTurn" player="Syria"> <stepProperty name="skipPosting" value="true"/> </step> <step name="SyriaCombatMove" delegate="move" player="Syria"/> <step name="SyriaPurchase" delegate="purchase" player="Syria"/> <step name="SyriaBattle" delegate="battle" player="Syria"/> <step name="SyriaEndRoundStep" delegate="endRound"/> <step name="SyriaNonCombatMove" delegate="move" player="Syria" display="Reposition Units"> <stepProperty name="repairUnits" value="true"/> <stepProperty name="removeAirThatCanNotLand" value="false"/> </step> <step name="SyriaPlace" delegate="place" player="Syria"> <stepProperty name="removeAirThatCanNotLand" value="false"/> </step> <step name="Syria1EndTurn" delegate="endTurnNoPU" player="Syria"/>Unfortunately (or fortunately), this is not reproducible with TWW (as units don't repair on the same turn).
Is it intended for a unit that get changed with "whenHitPointsRepairedChangesInto" to be simply reset like a newly placed unit (maybe on the assumption that it won't matter, as it is expected repair happening after all movement phases on the same turn are done (wrong assumption, with the current possibilities)), or what?
-
@Cernel Unless damage being reset is intentional, a clean bug report documenting the problem would be best IMO for getting it fixed. Otherwise this only falls on probably @redrum who is the only dev following this thread to fix the problem. The length and complexity of this thread locks out any other contributor (potentially someone new even) from resolving the problem.
-
@redrum There is a thing may you want to look into, as it is something I've never experienced before. If I have this:
<attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="hitPoints" value="1"/> <option name="whenHitPointsDamagedChangesInto" value="1:true:wall_fallen"/> <option name="isConstruction" value="true"/> <option name="constructionType" value="fortification"/> <option name="constructionsPerTerrPerTypePerTurn" value="1000"/> <option name="maxConstructionsPerTypePerTerr" value="1000"/> <option name="requiresUnits" value="metropolis"/> </attachment> <attachment name="unitAttachment" attachTo="wall_fallen" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="0"/> <option name="canNotMoveDuringCombatMove" value="true"/> <option name="attack" value="0"/> <option name="defense" value="0"/> <option name="isInfrastructure" value="true"/> <option name="hitPoints" value="2"/> <option name="whenHitPointsRepairedChangesInto" value="0:true:wall"/> <option name="isConstruction" value="true"/> <option name="constructionType" value="fortification"/> <option name="constructionsPerTerrPerTypePerTurn" value="1000"/> <option name="maxConstructionsPerTypePerTerr" value="1000"/> <option name="requiresUnits" value="metropolis"/> </attachment>The game starts with no problems nor errors both in 1.9.0.0.13066 and 2.0, but the "whenHitPointsDamagedChangesInto" appears not working at all.
My guess is that this is because support for changing units when they lost all their hitpoints was added after 1.9.0.0.13066. However, I guess this is a warning to mapmakers, that if you use this option in 1.9 and the game is not giving any errors, this doesn't necessarily means that your game actually works in 1.9.
-
@Cernel I fairly sure this is supported in 1.9.0.0.13066 as TWW uses it. At a quick glance, I think the issue probably is that it doesn't work if the unit has 0 HP remaining (unit dies instead). Can you try changing the wall to have 2 HP to see if it then transforms?
-
Hi redrum,
Was the bombing damage feature added? Based on the thread and what I have tested for naming it was not.
-
Hi @waxfingers
yea you can. Total World War uses it and I copied that for the Global 40 Expansion
edit
<!-- Battle Ship -->
<attachment name="unitAttachment" attachTo="battleship" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
<option name="movement" value="2"/>
<option name="isSea" value="true"/>
<option name="attack" value="4"/>
<option name="defense" value="4"/>
<option name="canBombard" value="true"/>
<option name="hitPoints" value="2"/>
<option name="blockade" value="1"/>
<option name="canBeGivenByTerritoryTo" value="British"/>
<option name="whenHitPointsDamagedChangesInto" value="1:true:BB_Damaged"/>
</attachment><!-- BB Damaged --> <attachment name="unitAttachment" attachTo="BB_Damaged" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType"> <option name="movement" value="2"/> <option name="isSea" value="true"/> <option name="attack" value="0"/> <option name="defense" value="4"/> <option name="canBombard" value="false"/> <option name="hitPoints" value="2"/> <option name="blockade" value="1"/> <option name="canBeGivenByTerritoryTo" value="British"/> <option name="whenHitPointsRepairedChangesInto" value="0:true:battleship"/> </attachment> -
Hi beelee,
Yes, I noticed the "HitPoints" damage change function was added as I tested that. I meant was the SBR damage bombing function added. It was not the main thing of that article, but it was mentioned as an idea at the beginning. I am looking for such a thing now.
My full idea is I want to have a way to make SBR damage be more permanently lasting and also have players keep fighters for defense back home to try to deter or respond to it (as Germany did).
While the initial SBR in the war didn't really amount to much but casualties, apparently near the end when the US put money into doing it and targeted transportation and oil facilities it started to work as a strategy, especially when some material production was actually fully shutdown.
My idea is to reduce the territory PUs to a permanent level, perhaps even 0 if not dealt with. The way I have seen to do this is to perhaps have a particular unit/facility in the territory which gets bombed. This unit/facility would then convert to another unit because of the bombed value. The condition is whatever that bombed out value unit is less the territory value (if I can grab that somehow) is the amount of PUs lost taken as a national objective/convoy type of thing (which I got to work) to a maximum of the territory value. So basically the game adds the territory PUs but then this bombing convoy takes them away again. E.g. Germany is 5 PUs, Facility bombed at 6 damage, German player forgoes repairing it at all, so at collect income he actually loses 1 PU, if he had paid 1 PU, he would then at least break even because then next round he would still need to pay this off or he keeps losing the 1 PU (it never gets generated by the territory). Thus, it is a way to actually force a response to bombing and not just leave factories burning and just use another one out of reach. The max damage of each unit/facility would be double the territory PUs in order to achieve 0 income. Eventually, if one can keep bombing like this then it would be a permanent hindrance to the economic territories that are reachable. But, with fighters defending at 2, then it also makes it so those need to stay at home and can't be heading all over the place. Apparently Germany had 70% of its Airforce parked in West G because of bombing runs, perhaps a nice thing for Russia.
-
@waxfingers right on I thought I may have misinterpreted your question. @redrum not around much these days. Pops in once in a while.
@RogerCooper might know of a map that does what you want or have an idea how to do it.
Seems as if you got the right idea and it should be possible
-
@waxfingers I like how @Black_Elk does it with his "Attack 0 Cost 5 Bombers". It's in the https://forums.triplea-game.org/topic/1140/global-40-house-rules/30
I can't remember but I think I use interceptors hitting at 2 and escorts at 1 due the cost difference.
Anyway, tested it a ton and found it to work good. Makes Germany have to keep Ftrs to defend.
But yea, I like your idea. I'll look at it closer when I get time. : )
