Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property

Trevan

Those are all good points but they are talking about what happens at the end of the round (my number 2 in the first post). I'm asking about the scenario before the standard/regular units fire.

Let's say you have a battle that at the beginning of the round, the defender only has units that can't roll. The option "Transport Casualties Restricted" is false. With the current code base, the attacker will have to make a roll. Afterwards, the remaining units will be auto-killed.

Is there a reason for why the attacker needs to make that extra roll?

Cernel

@Trevan said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

Those are all good points but they are talking about what happens at the end of the round (my number 2 in the first post). I'm asking about the scenario before the standard/regular units fire.

Let's say you have a battle that at the beginning of the round, the defender only has units that can't roll. The option "Transport Casualties Restricted" is false. With the current code base, the attacker will have to make a roll. Afterwards, the remaining units will be auto-killed.

Is there a reason for why the attacker needs to make that extra roll?

Assuming that "Transport Casualties Restricted" false is meant to detect that the game is following a v1 or v2 rules set, I believe there should be no autodestruction, as I said. So the check before the regular fire is acting correctly (if it is supposed to act only if the game is detected as being a v3 rules set).

As I said, I believe you should consider first all related problems. By testing it in the past, I believe how it works, currently, is that the remaining units are removed only after having given you the option to retreat.

To answer your question directly:

Is there a reason for why the attacker needs to make that extra roll?

Yes, because, this way, they are able to retreat, if one or more defending units remain (except that this is an incorrect behaviour for v3 and following, which I suggest to be kept as optional), since the step after the rolls is also (incorrectly) after the retreat step (am I right that it is?).

Trevan

I'm looking at the second place where the auto-kill is happening. And I think I misread the code. I think the auto-kill rarely ever happens there. It first checks that CollectionUtils.getMatches(defendingUnits, Matches.unitIsNotInfrastructure()).size() == 0. So, it will only do the auto kill IF there are only infrastructure units available. And only those infrastructure units will be auto-killed.

So the main auto-kill only happens before standard attack.

Another question. In this auto-kill location after the standard attack, it will only remove undefended transports IF "Transport Casualties Restricted" is true. But it will always remove units with no rolls. But the auto-kill location before the standard attack, it will only kill undefended transports AND units with no rolls IF "Transport Casualties Restricted". Any ideas why the two locations treat units with no rolls differently? Should they be treated the same? And if so, which way should it be treated?

Cernel

If I understand and recall correctly, this is how it works:

There is an autodestruction step before the fire steps that checks "Transport Casualties Restricted" being true.
There is an autodestruction step after the retreat steps that doesn't checks "Transport Casualties Restricted" being true.

Correct?

If this is correct, this causes the following problems, for which several issues have bee opened (and possibly are already open):

You have autodestruction steps only at some points, while, by rules, v3+ should have it anytime only defenceless remain against one or more offenceful (so the step should be at the start of the first combat round and after every step that may eliminate one or more defending units), while v1 and v2 should never have it (but it is good having it at least if the attacker cannot retreat, to skip usuless clicks).
The autodestruction step after the retreat step is wrongly placed and pointless if everything else would be correctly placed, as, if that would act, it would have already acted during an identical step before the retreat step (the retreat step is not a step that may eliminate one or more defending units).

However, as I said, I personally like the current (wrong) behaviour of causing autodestruction only after having the option to retreat (that is destroying the defenceless defending units only if you choose not to retreat), so I encourage the developers to keep the current behaviour as an option (a property that allows retreating against defenceless only units, as you currently can).

I hope now everything is clear. I think I've summarized at least a number of issues reported over the years, here. Once the defenceless case is fixed, the next step would be expanding it the same way to the case in which the defending units cannot target any offending units, while the offending units can (which is even more problematic and less supported, I believe).

Cernel

@Trevan said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

I'm looking at the second place where the auto-kill is happening. And I think I misread the code. I think the auto-kill rarely ever happens there. It first checks that CollectionUtils.getMatches(defendingUnits, Matches.unitIsNotInfrastructure()).size() == 0. So, it will only do the auto kill IF there are only infrastructure units available. And only those infrastructure units will be auto-killed.

So the main auto-kill only happens before standard attack.

You are probably right if you are looking at something before the retreat step. However, I believe you should find an "auto-kill" step for defenceless (not only infrastructures) after the retreat step.

Another question. In this auto-kill location after the standard attack, it will only remove undefended transports IF "Transport Casualties Restricted" is true. But it will always remove units with no rolls. But the auto-kill location before the standard attack, it will only kill undefended transports AND units with no rolls IF "Transport Casualties Restricted". Any ideas why the two locations treat units with no rolls differently? Should they be treated the same? And if so, which way should it be treated?

