Search options (Page 5 of 18)

The important distinction, though, is that it's bad data only within that user's account, rather than within the whole database, and a given user's bad data only affects other users when it comes to trades. As of now, I could go set the foil flag on all my Beta cards, and that will affect exactly zero people, until I try to list them for trade. I would rather tolerate bad data on the per-user level than introduce it on the card database level.

I think you've hit on the key here. The flag system IS a great system, but it has this one glaring deficiency.

If Sebi were to utilize MTGjson as ic0n67 suggests, or implement the data himself as Joe suggests, then it would be a simple database query when populating the flag dropdown to check what foil treatments a card does or does not exist in.

@Sebi — I've refrained from commenting until now, as I've already said a great deal on this topic. But I think I've figured out the solution.

The issue comes down to a conflict of short-term vs long-term needs: In the short-term, the community needs something ASAP so that they can start entering their etched cards into their inventories. In the long-term, Deckbox needs a sustainable, elegant solution, and almost all of us, including you, have agreed that a flag-based solution is just that (with only a few users voicing opposition, like psrex above, although his concerns with an etched flag can and should be dealt with in other ways). Unfortunately, the two needs do not jive, because meeting the long-term need will not allow for meeting the short-term need (due to development time).

The solution to this conflict? A planned migration:

STEP 1: Implement a temp system to meet the short-term need — Import the cards to the database however seems best in the short term (additional editions, different card names, custom collector numbers). Just ensure that there'll be a one-to-one relationship between an etched card in this temp system and an etched card in the final system.

STEP 2: Develop the long-term solution — Spend the time you need in updating your code in the background. I understand that it'll entail weeks of work, but it does seem like this will be a worthwhile time investment in the long run. In fact, take the opportunity to completely overhaul the pricing code, so that it's as modular and extensible as possible, to account for potential future weirdness from WotC (which is pretty much guaranteed, am I right???).

STEP 3: Release and migrate — In conjunction with releasing the updated pricing and flag engines, announce some planned downtime. During that downtime, run a script on the database that migrates everybody's inventories to the new system. It would see, e.g., Profane Tutor #401 from Modern Horizons 2 ETCHED and convert it to Profane Tutor #401 from Modern Horizons 2 with the etched flag set. Upon completion, delete the erroneous editions.

STEP 3a: Handle CSV imports — The only wrinkle in the above would be people like me who regularly export their inventory to CSV, then who might try to re-import after the migration, causing a long list of errors. You have two options: Leave it to the end-user to fix the "non-existing edition" errors, or create custom code to fix it for them. The only reason the latter might not be preferable is if it would cause a major performance bottleneck to the CSV import. But if you do a quick check for the existence of the erroneous editions within the CSV first, and only run the custom code if it returns true, the performance slowdown would only affect these few edge case users.

In summary — Don't compromise on the correct long-term solution out of short-term convenience or expedience. Instead, give us users a temporary way to handle our etched inventories, then gracefully migrate us over to the long-term solution once it's fully ready.

So I did some research, and this has to do with how specifically Excel on Windows interprets and displays UTF-8 encoded files. In short, it doesn't like them, and shows you weird character strings instead of the correct ones. However, if you were to view the CSV in another program, like Notepad++, the correct characters are visible in the file.

I found a way to fix this issue that doesn't seem to interfere with Deckbox import. Let me know if you encounter any issues, but now you should be able to download and view the files in Excel without issue, as well as import them into Deckbox.

(For those interested, I batch-converted all the CSVs to use UTF-8 with BOM. Excel apparently needs that Byte Order Mark to know it's actually UTF-8 and not Windows-1252. Dumb.)

This is a different issue than the above. The tildes are part of Deckbox's naming convention for that card, just as quotation marks are part of Kongming, "Sleeping Dragon" or the exclamation point is part of To Arms!. Deckbox won't let you import those cards without the tilde/quote/exclamation included. In other words, there's nothing to "fix" in this case. Instead, you'll just have to account for those characters when searching within your CSV export.

That said, I could see a valid argument for Deckbox accepting both To Arms! and To Arms as equivalent names. Going back to special characters, you're already able to import either Dandân or Dandan into Deckbox without error. The same could easily be true for card names that have punctuation in them. If you think that would help you, I'd suggest bringing it up to Sebi via a support ticket. It might not be that hard for him to implement since he already has some version of it in place for accented vowels and the like.

It would actually be a fourth color, as there's already three (or four if you count white): yellow for partial sets, blue for a full set (1x of each card), and green for a full playset (4x of each card).

You know what would be even better? Being able to set your own custom collection goals per edition. I could imagine this being a fourth column next to wishlist. You would simply add however many copies you want of each card in a given edition, and then the color coding on the Editions page would reflect whether or not you've completed that collection goal or not. I recommend a 4-color system -- white / no color for N/A (no collection goal set), light red for 0% (collection goal set but no cards collected yet), yellow for 1%-99% (partial completion), and green for 100% (full completion). Or just combine 0% with yellow for a simple 3-color system.

This could tie into the existing Wishlist as well. Users could optionally enable an auto-wishlist setting, in which all collection goals that don't have adequate inventory counts to cover them get auto-added to your wishlist. And then when you add one or more copies of that card to your inventory, it gets auto-decremented in your wishlist.

And the Mass Input convenience methods could be extended, not only to include the new Collection Goal column (and probably a Wishlist + Collection Goal option), but also to allow for partial collector number ranges for adding the cards. Then you as a user can easily dictate, "I want 4x copies of the main Eldraine set not including basic lands (#001 - #249), and 1x copy of the showcase cards (#273 - #302). But none of those stupid extended art variants!"

Makes sense. I was noticing the re-rendering of each colored indicator for "have enough" / "don't have enough" in sequence, and figured that was part of the bottleneck.

Sorry Sebi. Your users are just bound and determined to break your site. 

Looking forward to it!

I have no idea on a maximum, but I can comment on performance. TL;DR -- it got a lot slower for me with 2300+ cards in a deck.

So unlike a lot of people's versions of this, my reserved list "deck" actually lists 4x of each card..... because the dream is to own a playset of each P9 card, amirite??? LoL. In any case, that means 2300+ cards.

The other day I decided to actually go in and split rows and set specific editions for the ones I own. For instance, say I own 2x of a Collectors Edition version of a card, but my actual collection goal is 4x Revised of that card. I had to: 1) Add a new row for that card, 2) update the quantity of the new row to 2, and 3) change that row's edition to CE.

I noticed that all the actions took an abysmally long time. We're talking like 10-15 seconds per action. I have it set as a Deck Idea, not Built Deck, so I don't know if that affects it. I also am aware that Sebi has been silently making tweaks to the site's backend, so maybe I just did it at a bad time. And I'm using Chrome on Windows 10 if that matters.

However, if it's that slow all the time, then that would make it all but unusable for any box / binder that has frequently updating contents. Once all the contents are entered, though, it's not too slow for viewing / sorting.

An oft-requested feature! But no, nothing has been implemented as of yet. Built Decks are still the closest we have.

As I said before, that will get the job done, since it will allow for differentiation on a CSV.

My main concern is still with ease of identification when scanning lists of cards (whether in trades or one's own inventory). Most other card identifiers are easier to identify at a glance. Language, condition, foiling, and edition all have identifiable icons. The closest parallel are cards with variant artwork in the same set -- there's no way to tell them apart just by glancing at the table row; you have to hover to see the card image. However, it's worse with the etched variant, because the artwork is the same. We will have to hover over the edition icon in order to see the collector number, and then you'll "just have to know" that the little appended e means etched.

So. I shall be the etched flag flag-bearer till the bitter end.  ;-)

To be clear, I'm actually very happy to hear you proposing to change collector numbers to strings, as that could fix the other bugs I've mentioned (BFZ basics, Tahngarth). It's a good solution to implement. I just don't think that happens to be the best solution in the case of etched foils.

If you do indeed go with unique collector numbers a la Scryfall rather than flags, might I make a UI request? Could you add Collector Number as an additional optional column for card listings? Then at least I could see the collector number when scanning, and won't have to waste time hovering.

Agreed. There's definitely "solutions" within the current system to represent proxies, at least to your own eyes. Just do what works for you. Like, I have actual alters, so I can't use that flag... but I could just use "textless" or "artist proof".

However, those types of hacks have a couple drawbacks. The main one pointed out in the thread I linked to is that the cards are still included in the inventory's valuation. If my real cards are worth $5k (at least per Deckbox), but I proxy a full set of duals, some Cradles, a Mox Diamond.... it shouldn't suddenly say my inventory is worth $20k or whatever. Sure, you can filter out whatever flag it is you used to represent proxies, then view Total Set Value for the filtered listing.... but that's just hacky.

