You are not logged in. Please login or register.
Thanx a lot for the files!!!!
You're very welcome! Glad this project is of use to people. I don't usually get very much feedback, so it's hard for me to know whether or not this resource is valuable enough to keep working on. I appreciate your comment!
Last edited by meldon44 (2020-05-30 08:49:12)
Dear Deckbox friends,
I would like to apologize for getting behind on this community resource. My wife and I had a baby in mid-February, but along with that joy came a host of medical woes for a few weeks. We were in and out of hospitals with our new daughter, including the cardiac ICU for about a week. Thankfully, everything has stabilized and seems oK. Then of course throw COVID-19 into the mix, and that's a recipe for a lot of upheaval and not enough time!
But I plan to get all the missing precons added within a few days -- Challenger Decks 2020, Unsanctioned, and the THB Deck Builder's Toolkit. I'll also probably pre-add the C20 decks, so they're ready to verify upon release! Let me know if I've missed any other recent products.
Thanks for your patience!
MAJOR UPDATE
I completely revamped the coding of the webpage to improve its usefulness. While it won't look much different, everything has been rewritten to use more browser-compatible code, as I know it broke on some browsers (such as all versions of Internet Explorer). I'm still working to improve the mobile experience, but it should at least WORK on modern browsers. Please let me know if you encounter something that doesn't seem to work.
I've also decided to streamline my process of adding new decks by no longer adding CSV download links to the original post in this thread and attempting to keep it up-to-date and organized. I will always post a new comment when a CSV is available, with direct links to the CSV. But otherwise, all CSVs must be accessed from the webpage (which is linked in the original post): bit.ly/MTGprecons (note that capitalization matters with Bitly links!).
Along the lines of cleaning up the forum, I went through and deleted a whole bunch of my comments that merely announced new CSVs. That information has been added to a changelog on the webpage for anyone that cares, but now this forum thread is shorter and more open to general discussion.
A note on Jumpstart
Whew........ Jumpstart has a LOT of CSVs! Sorry for the delay, guys, but I finally slogged through all the data, tried to double-check everything as carefully as I can, and got it all added to the full list under Misc. Precons.
PLEASE let me know if you find any errors (far too easy to happen in a listing this big), and please send me lists of basic lands for the various themes and variants so that I can start marking the CSVs as fully verified. The special themed basics are properly included, but the "normal" basic lands are just included as a single clump, e.g. 7x Island, so I'd love to get something like this from you guys:
Theme: Under the Sea 2
3x Island #263
2x Island #264
2x Island #265
Last edited by meldon44 (2020-07-21 08:05:57)
1 (100%)This is a fantastic resource, thank you so much for putting this together. Just sent over a couple coffees for you and your wife 
Is there any chance of making the CSVs available via GitHub, to make it easier to submit new decks and corrections via pull requests?
This is a fantastic resource, thank you so much for putting this together. Just sent over a couple coffees for you and your wife
Thank you so much for spending the time (and money!) to do that. I apologize for this egregiously tardy thank you -- we started homeschooling our 5 school-age kids due to COVID-19, so.... don't know if you have any kids in your life.... but I'm sure you can imagine that it's been a crazy transition!
Is there any chance of making the CSVs available via GitHub, to make it easier to submit new decks and corrections via pull requests?
I could see transitioning from Dropbox to Github at some point, but considering the sheer number of CSVs and accompanying download links contained in this resource at this point, that's no small task. For now, the current system is working out alright.
Hi is there an intention to add series like
"Signature spellbook", "From the Vault" etc to the list?
Also +1 for adding csv to git hub with PR's instead of dropbox.
Because the list is only going to grow.
And having all SCVs versioned in one place will make them easier to manage.
Its big but not Gigabytes big, just a lot of text files.
And if they ever need to be e.g. migrated a script + PR will do
And maintaining current navigation page with links looks like it requires a lot of work while being sub-optimal UX
A CSV with list of products could be generated instead
And feed as data to UI like https://datatables.net/
Making adding new sets and fixing bugs easier.
Last edited by NamespaceV (2020-12-10 18:20:53)
Hmm a bit more work than i thought but i made a POC.
Uploaded to my random github project as i couldn't attach zip here:
https://github.com/NamespaceV/MtgSearch … ctSets.zip
Example.png shows how it looks if it doesn't run.
It should just run if you unzip and open list.html in browser.
In data/extract.js you can see script i run to get list of files and names.
I removed some obviously empty records but didn't check data much.
Definitely needs improvements but for initial POC good enough.
At least parents should be added as some names make no sense when i extracted name in box alone.
Default DataTable styling looks bad but i didn't care much for POC.
It works and you can search - this was POC scope.
If this looks interesting I can develop this idea more.
If not i'll probably hack some more simple automation for myself.
Json lists all dropbox files i found, definitely needs double check and cleanup.
But you could download all with next script and then just reupload them in different paths e.g. to git hub.
Takes time and needs double checks but should be faster than doing it manually.
Last edited by NamespaceV (2020-12-10 22:03:19)
Hi is there an intention to add series like "Signature spellbook", "From the Vault" etc to the list?
Hi! Thanks for taking an interest in this project and suggesting possible improvements!
So we'll start with the easy question above: I had not bothered with those products, since the main purpose of these CSVs is to make importing precons easier than it is using the native tools. A lot of precons contain a mix of card counts / editions / foiling / artwork variations, meaning using the "Add Card List" tool in Inventory or the "Mass Input" tool in Editions isn't ideal. However, products like Spellbooks, FTVs, and the new Commander Collections all contain a single copy of each card, from the same edition, with all cards being either foil or non-foil and with no artwork variations in that edition. They're also only 8 - 15 cards (20 for FTV:20). For these products, it's very easy to use the above-mentioned native tools.
That said, I see no reason not to include them in the list, since creating the CSVs will likewise be super easy. May as well have a complete listing!
Also +1 for adding csv to git hub with PR's instead of dropbox. Because the list is only going to grow. And having all SCVs versioned in one place will make them easier to manage. Its big but not Gigabytes big, just a lot of text files. And if they ever need to be e.g. migrated a script + PR will do
oK, so I am unclear on what exactly the benefits are for uploading all the CSVs to Github. But I will admit, I've never used Github for a collaborative project. The only reason I'm using it now is because it was a quick and easy way to get free web hosting! Heh.
For instance, you mention having all the CSVs "versioned". What benefit do you think it'll provide? The only versions they have, at least in my current workflow, is "unverified" (my initial build of the CSV based on card lists and assumptions for basic lands) and "verified" (after some source has confirmed that the CSV is 100% correct). The only "middle" version that ever occurs is when the double-sided tokens aren't available on Deckbox yet, in which case I leave the token counts out of the Count column (so that the CSV can still import without error). I'll then re-add the token counts once Deckbox has caught up. So perhaps "unverified", "incomplete", and "verified" are the three CSV versions? Even so, I don't see the benefit for me or the end user in having the CSVs archived and versioned on Github. Maybe I'm missing something.
The main benefit you and others seem to be pointing to is that Github allows you to submit a PR if you have a CSV you'd like to add. But unless I'm mistaken, you could do that anyways at my current project, and then I can add them to the main list in whatever way works best for me. So if the main benefit is allowing easier collaboration in creating CSVs, isn't that already possible? Again, maybe I'm missing something. :\
My main concern with moving to Github, as mentioned above, is the time it'll take to reorganize everything on Github. So it's about the sheer quantity of those text files, not the gigabytes. The fact that the list is only going to grow larger doesn't worry me; it's been very easy to manage all the CSVs in my local folder structure that's connected to Dropbox.
Please don't take all of this as me merely arguing with you and not listening. Rather, I'm presenting my understanding of what works and what would be beneficial, and I'm asking you to enlighten me if I'm missing an obvious benefit of transitioning to Github.
And maintaining current navigation page with links looks like it requires a lot of work while being sub-optimal UX
Can you please elaborate on that and explain in what ways you think it is sub-optimal? I am totally willing to optimize it, but I can't do so without more specific feedback.
A CSV with list of products could be generated instead
And feed as data to UI like https://datatables.net/
Making adding new sets and fixing bugs easier.
I have already considered this for a future upgrade to the page. Currently, it's actually VERY easy and fast to add a new set, and it wouldn't be any easier/faster to do it with a CSV of products. But you are correct that, if there's ever a bug that requires changing the HTML structure of every single list, or if I simply want to change the layout, it would be a lot easier to do it with a dynamically-generated page instead of static content. I have simply not gotten around to this yet. With a job, 6 kids, and another baby on the way, I don't have a ton of time to devote to this. I had actually set up a Kofi page, hoping a few kind souls would donate some money as a way to thank me for my time and effort, but..... pandemic. People aren't really interested in donating money to silly things like this right now!
Hmm a bit more work than i thought but i made a POC.
Definitely needs improvements but for initial POC good enough.
At least parents should be added as some names make no sense when i extracted name in box alone.Default DataTable styling looks bad but i didn't care much for POC.
It works and you can search - this was POC scope.
Yeah, I don't like table styling in general. (Especially on mobile!) That's the reason I went with dropdowns in the first place. Tables are fine for us analytical programmer types who don't mind sifting through a sea of data.... but not as friendly to the average user. Even if I update my UX based on further feedback you give me, I won't be adopting a table layout.
If search functionality is the primary improvement you were hoping to see in my current UX, well.... you're in luck! That's actually the next feature I was working on to be added. Stay tuned!
In the meantime, for your own uses, a couple quick alterations to your JS to help clean up the results you extract:
links = $(".list li a[href]");
function extract(id, a) {
var a = $(a),
precon_type = a.closest('.list_wrap').find('h3').find('span').remove().end().text() + ' - ',
precon_category = a.parent().prevAll('.category').first().text() || a.closest('.list').prevAll('h4').first().text(),
precon_note = a.children().text(),
precon_name = a.children().remove().end().text();
return {
href: a.attr('href'),
text: precon_type
+ (precon_category?precon_category+' - ':'')
+ precon_name
+ (precon_note?' ('+precon_note+')':''),
className: a.attr('class')
}
};
extracted = links.map(extract);
JSON.stringify(extracted,null,2);I haven't combed through all the data this produces, so there's still probably issues, but it'll be a lot more functional for you, and instead of including that extra data in the "Name" column of your DataTable, you could instead add more columns for this extra data.
1. Spellbook, from the vault and similar products
I see some Premium features around collecting. Maybe they make adding CSVs not wanted.
I'm more of a "use free stuff and write some own tools that suit me" rather than "pay for solution that adds to already expensive hobby" guy.
But definitely love what deckbox offers for free accounts and don't want to screw around their monetization model.
2. Dropbox vs Git
a) collaboration
Anyone can easily clone repo, change file contents/add files and propose changes, either fixes or new CSVs
with PullRequest they present their "version", you can see all changes highlighted, and either accept them as main version or not
and even if you accept changes that were incorrect there are tools to revert unwanted changes
(its easier or harder based on how they were merged and what changed after them)
I don't think you can set up dropbox like that
Downside is you need to learn some basic git commands and github UI.
And migration - if you have all files in some kind of directory you just commit them to git hub repo to some data folder.
If they are scattered you'll need some script to find, download and store them on some reasonable paths.
If you are doing anything around tech i really recommend learning git anyway as it is a really powerful tool for sets of text data like csv or code.
b) versioning
you have history of all changes saved, who and when changed them,
so if any file gets corrupted by mistake you can easily revert to file version from a few months away,
of if you see e.g. one person was sloppy when contributing you can review their changes later to double check them
also if you need to e.g. migrate as some CSV column changed name or format, e.g set name column "Rivals of Ixalan" was changed to use 3 letter code "RIX"
you can put changes in all files as a single "commit" so they are all marked as connected
and not only latest version is available, but all files before and after change can be downloaded if needed
git does the job of comparing all versions and storing only changes, so repo size doesn't grow too fast, but all versions are available
you can have multiple variants leaving in their own parallel universes called "branches", mix and match changes made on them
you can even try applying some changes made to old versions to a different version
(this requires both versions to be somewhat similar or it will not work reasonably, but magical merge algorithm works surprisingly well in most cases)
for simple CSV this is a bit of an overkill, more useful for working with code,
but even for CSV it allows more control, easier cooperation and experimentation
simple scenarios are pretty straightforward - you jus commit to change locally and push to change on server
but when you start adding multiple branches and merging different versions it can get complicated
and tools support all those different scenarios so they may be tricky to use some times
but i see you already host on git hub so you know at least the basics
c) organization
all CSVs are in one place and one can download repo or part of it to hdd if they want to
and if they want to run some scripts e.g. to import deck to Arena they can easier than in dropbox model where they have to use site or script crawlers
3. UI
It's a good practice to separate data and presentation.
So that you can create new presentation without altering data and add data without worrying about presentation breaking.
You can have multiple presentation options if you have separated clearly. e.g. One page with a table and another with expanding lists visualizing same data file.
We have a lot of tables in my work project so i suggested going with them as They allow filtering by multiple factors, searching etc out of the box.
But default setup looks worse than i remembers so definitely needs more work.
Not sure how good you feel about scripting. I'd put most layout work in Javascript and provide data to display in JSON, CSV etc.
This does require some learning to handle. And you have to unify structure, limit to a few styles rather than write custom layouts for all cases.
But then you can easily experiment with different changes and process data with scripts as layout and data are not coupled.
This is more of a mind set to learn - like in the script above,
thx for adding more info,
but when storing data like Category, Type, Note its much better to use different fields and glue them together in JS
than to concatenate all to Text field and have no option to change layout later or present list of all Categories with filter by category
4. General cooperation
I can prepare my version of https://meldon44.github.io/mtg-precons/
Hosting it temporarily on my account https://NamespaceV.github.io/
And if you like it I could PR to your https://github.com/meldon44/mtg-precons repo
I have some time ot experiment now as im not working for some time an d project seems fun,
but wont be able to support project in the long run.
PS
github.io is great, i was looking for some lightweight free hosting and this is really nice
No server side scripts but other than that really great - mimics CD pipeline without any devops for static content
and JS + static files can do a lot if you like that stack
Last edited by NamespaceV (2020-12-11 14:41:10)
Hi,
I'll throw my vote behind adding the CSVs to github. I'm just a the point of adding precon decks to my deckbox inventory and luckily I ran across this thread... great resource and thanks for the work.
Having the CSVs on github makes it easier for me to browse them rather than downloading them individually. Also the first thing I did was look for a template of some sort as I was not clear on what columns I should put in any of the CSVs I make. Perhaps I missed it... I ended up downloading one of the existing CSVs to have a look.
How much the versioning would be of use in this case is questionable as, as it was mentioned, the individual files are not changing much. However in the even of there being a correction to a CSV it is really easy to see this on github verses reading through the forum or changelog on the website. Also, it gives the ability for a person to simply clone the entire repo, if they like, in one easy step as well as easily get updates (a simple pull vs checking the website). Submitting new CSVs is a simple pull request and these are easily seen on the github page as well as their status (have they been accepted, etc.).
Lastly, as was mentioned, hopefully at some point someone steps up and offers to help on a regular basis instead of everything being on one person's shoulders... having everything in github makes that collaboration much easier.
For all the good reasons mentioned previously plus mine above, I recommend utilizing github as much as possible.
Now onto making and contributing some CSV files.
I downloaded CSVs with a script and created a PR to original site repo with all CSV.
I found 440 of them. All precon csvs have 2.54 MB total (with sizes 400kb - 0.5 kb) Zip of all CSVs is 686kb
https://github.com/meldon44/mtg-precons/pulls
If meldon44 likes this idea he can accept PR and all CSVs I found will be versioned on his git hub repo as well.
This should make it easier to help add new files of fix errors in existing ones - anyone can clone a copy, fix/add and create PR.
If changes look good meldon44 could accept, reject or comment whet needs to be addressed if its generally ok but there are some issues.
https://namespacev.github.io/files/PreconDecksCsv.zip - zip with all CSVs as of 2020-12-13 if you don't want to use Git,
will get outdated if anything changes so git will be better to keep latest version
Github Pages has bandwith limit of 100GB per month,
https://docs.github.com/en/free-pro-tea … age-limits
Seems like it has enough bandwidth but might be an issue at some point, so maybe keeping links to dropbox should stay.
But even then CSVs in git for reference/source of truth/making fixes easier is the way to go. Then exporting the latest version to dropbox.
But if PR is accepted you can easily change host links by replacing "https://bit.ly" with "/decklists/".
Then dropbox will not be needed as site will use hosted csv's directly.
I can show in next PR if this one is accepted.
I played a bit with UI, but I can't get any real improvement yet.
So that part has failed.
PS I remembered what i came here for originally - adding some jump start packs.
I'll check CSVs for ones i got and can create PR with lands etc in ones i got, if the first PR with CSVs is accepted.
Also UI i had issues with was mostly Jumpstart but its really special case so maybe only this one needs some tweaking,
as usual scenario is having a few packs and finding which one is which as they are not labelled,
so it could use a separate site for finding correct pack to load.
Last edited by NamespaceV (2020-12-14 17:36:53)
Question from a noob to this...
So I'm trying to figure out the best way to create a new CSV for one of the precon decks I have that is currently not on the site. What I don't see is any central instructions for the best way to do so; ie. best place to get the deck list as a starting point, a simple template to use, any preferred style guide (for lack of a better description, etc.). Yes I believe I have an answer to each of these after reading through the forum messages and looking at some of the CSV files... but it would be useful to have something on the site.
Note: I have only every exported my DeckBox inventory for backup purposes. I have not done any imports or much looking at the exports.
I'd be willing to put something together, since I'm going through the process anyway, if it would help. So...
1. Where to get the list of contents of a precon deck?
- That works as a easy starting point for creating a CSV
- Any suggestion for editors or macros/scripts to massage the starting data into a CSV
- (edit: possible answer) So it looks like mtg.fandom.com has pretty well every precon and downloadable text lists that could easily be massaged into CSV format.
2. Template of the CSV
- I see the headings "Count,Name,Foil,Card Number,Edition,Language"
- I also see a few CSV that seem to be divided into sections. Is this supported by the import function? (maybe there is something on the DeckBox site I should be reading... haven't checked yet)
3. Any guidelines of style to use when creating the CSV?
- Capitalization: does it matter?
- Keywords that can be used? ex: For the Foil column I see either empty or "Foil"
- Order of cards in the CSV file?
4. Anything else that makes it easier to accept a CSV when submitting it?
- Note on how the CSV was verified or if it was verified?
- Note on the source of the contents... from a site, from an actual deck, etc.?
Hmm, one more pro about using github for the CSVs... you have a history of who did the initial submit (PR), who verified, any issues (can be noted in the commit messages), etc. All the info about a particular CSV file is bundled with the file either as part of the commit messages or as the conversation with the PR, etc.
Last edited by HeyMerlin (2020-12-15 00:29:49)
@NamespaceV —
1. Spellbook, FTV, etc.
The "Mass Input" tool in Editions is only available to premium users. However, the "Add Card List" tool in Inventory is available to free accounts. Go to your Inventory > Add Cards > Add Card List, then set the Default Values to e.g. From the Vault: Angels, Mint, English, and Foil. Copy'n'paste the list of 15 cards from anywhere on the internet, and voila. Added without issue!
2. Dropbox vs. Github
Alright, you guys have convinced me! I'll work on making my transition to Github. Thank you for the PR; that gets me a headstart. And yes, 440 files is the correct amount.
I do think that Github is complete overkill for the CSVs. Based on everything both of you have written, the main benefit seems to be C) organization, allowing people like you guys who are familiar with Github to just download the entire batch of CSVs at once.
The other semi-benefit is keeping track of who submitted and who marked a CSV as verified, in order to maintain quality control. That has been a non-issue up until now, since almost no one has been contributing CSVs. But perhaps this is the start of a new era.
3. UI
I think you underestimate my knowledge. LoL. I am very familiar with separation of content / layout / styles / behavior, and always try to code in that paradigm. The current hardcoded data is a relic of my training, though. It was drilled into me to always start with a functional page, even for people who have Javascript turned off (and I always thought it was so incredibly stupid that we have to cater to people who don't want to enter the modern age, but anyways.....). So I created the page to look and work fine with or without Javascript. Then I use JS to transform some aspects of the layout onload.
But I agree with you that it's reached a point that I'd rather separate the data and dynamically create the layout. When I first designed the page, it was a much smaller amount of data to wrangle! I'm fluent in using JS/jQuery to create layouts, so I'll be updating my scripts soon to make everything dynamic.
By the way, the only reason I concatenated all the extra info in the script update I gave you was just so it worked in the current table layout you had. I trusted you would be very capable of adapting the code and altering your table layout if you so chose.
4. Cooperation
Thanks again for taking an interest in this project! Before accepting your PR, I have a couple questions:
A. On Github, what is the preferred organization for an extensive repository of CSVs like this? Organize them in multiple subfolders based on precon type, or prepend that info to the filenames while keeping them all in one folder? Currently, my Dropbox has them all in a subfolder hierarchy, so it would be pretty easy for me to just copy that hierarchy to Github.
B. The reason I started using Bitly is because I wanted to see data on how often various products were downloaded, as well as things like whether people were tending to download e.g. individual Commander decks or the bundles like C20 - All 5 Decks. (I also liked that the Bitly links were much shorter and nicer to glance through in the source code than the native Dropbox links. But that would also be true using Github.) If I were to switch away from my Dropbox/Bitly setup, what would be the easiest way to continue this data collection on CSV downloads? I've never used Google Analytics, but from my vague understanding of it, the free account limits how many things you can track, so I definitely wouldn't be able to track all 440 (and growing) links.
5. Jumpstart
Can you think of anything better than the current system I've implemented to figure out what packs you have? In the current setup, it's easy to drill down to the correct color and pack name. Then it's just a matter of figuring out which variant you have. I did this by analyzing all the decklists and determining a unique card (or combination of cards) that makes that variant unique from the others. So if you have the Jumpstart pack in front of you, you look at the card name(s) on the website and see if it's in your pack. If so, that's the correct CSV to download.
For example, say you have an "Above the Clouds" pack. You know it's blue, so you go to Jumpstart > Blue and find the Above the Clouds variants under Common Packs. You notice you have both Inniaz, the Gale Force and Warden of Evos Isle in your pack, so you download the first variant. Now, Clouds 2 also has Inniaz... but it doesn't have Warden. And Clouds 3 also has Warden... but it doesn't have Inniaz. So the only possible pack it could be is Clouds 1, which has both.
I can think of no better system than this, since the Front cards in the packs aren't labeled in any way to let you know which variant you have. And you certainly don't want to look through an ENTIRE pack list! I guess you could start typing in card names in a box, and it would filter to the one you need? But that seems like more work for users than the current system.
=========================
@HeyMerlin — I'm curious about this statement you made: "Having the CSVs on github makes it easier for me to browse them rather than downloading them individually." You're either browsing them in an ugly tabular layout on Github or browsing them through categorical dropdowns.... but either way, you're having to browse to find the one you want, correct? And then unless I'm missing something on Github, you have to download the CSVs individually there, too (is there a way to select multiple files and download just those as a ZIP?). Or I guess you can download/clone the entire repo and do all the browsing on your computer. So unless I'm misunderstanding you, it sounds like it has more to do with the browsing experience. You'd rather a table than dropdowns?
As to your other question: A CSV creation guide is a great idea! Thank you for suggesting it. As someone who does it all the time, it didn't occur to me that saying "make a CSV and send it my way" would be a hurdle. But duh, of course it would. Heh.
Honestly, anywhere you trust. I actually use MTG Wiki quite extensively and contribute to it myself, but you could just use info from the mothership. Easiest way to find decklists on Wizards' website is through Google.
I'll create a CSV template for download, though I suspect downloading a filled-in CSV might actually help a person understand it better.
As to columns, the absolute minimum we need is Count, Name, Card Number (for artwork variants when the card appears more than once in the set, such as basic lands), and Edition. The Foil column is only required for precons with foils in them, and Language isn't strictly necessary, though I made the decision early on to have all CSVs default to English. (Originally I had a Condition column and would set it to Mint, assuming unopened precons, but many people have opened and played with their precons, so I simply removed the condition column entirely and leave it up to the individual to set.)
As to sections within the CSV: No, it doesn't negatively affect import. As long as nothing is in the Count column, Deckbox will ignore that row entirely. So I started dividing decks, thinking some users might find it useful, such as in the case of Event/Challenger decks that have sideboards — nice to see what the sideboard is supposed to be! But having sections is definitely not necessary, and most of the CSVs are older additions and don't have any sections.
You know? I've never tried it without proper capitalization, but I imagine it would work. The most important guideline for the CSV is simply... does it import without error?
That said, I personally prefer proper capitalization, and the editor inside of me will probably feel compelled to go correct everyone's capitalization, so.... for my sake, please. 
I also like the columns to be in the order I have them. The order doesn't technically matter, as it'll import with any column order, but I think keeping a consistent layout is smart, especially considering all the discussion of future migrating/merging/updating.
You've already identified the only necessary "keyword" and its correct usage. For any of Deckbox's flags (this goes for misprint, altered art, signed, etc), you either leave it blank or include the appropriate word to set the flag to true. If you leave Language or Edition blank, then it'll be imported without that value set. If you leave Card Number blank, Deckbox will choose a card number to set. A blank name will throw an error, and a blank count will mean the row gets ignored, as mentioned above.
Whether or not it's verified is required info. If a CSV is submitted without this being specified, I'll add it as unverified. How it's verified hasn't mattered to me thus far, but once we migrate to Github, there's no reason this info can't be included, as it'll help vet the CSVs. And if it's ever discovered that a supposedly verified CSV is actually not accurate, we'll know who to blame!
Some examples: Say you opened a commander deck and did nothing to it except replace the basics with full-art lands, throwing all the basics into your basic land box. Since you can now no longer know with 100% certainty which exact lands originally belonged in that deck, you would mark it as unverified. But you can add a note stating that the rest of the contents were verified. What about an old theme deck that's been stored loose in a box next to some other decks / cards? Use your best judgment. If you feel confident none of the cards got separated or mixed up despite being loose, then mark it verified and specify it was verified by your opened copy.
The verification method I've come to prefer is unboxing videos. Unfortunately a lot of YouTubers will skip past the lands, but I've found a few sources that do a good job showing even the basic lands.
Thank you as well for your interest, and looking forward to your contributions!
Last edited by meldon44 (2020-12-15 05:33:20)
3 UI
I kinda feel for this no JS style.
But with current SPAs, React etc not having JS is really niche.
And supporting no JS is a real pain in most tech.
I think this expand gradually style is a better approach than table, but it feels it needs some tweaks...
Ctrl + F doesn't work, Some categories are not 100% clear, going 5 levels deep with scrolling in some cases feels weird...
maybe some filtering on top...
maybe a bit streamlined layout, some "go into" optimizations so you don't scroll that much...
wider usable screen space...
I can't pinpoint exact solution though.
I'll try to present some prototype if I find a good idea.
4 Coop
If you have a reasonable directory structure - it is preferred to flat one. I got all CSVs with a script and didn't bother to reorganize them.
Each tree is a choice, so some good criteria would be nice. But in files structure you can search with more tools like find explorer utils, scripts etc.
As for stats i don't know if there are any analytics on github io. Probably not so Bitly might be still needed if it provides value.
If you have all files and upload them to git hub I can abandon my PR.
I just want to be able to PR e.g. adding types of lands to Jumpstart packs.
5 Jumpstart
The idea to have characteristic cards is great.
But still going through that much wasted screen space with constans scrolling is not great:
https://ibb.co/hRCNM7F
And usually you have more than one pack and will scroll back nad forth.
Hmm it worked ok when finding packs i got... it doesn't feel good but is functional. I found files I needed pretty fast.
Last edited by NamespaceV (2020-12-15 12:44:28)
@HeyMerlin — I'm curious about this statement you made: "Having the CSVs on github makes it easier for me to browse them rather than downloading them individually." You're either browsing them in an ugly tabular layout on Github or browsing them through categorical dropdowns.... but either way, you're having to browse to find the one you want, correct? And then unless I'm missing something on Github, you have to download the CSVs individually there, too (is there a way to select multiple files and download just those as a ZIP?). Or I guess you can download/clone the entire repo and do all the browsing on your computer. So unless I'm misunderstanding you, it sounds like it has more to do with the browsing experience. You'd rather a table than dropdowns?
It really depends on what I'm after as to which way I'm going to access the CSVs. The layout you have on the website is great... I like the drop downs. However it is I'd use it so long as I know not only the deck name but also exactly when it was released (part of what expansion). Of course I can look that up. Or perhaps if ctrl-f was working so I could search for the deck name.
Whereas if I do not have all the info, maybe just the deck name or perhaps a partial name, I can search GitHub easily with this info or browse through the file structure and files on GitHub... looking at the contents of the files right on GitHub. I find this quicker and easier in some ways for a couple of reasons:
1. Yep I'm use to GitHub so I have to state that first as I'm likely biased because of it.
2. Looking at the contents of a CSV file on GitHub means I don't have to download it and open it locally (less steps and I'm not opening whatever default program for CSVs which is Excel in my case. The less windows/applications popping up the better). If I then want a copy of the CSV I have a couple of options... copy/paste is almost the quickest and easiest... if I'm browsing anyway.
3. I can search using logicals, and advanced queries.... this wouldn't be used often I expect.
You are probably right in that I'd clone the repo as then I could simply grep the files or file names for what I'm looking for.
I get it, it really is a matter of personal preference. If the search functionality was working on the web page then it is the first spot to look, especially if I just want to get a single CSV so I can import my deck.
GitHub adds flexibility which can be useful.
Perhaps not the most convincing argument but using GitHub is a "value add" feature.
As to your other question: A CSV creation guide is a great idea! Thank you for suggesting it. As someone who does it all the time, it didn't occur to me that saying "make a CSV and send it my way" would be a hurdle. But duh, of course it would. Heh.
Thanks. I've done enough documentation that I'm use to looking at things from a newbie point of view. Also I likely over analyze everything so yep I'm going to have questions! :-)
You know? I've never tried it without proper capitalization, but I imagine it would work. The most important guideline for the CSV is simply... does it import without error?
That said, I personally prefer proper capitalization, and the editor inside of me will probably feel compelled to go correct everyone's capitalization, so.... for my sake, please.
I'm right there with you on that one. :-) It's good to have the preferred way mentioned in a style guide though. Hmm, also... do you expect people to test the CSV by importing it themselves first? (Another point for the guide or FAQ or whatever form of documentation is used)
Thank you as well for your interest, and looking forward to your contributions!
Thanks for taking the feedback and considering the options. I have several precons that I was getting around to adding to DeckBox so this definitely benefits me also.
I checked jumpstart packs I got:
Jumpstart - (B) Phyrexian.csv
Jumpstart - (B) Spooky 4.csv
Jumpstart - (B) Vampires 4.csv
Jumpstart - (B) Minions 1.csv
Jumpstart - (G) Cats 2.csv
Jumpstart - (G) Dinosaurs 3.csv
Jumpstart - (G) Lands 2.csv
Jumpstart - (G) Predatory 1.csv
Jumpstart - (R) Lightning 2.csv
Jumpstart - (R) Smashing 1.csv
Jumpstart - (U) Milling.csv
Jumpstart - (U) Spirits 1.csv
Jumpstart - (W) Enchanted 1.csv
Jumpstart - (W) Heavily Armored 3.csv
They seemed ok but lands were labelled as 6 M21 and all my packs had 2 of each 3 basic lands from the set
I'd gladly do PR splitting those 6 lands to 3 pairs,
It seems all packs have the same structure so i'd change all decks to have 2 of each basic and later fix if any is proven to be different
And i see no "Faction cards" in deckbox so those didn't import, but it was expected
I assume "Jumpstart Front Cards" is just a placeholder name and will be replaced if/when those cards are added to db
Last edited by NamespaceV (2020-12-16 09:05:42)
They seemed ok but lands were labelled as 6 M21 and all my packs had 2 of each 3 basic lands from the set
I'd gladly do PR splitting those 6 lands to 3 pairs,
It seems all packs have the same structure so i'd change all decks to have 2 of each basic and later fix if any is proven to be different
Alright, so things are going to be crazy for me until after Christmas, so as a quick fix, I just went ahead and merged your PR so that you can at least start submitting some of these pack changes. I'll go back and reorganize the CSVs later based on my current folder structure.
Feel free to change all the packs that have 6 M21 (non-showcase) basic lands. However, many of the packs have 5 or 7, so I'd like to see examples of those packs to determine if there's a pattern prior to changing all those CSVs.
When you submit the PRs, please indicate which CSVs have been verified. I of course can just reference your above post, but it'll be good to have it in Github as well.
And i see no "Faction cards" in deckbox so those didn't import, but it was expected
I assume "Jumpstart Front Cards" is just a placeholder name and will be replaced if/when those cards are added to db
By "faction cards", I assume you mean the cards that say e.g. "Plus One" so you know which theme you have? Those are the Jumpstart Front Cards. They didn't use to be on Deckbox, which is why I left the Count column blank, but all 46 have actually been added now. Apparently I just forgot to update the CSVs!
P.S. Congrats on getting the Phyrexian pack! I've heard that one is hard to get, but that swamp is so awesome.
Last edited by meldon44 (2020-12-16 10:46:22)
PR for splitting 6 in 2-2-2
https://github.com/meldon44/mtg-precons … e9a6061244
5 and 7's left unmodified as pattern needs to be confirmed, for all i know they might go random on them
If "Jumpstart Front Cards" were added I can update this part of CSVs.
I opened quite a few JMP packs. There were many cards in the set i liked and didn't have.
Generally got quite good packs but didn't hit Rhystic Study I wanted for EDH related collection part, I'll need to trade for it.
Phyrexian swamp is really unique, and i didn't have Sheoldred
guess now i need to search for Phyrexian Elesh Norn to match... or not 300$... why cant this game be cheaper 
Its really fun to play and collect but many prices are just absurd 
I started collecting in Amonkhet and there is so much backlog to catch up to.
I think im pretty crazy already but there is just way too much stuff.
Assuming packs are equally likely there between those 121 different packs (10+1 Mythic, 30Rare, 80 common packs)
1 in 121 is 0.82%
around 18% chance if you buy a whole 24 pack box
around 54% chance if you open 4 boxes...
to get 90% you need 12 boxes of JMP, and you can still not get one 10% of time...
Guess I'll better just buy Rhystic Study, it is in one pack type only
Edit: found bug in forum, pasting Unicode cry emoji ends post content
Last edited by NamespaceV (2020-12-16 15:57:03)
I'm documenting instructions for converting the downloaded .txt files from MTG Wiki to .csv (with an example of using Visual Studio Code, but I can add Excel also). I have a couple of questions...
1. What is the recommended order of the cards in the .csv file?
* I noticed NamespaceV sorted primary by edition, not sure on the secondary.
2. Should there be any spaces (blank rows) in the .csv file?
* Example: if the deck has a sideboard, or extras...
I'm documenting instructions for converting the downloaded .txt files from MTG Wiki to .csv (with an example of using Visual Studio Code, but I can add Excel also).
Yeah, I would definitely add Excel, since that's likely more common for people to have than the former.
1. What is the recommended order of the cards in the .csv file?
* I noticed NamespaceV sorted primary by edition, not sure on the secondary.
With a few exceptions, I always sort by edition first, then by collector number. NamespaceV was just keeping the original sorting I had.
I have found the easiest way of doing this is importing it into a "dummy" inventory (second account), using Deckbox's native sort, then exporting the sorted version (overwriting the original CSV). This also kills two birds with one stone by testing the CSV for errors at the same time.
However, you do then have to edit the export to remove a bunch of extraneous columns. I also reorder the columns, because I like the foil flag right by the card name (makes it easier to see which is foil at a glance), and I like the collector number to the left of the edition name (partly because of how Excel formats numbers vs text (right-aligned vs left) but more because edition is a mostly unchanging value that I can ignore over on the right, whereas I'd rather see the collector number more easily when editing lands).
2. Should there be any spaces (blank rows) in the .csv file?
* Example: if the deck has a sideboard, or extras...
I mostly only did that with decks that have sideboards. I think I also have done that with some of the products that contain two decks (like Duel Decks). That said, I've changed my approach over time and haven't always gone back to update old CSVs to match new conventions. #lazy
If we're making an official and definitive style guide, then yes, I would like to have any "sections" of the product be clearly delineated. In Excel, it looks best to leave a blank row, then put a section label in all caps in the Name column (second col) after that blank row, and then proceed with the CSV directly after on the next row. Go look at a Challenger Deck such as Cavalcade Charge -- that's the template I'd like to use.
However, let me know if the blank row looks weird or causes issues in other programs. I only ever use Excel to work with CSVs. It would probably be just as effective to not have a blank row, as long as we have an all-caps section label that's easy to pick out. As someone who does a lot of document formatting, I've just grown to appreciate the benefits of white space, hence my inclination to leave a blank line. LoL
Last edited by meldon44 (2020-12-18 11:49:02)
I don't recommend using excel for CSVs - it corrupts data with its magical autoformatting and poor Unicode support.
Unfortunately I haven't found anything better for manual browsing, but wherever you can I do advise using scripts and text editors rather than excel for edits.
Then checking in excel without saving.
As it is easy to break CSV data. Fortunately MTG cards don't use many special characters, long digits or date like digits, so it shouldn't be that bad.
But be careful, excel "helping" breaks things.
https://www.ietf.org/rfc/rfc4180.txt
Empty lines are not CSV compatible. There should be a data row there, CSV does not have comment rows etc.
But i guess as long as it doesn't break import it might improve clarity to some degree...
but some tools might break when rows don't follow same column pattern, so this might hurt when writing automated fixes with scripts.
I only uploaded files I got by crawling page, I didn't change them.
If there is some extra constraints like sorting be edition then collectors number etc we can write e.g. python script to fix/enforce this.
bump for PR:
https://github.com/meldon44/mtg-precons … e9a6061244
splitting 6 lands to proper types, i can fix the ones where i didn't sort by collectors numbers (Islands) if this style is expected
Last edited by NamespaceV (2020-12-19 15:22:35)
Hmm, so for a general process does this work:
1. Find the deck on MTG Wiki and download the txt version
2. Convert as is to CSV using the column headings previously spec'ed.
- adding the expansion, card condition, and language
3. Import to secondary Deckbox account
4. Use Deckbox to modify the cards to the correct card numbers, foil, etc.
- Sort by edition/release
5. Export as CSV file
6. Confirm it is in the format, sorting order, etc. that we want
7. Submit for adding to repository
There are a bunch of details missing but if we can agree on the general procedure I can flush out all the details so we have a complete set of instructions.
2021-01-25 19:43:22164 (100%)I think there is an error with the Above the clouds 3, There is no extra basic island, and there is a Serendib efreet with the windreader sphinx and warden of evos isle
Either that or I got an error pack
I think there is an error with the Above the clouds 3, There is no extra basic island, and there is a Serendib efreet with the windreader sphinx and warden of evos isle
Sounds like you might have an error pack if you had a pack with Serendib Efreet, Warden, AND Windreader. Serendib should only be in Clouds 2, which contains neither Warden nor Windreader. Here's the official decklists that I used to build the CSVs. Check your Above the Clouds pack(s) against those lists and let me know what you find.