* 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>
* 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).
* add new fields to proto
* update token dlg
* send facedown in command
* update server to get it to work
* disable certain edits when face down
* update client event processing
* log face-down token creation
* Don't support colors on face-down tokens
The other client doesn't know about the color, so it causes a desync
* Update wording
Co-authored-by: Basile Clement <Elarnon@users.noreply.github.com>
* Allow annotations on face-down tokens
---------
Co-authored-by: Basile Clement <Elarnon@users.noreply.github.com>
* 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
* Saner and more performant color filtering.
* Update visual_database_display_color_filter_widget.cpp
---------
Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
Co-authored-by: Zach H <zahalpern+github@gmail.com>
* update hnadling of keywords: AND, OR, NOT in card search
* added and
* update test
* update test
* update OR to not be [oO][rR] and just look for OR
* keyword testing
* adjusted new test
* implement test case for cards with keyword in name
* implement test case to cards with keyword in name
* format
* update test case
* change test cas
* update truth test case
* changed test card search from real cards to fake and added cards
* Update tests/carddatabase/data/cards.xml
Co-authored-by: RickyRister <42636155+RickyRister@users.noreply.github.com>
* Update tests/carddatabase/filter_string_test.cpp
Co-authored-by: RickyRister <42636155+RickyRister@users.noreply.github.com>
* Update tests/carddatabase/filter_string_test.cpp
Co-authored-by: RickyRister <42636155+RickyRister@users.noreply.github.com>
* update formatting
* update cardatabase_test to include +2 cards
* update test case +1 set + 1 type
---------
Co-authored-by: RickyRister <42636155+RickyRister@users.noreply.github.com>
* fix: Use isRebalanced to detect Arena cards
In #5759 we introduced a setting (off by default) to disable the use of
Arena cards. This was done by checking the `isOnlineOnly` property of
the card, which accidentally also disabled online *printings* of cards
that otherwise exist in paper (e.g. Vintage Masters).
This PR does the same thing but uses the `isRebalanced` property
instead, which is `true` for Arena cards only and should have been used
from the start. This setting does not impact online-only printings such
as Vintage Masters. The settings is still on by default.
* Update setting to mention Alchemy rather than Arena
The divideCardSpaceInZone function introduced in #4930 is buggy and
sometimes returns an index that is too large for the current zone, which
causes us to call `cards.at(index)` with an `index` that's bigger than
the amount of cards.
This is the bug that #5609 intended to fix but was improperly diagnosed.
Remove part of #5609 as the cases it is guarding against (e.g. null card
pointer) cannot actually happen.
This is part of the code from #4974, including an improved drag-and-drop
API and its use to display visual feedback of card destination on the
board.
It does not include the improved logic for pushing cards around as I
still need to figure out edge cases there - the logic for choosing where
cards go is not changed, so some of the artifacts described in #4817
and #4975 (particularly around multi-card) are still present.
* Use enum for ThemeManager brushes
This patch introduces an enum to distinguish the different brushes that
can be set by the theme (hand, stack, etc.) and generic functions taking
the enum rather than having one copy of each function for each brush.
This is preliminary work before merging StackZone and HandZone to
simplify #4974.
* Include <array> header
* Header spacing
