Route opponent-hand reveal and discard through FloatingZone on desktop

[MostCromulent]

USING MIND WARP, X=2

BEFORE:
Reveal step

Select step

AFTER:
Reveal step

Select step

---

Summary

Per #10646 (comment): RevealYouChoose / LookYouChoose discards (Inquisition, Mind Warp, etc.) currently surface as a names-list reveal dialog followed by a separate selection grid, when the opponent's hand could be the selection UI directly.

This routes both steps through the existing FloatingZone: reveal opens the hand face-up with a minimal OK acknowledgement; the pick uses InputSelectCardsFromList so legal targets are clicked in that same FloatingZone.

Implementation

• PlayerControllerHuman.reveal() — desktop opponent-hand reveals swap getGui().reveal() (names list) for tempShowZones + getGui().message() (visual hand + minimal OK).
• PlayerControllerHuman.chooseCardsToDiscardFrom() — opponent-discard pick routes through InputSelectCardsFromList; tempShows the full hand for Reveal*/Look* modes without RevealNumber so revealed non-selectable cards stay visible. RevealNumber spells (Blackmail, Cabal Interrogator) keep the conservative tempShow-of-valid path so unrevealed cards stay face-down.
• CMatchUI.hideZones() — fix a pre-existing asymmetry: tempShowZones special-cases ZoneType.Hand, but hideZones only checked FLOATING_ZONE_TYPES (which omits Hand). The FloatingZone opens for an opponent's hand but never closed programmatically.

Safety

Both PCH changes gate on UI_SELECT_FROM_CARD_DISPLAYS && !getGui().isLibgdxPort() — the same condition useSelectCardsInput already uses. Mobile and preference-off paths are unchanged. isLibgdxPort() is the per-GUI network-safe check from #10615. No engine, protocol, or TrackableProperty changes.

RevealNumber partial-reveal spells (e.g. Blackmail revealing 3 of 5) are rendered safely: FloatingZone.getCards() returns all hand cards, but each is drawn according to the existing mayView check — only mayLookTemp-flagged cards (the revealed subset) show their faces, the rest render as card backs. Non-revealed cards' identities stay hidden; only hand size is conveyed, which is already public info.

Potential code cleanup (not in this PR)

FPref.UI_SELECT_FROM_CARD_DISPLAYS was added in 2019 (commit 09fc3ae60c2) alongside the original arrangeForScry GUI introduction, which brought in-zone selection as a new UX. The preference has defaulted to true with no user-facing UI toggle ever since — effectively the active desktop UI path for 7+ years.

The preference gates whether InputSelect extends beyond the local player's own hand and battlefield to other zones (opponent-hand FloatingZone, libraries, graveyards, etc.) — i.e. click a card in its zone display versus fall back to a names-list dialog. All three desktop call sites in PlayerControllerHuman pair it with !getGui().isLibgdxPort().

A separate cleanup PR could drop the FPref entry, simplify the three dual-gate sites to single !isLibgdxPort() checks, and collapse the now-dead fallback branches in useSelectCardsInput (the zone-set ternary) and arrangeForScry (the manual-order path).

---

🤖 Generated with Claude Code

[MostCromulent]

Let me know if you want the FPref.UI_SELECT_FROM_CARD_DISPLAYS code cleanup suggested above as part of this PR.

[tool4ever]

I think in general this seems better:

• now leverages the advantage of being able to inspect the boardstate, helping you make tough decisions
• the used dialog had incorrect implications about the order mattering (while rare it sometimes does but that decision is done afterwards by the owner!)

the only minor downside remaining is no longer being able to use the keyboard to progress:

• though arguably that was a rather fiddly process, I doubt many users were doing that over mouse unless they had a very good reason (technical/physical)...?
• but I think we could do much better and turn it into a real speed-up for everyone across multiple use cases 🧠

what if we (temporarily) assign the number keys to the first 9 selectables? might have to draw small labels on them for clearity or something - maybe based on Ctrl press 🤔
want to give that a shot? 🥳

(there's actually one place in CMatchUi that uses VK_* similarly already but for abilities)

[MostCromulent]

what if we (temporarily) assign the number keys to the first 9 selectables? might have to draw small labels on them for clearity or something - maybe based on Ctrl press 🤔
want to give that a shot? 🥳

yeah I'll try that out - might also look at how seamlessly we could integrate a search filter at the top as well, since we also lose that compared being able to start typing in the previous list view

[MostCromulent]

Should work for any card-select prompt that uses FloatingZone - opponent hand, graveyard, exile, library etc.

Does not apply for cases which don't use FloatingZone - own hand, battlefield, players, ephemeral non-zone cards (though as follow up I'm going to explore what we could do about the ephemerals; plausibly could generate a temp FloatingZone window containing the ephemeral cards to take advantage of same UX).

[tool4ever]

Let me know if you want the FPref.UI_SELECT_FROM_CARD_DISPLAYS code cleanup suggested above as part of this PR.

hmn I'm undecided if users might prefer having the preference actually GUI-exposed now that this PR increases its usage 🤔
let's wait a bit and see if we'll get some reactions after merging on Discord?

[Jetz72]

If the revealed zone is prompting the user to choose something (e.g. some number of cards to discard), maybe the prompt might replace the usual title text? Or does it already seem visible enough in the usual prompt space?

[MostCromulent]

If the revealed zone is prompting the user to choose something (e.g. some number of cards to discard), maybe the prompt might replace the usual title text? Or does it already seem visible enough in the usual prompt space?

Yeah I think this is worthwhile, otherwise its not immediately obvious what you're expected to do in window unless you cross reference with the prompt.

[MostCromulent]

Potential follow-up:

Forge currently processes a discard effect as two separate actions: reveal stage shows window with revealed cards, user clicks ok, then it repaints window for discard stage. I don't think there's any reason from a rules perspective why that two stage process is necessary? If the discard stage is able to display the revealed cards at same time (which it now does in this PR) this can potentially be consolidated into one action (at least on desktop). Would need to consider mobile UI.

[tool4ever]

yea some API even call tempShowCards on their own
and there is also DelayedReveal which offers a more dedicated mechanism for this?

In general there should be substantial cleanup potential for redundant or almost useless code in these PlayerController methods, just need to carefully consider what each effect attempts to do...

and ideally some more Javadoc to explain less obvious concepts