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.
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)
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.
These new methods will be used to cache the values of Image keys, as well as to determine whether a card has an alternate image (and so key).
Methods on CardImageKeys have been distinguished in names to not confuse them with similar names (but completely different use and output) from InventoryItems interface.
CardImageKeys for PaperCard are also cached in private attribute to reduce OPS in Card Catalogs that are consistently the same.
As for Tokens, the output of these two new methods is the same as getImageKey.
These methods have been also moved to interface (and so class) as this would result in better encapsulation (esp. hasBackFace - using CardRules within the card - similar to `Card` class).
ImageUtil.getImageKey calls will be replaced with these methods, limiting their use only to downloaders (when set attribute can be added or not). PaperCard will always add the set info).
Pattern.quote has some corner cases on MAC not working (`ME/` ended up in three splits).
Resorted back to `//` as the key will never be a true file path anyway!
THe content of the setFolder is cached, filtering only images and key prefixes.
Working on prefixes only to get rid of all .full or .fullborder possible variations.
The huge improvement is due to a re-use of a getAllCards(Name, Predicate) method I started implementing into another branch for DeckImporter - re-using this method internally resolves a **lot** of duplicated iterations, and checks, which made the whole method to run even faster than the original legacy implementation!
An extra test method has been added to verify the corner case of querying for a card from editions with a very high (and weird) artIndex (like a land) - making sure that exact card is finally returned!
New method in Interface API to get all cards in a given setCode.
This has changed the implementation of getArtCount avoiding to iterate over all the possible card prints.
This optimisation removes redundant queries when looking for cards by specificed Art Preference.
getCardsFromSet has been worked-around, avoiding querying for potential candidates already in memory.
A preliminary benchmark/tests is implemented too.
There was a FIXME/TODO comment I just have found out relating to putCard implementation being inefficient.
I've re-used the new-methods implemented for lazyCardLoading to improve existing implementation.
Also, now all the PaperCard constructors won't miss collectorNumber and ArtistNames as gathered from CardInSet in CardEdition - YAY
Various optimisation to the PaperCard implementation:
- removed once and for all retrieveCollectorNumber method - we're now safe and sound that all PaperCard instances will have a collector Number matched.
- That is also made sure by removing all the many (legacy) class constructors. Only left two - with correct parameter passing!
- finally, collectorNumberSortingKey is created onces, and saved - as this won't change (for better performance)
