This commit includes a substantial change//integration into main body of DeckRecognizer API.
First off, the types of tokens emitted by recognised as now increased, leaving place to newly specialised WARNING messages, as well as tokens for cards in invalid set or sections. Moreover, a new token for UNSUPPORTED_DECK_SECTION has been introduced, which works in pair with the new extra addition of allowed Deck sections.
This new list of allowed sections is also used whenever a new DeckSection token is created (constructor) so that if the section is not currently supported, an UNSUPPORTED_DECK_SECTION token is emitted instead.
Similarly, the card recognition step has been updated so that now deck validation mechanism has been integrated at the token level. In other words, everytime each card token is now matched to the most correct section, regardless of what's been specified in card list.
Last but not least, DeckRecognizer now includes the method to parse the whole card list (and not just a single line) to better encapsulate all the logics.
Added control to include Banned and Restricted cards, as well as a newly regExp to specify Mana colour tokens using MANA symbols placeholders (e.g. {G} for green).
Tests for new features have been added and internal documentation improved, and old ones updated with new tokens and APIs.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
Previous implementation was lacking to check for commander section, plus re-used the code of validators. This one is a refined and refactored implementation.
Note: as default, the method will always return Main, as there is no possibility, in general, to say whether Sideboard should be preferred instead - without any other knowledge about the deck.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
All card tokens (those having an instance of PaperCard set) now share the same message with no code duplication.
The message has been also update - and so corresponding tests - to include set code in square brackets, and collector number (identified by sharp symbol).
This change will also simplify token formatting in Deck import.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
TokenType instantiated by the DeckRecognizer have been further specialised and extended to also include Banned and Restricted Cards.
Therefore, controls when recognising cards has also been extended and improved.
Now DeckRecognizer include specific extensions for additional constraints imposed by Game Format, Deck Format, release date and art preference. Consequently, all methods used to retrieve cards from CardDb have been updated accordingly, using recognizer settings.
Test suite has been updated accordingly - and all tests re-organised with comments for better code navigation.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
A new CardEdition.Predicates has been added to return the CardEdition with all basic lands according to current default Card Art Preference.
This predicate will be used in DeckProxy to getDefaultSet whenever None is specified.
Moreover, quick fix to javadoc and made "isCustomEditions" final.
Fixing NPE occurring when gathering statistics on Card Edition in CardPool and the Edition does not exist.
This patch simply discards any stats about not-found card editions
Added tests for new setting w/ CardArtPreference and FIX bug on foil request when no edition is specified.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
The API now includes three new methods to proxy card requests to any available database of cards. These methods are currently used by the DeckRecognizer to match any card request from the Deck Importer - so the API adapts to those particular use cases.
However, method signatures are general enough to be further used elsewhere in forge, if necessary.
The first immediate advantage here is that with this addition, Deck Import automagically extends support to also including custom cards.
Moreover, this avoids DeckRecognizer to have lower-level references to CardDb - therefore, better encapsulation so that any DB interaction is correctly proxied by StaticData.
Signed-off-by: leriomaggio <valeriomaggio@gmail.com>
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>
