Triplea: Infinite loop in battle calculator

[simon33-2]

How can the problem be recreated?

Unsure to be honest. We believe that the properties for subs are corrupted in the save file and this later causes issues for attacking subs with defending planes but no defending destroyers. Probably vice versa too.

If you download the below file, Open the battle calculator for SZ112, swap sides, add in SZ111 defenders and some planes, then run the calculator, you will get the problem.

Do you have any ideas for an expected fix?

Attach a Save Game

https://www.axisandallies.org/forums/assets/uploads/files/1600889975703-triplea_35795_1rus.tsvg

If playing a prerelease, which version are you using?

Game Version:
2.2.20868

If playing a prerelease, does this happen on the latest release?

• [] yes
• [] no

Is there anything else we should know?

Hopefully, this is enough. Many players are noticing this problem. Also, subs lose their stealth properties at certain points; this is likely the same problem.

[trevan]

@simon33-2 , do you know what version of the game created that save file? And has it been saved in newer versions of the game?

I'm stepping through the code and I see that the submarines are not flagged as isSub or as canEvade. In a battle, a sub will automatically submerge when there are only airplanes, but that is because of the canEvade flag. And since these subs don't have it, the battle calculator will spin forever since both sides should be able to fire but they actually can't.

I know there was a change to how subs worked and so that's why I'm wondering when the save was made. If it was saved before the change and then resaved afterwards, that might be a clue to the cause.

[simon33-2]

It was created with 2.2.20868 it seems, although the version which played the second turn is unknown.

I'll pass that on.

[trevan]

Is the original save available? Or any earlier saves? It would be interesting to see when the data changed.

[simon33-2]

Have a look here: https://www.axisandallies.org/forums/topic/35795/l20-bm3-freh-vs-dawgoneit-allies-18

[panther2]

@trevan Chances are that this is related: Users report similar sub-related problem situations for example in
https://www.axisandallies.org/forums/topic/35832/2-2-bugs-forum-autosaves-and-sub-rules-issues

[trevan]

@panther2 , yes the sub movement issue there is related.

The problem is that in 2.2, the way canEvade and other sub related attributes was tracked changed to fix some bugs. The PR for that change is in https://github.com/triplea-game/triplea/pull/7227.

Unfortunately, it looks like if you CREATE a game with 2.2 and then open the game in 2.0 or 2.1 and save it, all of the subs (anything with isSub) is broken.

This issue will not show up if you CREATE a game with 2.0 or 2.1 and then play it in 2.2. Or, if you create the game in 2.2 and only play it in 2.2.

I'm not sure how to fix this other than tell people to upgrade to 2.2 or don't start any pbem or pbf with 2.2 if you know that the other players are on an earlier version.

[DanVanAtta]

I think there used to be a warning that a save was made with a newer version of the engine. That code, if exists, could be dead (not working). This does seem like a case where we should mention that the save is newer than the current engine, it might work but user should upgrade to avoid potential problems.

[DanVanAtta]

With the above said, it seems a secondary fix would be to have the battle calculator detect the looping. I wonder if there is also a missing condition in the stalemated battle, really the battle once at a point that neither side can hit one another, the battle should end as a stalemate. I'm tempted to say we should also put a cap on the max number of combat rounds that the battle simulator would do just in case and in general (but that might paper-over problems unless we are careful, perhaps offer to submit a bug report with a stack trace and terminate the battle calc for example by throwing a "CombatNeverFinishesException")

[trevan]

With the above said, it seems a secondary fix would be to have the battle calculator detect the looping. I wonder if there is also a missing condition in the stalemated battle, really the battle once at a point that neither side can hit one another, the battle should end as a stalemate.

There probably needs to be a condition now. Previously, the only units that couldn't hit each other were subs and air. And there is a step to automatically sink the subs in this situation. But with the splitting up of canEvade from canNotTarget and canNotBeTargetedBy, a map maker can create similar stalemate setups.

Once the FiringGroup PR is done, I can do a check at the stalemate spot and see if both sides have 0 firing groups and if so, stalemate it.

[DanVanAtta]

Sounds good @trevan, thanks

[Cernelius]

Is it documented that backward compatible changes do not cause first digit increases (that is, if saves taken with the old engine are not loadable in the new one, this would be a first digit increase, while, if saves taken with the new engine are not loadable in the old one, this would not be a first digit increase (which accords to what already happened))?

