This subtle bug occurred whenever the algorithm for smart card art selection wanted to add a card with multiple arts and the number of cards per art to add was not even. To avoid zeros, the cardsPerArtIndex was set at least to one, and so the rest - leading then to adding too many (extra) cards not originally present in the deck.
Thanks to @Snoops for the heads up.
If there is any preferredArt, update will never be applied.
The scenario is: if card was originally without any specified edition, AND there is preferred art, that would've been returned in the first place.
Thus, if the smartCardArt optimisation is enabled, any card with the preferred art won't be updated iff edition and artIndex coincide.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
On Mobile Forge Port (only) there is the possibility to set a preferred art for a card, from card catalog.
Once a card art is selected, it will always be returned for that specific art whenever no other specific edition is specified.
This commit adds changes to cardDb setPreferredArtMethod (API) and CardRequest.fromString to work with any preferred art (if any).
CardRequests reflects this change by adding another (private) constructor which expects to create a CardRequest from a preferredArt entry in the form of (CardName|SetCode|ArtIndex)
On Mobile Forge Port (only) there is the possibility to set a preferred art for a card, from card catalog.
Once a card art is selected, it will always be returned for that specific art.
This commit adds changes to cardDb setPreferredArtMethod (API) and CardRequest.fromString to work with any preferred art (if any).
CardRequests reflects this change by adding another (private) constructor which expects to create a CardRequest from a preferredArt entry in the form of (CardName|SetCode|ArtIndex)
Now DeckRecognizer supports all the exports of decks from Deckstats.net.
This now also includes card lists grouped by Rarity, CMC, and Mana Colours.
A new set of tests have been also added to test for the new non-card token types parsing, as well as a condition with multiple constraints imposed on the deck recogniser at a time. In particular, now all the combinations of constraints (also together) have been tested, and therefore the types of token returned has been adjusted.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
This is another extra improvement which avoids setting up card catalog in current editor whenever it is actually **not** needed.
To do so, ItemPool now implements and equal method, which reflects to equality of contained items.
This is because card pool is set up multiple times whenever the Deck Editor tab is initialised - and the operation of setting up the catalog manager is particularly expensive (let alone useless when it's already done!)
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
This commit includes support to the XMage format in Deck Recognizer along with corresponding new tests and updates to labels for UI
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
DeckRecognizer now also support the (special) format for request lines in MTGGoldfish deck exports.
In Addition, changes to reduce comparisons, and general performance in card matching.
The new DeckRecognizer implementation comes fully tested to check the new multiple line request format supported.
The DeckRecognizer has been made very versatile for card recognition - supporting request with multiple formats - as well as for NON-CARD tokens including "Deck Name", "Deck Sections", and "Card (Core) Types".
There is also integration for constraints imposed on card matching due to
restrictions (in set) from Game Format, Deck Format (banned cards), and Date (Release Before).
In those cases, new Token Types will be returned (i.e. "IllegalCard" and "InvalidCard", respectively) that could be pretty-printed or emphasised in DeckImport.
The getCardFromEditions series now include new variants (also for released before/after) accepting an extra filter to be
passed used as an extra filter for returned cards!
Previous implementation did not consider the amount per card included in the pool already - so the filtered pool always got 1 amount for each card passing the filter.
This should be no problem considering where this method is used. However, to make it portable to other cases, I made the implementation to report the same amount of cards in the new filtered pool.
When StatTypeFilter is used withing Deck Editor (with all PaperCard instance in ItemPool), avoiding checking instance class improves performance a bit (saving a couple of hundreds of milliseconds).
However, when this filter with also other inventory items (pack or deck), the same code as before is executed.
