Unit Option When Damaged Change Into Different Unit (Weakened Battleships)


  • Moderators

    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.


  • Admin

    @Cernel the error you posted is related to the new unit scroller and there is already a github issue open for it


  • Moderators

    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.


  • Moderators

    @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).


  • Moderators

    Also, just discovered an actual problem.

    If you edit the damage, the unit doesn't change to the one it should.


  • Moderators

    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 10
    

    In 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.


  • Admin

    @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.


  • Moderators

    @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 whenHitPointsRepairedChangesInto and units that immediately repair for free and whenHitPointsRepairedChangesInto back 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).


  • Moderators Admin

    @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.


  • Moderators

    @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.


  • Moderators Admin

    @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.


  • Moderators

    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?


  • Admin

    @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.


  • Moderators

    @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.


  • Admin

    @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?


Log in to reply