* 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).
* 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
* 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
* Try to better reproduce pre-provider ID behavior
If "override all card art with personal preference" setting is set, look
for custom art for all sets instead of just the most preferred set.
* Warning when using both custom art and the printing selector
* QDirIterator::nextFileInfo is Qt 6.3+
* Translation
`refreshTags` is not connecting the signal to open the dialog to edit
the tags, so tags can only be edited once for a given deck.
Fix by only having the logic for creating the "Edit tags" button once
and call it from `connectDeckList`.
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.
C++ does not require compilers to zero-initialize value types, so
depending on the platform (here: Linux), the deck editor starts up with
an uninitialized value in the `modified` flag, which is usually not
zero.
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.
* Close the `TabGame`s when closing the `TabSupervisor`
This ensures that we go through the same code path (in terms of Qt
events) when closing the whole supervisor as when closing a single tab.
Also, use the `close` event instead of the `hide` event to detect when
we are closing a game.
Fixes#5697
* Compat with old Qt versions
* Old Qt, reloaded
* Review: use hideEvent and call super
* 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
Currently, zones must keep track of which cards they move in order to
manually call `updatePath` on arrows.
This patch sets the `ItemSendsScenePositionChanges` flag on
`ArrowTarget`s to automatically update arrow positions without requiring
zones to keep track of that information.
- Remove hardening flags to allow debug builds (otherwise GCC complains
because nix adds the FORTIFY_SOURCE flag, which is not compatible
with -O0)
- Allow ninja as build system
- Add clang-tools dependency for LSP support
* Improve drag & drop behavior
This patch tweaks the drag & drop behavior (in particular, the grid
placement) to be more intuitive. More precisely, with this patch the
drag & drop will:
- Only use the "hot spot" (i.e. position of the cursor on the card)
for zones where the card is actually displayed around the cursor (in
particular, not on the table where the card snaps to the grid).
- Use better boundaries computed with respect to the center of the
card (rather than its top left corner) for determining which grid
cell a card should go to
- Align behavior of the preview and the actual effect when overflow of
the 3-card stacks occurs
- Avoid visual glitches where the cursor ends up outside of the card or
at incorrect offsets when moving the mouse too fast (which translates
to overflows of the hot spot computation)
* Address review comments
- Use simpler computation for restricting hotSpot range
- Prevent dropping cards onto full 3-card slots
* Make cards rounded
Magic cards have rounded corners, and playing cards tend to have rounded
corners as well, but Cockatrice currently displays rectangular cards.
This can cause visual glitches when using image scans where the border
does not extend in the corner, and for this reason Cockatrice always
draws a (rectangular) border around the card to try and make it look a
bit better.
In this patch I take a different approach: rather than try to make
rounded pegs, er, cards, go into a square hole, the hole is now rounded.
More precisely, the AbstractCardItem now has a rounded rectangular shape
(with a corner of 5% of the width of the card, identical to that of
modern M:TG physical cards).
As a side effect, the card drawing gets a bit simplified by getting rid
of transformPainter() when drawing the card outline and using the
QPainter::drawPixmap overloads that takes a target QRectF instead. This
means we no longer have to bother about card rotation when painting
since that's taken care of by the Graphics View framework (which
transformPainter() undoes).
* format
* Also give PileZone rounded corners
* Forgot untap status + bits of CardDragItem
* fix deckviewcard calculations
* Rounded CardInfoPicture
* PictureLoader: Replace downloadedPics cache with QNetworkCache
Currently when the "Download card pictures on the fly" option is
enabled, Cockatrice stores downloaded pictures into a downloadedPics
sub-folder, keyed on set and card name. If a picture is found in that
folder, we never try to download a picture for that card ever again
(until it is reprinted in a more recent set, I guess).
This has the unfortunate consequence that if you change the URLs for
downloading card images, the changes are not applied to cards that
already have their picture downloaded. In particular, if you use
localized card pictures (through !sflang!), you get a mix of cards in
different languages depending on the currently configured language at
the time each card was downloaded.
This patch removes that mechanism in favor of setting a
QNetworkDiskCache on the QNetworkAccessManager used by the PictureLoader
to download pictures. The QNetworkDiskCache caches the picture keyed on
their URL: if the URL changes, a new request will be made. In
particular, if you use picture URLs with !sflang! and change the
language, pictures for the current language will be downloaded even for
cards that already have a picture. The QNetworkDiskCache is configured
with a maximum size of 4GB, which should be enough to hold one
high-quality JPEG for each M:TG card in existence.
Note that this does not affect the existing mechanism for defining
custom card art, either through the CUSTOM directory or the set-based
one. Cockatrice will still read existing cards in the downloadedPics
directory as before, it will just no longer write into that directory
(since pictures are cached by the QNetworkDiskCache instead). To fully
switch to the new cache, users should use the "Delete Downloaded Images"
button in the settings: it will clear the QNetworkDiskCache but also
remove the downloadedPics directory.
* Do not use system cache dir for portable installs
* Add settings for network cache size
* Delete corrupted cache entries
* Use old-style connect() syntax (Qt5 build failure)
* Add setNetworkCacheSizeInMB to test mocks
* setTransferTimeout was added in Qt 5.15
* Improve logging messages
We now have the following messages
- "Trying to download picture from url: URL" before loading a picture
when picture download is enabled
- "Trying to load picture from cache: URL" before loading a picture
when picture download is disabled (i.e. cache-only offline mode)
- "Removing corrupted cache file for url URL and retrying (ERR)" when
when we fail to load a picture from the cache. Usually, this should
be due to the timeout, in which case ERR will be "Operation
Canceled".
- "Download failed for url URL (ERR)" when there was an error
downloading a picture from the network (ERR is the error message)
- "Following redirect to URL" and "Following cached redirect to URL"
when following a redirect (from network/from cache)
- "Image successfully downloaded from URL" and "Image successfully
loaded from cached url at URL" on success
- "Possible cached/downloaded picture at URL could not be loaded" on
ImageReader error
* Clarify that network cache is on disk
Also migrate "Delete Downloaded Image" to a "Clear" button right next to
the network cache size.
* Remove qPrintable
* Move pixmap cache settings to card sources
* qDebug().nospace()
* some formatting on debug messages
* format
* inverted condition
---------
Co-authored-by: ebbit1q <ebbit1q@gmail.com>
* Better support Double-Faced Cards
This patch allows cards to be (virtually) transformed into other cards
while preserving their state, essentially implemeting the MTG mechanic
of the same name.
On the server side, this is implemented by allowing cards to be "stashed
away". A card that is stashed away is not in any zone, but is instead
owned by another card. When a token is destroyed due to a zone change,
if it had a card stashed away, that card is placed in the target zone
instead of the token.
On the database side, `attach="transform"` is used on `<reverse>` and
`<reverse-related>` to indicate that the created token should be
transformed this way.
Old servers ignore the new field in `Command_CreateToken` and will
perform a regular attachment, as currently.
* Address review comments
* Prevent tokens from being stashed
* format.sh
In b282df2e27 (#4728) the logic for
creating <pt> values was updated to avoid adding a final slash after an
existing power value and missing toughness value. This works by setting
the ptSeparator to an empty string when either the power or the
toughness is undefined. However, due to the ptSeparator variable being
scoped out of the `for` loop, this causes all remaining cards to have an
empty string as a separator, ending up with <pt> values of e.g. 21
instead of 2/1.
Moreover, the implementation from #4728 is ambiguous in the case of a
card having a toughness value but no power value: in that situation, it
creates a <pt> entry with the toughness value and no separator, which is
not a good idea since it is not possible to know if <pt>2</pt> means
power 2 and no toughness, or no power and toughness 2 (Cockatrice takes
the first interpretation).
To avoid ambiguities, the <pt> value is now one of:
1. A regular P/T value when the card has power and toughness
2. A simplified P value when the card has power but no toughness
3. A simplified /T value when the card has toughness but no power
4. Absent when the card has neither power nor toughness
Note that, as far as I can tell, Cockatrice seems to (incorrectly, IMO)
ignore the initial slash if present in Player::parsePT, and treat /T as
a power value. However that is a separate issue: this patch is concerned
with Oracle and ensuring proper values in cards.xml, not with how
Cockatrice interprets those values.
Currently Cockatrice allows revealing the whole hand, or one card at
random from the hand. Sometimes, a player needs to reveal a specific
card from their hand instead, which is not supported. To achieve a
similar effect, players usually move the corresponding card (or cards)
to a public zone, then back to their hand. While this works, it is
unsatisfactory (compared to a regular reveal, you can't keep the
"revealed" window around, for one) and somewhat unintuitive.
This patch adds a "Reveal to..." menu to cards and card selections in
the player's hand or in custom zones (this includes looking at the
player's library). This menu allows revealing a card or set of cards to
any given player, or to all players.
To implement this functionality at the protocol level, the existing
RevealCards command is extended to support revealing multiple specific
cards. This is done by making `card_id` a non-packed repeated field in
the `Command_RevealCards` and `Event_RevealCards` protobufs. Using a
non-packed repeated fields allows maintaining backwards compatibility:
an empty optional field is encoded the same way as an empty non-packed
list, an optional field with a value is encoded the same way as a
one-element non-packed list, and when decoding a multi-elements
non-packed list as an optional, only the last item in the list is read.
Since the RevealCards command already exists, and due to the compatible
encodings, a new client connecting to an old server can reveal a single
specific card from their hand. When trying to reveal multiple cards at
once, the old server will only see the request for one of the cards to
be revealed, and the player will have to reveal each card separately.
On the other hand, `Event_RevealedCards` already has an explicit list of
cards revealed by the server, and the `card_id` field is only used when
exactly one card has been revealed: thus, old and new clients will
behave identically when receiving a new `Event_RevealedCards`. In
particular, if a player using a new client reveals multiple cards from
their hand on a new server, another player using an old client will
correctly see all the revealed cards.
The approach used to build the "Reveal to..." menu is slightly different
from the approach used to build other player selection menus. Because
the "Reveal to..." menu is specific to each card, but must also be
updated whenever a player is added to or removed from the game, I chose
to re-create it on the fly whenever a card is clicked, as that seemed
the safest way to avoid both memory leaks and inconsistent state given
my understanding of the code.
* Enable buttons for current game when receiving server response
Previously, upon joining a game, we were unconditionally re-enabling the
"Join" button in the lobby, even if it was not enabled in the first
place, causing #4698. This could also lead to issues where if the user
selects a different game after joining (which they can do in case of
e.g. network connectivity issues), the "Join as spectator" button could
get incorrectly disabled.
This fixes#4698 by re-enabling the buttons based on the state of the
currently selected game at the time the response is received. This also
avoids inconsistencies if a different game has been selected in between
joining and receiving a response from the server.
* Typo: enable gameButton in enableButtons
The "create game" button was incorrectly being disabled in enableButtons
whereas (as the name indicates) it should have been enabled
* Remove misleading comment about race conditions
