Fix bot turn desync - #19
Open
iothingcloud wants to merge 1 commit into
Open
Conversation
Owner
|
I think the fix should be: stop the game and save it as "in progress" and return to the gamemode selection. As is I think it will likely fail over and over and be stuck in an endless loop and the user needs to reboot the esp32 to regain control. remove unrelated checkers changes |
ChessBot::makeBotMove() has three early-return paths (stockfish parse failure, attempt to move wrong-coloured piece, empty source square) that skip applyMove() entirely. The returns result in no move being made and no LEDs shown. update() still subsequently calls updateGameStatus(), which advances the turn unconditionally, regardless of whether a bot move actually happened. If Stockfish ever returns a move that doesn't parse or doesn't match the current board (e.g. after a transient API hiccup), the turn flips to the human player while the physical board stayed untouched, permanently desyncing the game state from the board until manually fixed via FEN edit. makeBotMove() now returns false on every no-op path (with a short backoff timer so repeated failures don't hammer the API). update() only advances the turn when a move was actually applied - the bot's turn simply retries on the next loop pass instead.
iothingcloud
force-pushed
the
fix-bot-turn-desync
branch
from
June 29, 2026 06:58
3b251a6 to
665fe05
Compare
Author
|
sorry, I missed that it was merged in my local repo. no checkers in this version. Also, the reason this triggers quite a bit in my network is because I was at the extremity of WiFi coverage using the ESP32 and i hit about 10 instances of this bug in my games. I also get the periodic "blue LED scan" as it tried to re-connect WiFi. I haven't seen the problem since. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ChessBot::makeBotMove() has three early-return paths (stockfish API parse failure,
attempt to move wrong-coloured piece and empty source square) that skip applyMove() entirely. Subsequently no move is made and no LEDs shown, yet silently update() calls updateGameStatus(), which advances the turn unconditionally regardless of whether a move actually happened.
If Stockfish ever returns a move that doesn't parse or doesn't match the current board (e.g. after a transient API hiccup), the turn would flip while the physical board stayed untouched, permanently desyncing the game state from the board until manually fixed via FEN edit.
makeBotMove() now returns false on every no-op path (with a short backoff so repeated failures don't hammer the API), and update() only advances the turn when a move was actually applied - the bot's turn simply retries on the next loop pass instead.