As I said, there are problems related to mass destruction of units, that is generally wrongly implemented. I at least need to know if what you are talking about is immediately after the defensive fire or also after the step in which you may be able to retreat. Also you should clarify what you mean with "no rolls" (does that refer only to units that actually have 0 rolls (and maybe defence 1 or more) or also to units that have positive rolls (normally 1) but defence 0?).

Trevan

@Cernel said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

If I understand and recall correctly, this is how it works:

There is an autodestruction step before the fire steps that checks "Transport Casualties Restricted" being true.

There is an autodestruction step after the retreat steps that doesn't checks "Transport Casualties Restricted" being true.

Correct?

Partially.

There are two types of auto-destruction: 1) unescorted transports 2) units with no rolls. #1 is always controlled by "Transport Casualties Restricted". #2 is only controlled by "Transport Casualties Restricted" before the standard fire step. After the standard fire step, it doesn't care about that property.

The auto destruction also never happens after the retreat steps. It is either before the standard attack or after the standard attack but before the retreat step. Now, technically, after the retreat step, it will start a new round and will then run the auto destruction step that occurs before the standard attack, so in a way it does happen after the retreat step But that is technically in a new round.

@Cernel said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

As I said, there are problems related to mass destruction of units, that is generally wrongly implemented. I at least need to know if what you are talking about is immediately after the defensive fire or also after the step in which you may be able to retreat. Also you should clarify what you mean with "no rolls" (does that refer only to units that actually have 0 rolls (and maybe defence 1 or more) or also to units that have positive rolls (normally 1) but defence 0?).

After the defensive fire. As I mentioned above, there is technically no auto-kill after the retreat step.

If a unit has attack/defense power > 0 or has a unit support attachment is considered to have rolls left. So the opposite of that is a unit with "no rolls".

Cernel

@Cernel said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

As I said, there are problems related to mass destruction of units, that is generally wrongly implemented. I at least need to know if what you are talking about is immediately after the defensive fire or also after the step in which you may be able to retreat. Also you should clarify what you mean with "no rolls" (does that refer only to units that actually have 0 rolls (and maybe defence 1 or more) or also to units that have positive rolls (normally 1) but defence 0?).

After the defensive fire. As I mentioned above, there is technically no auto-kill after the retreat step.

If a unit has attack/defense power > 0 or has a unit support attachment is considered to have rolls left. So the opposite of that is a unit with "no rolls".

That is not answering my question. From a mapmaker perspective, when you give "attack" and "defense" values, that is not defining the rolls that the unit has. Also I'm not sure if by power you mean the multiplication of strength and rolls (that is 0 as long as at least one of the two is 0). I'll make it easier to be answered. Which ones of the following two is what you define units having "no rolls":

A unit with defence 1 or more and defensive rolls 0.
A unit with defence 0 and defensive rolls 1 or more.

And is that after all supports have been applied?

A mapmaker can make a unit defenceless in one or both of two ways: By setting it's defence to 0 or by setting its defensive rolls to 0. I just want to be sure that you are considering both cases. Additionally, you could also make the unit unable to target any units, that would be substantially the same as having power 0, and should be actually treated the same way.

Trevan

@Cernel said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

That is not answering my question. From a mapmaker perspective, when you give "attack" and "defense" values, that is not defining the rolls that the unit has. Also I'm not sure if by power you mean the multiplication of strength and rolls (that is 0 as long as at least one of the two is 0). I'll make it easier to be answered. Which ones of the following two is what you define units having "no rolls":

A unit with defence 1 or more and defensive rolls 0.

A unit with defence 0 and defensive rolls 1 or more.

And is that after all supports have been applied?

A mapmaker can make a unit defenceless in one or two ways, or both: By setting it's defence to 0 or by setting its defensive rolls to 0. I just want to be sure that you are considering both cases.

Here's the code that defines whether a unit has "rolls". This is existing code, by the way.

      // if unit has attack or defense, return true
      final UnitAttachment ua = UnitAttachment.get(ut);
      if (attack && ua.getAttack(player) > 0) {
        return true;
      }
      if (!attack && ua.getDefense(player) > 0) {
        return true;
      }
      // if unit can support other units, return true
      return !UnitSupportAttachment.get(ut).isEmpty();

So, I think #2 would be considered to have no rolls, unless it also has a unit support attachment.

Cernel

