Expanded yield system / auto-pass options

[MostCromulent]

---

Summary

Inspired by recent discussion on the Forge Discord, this PR adds an expanded yield system to reduce click fatigue in multiplayer games and speed up play. Changes are extensively documented in Documentation. Fully backwards compatible with current functionality: the feature is disabled by default and must be explicitly enabled in preferences.

Problem

In multiplayer Magic games (3+ players), the current priority system requires excessive clicking:

• Dozens of priority passes every turn in a 4-player game.
• Players must manually pass priority even when they have no possible actions.
• This creates click fatigue and slows down gameplay significantly (particularly if players are inattentive and don't immediately respond to prompts).

Solution

Expanded yield options that give players more flexibility to control yield timing and conditions. The aim is to help players spend less time responding to unnecessary priority prompts and let them get to their desired phase of action quicker:

Particularly helpful for that one friend who won't pay attention to priority prompts in Commander.

• Yield Options Panel: Dockable panel with extended yield buttons and visual feedback (blue=ready, red=active)
• Six Yield Modes: Next Phase, Before Combat, End Step, End Turn, Your Next Turn, Stack Clears
• Smart Suggestions: Prompts to auto-yield when player cannot respond (no mana, no actions, can't respond to stack). Configurable through checkbox options in game taskbar menu.
• Configurable Interrupts: Automatically cancels yield when attacked, targeted, mass removal cast, etc. Interrupt conditions are highly configurable through checkbox options in game taskbar menu.
• F-Key Hotkeys: F1-F6 for yield modes, ESC to cancel.

Key Design Decisions

• GUI-layer only: No changes to game engine or network protocol (Edit: though see comments below about network implementation to avoid desync).
• Feature-gated: Default OFF, requires explicit enable + restart
• Network independent: Each client manages its own yield state locally
• Backward compatible: Existing Ctrl+E behavior unchanged when feature disabled

Testing

Changes have been tested in local play (thanks to PotionSTAT for testing and feedback). As changes are purely on the GUI layer and do not involve network logic, there is no reason to think testing would not replicate in network use cases. (Edit: see comments about network play below).

---

Code authored by Claude Code (Opus 4.5) under human direction and review.

[MostCromulent]

Testing by PotionSTAT has revealed an issue with network play integration not realised before PR.

YieldController was using gameView.getGame() which returns an unsynchronized dummy object for network clients. Have refactored to use network-safe GameView properties and added StackItemView.getApiType() for mass removal detection. Will also check implications for smart prompts.

[MostCromulent]

Re: Network Code Changes

While the yield system was designed to avoid network protocol changes, in testing discovered that smart suggestions in InputPassPriority had a network compatibility issue requiring new TrackableProperties. This is because the logic was checking the Game object on the server which doesn't exist on network clients.

The solution: Add two TrackableProperties (HasAvailableActions, WillLoseManaAtEndOfPhase) to PlayerView. These piggyback on existing GameView serialization—no protocol changes required. The host calculates these values and they're automatically included when GameView is sent to clients.

The yield system remains client-local; this ensures the data for yield suggestions is synchronized, while yield decisions stay independent per client.

The alternative to making these network changes would have been implementing a more basic heuristic for the yield prompts which would have been a worse and experience for the player.

Edit: Claude AI's explanation for why server needs to know client yield mode state

The server needs to track the client's yield mode to detect end conditions because the client doesn't have access to the same context as the server, which has the authoritative game state and can reliably detect when yield end conditions are met across all players.

When client activates a yield mode it uses notifyYieldModeChanged to notify the server. The server then monitors game state and checks yield end conditions in YieldController.java. When end condition is met the server calls clearYieldMode() which triggers syncYieldModeToClient() to notify the client.

Both server and client stay in sync about yield state. If only the client tracked it, multiplayer edge cases could cause the client to yield too long or not long enough.

[tool4ever]

I still need to investigate this, seems rather hacky

• but if it's needed it should reuse lookupPlayerViewById

[MostCromulent]

I'll address the duplicate function issue now, and can come back to this if you find a better approach.