Fix lobby start crash for auto-generated deck variants#10643
Open
MostCromulent wants to merge 1 commit intoCard-Forge:masterfrom
Open
Fix lobby start crash for auto-generated deck variants#10643MostCromulent wants to merge 1 commit intoCard-Forge:masterfrom
MostCromulent wants to merge 1 commit intoCard-Forge:masterfrom
Conversation
GameLobby.startGame rejected slots with a null deck and then crashed in RegisteredPlayer's constructor when the deck arrived as null anyway, even though MoJhoSto and MomirBasic generate decks themselves and intentionally hide the deck chooser. The desktop lobby's setReady had a hardcoded bypass that named both variants explicitly, but the mobile lobby and the start path itself had no equivalent. Add GameLobby.hasAutoGeneratedVariant() and route all three call sites through it, so any future auto-generated variant is covered without further edits. In startGame, detect the auto-gen variant before the slot validation loop and generate the deck before constructing the RegisteredPlayer — which removes the need for a placeholder deck and drops the now-redundant section-by-section copy block. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Closes #10642.
Summary
GameLobby.startGamerejected null decks before the auto-generation logic could run, andRegisteredPlayer's constructor would NPE on the null deck if the rejection were bypassed. MobileLobbyScreen.setReadyandGameLobby.startGameitself had no equivalent of the desktop's bypass.This change adds
GameLobby.hasAutoGeneratedVariant()and routes all three call sites through it. InstartGame, the auto-gen variant is detected before slot validation and the deck is generated before constructingRegisteredPlayer, so no null ever reaches the constructor.Why this differs from the fix sketched in the issue
The issue's proposal passes a placeholder
new Deck("auto-generated")toRegisteredPlayerto dodge the NPE. That works but hands throwaway data to a constructor that immediately copies it. The auto-gen variant lambdas inGameTypealready ignore theirRegisteredPlayerargument, so generating the deck first and constructing the player with the real deck removes the placeholder entirely, lets a small section-by-section copy block that was reshapingautoDeckfor no reason go away, and lets the desktop lobby's hardcodedvntMomirBasic && vntMoJhoStocheck be replaced with the same helper — the issue's approach left that brittle parallel rule in place, where a future auto-gen variant would silently regress.🤖 Generated with Claude Code