A second concern is with universal recognizability when it comes to those "anything in my inventory is available to trade, just ask" type posts. Without an actual proxy identifier, people will think your Taiga with an altered flag is just that -- an altered Taiga -- and propose a trade for it, wasting both their time and yours. "But meldon," you say, "it's as simple as explaining it in your profile or post." Well, nothing is as simple as it should be when it comes to real-life interactions with human beings. People don't read. People will misunderstand. You'll forget to add it to your post. And so on. Can it work? Sure. But is it the most ideal UX? No.

I don't have any personal investment in the discussion, as I don't see any point in listing proxies in my inventory. But for the overall betterment of the site, I would propose a dedicated proxy flag that hooks into the pricing as the ideal solution. And since Sebi might have been looking into flags anyways, just thought it was a good opportunity to bring it up.

That would be cool! But no, unfortunately (or I guess fortunately, if you're the opponent).

Short answer: Although a creature can't deal negative damage in combat and instead deals zero, its power CAN be negative for the purposes of calculation. That means Morphling would in reality be a -2/8 (that deals zero damage), so the third ability will add +X to -2. Thus, the abilities are inverse operations, that is, they undo each other.

For a slightly longer answer that references the actual official rules, see comments #2 and #3 of this post.

Alright, so I played around with it a bunch in my inventory, so hopefully now I can answer any questions you have. Here goes....

No, it doesn't work for Mark All. Using that option, regardless of what the current filter shows, will literally mark all your inventory as tradeable.

But you know what?? That's a great feature suggestion! It feels more intuitive that you would only add the current filtered set to your tradelist. Perhaps there should just be a new option in the drop down — rename the current option to something more clear like "Add Full Inventory to Tradelist", and then add the option "Add Current Selection to Tradelist".

Correct. Auto-Trade will override most (but not all; see below) manual tradelist selections you've made. Note that it only works with built decks, though, not deck ideas.

Since it's a little unclear what order you're asking about performing the actions in, here's a couple scenarios:

Scenario A — You don't have Auto-Trade enabled yet. You have Doom Foretold in a built deck, but you have also manually listed it for trade. You can navigate to both the deck and your tradelist and see it in both locations. You can also see it counted in both the deck and tradelist columns of your inventory. Then you enable Auto-Trade. Doing so will remove Doom Foretold from your tradelist. In fact, you can no longer manually add it to your tradelist at all. It looks like you can, because you can update the tradelist count field on your Inventory page, and the count will appear to stick. But if you refresh or navigate to your tradelist, you'll see that Auto-Trade has once again removed it from trade (although there is an exception to this behavior; see below).

Scenario B — You already have Auto-Trade enabled. Doom Foretold is not in a deck yet, so it's currently listed in your tradelist due to Auto-Trade. Then you add it to a built deck. Unintuitively (especially considering how it worked in Scenario A), Doom Foretold will not be removed from your tradelist by Auto-Trade, but instead will be added to a "needs attention" filter (more on that below). However, if you trigger Auto-Trade to refresh, such as by changing another deck from Deck Idea to Built Deck, then Auto-Trade will reevaluate all your cards, and will determine that Doom Foretold should no longer be traded.

====================================

How Auto-Trade works

"Auto-Mark Unused for Trade", or Auto-Trade for short, seems to be both a process that will run at certain points, as well as a persistent state that modifies how cards interact with your lists. It only works with Built Decks and doesn't care at all what you have in your Deck Ideas (even if you have matched the cards in a deck idea to cards in your inventory). Thus, if you have only deck ideas and no built decks, your entire inventory will be made tradeable. Note also that the "sharing cards between decks" setting in your profile affects how Auto-Trade builds your tradelist.

When you first turn on Auto-Trade, the process will run and fully evaluate every card you have, removing it from your tradelist if it's in a built deck, adding it if it's not. It adds any difficult-to-evaluate cards to a special "needs attention" filter you can access from your inventory.

The "needs attention" filter appears to be for any cards with the same name that have multiple versions in your inventory (e.g. 1x M12 Shock, 2x M14 Shock, 1x foil M14 Shock). Even if you specify the specific version to use on the deck page, Auto-Trade will still act like it can't determine which card shouldn't be traded. (I guess better to err on the side of caution?) In order to resolve these conflicts, you have to manually specify the quantity of each version to trade. Continuing with Shock as our example: Once the combined sum of all versions of Shock in your built decks and tradelist equals the total number of Shocks (all versions) in your inventory, it will disappear from the "needs attention" filter.

While enabled, Auto-Trade interacts with card updates in the following ways:

• Adding a card from your inventory to a built deck will not remove it from your tradelist. Instead, it will be added to the "needs attention" filter

• Removing a card from a built deck will not add it to your tradelist. Instead, it will be added to the "needs attention" filter.

• Adding a card to your inventory with the Add Card widget will not add it to your tradelist. Instead, it will be added to the "needs attention" filter.

• Adding a card to your inventory by increasing the count of an existing card WILL update your tradelist (needs a refresh to see the updated count).

• Updating the tradelist count field of any card behaves as follows:
  

  • If the card is the ONLY version of that card's name (e.g. you have 4x foil M21 Shock but no other Shock), the tradelist count will be set to the value that Auto-Trade will then calculate, no matter what you enter.

  • If you DO have multiple versions of that card name, then the tradelist count will retain the value you set. If the value you entered resolves a "needs attention" conflict, it'll be removed from that filter. If it reintroduces a conflict, it'll be added back to that filter.

  • Either of the above changes will trigger an Auto-Trade refresh, meaning all the above examples of cards not being properly added to / removed from your tradelist will be fixed.

  • If you enter the same number that was already in the tradelist count field, no refresh will be triggered.

• Updating a deck to Built will trigger a refresh, so all cards in that deck will be removed from your tradelist. Conversely, changing a deck back to Idea also triggers a refresh, and all its cards will be re-added to your tradelist. In both cases, you may end up with new "needs attention" conflicts.

Other Questions

No, your tradelist will retain the state it was last in when Auto-Trade is disabled.

The easiest way to trigger an Auto-Trade refresh is to attempt to edit the tradelist count field of a card using a different value than what's currently there. A refresh will also be triggered any time you change a deck to/from Deck Idea or Built Deck. If all else fails, you can disable Auto-Trade, then re-enable Auto-Trade.

Not directly. To achieve this:

1. Tools > Export — The downloaded CSV file contains your current tradelist counts.

2. Tools > Enable Auto-Trade — Do whatever. Just don't add or remove cards from your inventory (or the downloaded CSV will be out-of-sync).

3. Tools > Disable Auto-Trade — Make sure you do this before the following!

4. Tools > Remove Everything — Clears your inventory and tradelist.

5. Add Cards > From CSV File — The exported CSV file will restore your original tradelist along with your inventory

Quirks / bugs to be aware of

• When you're in your Inventory, you can update the tradelist count field of a card, and the number appears to stay. However, if you refresh your inventory or navigate to your tradelist, the count will NOT have been updated and instead reverts to its Auto-Trade value. Ambiguous user input is not desired behavior and will hopefully be fixed. If users can't manually override Auto-Trade (which honestly should be a consideration), then those fields should be locked and no longer editable to avoid this confusion.

  
  

• Using the "Mark all for trade" function while Auto-Trade is enabled will override Auto-Trade and will persistently add all cards in your inventory to your tradelist — i.e. counts updated via "Mark all" will NOT revert after a page refresh / navigation. Then if you trigger an Auto-Trade refresh, unexpected tradelist counts occur and they don't seem to fix themselves. You have to disable and reenable Auto-Trade to correct it. Obviously, no user who wants to use Auto-Trade should reasonably want to also use Mark All.... but someone might do it anyways. The Mark All option should probably be removed / disabled while Auto-Trade is on.

  
  

• The "needs attention" filter has a number next to it indicating how many card name conflicts* are present. However, this number does not update correctly when a card is added to your inventory or to a built deck. The card does indeed get added to the "needs attention" filter, but the filter's count is NOT updated to reflect the new card. This is workable as long as there's other cards that already needed attention, because you can click the filter link and will see the uncounted new cards. It becomes a problem, though, once you've resolved all the conflicts, because then the link is no longer displayed and you won't be alerted to any conflicts with new cards.

  
  

  * The number does not reflect the total number of unique versions. If you have 12 different versions of Forest, they will still only be counted as 1 conflict.

You're not missing anything. Sebi just hasn't had a chance to get the tokens imported yet. Should be soon.

I feel like I may be misunderstanding what you're proposing. Blocking is already an available feature, and that stops someone from proposing trades with you. It also prevents you from accidentally proposing trades with someone you were wanting to avoid.

I just tested it out on a couple users who have cards in my wishlist. Blocked them and they disappeared from Trading Opportunities, unblocked them and they came back.