@Trevan You can paste that, and I appreciate the effort, but I'm not understanding it. That looks like something that checks if the unit has no attack or no defence, which would make no sense. The defending units should only be checked for defence (they must be all defenceless, but it doesn't matter if they are offenceful or not). The offending units should only be checked for offence (at least one of them must be offenceful, but it doesn't matter if it is defenceful or not).

On top of this, as I said, a unit able to targe no units currently in the battle should be treated exactly the same way as a powerless unit.

Trevan

@Cernel said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

@Trevan You can paste that, and I appreciate the effort, but I'm not understanding it. That looks like something that checks if the unit has no attack or no defence, which would make no sense. The defending units should only be checked for defence (they must be all defenceless, but it doesn't matter if they are offenceful or not). The offending units should only be checked for offence (at least one of them must be offenceful, but it doesn't matter if it is defenceful or not).

On top of this, as I said, a unit able to targe no units currently in the battle should be treated exactly the same way as a powerless unit.

I don't know how to explain it any better than. A unit that has an attack (in the attack case) or a unit that has a defense (in the defense case) is considered to be "useful" (for lack of a better term). In addition, units that have a support attachment are also considered to be "useful". If all of the units are not "useful" and the opposing player has non-infrastructure unit, then all of the units are auto-killed.

This only happens if "Transport Casualties Restricted" is true or if it is false and the defender only has infrastructure units left.

I feel like the second case is a rare situation and probably never reached by most players. I'm not sure how to replicate that situation in a game, so if anyone has an idea on how to replicate it, I'd appreciate it.

LaFayette

@Trevan said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

This only happens if "Transport Casualties Restricted" is true or if it is false and the defender only has infrastructure units left.
I feel like the second case is a rare situation and probably never reached by most players. I'm not sure how to replicate that situation in a game, so if anyone has an idea on how to replicate it, I'd appreciate it.

Indeed, you'd have to build a map specifically with those settings.

The lack of support attachments is to ensure that the defender power won't change. There can be enemy negative buffs, in which case you would not want an auto-kill. For example say there was a suicide unit that lasted one round and gave -1 to all defenders for one round. If there is one attacker and the negative buff unit, they could potentially auto-kill the whole defensive stack.

Generally the rule is, if the defender has no power left, and the attacker would just need to sit there and keep rolling dice, then it's an auto-kill situation.

@Cernel the attack/defense properties referenced in code come straight from the XML unit properties. It could be debatable that those should be multiplied by the number of rolls and then checked if zero. The check for support attachment is notable as units with non-zero power but zero rolls could perhaps be eligible for support buffs that could change as the battle progresses.

beelee

@LaFayette said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

Generally the rule is, if the defender has no power left, and the attacker would just need to sit there and keep rolling dice, then it's an auto-kill situation.

Cernel

Thanks @LaFayette for clarifying that it depends exclusively on the basic defence value (as defined in the xml), and not at all on the defensive rolls value. I'd say the program should rather look at the current value, after applying all supports (instead of looking if there are any), territory effects and whatever the like.

@Trevan I think this is such a mess of unclear things and problems (outright wrong behaviours) that the only way out I see is that a developer documents exactly how the system works (every case of auto-elimination of units, clarifying exactly and fully when it happens and under what conditions it happens), then we can discuss how it should work, instead. I suggest doing this both for the non-infrastructure and the infrastructure case (infrastructures have problems too, I recall), trying to set or keep them apart.

LaFayette

@Cernel teasing out how it works is maybe not feasible. There's probably around 2-5k lines of code around thus, and you've seen how much analysis there was for about 10 of them.

Beyond that, we should be able to state how the sequencing should work ignorant of the actual. Such specifications are actually a really important and necessary thing for developers to have.

Let's be sure all specific questions here are answered. At some point we need a restructuring if rules are applied so that they are sensible and configurable. Assumptions like "in vo2 all units have defensive values and transport restricted means v3" need to be made explicit and bot just special cases throughout.

Trevan

@LaFayette said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

Generally the rule is, if the defender has no power left, and the attacker would just need to sit there and keep rolling dice, then it's an auto-kill situation.

So, should the "remove units that can't roll anymore" (not including unescorted transports) logic be based on the value of "Transport Casualties Restricted"? Because it is sometimes based on the value and sometimes isn't.

LaFayette

In short, yes (kinda).

In the current code the 'transport casualties restricted' tells you if the transports can defend of not. That is used in place of checking for a 'v3' rule set. Probably we should be checking if the transport units have hitpoints instead.

Cernel

@Trevan So why the first post still says "At the end of a round when a defender either has no more units or only infrastructure units"? Didn't you say that is actually in between of the defensive fire step and the retreat step? You said there is nothing related to this issue anywhere after the retreat step (thus nothing "at the end of a round"), right? Just asking to be sure the first post is wrong and being corrected by following ones.

Also, didn't you say that you misread the code, and the first auto-kill is about defenceless and the second about infrastructures? In this case, of course, the first one would be v3 rules only and the second one would be generic.

Also, can you confirm that when you said things like this:

Another question. In this auto-kill location after the standard attack, it will only remove undefended transports IF "Transport Casualties Restricted" is true. But it will always remove units with no rolls. But the auto-kill location before the standard attack, it will only kill undefended transports AND units with no rolls IF "Transport Casualties Restricted". Any ideas why the two locations treat units with no rolls differently? Should they be treated the same? And if so, which way should it be treated?

The "units with no rolls" are actually units with attack and defence values equal to 0 (which I would say is a wrong check, as only one of the other should matter, dependind whether the unit is offending or defending) and with no support attachments, regardless of their offensive or defensive rolls values? If so, can everyone please stop confusingly saying "no rolls" or "units that can't roll anymore" to refer to this, as that literally comprises units that have 0 rolls (and possibly positive attack or defence or both) and units that cannot target any remaining units, which I understand it is not what it is being checked (right?)?

Regarding:

There are two types of auto-destruction: 1) unescorted transports 2) units with no rolls. #1 is always controlled by "Transport Casualties Restricted". #2 is only controlled by "Transport Casualties Restricted" before the standard fire step. After the standard fire step, it doesn't care about that property.

How is the situation after the fire steps ever even happening since you said:

I'm looking at the second place where the auto-kill is happening. And I think I misread the code. I think the auto-kill rarely ever happens there. It first checks that CollectionUtils.getMatches(defendingUnits, Matches.unitIsNotInfrastructure()).size() == 0. So, it will only do the auto kill IF there are only infrastructure units available. And only those infrastructure units will be auto-killed.

And, obviously, when only infrastructures remain for one or both sides, the battle is over regardless of anything else. So how is not everything else useless for the second check.

Furthermore, and here we go back to what I suggested that, before thinking about fine tuning these codes, one should rather fix the known problems related to them, you say:

The auto destruction also never happens after the retreat steps. It is either before the standard attack or after the standard attack but before the retreat step.

Which is contrary to what experienced as reported at this issue:

https://github.com/triplea-game/triplea/issues/4688

TripleA should not offer the attacker's option to retreat, if after a round of combat only a defending AAA-gun is left. In the attached savegames (1.9/1.10) the remaining infantry is incorrectly offered a retreat option when facing only a "defending" AAA gun.

That is saying the problem is actually the behavioural absence of auto-destruction "after the standard attack but before the retreat step".

Cernel

@LaFayette said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

In short, yes (kinda).

In the current code the 'transport casualties restricted' tells you if the transports can defend of not. That is used in place of checking for a 'v3' rule set. Probably we should be checking if the transport units have hitpoints instead.

V3 transports have hit-points too. Just you can assign to those hit-points only after nothing else eligible remains.

Moreover, in my opinion, infrastructures have hit-points too and should be targetable by other units if these units have targeted fire against the infrastructures (for example, I believe a flying infrastructure should be targeted by AA fire). I said in my opinion, as this never acually happens in the basic games, so I'm extrapolating.

Trevan

@LaFayette said in Question on MustFightBattle#checkForUnitsThatCanRollLeft and "Transport Casualties Restricted" property:

In short, yes (kinda).

In the current code the 'transport casualties restricted' tells you if the transports can defend of not. That is used in place of checking for a 'v3' rule set. Probably we should be checking if the transport units have hitpoints instead.

I'm not talking about transports. My question is about the other "auto-kill" situation; units that can't do anything anymore because they either don't give support or they have no attack/defense.

In one part of the code, those units are auto-killed depending on the value of "transport casualties restricted". In another part, those units are auto-killed regardless of the value of "transport casualties restricted". I feel like that is a bug. Going through the history, it looks like the code to auto-kill these "useless" units and the code to auto-kill the unescorted transports were add before the "transport casualties restricted" check. And then when that check was added, it was either not added in all the correct places or was added in too many places.

LaFayette

@Cernel Well, v3 transports do and don't have hitpoints, and that is my point. Instead of modelling it well, we have this hack "v3 transports restricted".

If you add transports to a battle calc, you're not adding hitpoints. A hitpoint is a damage slot you can assign during a battle. If you can only assign such damage at the end, and if you do it's always an auto-kill situation, then those units do not actually have hit points. That is my point, instead of having a "hit points" unit property that is set to zero for transports, we do this very round-a-about pedantic way to have a 1-hitpoint unit to effectively have no hit points. If the code just considered it if 0-hitpoint units remained then things would flow naturally rather than this special casing for a specific property that is only for transports and that also effectively overrides their unit properties.