Repository navigation
bugfix(recorder): Prevent mismatch in replay playback by restoring slot setup before replay creation - #3200
Conversation
09a85e2 to
d2b9896
Compare
Walkthrough
ChangesSkirmish setup handling
Priority: Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested labels: Suggested reviewers: Merge Risk:
|
d2b9896 to
70b8ea6
Compare
… to a separate function.
…rting a new replay.
There was a problem hiding this comment.
Actionable comments posted: 1

Review info
-
Run configuration-
- Source mode: Auto
- Repository: Unavailable
- Branch: Unavailable
- File: No configuration file from this repository applied
- Commit: Unavailable
- Layers: Organization UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
6f7d5887-40b1-4ab3-8bac-0cf610230070
Files selected for processing: 4-
Core/GameEngine/Include/GameNetwork/GameInfo.hCore/GameEngine/Source/GameNetwork/GameInfo.cppGeneralsMD/Code/GameEngine/Source/Common/Recorder.cppGeneralsMD/Code/GameEngine/Source/GameLogic/System/GameLogic.cpp
Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.
-
| if (slot->hasSavedOriginalSetup()) | ||
| { | ||
| DEBUG_ASSERTCRASH(m_gameMode == GAME_SKIRMISH, ("Expected GAME_SKIRMISH but got %s", toString(m_gameMode))); | ||
| TheSkirmishGameInfo->handleOriginalSetups(); |
There was a problem hiding this comment.
Restore setups before checking duplicate colors.
If a saved Skirmish.ini slot list contains duplicate colors, the parser accepts it and the skirmish menu loads it. (raw.githubusercontent.com) The recorder saves those colors as originals. This call then restores them after checkForDuplicateColors clears one. Playback clears the duplicate without restoring it, so the game and replay use different colors and random draws.
Move this call before checkForDuplicateColors so both paths normalize the same setup.
[Medium impact] The changes affect skirmish setup and replay playback. The replay fix appears safe to merge, with a non-blocking display regression for network games and replay playback. Findings
|
| if (!loadingSaveGame && m_gameMode == GAME_SKIRMISH) | ||
| { | ||
| GameSlot *slot = TheGameInfo->getSlot(i); | ||
| if (!loadingSaveGame) { | ||
| if (slot->hasSavedOriginalSetup()) | ||
| { | ||
| DEBUG_ASSERTCRASH(m_gameMode == GAME_SKIRMISH, ("Expected GAME_SKIRMISH but got %s", toString(m_gameMode))); | ||
| TheSkirmishGameInfo->handleOriginalSetups(); |
There was a problem hiding this comment.
Opponent choices appear random
The new GAME_SKIRMISH guard also removes saveOriginalSetup() for network games and replay playback. Those slots keep their original fields at -1, so the loading screen and diplomacy panel show opponents as random even when they picked a fixed color and faction. Keep saving the original setup for every active slot; restrict only restoration to skirmish games.
#2373 broke replays of restarted skirmish games again, making them mismatch 100% of the time. This PR fixes that.
The issue is that restoring the original slot data (color, position and faction) in
GameLogic::tryStartNewGamehappens too late because theRecorderClassupdate runs first. So for restarted games, a new replay is created with incorrect data. That's why I refactored the code, extracted it to a separate function and call it from both places.Calling
handleOriginalSetupsfromGameLogic::tryStartNewGameis strictly unnecessary now, but I kept the call there because it shouldn't need to rely on the code inRecorderClassto handle the player setups.TODO: