Skip to content

fix(endgame): "Continue in Singleplayer" resumes the run instead of starting a new one - #503

Open
ChronoFinale wants to merge 1 commit into
Balatro-Multiplayer:mqttfrom
ChronoFinale:pr/continue-singleplayer
Open

fix(endgame): "Continue in Singleplayer" resumes the run instead of starting a new one#503
ChronoFinale wants to merge 1 commit into
Balatro-Multiplayer:mqttfrom
ChronoFinale:pr/continue-singleplayer

Conversation

@ChronoFinale

Copy link
Copy Markdown
Contributor

"Continue in Singleplayer" read the save off disk immediately after an async save_run() (usually nil, since the write hadn't landed), so it started a brand-new run instead of resuming. Resume from the actual run state instead.

Rebased clean onto current mqtt. Test: luajit tests/test_continue_singleplayer.lua — green.

Closes #484

Continuing in singleplayer from the end-of-match screen silently started
a brand-new run instead of resuming the match. save_run() only
synchronously populates G.ARGS.save_run; the actual save.jkr write is
dispatched to the async SAVE_MANAGER worker thread. The handler read
save.jkr back off disk immediately after calling save_run(), racing that
write -- and since G.F_NO_SAVING is true for an entire MP match, there
was no prior save on disk to fall back on either, so the read reliably
came back nil and G:start_run began a fresh run.

Capture the in-memory G.ARGS.save_run snapshot (deep-copied before
G:delete_run() can mutate the live G.GAME table it still references)
and hand it straight to G:start_run, skipping the disk round trip.
Extract the "what do we do with the captured snapshot" branch into a
pure MP.UTILS.decide_continue_singleplayer so it's unit-testable
without disk or event-queue stubbing, and add a nil-snapshot guard that
aborts with a logged error instead of silently starting a fresh run.
@ChronoFinale
ChronoFinale marked this pull request as ready for review July 23, 2026 23:23
@ChronoFinale

Copy link
Copy Markdown
Contributor Author

Follow-up from in-game testing: with the resume fix in, there's a remaining gap on the loss path — when you lose the continued singleplayer run, it just drops you back into the same blind again instead of ending/handling the loss.

This ties directly to the open expected-state question in #484 (what "Continue in Singleplayer" should do regardless of win/lose, and where it should resume). Until that behavior is decided, the loss case currently loops the same blind — flagging so the expected-state call in #484 explicitly covers the loss path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant