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

Cernel

@Frostion It works only for hitpoints, but this doesn't exclude infrastructures. In the example above, castle units may be infrastructures damaged by AA attacks from trebuchets.

redrum

@Frostion The latter. The check of changes into is done at the end of each combat round. It now checks any damaged units and any units killed that round on whether they should change into a new unit.

It only works on normal unit HP not bombing damage. A similar mechanism could be added for bombing damage so could be a new feature request. I believe bombing damage can be done by non-air units but not positive.

@Cernel I don't believe changes into works for air battles as they have separate logic but haven't tested it. It should work for any part of a regular battle so AA, bombard, subs, etc.

I believe for retreating it will keep existing possibilities but won't have any unload limitations since its a new unit.

I believe it should work for AA that kill in one shot during normal battles.

I don't think it'll work for flyover or strat bombing AA as those aren't regular battles with combat rounds.

beelee

@redrum I know a lot of people have worked on this project over the years. You absolutely qualify for the triplea Hall of Fame. : ) Good Stuff !

Cernel

@redrum That retreat thing is a pretty major element, especially under default rules, in which if any of the units are unable to retreat, none can. It would at least need to be documented, as I don't think it may be expected.

redrum

@Cernel I did a basic retreat test and seemed like everything worked fine and it keeps the existing possibilities.

redrum

The changes to support this parameter for units with 0 HP has been merged. Please test out the latest pre-release and let me know if you have any issues.

Frostion

@Hepps @redrum
Total World War v3 has the following unit pictures:
germanBattleship
germanBattleship_hit
germanBattleship_hit1
germanBattleship_hit2

When and how exactly do the _hit1 and _hit2 images come into use? When are they used ingame to show the damaged unit?

When I try to implement multi HP units with more than one hit image, the engine seems to only want to use the single and normal _hit version, and not the numbered ones. A unit with 2 HP damage is just displayed on the map with the _hit picture supplemented by a black "2" number.

(Used the latest pre-release when testing)

Cernel

@Frostion Not up to me to answer, but I can only guess those images (hit1 and hit2) are not currently used by the game.

Cernel

Off topic, but I see a lossless compression thing run there. Any more info about it (in another topic)? How about a stickied topic with info on how to do that same process, in case other mapmakers may want to give a shot to it.

redrum

@Frostion I'm fairing certain those 2 images aren't used and just extras that @Hepps was testing with as alternatives. If you look at the germanCarrier images those so the normal images that are needed. There are only 2 images for each unit a normal one used when at full HP and a "_hit" one used if the unit has any HP damage.

The only way to achieve different unit images per amount of damage would be to use whenHitPointsDamagedChangesInto for each point of damage and have a different unit for each.

Cernel

@redrum There is a problem, using TripleA 2.0.16244.

I have this game code:

				<attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
                         <option name="movement" value="0"/>
                         <option name="attack" value="0"/>
                         <option name="defense" value="0"/>
                         <option name="hitPoints" value="1"/>
                         <option name="whenHitPointsDamagedChangesInto" value="1:true:wall_breached"/>
                         <option name="requiresUnits" value="city"/>
                </attachment>
				
				<attachment name="unitAttachment" attachTo="wall_breached" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
                         <option name="isInfrastructure" value="true"/>
                         <option name="movement" value="0"/>
                         <option name="attack" value="0"/>
                         <option name="defense" value="0"/>
                         <option name="hitPoints" value="2"/>
                         <option name="whenHitPointsRepairedChangesInto" value="0:false:wall"/>
                </attachment>

All works fine, game-wise, and here it is the relevant history (tested by editing 99 Carthage warelephants in Roma):

Combat
Carthage creates battle in territory Roma
Battle in Roma
Carthage attack with 99 warelephants
RomanRepublic defend with 1 ballista, 1 city, 1 horseman, 2 legionarys, 2 leviss and 4 walls
RomanRepublic roll dice for 1 ballista in Roma, round 2 : 3
Carthage roll dice for 99 warelephants in Roma, round 2 : 6,3,5,6,2,1,5,5,4,1,6,5,4,6,5,6,3,2,6,5,3,5,3,6,6,1,4,4,1,4,2,5,5,5,4,4,6,4,6,3,6,5,3,2,5,2,6,2,1,6,3,4,1,3,1,6,4,6,3,2,5,4,1,5,2,4,2,4,4,4,5,1,4,1,2,2,4,3,5,4,3,3,2,6,5,1,5,2,3,3,6,2,3,5,1,1,4,6,4
RomanRepublic roll dice for 1 horseman, 2 legionarys, 2 leviss and 4 walls in Roma, round 2 : 1,5,1,4,1
Units damaged: 3 warelephants owned by the Carthage
4 walls owned by the RomanRepublic, 1 ballista owned by the RomanRepublic, 2 legionarys owned by the RomanRepublic, 2 leviss owned by the RomanRepublic and 1 horseman owned by the RomanRepublic lost in Roma
4 wall_breacheds owned by the RomanRepublic added in Roma
Carthage captures 19PUs while taking RomanRepublic capital
Carthage takes Roma from RomanRepublic
Carthage win
Battle casualty summary: Battle score (TUV change) for attacker is 27
Recording Battle Statistics
Non Combat Move
7 units repaired.
4 wall_breacheds owned by the Carthage removed in Roma
4 walls owned by the Carthage added in Roma

But I get the following error, when I conquer a territory after having removed all wall units, thus capturing them all as damaged wall_breached infrastructures, and repairing them at the start of the immediately subsequent non combat movement phase:

ott 19, 2019 9:00:05 AM org.triplea.game.client.HeadedGameRunner lambda$main$0
GRAVE: null
java.lang.NullPointerException
	at games.strategy.triplea.image.UnitImageFactory.getBaseImageUrl(UnitImageFactory.java:148)
	at games.strategy.triplea.image.UnitImageFactory.getBaseImageUrl(UnitImageFactory.java:142)
	at games.strategy.triplea.image.UnitImageFactory.getTransformedImage(UnitImageFactory.java:156)
	at games.strategy.triplea.image.UnitImageFactory.getImageDimensions(UnitImageFactory.java:306)
	at games.strategy.triplea.ui.unit.scroller.AvatarPanelFactory.createUnitStackImage(AvatarPanelFactory.java:79)
	at games.strategy.triplea.ui.unit.scroller.AvatarPanelFactory.buildPanel(AvatarPanelFactory.java:51)
	at games.strategy.triplea.ui.unit.scroller.UnitScroller.lambda$drawUnitAvatarPane$4(UnitScroller.java:167)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:776)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:727)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:746)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Yet, everything in view seems working fine. The "wall", "wall_breached" and "wall_breached_hit" images are all in the "units" main folder (and not in the players subfolders). Am I correct I don't need a "wall_hit" unit, since the "wall" is 1 hitpoint changing when going down to 0 (removed)?

Moreover, this error happens only sometimes, under the exactly same after combat situation, beside only of a varying number of "warelephants" getting damaged, depending on dice results (that doesn't matter, as all are repaired for free on the same turn).

p.s.: Can I also get confirmed that what I'm doing is fine and meant to be supported, especially referring to changing a not infrastructure unit into a damaged infrastructure one?

Cernel

The game code could have been just this:

				<attachment name="unitAttachment" attachTo="wall" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
                         <option name="whenHitPointsDamagedChangesInto" value="1:true:wall_breached"/>
                         <option name="requiresUnits" value="city"/>
                </attachment>
				
				<attachment name="unitAttachment" attachTo="wall_breached" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
                         <option name="isInfrastructure" value="true"/>
                         <option name="hitPoints" value="2"/>
                         <option name="whenHitPointsRepairedChangesInto" value="0:false:wall"/>
                </attachment>

Cernel

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.

redrum

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

Cernel

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

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

Cernel

Also, just discovered an actual problem.

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

Cernel

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.

LaFayette

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

Cernel

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