[49.20] Round not advancing in round report

[gsparks3]

Environment

Standalone Megamek, version 0.49.20 Java Vendor: Eclipse Adoptium Java Version: 17.0.11 Platform: Windows 10 10.0 (amd64)

Description

Late in a lengthy, multi-day multiplayer game, we noticed that the round report had not advanced past round 12, and in fact the report for "round 12" contained reports for multiple turns.

Files

Note: While testing the effects of loading these saves, I always joined as player Mishra. I am not sure if joining as a different player changes anything.

Beginning of round 4, prior to any reinforcements: BigFightDay1end.sav.gz Loading the above save reproducibly produces the following error: megamek.log

18:01:07,165 ERROR [megamek.client.AbstractClient] {AWT-EventQueue-0}
megamek.client.AbstractClient.handlePacket(AbstractClient.java:383) - Failed to parse Packet command PHASE_CHANGE
java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 10
    at java.base/java.util.Vector.elementData(Vector.java:731)
    at java.base/java.util.Vector.get(Vector.java:752)
    at megamek.common.Game.getTurnForPlayer(Game.java:612)
    at megamek.client.Client.isMyTurn(Client.java:205)
    at megamek.client.ui.swing.boardview.TurnDetailsOverlay.gameTurnOrPhaseChange(TurnDetailsOverlay.java:58)
    at megamek.client.ui.swing.boardview.AbstractBoardViewOverlay$1.gamePhaseChange(AbstractBoardViewOverlay.java:245)
    at megamek.common.event.GamePhaseChangeEvent.fireEvent(GamePhaseChangeEvent.java:68)
    at megamek.common.AbstractGame.fireGameEvent(AbstractGame.java:173)
    at megamek.common.Game.processGameEvent(Game.java:739)
    at megamek.common.Game.setPhase(Game.java:735)
    at megamek.common.IGame.receivePhase(IGame.java:110)
    at megamek.client.AbstractClient.changePhase(AbstractClient.java:488)
    at megamek.client.Client.changePhase(Client.java:187)
    at megamek.client.AbstractClient.handleGameIndependentPacket(AbstractClient.java:465)
    at megamek.client.AbstractClient.handlePacket(AbstractClient.java:376)
    at megamek.client.AbstractClient$1.lambda$packetReceived$0(AbstractClient.java:531)
    at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
    at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
    at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
    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)

I am uncertain if this had any effect on the issue in question, as the issue did not occur until multiple turns/multiple days/multiple save and load cycles later.

Beginning of round 7 (after reinforcing from MUL on round 6): bigFightDay2end.sav.gz Loading this save reproducibly generates the same error as above. Also, if one attempts to open the round report immediately after loading the save, it will fail to display anything. No other errors are visible in the log file: megamek.log Issuing /skip commands until the phase advances and re-opening the round report will cause it to display properly. At this point in the game, the issue still has not occurred.

Beginning of round 10: bigGameDay3end.sav.gz Loading the above save behaves almost identically to the round 7 save. This is the last save I have from before the issue occurred.

Beginning of round "12" (actually 13), after reinforcing from MUL a second time on round 12: bigGameDay4end.sav.gz Loading this save behaves similarly to the two above saves in terms of needing to advance the phase before the round report will display. However, after doing so, it is visible that there is an additional "Initiative Phase for Deployment for Round 12" at the bottom of the round report - which should actually be the start of round 13.

Beginning of round "12" (actually 16): bigGameDay5end.sav.gz Loading this save behaves similarly to the above save, except that after advancing the phase and viewing the round report, you can observe that there are no less than 5 rounds in the "Round 12" report (easiest to observe using the "Phase" search to skip to the phase headers).

Beginning of round "12" (actually 18): turn18startBugged.sav.gz This was the point where we noticed a more serious issue - the reinforcements loaded from a MUL on turn 18 did not deploy, as the game did not think the round had actually advanced. Also, weapon-delivered smoke also does not seem to be dissipating, although I am not 100% certain on the latter.

[gsparks3]

Additional note: for the saves where the bug is present, continuing through the turns will reproducibly fail to advance the round number.

[SJuliez]

I fixed the very similar-looking issue #5542 with #5545. This was right somewhere in 0.49.20. I wonder if your game was played with a prior or later version.

The logged issue likely doesnt have a direct connection. It should not be able to prevent round advancement.

[gsparks3]

This was specifically the official 49.20 release. Checking dates, #5545 was merged on June 6, while the release was on June 28, so it should have had that fix, but the issue still occurred.

[SJuliez]

it seems that part of #5545 got lost, maybe I didnt get merge conflicts with my own other PRs right. I will re-apply it :)

[gsparks3]

Well, that would certainly explain it. Thanks for the fix!