Foil / non foil card variants and price

[NikolayXHD]

Mtgjson.com data provides foil / nonfoil card price and hasFoil, hasNonFoil fields in Card structure

[AaronLS]

Have you been working on this? I've been thinking about tackling this in two phases.

Phase 1) Update the data structure to support foils, but rollup card variants to a Sum so that other code doesn't have to handle yet. Preserving that information in the data model so it is captured as users import.

Change things like DeckZone.Count which is a Dictionary<string,int> to a Dictionary<string,CardInventory[]>

class CardInventory { int Count, CardVariant CardVariant }, where CardVariant is an enum for Normal/Foil. So a card of a given ID will have up to two CardInventory items in the subarray, each with a count.

For now, anywhere that uses the .Value int of the current dictionary will need to be changed to .Sum(ci=>ci.Count) to sum the varients for a given card ID.

This means the data structure can now record foils, and import routines can start to iteratively be updated to take advantage of that.

We'll have to handle opening collection/deck files of the old format, and default all counts to Nonfoil. I'm thinking add a FileFormatVersion field, and we can deserilize a single property class with only this field first when opening a file, and if it's null, we know it's old format, if it's not-null we know it's new format, and further can leverage in future for additional changes.

These changes will not be apparent in the UI, and the varients will "roll up". But we'll no longer be "losing" this info when people import.

Phase 2) Decide how to expose through UI. Start changing code to distinguish between the variants and expose in the UI.

Thoughts on CardVariant enum: IDK if it'd be better to use a string like "Normal"/"Foil". This might provide some flexibility for additional variations in the future with minimum or no coding. I.e. if a import routine could be updated to handle a new variant, and maybe the UI would just show a text annotation/tag for that variant so that new variants can be handled by only requiring updates to the import routines. At least preserving that information even if we don't do anything graphically with that information, so that there's not an urgency to "catchup" to new variants. I.e. I don't if something like an Etched Foils might come along that doesn't have a distinct card ID. Maybe I'm overthinking it.

How are cards of multiple languages handled? Do they have distinct IDs or do they currently roll up similar to foils? I.e. I'm thinking are there other types of variants aside from Foils that are not currently preserved in the data model.

[NikolayXHD]

Hi @AaronLS. After some conderation, which I will get into details below, I estimated the foil / non-foil distinction as a rather big and challenging undertaking, which I did't dare to take at that time.

First, the data structures not properly designed to work as inventory manager. So there is this phase1 question of how to properly modify them.

Now what scares me, is UI design & implementation phase2. Why?

In my opinion, after doing phase1 we may easily find ourselves in a position, where phase2 turns out requiring way more effort than imagined, to a point where it is prohibitive.

The UI is built from the most basic .NET controls, because all advanced controls do not support choosing arbitrary colors, so they are not compatible with dark color scheme.

Buttons, menus, tabs, scrolls are all made by hand from scratch specifically for this application. They also need to work reasonably well under Linux. So, whatever UI we come up with, will almost certainly require significant low-level effort with user controls.

Specifically, suppose we add a little menu over the card picture, which opens a little table where user specifies a mapping like

nonfoil: 1
foil weared: 2
foil: 1 

Even this little piece of UI requires something not easily available - a multiline grid UI or a functional equivalent.

Who in their right mind will spend like a week or two of their time (or is it a month or two?) for free, to build a homemade grid user control, using obsolete .NET WinForms technology, supporting arbitrary colors for Backround and Font, and also working well under Linux. And all this just for one specific little app with a couple thousand users.

I had the same problem when planning & implementing DeckList, so that user could search the decks bases on cards it owns.
Luckly then, I was able to (actually my wife was able to) come up with a UI that does the trick using only singular text inputs and buttons, no fancy user interaction.

If we can do the same for card properties tracking (foil / non foil, good condition / weared and so on), then it can have the bright future 🙂

Because I don't develop Mtgdb.Gui much anymore, I will only be able to provide moderate help, mostly consulting, reviewing, and testing. The bulk of development work falls on the shoulder of brave volunteers 😎

[NikolayXHD]

Thinking on possible UI. Is it enough to have a multinline text input, where user types the properties

# input detailed inventory stats for owned card_name copies
# here comes a comment with an extensive explanation of what user can type
foil:
  new: 1
  weared: 2
non-foil: 1

behind the scenes it is stored in an inventory file like

unreadablecardid:
  # couple of fileds for human-readability
  name: Plains
  set: ISD
  number: 31a
  inventory: # actual data
    foil: 1
    # ...
anothercardsunreadbleid:
  # ...

what attracts me, is that even bad UI can be compensated by user creatively using a text editor to do whatever they want with inventory data, because it is 1 file, it is humen readable, it has standard yaml syntax so any decent text editor will provide syntax coloring, possibliy even intellisence if yaml schema is somehow provided.

Or maybe a .csv instead of .yaml, so that it is more readily available to data exploration like filtering, pivot table aggregates and so on.

With advanced user interaction outsourced to an external text or spreadsheet editor, whe can do whatever fancy things we like in regards to displaying existing inventory data over the cards.

If only there was a standard way to open a text editor on a particular line within text file, we could rely on external editing enirely.

Like user clicks on a card to input inventory data, and the external editor opens the file and scrolls to a proper location.