* feat: Configurable colors for card counter
This patch adds support for:
- User-defined colors for card counters;
- 3 additional types of card counters.
The colors used for counters is stored locally and not shared with other
users. This is intentional as the feature is likely to be used for
improved accessibility.
In order to preserve backwards-compatibility, and because I don't have a
better idea, counters keep their existing color-based names (Red, Green,
Yellow) in menus and in the message log. For consistency, the new
counters also get assigned color-based names (Cyan, Purple, Magenta).
This choice is a compromise, as allowing user-defined names for counters
raises many additional (UI/UX) questions that I don't know how to
answer. A good long-term solution would be to include counter names as
part of a game definition system and hence would be in scope for #1740.
The choice of adding 3 additional types of counters and the Cyan, Purple
and Magenta names are not random. The existing code for determining
counter colors goes: Red, Green, Yellow, Cyan, Purple, Magenta, Black
(unreadable) and thus 6 is the maximum number of counters that existing
versions of Cockatrice are able to support. This way, released clients
get a degraded experience (cannot interact with the new counters,
messages in the server log say "Player X places 1 on Card (now 1)"
without specifying 1 of what), but do see the counters properly.
Fixes#2020
* Do not use %n
* Use SettingsManager
* Use qSin instead of sin
Fix build failures with old GCC.
* Use letters for card counter names
* Place card counter actions in separate menu
* Remove copy-paste error
* include QtMath
* Do not color whole settings page
* derp
---------
Co-authored-by: Zach H <zahalpern+github@gmail.com>
* Parallelize picture loader.
* Queue requests instead.
* Include a status bar for the picture loader.
* Save redirect cache on destruction.
* Address comments.
* Let's not overwrite an ambigious variable name.
* Lint.
* Oracle needs the status bar too.
* We actually get a free request if we hit a cached image.
* Fix cmake list.
* toString() the url.
---------
Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
* Add a group criteria to the deck list model and a combo box to the deck dock widget to change it.
---------
Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
Although this config is not built on CI, while trying to compile locally, the build failed due to warnings and -Werror.
Some qt functions were actually deprecated (but not removed) before version 6.0.0 and clang (righfully) complains about comparison between different types of enums.
* Remove `isView` flag from CardZone
This flag is used for two purposes:
1. It is used as a check for casting to a zone to a `ZoneViewZone`;
2. Non-view zones are added to the player's zones on construction
This patch removes the `isView` flag and instead:
1. We directly cast zones to `ZoneViewZone` using a dynamic (qobject)
cast and use the result of the cast instead of the `isView` flag to
detect if we are a view zone or not;
2. The player records its own zones when they are created, simplifying
control flow.
* Review
* client: Support arbitrary game zones
Currently, the client ignores cards in unknown zones, as there is an
implicit assumption that the set of zones known by the server and the
client are the same.
This patch makes it so that the client accept "custom zones" from the
server (zones outside the builtin deck, graveyard, exile, sideboard,
table, stack and hand zones) using the information from the
ServerInfo_CardZone. Moving cards from/into these zones happens
through a "View custom zone" action in the Game > Player menu and
properly appears in the chat.
Note that this patch intentionally does not introduce any support for
having the server actually create such zones. Instead, this patch aims
to improve backwards compatibility for when we do get to adding this
capability in the future, by making sure that current clients will be
able to interact with future new zones (even if suboptimally).
