Skip to content

Bind docked zones to live PlayerView to fix stale cards on new match#11192

Merged
tool4ever merged 2 commits into
Card-Forge:masterfrom
MostCromulent:docked-zone-stale-cards
Jul 10, 2026
Merged

Bind docked zones to live PlayerView to fix stale cards on new match#11192
tool4ever merged 2 commits into
Card-Forge:masterfrom
MostCromulent:docked-zone-stale-cards

Conversation

@MostCromulent

Copy link
Copy Markdown
Contributor

Closes #11111.

Summary

Fixes docked zone tabs (e.g. "Playable Zone Cards") showing the previous game's cards after "Start New Match".

Bug report

With a zone view docked as a tab (rather than floating), starting a new match left the previous game's cards in the tab. They never cleared — persisting through the whole new game, even after drawing and playing. Floating zone windows were unaffected.

Root cause

At each game start, CMatchUI.updatePlayerControl rebuilds the docked tabs via FloatingZone.registerZoneDocs, binding each VZone to a PlayerView from getLocalPlayers() (the gameControllers key set). On restart the desktop reuses the same CMatchUI without resetting controller state (only mobile calls resetForNewMatch), and the new game installs fresh PlayerView instances. Because TrackableObject equality is by id, re-registering the local player leaves the HashMap's original stale key in place — so getLocalPlayers() returns an orphaned PlayerView from the prior game that never receives updates. Floating windows dodge this by being rebuilt lazily on click against the live view.

Fix

Source the local players from the live game view (getGameView().getPlayers() filtered by isLocalPlayer) instead of getLocalPlayers(), so docked zones bind to the live PlayerView and refresh correctly.

Alternative considered

Resetting the reused controller state each game (mirroring mobile's resetForNewMatch) would fix the root cause more broadly. It was not taken here because it lives in shared lifecycle code (AbstractGuiGame/HostedMatch) exercised by desktop, mobile, network host, and client — a much larger blast radius. This PR takes the lower-risk desktop-scoped fix.


🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@MostCromulent MostCromulent requested a review from tool4ever July 9, 2026 22:36
@MostCromulent MostCromulent added BUG Something isn't working GUI Desktop labels Jul 9, 2026
Comment thread forge-gui-desktop/src/main/java/forge/screens/match/CMatchUI.java Outdated
Root-cause fix for docked zone tabs showing the previous game's cards after
"Start New Match".

getLocalPlayers() returns gameControllers.keySet(), keyed by PlayerView
(equality is by id). Desktop reuses the GUI across matches without clearing
the map, so when setOriginalGameController re-registers the new game's live
PlayerView, HashMap.put keeps the id-equal old key and only swaps the value --
keySet() then hands back the prior game's orphaned view, which never updates.
registerZoneDocs binds docked zones to that stale view.

Removing the id-equal entry before re-putting makes the live instance the key,
so getLocalPlayers() returns live views for every consumer. Only the key
changes; the value and all id-based lookups are untouched, so existing callers
behave identically. Reverts the desktop-scoped registerZoneDocs workaround.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@MostCromulent MostCromulent force-pushed the docked-zone-stale-cards branch from 48cf2df to 7f15a52 Compare July 10, 2026 10:25
@tool4ever tool4ever merged commit 1eec014 into Card-Forge:master Jul 10, 2026
2 checks passed
@MostCromulent MostCromulent deleted the docked-zone-stale-cards branch July 10, 2026 21:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

BUG Something isn't working Desktop GUI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

When "Start New Match" is selected, information from the previous game is carried over.

2 participants