I think this would be opportune to be standardized, as otherwise every time you add a new feature (like a new unit option that didn't exist or existed under a different name) you would have to increase the first digit, that I feel should not be something that gets increased that easily.

For example, if TripleA would increase the first digit at every forward incompatible changes and this would have been the case before all the features tracked here:
https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list
were implemented, now the first digit of TripleA would be somewhere over number 50.

If everything is supposed to be fine as long as everyone has the latest release (like in the case at hand), I think this should not require a first digit increase (as I think people should take care to be on the latest release anyway, especially when playing multiplayer).

For forward compatibility, it may be advisable that the program always refuses to load saves made with programs of higher first or second digit, asking people to download the latest release or the release the save was made with if it is not the latest.

It may be also good to have first digit increases for breaking backward compatibility, second digit increases for breaking forward compatibility (the case at this issue) and a third digit for neither, additionally to the last (fourth) digit.

[DanVanAtta]

Saves in a new engine working in an old is called 'forward compatibility'. That is not captured at all in the version numbering. The first digit represents only backward compatibility. The second is a release number, the third a build number. That versioning system was the subject to a lot of bike shedding. I don't see value in further bike shedding over it. It is set for the foreseeable future and I do not support changing it.

For forward compatibility, it may be advisable that the program always refuses to load saves made with programs of higher first or second digit, asking people to download the latest release or the release the save was made with if it is not the latest.

I believe there is code to warn about this. I suspect that is broken. It really speaks to the need to untie the knots in the code and get things automatically tested. Regardless it's a feature that should be restored in one manner or another.

[Cernelius]

Saves in a new engine working in an old is called 'forward compatibility'.

This is what I said (if by "saves in a new engine" you mean "saves made with a new engine").

In this case, we have forward compatibility being broken (saves made with a new engine possibly not working in an old one) between 2.1 and 2.2, but no backward compatibility breakage.

That is not captured at all in the version numbering. The first digit represents only backward compatibility.

Good to know. That is exactly what I was proposing (and now I see it is already the case). Is it documented anywhere? Should this knowledge (about what the realease numbers mean) be made more easily accessible to regular users (telling them that as long as the first digit is not increased, there should not be backward compatibility problems, while forward compatibility is not guaranteed)?

[trevan]

I think there used to be a warning that a save was made with a newer version of the engine. That code, if exists, could be dead (not working). This does seem like a case where we should mention that the save is newer than the current engine, it might work but user should upgrade to avoid potential problems.

I tracked down this code. It had been deleted. I've created a PR to re-add it - #7871

[simon33-2]

Should there be an incompatible release for this problem? Or do you think just re-adding the warning would be enough.

[simon33-2]

Slightly different path to reach the same problem. Run the battle calculator on the below save in the Caroline Islands:
BattleCalcBug.zip

Does not cause a problem if edit mode is off, although that is easy to leave on.

[Cernelius]

Should there be an incompatible release for this problem? Or do you think just re-adding the warning would be enough.

@simon33-2 Did you read what @DanVanAtta wrote?

The first digit represents only backward compatibility.

As I said, I agree that forward compatibility breakages (this problem) should be no reason for increasing the first digit.

[simon33-2]

@simon33-2 Did you read what @DanVanAtta wrote?

Re-reading it, I would still advise an incompatible release. This problem is pretty annoying - some users advising avoiding 2.2. Also, fixing the warning does not resolve the problem because it occurs when an old version with the broken warning opens the save game.

There haven't been enough incompatible releases ever since 1.9. The sub change should have been an incompatible release IMO. It is incompatible isn't it?

[Cernelius]

There haven't been enough incompatible releases ever since 1.9. The sub change should have been an incompatible release IMO. It is incompatible isn't it?

@simon33-2 Did you ever take a look at this feature list:
https://forums.triplea-game.org/topic/182/guidelines-and-feature-request-list

The ones written off are the ones done.

That is only since 1.9. If one would increase the first digit at every forward incompatible release since TripleA existed, we would be well past TripleA 100.0 by now. You cannot seriously force incompatibility every time you add a new feature (that maybe is for some new custom map only).

[trevan]

@simon33-2

There haven't been enough incompatible releases ever since 1.9. The sub change should have been an incompatible release IMO. It is incompatible isn't it?

The sub change isn't incompatible. Saves from 2.0 and 2.1 will load fine in 2.2 and work without any issues (except a really rare case that I'm not sure any map actually supports). The problem is when you load a 2.2 save in 2.0 or 2.1. If all the players in a game have upgraded to 2.2, then no one will have any issues.

[Cernelius]

@simon33-2

There haven't been enough incompatible releases ever since 1.9. The sub change should have been an incompatible release IMO. It is incompatible isn't it?

The sub change isn't incompatible. Saves from 2.0 and 2.1 will load fine in 2.2 and work without any issues (except a really rare case that I'm not sure any map actually supports). The problem is when you load a 2.2 save in 2.0 or 2.1. If all the players in a game have upgraded to 2.2, then no one will have any issues.

Correct. The latest release (2.2) is not incompatible, as far as what is being reported here. It is the previous release (2.1) that is incompatible with it. Not sure how many times this needs to be repeated.

Really, the only problem here is that every time someone gets a savegame made with a more recent release, the user should be either strongly suggested or even obliged to upgrade at least to that. Of course, this problem cannot be fixed but for the future.

[DanVanAtta]

A code change was just merged that will warn and require a user with an older game engine to upgrade to at least the same version as the save game. In other words, if you open a 2.2 save with a 2.1 game, you'll get a message telling you to upgrade.

The remaining work I think for this issue is to avoid the infinite loop and to instead have the calculator error out and send us a bug report. There are hopefully reasonable ways to do this, if the number of battle rounds reaches say 10,000 then perhaps there should be an error at that point. Specifically it would be a bug to get that far as it implies the battle is probably stalemated but we have not detected that condition and so the battle just keeps looping.

[Cernelius]

The remaining work I think for this issue is to avoid the infinite loop and to instead have the calculator error out and send us a bug report. There are hopefully reasonable ways to do this, if the number of battle rounds reaches say 10,000 then perhaps there should be an error at that point. Specifically it would be a bug to get that far as it implies the battle is probably stalemated but we have not detected that condition and so the battle just keeps looping.

This is one of the cases you get a stalemate.

If, for any reason, both sides cannot target anything left on the other side, the battle ends immediately, at that point.

In theory, one could argue that in v1 and v2 you should be allowed to keep making useless combat rounds "ad infinitum", since there is no stalemate, but this is just because, in the basic games, there are no units with defence 0. I think the stalemate rule, in this case, can be generalized back to v1 (also since, otherwise, if nobody can hit each other and it is not possible to retreat, the game will be unable to proceed).

The only action that may still be done is retreating, if all offending units left have the canRetreatOnStalemate option.

This is still an item that is missing at:
https://github.com/triplea-game/triplea/issues/6532

I believe the most typical example of stalemate in which both sides cannot hit each other is given in the World War II v6. Reproduction steps:

• Skip until the start of Germans Combat Move.
• Move 2 submarines to 14 Sea Zone.
• End the Combat Move phase.
• If you kill the carrier while at least 1 submarine remains, you are in a condition in which either side cannot hit the other one (stalemate).
• PROBLEM: TripleA gives you the ability to retreat any remaining submarines (when you have 1 or 2 submarines left against 1 fighter alone), but this is an illegal action, because the battle ended in stalemate and submarines cannot retreat on stalemate (only transports can).

The problem here is the same, or rather part of it.

[DanVanAtta]

The battle calculator should stop once a stalemate has been hit. If it does
not detect it, then we get an infinite loop and locked up game

On Mon, Oct 12, 2020, 5:41 PM Cernelius [e-mail] wrote:

The remaining work I think for this issue is to avoid the infinite loop
and to instead have the calculator error out and send us a bug report.
There are hopefully reasonable ways to do this, if the number of battle
rounds reaches say 10,000 then perhaps there should be an error at that
point. Specifically it would be a bug to get that far as it implies the
battle is probably stalemated but we have not detected that condition and
so the battle just keeps looping.

This is one of the cases you get a stalemate.

If, for any reason, both sides cannot target anything left on the other
side, the battle ends immediately, at that point.

In theory, one could argue that in v1 and v2 you should be allowed to keep
making useless combat rounds "ad infinitum", since there is no stalemate,
but this is just because, in the basic games, there are no units with
defence 0. I think the stalemate rule, in this case, can be generalized
back to v1 (also since, otherwise, if nobody can hit each other and it is
not possible to retreat, the game will be unable to proceed).

The only action that may still be done is retreating, if all offending
units left have the canRetreatOnStalemate option.

This is still an item that is missing at:

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

I believe the most typical example of stalemate in which both sides cannot
hit each other is given in the World War II v6. Reproduction steps:

• Skip until the start of Germans Combat Move.
• Move 2 submarines to 14 Sea Zone.
• End the Combat Move phase.
• If you kill the carrier while at least 1 submarine remains, you are
  in a condition in which either side cannot hit the other one (stalemate).
• PROBLEM: TripleA gives you the ability to retreat any remaining
  submarines (when you have 1 or 2 submarines left against 1 fighter alone),
  but this is an illegal action, because the battle ended in stalemate and
  submarines cannot retreat on stalemate (only transports can).

The problem here is the same, or rather part of it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/triplea-game/triplea/issues/7848#issuecomment-707416611,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC6SZOKL3MRTNR7T4GAIYQDSKOO4BANCNFSM4SFSGBPQ
.

[simon33-2]

The sub change isn't incompatible

That is open to interpretation.

[DanVanAtta]

Forward vs backward compatibility. Backward compatibility once broken is
hard to fix. Forward compatibility is easier to fix so long as the newer
versions are backward compatible. When talking about compatibility, unless
qualified, we're referring to backward compatibility

On Mon, Oct 12, 2020, 9:38 PM simon33-2 [e-mail] wrote:

The sub change isn't incompatible

That is open to interpretation.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/triplea-game/triplea/issues/7848#issuecomment-707481580,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC6SZOIWMXWTM3BJ2TKHYALSKPKWBANCNFSM4SFSGBPQ
.

[trevan]

Once the FiringGroup PR is done, I can do a check at the stalemate spot and see if both sides have 0 firing groups and if so, stalemate it.

I've created #7948 to stalemate the game if neither side has a firing group.