Deadlock during (milita) AI leads to player turn (without reseting the AP)

Issue #57 resolved
Oliver Jankowski created an issue

If a deadlock occurs during militia AI, the turn of the militia ends and a new player turn starts. But the AP of the players MERCs are not calculated for the new turn, the AP remain the same as at the end of the last turn.

Why this error occurs (as far as I understand): When a deadlock occurs, the turn of the deadlocked soldier ends (AIMain.EndAIGuysTurn()) and a new turn for the players team is started (TeamTurns.StartPlayerTeamTurn()), see AIMain.cc, line: 681f. But the code for calculating the new Action Points is never reached, because at the end of AIMain.EndAIGuysTurn(), the else branch with the TeamTurns.EndAITurn() is not entered, because there are (normally) soldiers, which weren't processed so far.

Solution: Ending the turn of the militia seems to be not necessary. So I removed the TeamTurns.StartPlayerTeamTurn() from AIMain.EndAIDeadlock(). Now the next soldier is processed after the deadlocked soldier. For the 'Escape Enemy's Turn' Cheat, which uses the deadlock mechanism to abort the enemy turn, I have to add the TeamTurns.StartPlayerTeamTurn() after the corresponding AIMain.EndAIDeadlock() call.

My tests with militia deadlocks worked fine. I haven't had an enemy deadlock so far. And I didn't test the Cheat. The added savegame has often deadlocks (to see the deadlock, you need the debug mode.

Comments (2)

  1. Gennady Trafimenkov repo owner

    Oliver thank you for discovering the bug and suggesting a solution.

    I dug into the change history and found that the bug was caused by incorrect changes in rev 6006534.

    Your solution is good, but it is slightly different from the original behaviour. I think it is better to restore the original behaviour in order to avoid subtle bugs in the future.

    Thanks a lot for discovering the bug and the cause.

  2. Gennady Trafimenkov repo owner

    Fixed issue #57 (Deadlock leads to player turn without reseting the AP)

    This bug was caused by incorrect changes in rev. 6006534

    Thanks to Oliver Jankowski for discoverying the bug and suggesting a solution

    → <<cset 4a152b19727d>>

  3. Log in to comment