I've found a bunch more, it seems to be a more widespread issue. Just from looking over the Odyssey spoiler, so far I've found Cursed Monstrosity, Decompose and Gorilla Titan.
I've found a bunch more, it seems to be a more widespread issue. Just from looking over the Odyssey spoiler, so far I've found Cursed Monstrosity, Decompose and Gorilla Titan.
Fixed these and some others I found. Also fixed a bunch of other bugs and added 4 new sets.
Hi Sembiance!
When adapting to the new character for choose abilities, I found a missing dot '.' in the ability text of Blizzard Specter`s first choose ability.
Does every single card have a unique multiverse id? Do promo cards get those?
No. The 'multiverseid' is for cards that are on Wizard's Gatherer site. That site is missing almost every promo card and several card sets, thus many cards do not have multiverseids.
Are the expansion codes for the Eighth/ Ninth Edition starter cards and Coldsnap theme deck reprints official codes? Or did you make them up? Just wondering if there's any chance they could get used by an official set later on.
Are the expansion codes for the Eighth/ Ninth Edition starter cards and Coldsnap theme deck reprints official codes? Or did you make them up? Just wondering if there's any chance they could get used by an official set later on.
I made them up. I figured it's about the same situation as some of the other non official set codes (ATH, ITP, DKM, RQS, DPA).
A few thoughts on the "starter" cards in 8th ed., 9th ed., and M15: For consistency's sake, I was thinking it might make more sense to not have separate sets for the 8th and 9th starter cards.
Of course, the way it is in M15 is a little confusing: there doesn't seem to be a way to distinguish starter cards from normal cards without some kind of analysis of their collector numbers. If a booster pack simulator just went off this data, Terra Stomper might show up in a virtual draft. This wouldn't be as big of a deal with 8th and 9th edition cards because their collector numbers are prefixed with "S".
My suggestion would be to have all starter cards mixed in with the non-starter cards from that set, but either 1: Add a "set size" field to each set (after all, the collector number on every card tells you the size of the set); this would allow you to distinguish M15 starter cards and would just be useful in general (the size of the card array is not always the right value), or 2: have "starter":true present on all starter cards in 8th ed., 9th ed., and M15.
Are the Collector's Edition and International Collector's Edition sets part of this file? I didn't see them so I just want to make sure i haven't missed anything.
If they are not, is there any thought to getting them added?
Another thing I noticed is that the languages seem messed up. Specifically, I was looking at Russian cards and it seems that there are entries for Russian Beta cards (among other sets) and I am pretty sure cards weren't printed in Russian until around 9th Edition.
A few thoughts on the "starter" cards in 8th ed., 9th ed., and M15: For consistency's sake, I was thinking it might make more sense to not have separate sets for the 8th and 9th starter cards.
Of course, the way it is in M15 is a little confusing: there doesn't seem to be a way to distinguish starter cards from normal cards without some kind of analysis of their collector numbers. If a booster pack simulator just went off this data, Terra Stomper might show up in a virtual draft. This wouldn't be as big of a deal with 8th and 9th edition cards because their collector numbers are prefixed with "S".
My suggestion would be to have all starter cards mixed in with the non-starter cards from that set, but either 1: Add a "set size" field to each set (after all, the collector number on every card tells you the size of the set); this would allow you to distinguish M15 starter cards and would just be useful in general (the size of the card array is not always the right value), or 2: have "starter":true present on all starter cards in 8th ed., 9th ed., and M15.
What do you think?
I wasn't even aware that M15 had starter cards, so this is new information to me. I thought this was just a legacy thing they did back then for 8ED/9ED, so that's why I was cool splitting them off into their own sets the same way magiccards.info does. With them doing it again as recently as M15 (and maybe other sets?) perhaps I should reconsider how I handle them. Looks like for Magic 2015 anything numbered 270 or higher is considered from the M15 starter set. Your idea for marking these cards with a 'starter' flag or some other flag is probably the best option. While I'm not in love with removing the 8BS/9BS sets and re-merging them with 8ED/9ED, I know I also don't want to have to make 'Starter Set' or 'Boxed Set' for Magic 2015 and every future core set they release in the future. Let me think about this some more before acting. Thanks a lot for the heads up and suggestions!
Are the Collector's Edition and International Collector's Edition sets part of this file? I didn't see them so I just want to make sure i haven't missed anything.
If they are not, is there any thought to getting them added?
Don't have them up there yet. I have added them to my To-Do list
Another thing I noticed is that the languages seem messed up. Specifically, I was looking at Russian cards and it seems that there are entries for Russian Beta cards (among other sets) and I am pretty sure cards weren't printed in Russian until around 9th Edition.
Oh, and thanks for doing this.
I actually do this on purpose. If a card is reprinted in a later set and gets a foreign language translation in that set, I apply those foreign language names to all previous prints of that card. I figured it would be useful for folks who use this data in apps. However, due to myself doing this, the presence of foreign language names does not mean that the card was printed in that language in that set. So if folks were using that field to determine this fact, that's not doable with my data.
Honestly some day I'd like to add full foreign language files for sets that have foreign language releases, but that's a big undertaking and I'm in no hurry to do it (despite numerous requests for it).
As far as changing the retroactive foreign language data... not sure I'm ready to jump on board with that yet.
Hmmm... is there any way of having a standardized UID for each card ever printed, which would be kept in sync with MTGJSON updates?
It's fairly simple to make your own, given Wizards' own rules about naming. If you want a UID for a card (where "card" means what it does in the MTG rules -- that is, it doesn't care about printing edition), just use the English name. By the rules they can never re-use those. If you want a UID for each printing, Set Code + English Name comes pretty close. MTGJSON has updated set codes a few times, but those updates are fairly rare.
Private Mod Note
():
Rollback Post to RevisionRollBack
My MTG Site: Graceful Stats (deckbuilding website that actually works on mobile)
@Sembiance: Would it be possible to generate and maintain UID's for those cards without multiverse ID directly in MTGJSON? Even something along the lines of "mtgjsonID00001", "mtgjsonID00002", "mtgjsonID00003", etc. I'm sure it would simplify a lot of the things with cards without a proper ID.
I am hesitant to provide such a thing as I try to limit any MTGJSON specific data to a bare minimum. Also it adds some additional complexity to updates I make to the data in the future as I need to either ensure or not ensure the ID remains the same if I correct for errors or set codes or names change. In general I feel each app and website is going to store the data in a different way anyways, so I figure any sort of unique id system should probably be left on the app/website side that consumes the data. Note: I could be wrong on this opinion
It's unfortunate that Wizard's Gatherer site doesn't have multiversid's for all their cards. That said, how are people designing their MySQL tables using the JSON data? I'm most curious how Sembiance, you set up yours, as you're the most familiar with MTGJSON.
I currently have 3 tables, "cards", "sets", "extras" with the JSON data parsed accordingly. I have it setup so the set code exists in both the "cards" and "sets" table to get set information if needed. For UIDs I just added an integer ID to all the cards. How have other people set theirs up, especially Sembiance?
Thank you for creating MTGJSON it's wonderful work and I'm using it to build a deck building site.
It's unfortunate that Wizard's Gatherer site doesn't have multiversid's for all their cards. That said, how are people designing their MySQL tables using the JSON data? I'm most curious how Sembiance, you set up yours, as you're the most familiar with MTGJSON.
I currently have 3 tables, "cards", "sets", "extras" with the JSON data parsed accordingly. I have it setup so the set code exists in both the "cards" and "sets" table to get set information if needed. For UIDs I just added an integer ID to all the cards. How have other people set theirs up, especially Sembiance?
Thank you for creating MTGJSON it's wonderful work and I'm using it to build a deck building site.
Hello
I actually have never imported the data myself into a different database. I just work directly with the JSON. So I myself have no UID system for the cards. Sorry I don't have better news for you.
Hi there, I just encountered a UID related problem here aswell.
I started using the JSON files around Journey into Nyx and imported the cards into an MySQL table. Essentially every card has ID, name and other properties. The ID is unique and represents the order in which the cards were added to the database, which in turn should represent the order of the card names in the JSON-files.
Today I updated to the latest version containing the commander 2014 cards. By doing so I empty the cards table and reread the whole JSON file.
This somehow messes up the ID's of some cards. For example rolling thunder had ID 2901 before and now has ID 2911, which is really bad for me.
Until now I had the assumption that new cards are just added to the end of the JSON file, but maybe it works different.
Could I fix this problem by parsing the AllSets.json file instead of the Cards.json file? The files are quite large and I find it hard to figure out how the new cards are added to these files.
About the problem of multiple versions of a card: I have several other databases, one for all magic sets (including promo and so on) and one 'card set relation (CSR)' database.
Now if i want to specify that my rolling thunder card is from the 'Battle Royal Box Set' I would represent the card by the row of the CSR database looking like this:
(2901, 49) where the first number is rolling thunders ID and the second number is the ID of the Battle Royal Box Set in my set database.
Maybe one would like to put the set-related card properties (like flavortext) into the CSR database and thus extending the tuples.
I actually have never imported the data myself into a different database. I just work directly with the JSON. So I myself have no UID system for the cards. Sorry I don't have better news for you.
Still good to know.
Also suggestion, it'd be nice to add an underscore to the promo files so for example, pFNM.json would be _pFNM.json. This makes it so all the promo files are together when sorted alphabetically.
That reminds me, do all cards other than promos have multiversid's so the only files I have to watch out for are the one's that start with a lowercase p or are there other exceptions? This may be good to add to the documentation.
Really enjoying the JSON files!
EDIT: Nevermind, you already have the multiversid information in your docs.
Come to think of it, "SET CODE + card.imageName" should be a unique identifier for the card. Normally "SET CODE + card name" would be a unique identifier, but some sets have multiple cards with the same name, but with different art, etc. In these cases the imageName property on the card is unique per same named card. So set code + imageName should yield a 100% unique ID for the card.
Come to think of it, "SET CODE + card.imageName" should be a unique identifier for the card. Normally "SET CODE + card name" would be a unique identifier, but some sets have multiple cards with the same name, but with different art, etc. In these cases the imageName property on the card is unique per same named card. So set code + imageName should yield a 100% unique ID for the card.
I was thinking of doing this myself. It's a pretty good solution assuming the card.imageName never changes. In worst case scenarios you would just have to rename the image file name so card.imageName would not have to change.
Also I would recommend not hashing for those doing something similar. I initially hashed with md5 and found some overlaps. It's bound to happen since there are so many magic cards. As far as I can see, there are two alternatives, no hash at all (I chose this), or encryption. But there's no reason to do the encryption as far as I can see because I just need a unique identifier. I used setCode-imageName (with a dash between them, no spaces). Also uniqid in php does not work because it's based on time so when reimporting or updating the database the UID wouldn't match.
Developer here. Sorry if it's been asked before, but what would you recommend for getting the image of the actual card? (original card frame, i.e. a scan of a card)
This won't work, unfortunately, because of cards with two spells on them eg. Crime//Punishment, which share the same image name.
Anyways, I prefer nondescriptive UID's, so I came up with this solution:
SHA256 of a string made of "(imagename)(setcode)(multiverseid)(name)".
If there's no multiverseid, I use "-1".
Testing on current DB yields no duplicates.
Good catch. Now I have to go back and modify the UID again. Also couldn't you use, (imageName)(setCode)(cardNumber)? I'm thinking of doing this based on what you told me.
As for nondescriptive UID's, I like them too, however there's an increasing chance of overlap as more cards are added later. I just want it to be future proof as possible.
When using md5, I had about 30ish overlaps. sha256 is 256bit and md5 is 128bit so probability wise sha256 is a lot better but there's still a chance of overlap.
AFAIK cards like Crime//Punishment have the same card number, so this wouldn't work.
As for the overlapping issue, using multiverseid should prevent it in the future. One could use sha512, but IMHO that'd be an overkill.
The card number for Punishment is 150a and Crime is 150b. Notice the a and b difference.
The hash is just a checksum. It takes the input data and outputs a 512/256/128 bit number. The multiverseid in the hash won't prevent overlap.
I was thinking of doing this myself. It's a pretty good solution assuming the card.imageName never changes. In worst case scenarios you would just have to rename the image file name so card.imageName would not have to change.
This won't work, unfortunately, because of cards with two spells on them eg. Crime//Punishment, which share the same image name.
Anyways, I prefer nondescriptive UID's, so I came up with this solution:
SHA256 of a string made of "(imagename)(setcode)(multiverseid)(name)".
If there's no multiverseid, I use "-1".
Testing on current DB yields no duplicates.
Yes, imageName doesn't change. I've only changed it once for about 2 cards that I had a bug for and had the wrong imageName. So relying on it as part of a UID is a safe thing to do.
As for the split cards, I forgot about those cards. Adding the 'name' field to the UID as well should be sufficient. Not all cards have a multiverseid field, so really just setCode+imageName+cardName should be a unique enough identifier.
Fixed these and some others I found. Also fixed a bunch of other bugs and added 4 new sets.
Fixed.
No. The 'multiverseid' is for cards that are on Wizard's Gatherer site. That site is missing almost every promo card and several card sets, thus many cards do not have multiverseids.
I made them up. I figured it's about the same situation as some of the other non official set codes (ATH, ITP, DKM, RQS, DPA).
Minouris's Library - Collection manager and deck builder. It's nifty - Check it out!
Of course, the way it is in M15 is a little confusing: there doesn't seem to be a way to distinguish starter cards from normal cards without some kind of analysis of their collector numbers. If a booster pack simulator just went off this data, Terra Stomper might show up in a virtual draft. This wouldn't be as big of a deal with 8th and 9th edition cards because their collector numbers are prefixed with "S".
My suggestion would be to have all starter cards mixed in with the non-starter cards from that set, but either 1: Add a "set size" field to each set (after all, the collector number on every card tells you the size of the set); this would allow you to distinguish M15 starter cards and would just be useful in general (the size of the card array is not always the right value), or 2: have "starter":true present on all starter cards in 8th ed., 9th ed., and M15.
What do you think?
If they are not, is there any thought to getting them added?
Oh, and thanks for doing this.
I wasn't even aware that M15 had starter cards, so this is new information to me. I thought this was just a legacy thing they did back then for 8ED/9ED, so that's why I was cool splitting them off into their own sets the same way magiccards.info does. With them doing it again as recently as M15 (and maybe other sets?) perhaps I should reconsider how I handle them. Looks like for Magic 2015 anything numbered 270 or higher is considered from the M15 starter set. Your idea for marking these cards with a 'starter' flag or some other flag is probably the best option. While I'm not in love with removing the 8BS/9BS sets and re-merging them with 8ED/9ED, I know I also don't want to have to make 'Starter Set' or 'Boxed Set' for Magic 2015 and every future core set they release in the future. Let me think about this some more before acting. Thanks a lot for the heads up and suggestions!
Don't have them up there yet. I have added them to my To-Do list
I actually do this on purpose. If a card is reprinted in a later set and gets a foreign language translation in that set, I apply those foreign language names to all previous prints of that card. I figured it would be useful for folks who use this data in apps. However, due to myself doing this, the presence of foreign language names does not mean that the card was printed in that language in that set. So if folks were using that field to determine this fact, that's not doable with my data.
Honestly some day I'd like to add full foreign language files for sets that have foreign language releases, but that's a big undertaking and I'm in no hurry to do it (despite numerous requests for it).
As far as changing the retroactive foreign language data... not sure I'm ready to jump on board with that yet.
It's fairly simple to make your own, given Wizards' own rules about naming. If you want a UID for a card (where "card" means what it does in the MTG rules -- that is, it doesn't care about printing edition), just use the English name. By the rules they can never re-use those. If you want a UID for each printing, Set Code + English Name comes pretty close. MTGJSON has updated set codes a few times, but those updates are fairly rare.
I am hesitant to provide such a thing as I try to limit any MTGJSON specific data to a bare minimum. Also it adds some additional complexity to updates I make to the data in the future as I need to either ensure or not ensure the ID remains the same if I correct for errors or set codes or names change. In general I feel each app and website is going to store the data in a different way anyways, so I figure any sort of unique id system should probably be left on the app/website side that consumes the data. Note: I could be wrong on this opinion
Do you have a way of dealing with multiple versions of cards in the same set with the same name?
Which reminds me that I should have a look at how the alternate art foils from intro packs for Khans are handled...
Minouris's Library - Collection manager and deck builder. It's nifty - Check it out!
I currently have 3 tables, "cards", "sets", "extras" with the JSON data parsed accordingly. I have it setup so the set code exists in both the "cards" and "sets" table to get set information if needed. For UIDs I just added an integer ID to all the cards. How have other people set theirs up, especially Sembiance?
Thank you for creating MTGJSON it's wonderful work and I'm using it to build a deck building site.
Hello
I actually have never imported the data myself into a different database. I just work directly with the JSON. So I myself have no UID system for the cards. Sorry I don't have better news for you.
I started using the JSON files around Journey into Nyx and imported the cards into an MySQL table. Essentially every card has ID, name and other properties. The ID is unique and represents the order in which the cards were added to the database, which in turn should represent the order of the card names in the JSON-files.
Today I updated to the latest version containing the commander 2014 cards. By doing so I empty the cards table and reread the whole JSON file.
This somehow messes up the ID's of some cards. For example rolling thunder had ID 2901 before and now has ID 2911, which is really bad for me.
Until now I had the assumption that new cards are just added to the end of the JSON file, but maybe it works different.
Could I fix this problem by parsing the AllSets.json file instead of the Cards.json file? The files are quite large and I find it hard to figure out how the new cards are added to these files.
About the problem of multiple versions of a card: I have several other databases, one for all magic sets (including promo and so on) and one 'card set relation (CSR)' database.
Now if i want to specify that my rolling thunder card is from the 'Battle Royal Box Set' I would represent the card by the row of the CSR database looking like this:
(2901, 49) where the first number is rolling thunders ID and the second number is the ID of the Battle Royal Box Set in my set database.
Maybe one would like to put the set-related card properties (like flavortext) into the CSR database and thus extending the tuples.
Still good to know.
Also suggestion, it'd be nice to add an underscore to the promo files so for example, pFNM.json would be _pFNM.json. This makes it so all the promo files are together when sorted alphabetically.
That reminds me, do all cards other than promos have multiversid's so the only files I have to watch out for are the one's that start with a lowercase p or are there other exceptions? This may be good to add to the documentation.
Really enjoying the JSON files!
EDIT: Nevermind, you already have the multiversid information in your docs.
I was thinking of doing this myself. It's a pretty good solution assuming the card.imageName never changes. In worst case scenarios you would just have to rename the image file name so card.imageName would not have to change.
Also I would recommend not hashing for those doing something similar. I initially hashed with md5 and found some overlaps. It's bound to happen since there are so many magic cards. As far as I can see, there are two alternatives, no hash at all (I chose this), or encryption. But there's no reason to do the encryption as far as I can see because I just need a unique identifier. I used setCode-imageName (with a dash between them, no spaces). Also uniqid in php does not work because it's based on time so when reimporting or updating the database the UID wouldn't match.
Good catch. Now I have to go back and modify the UID again. Also couldn't you use, (imageName)(setCode)(cardNumber)? I'm thinking of doing this based on what you told me.
As for nondescriptive UID's, I like them too, however there's an increasing chance of overlap as more cards are added later. I just want it to be future proof as possible.
When using md5, I had about 30ish overlaps. sha256 is 256bit and md5 is 128bit so probability wise sha256 is a lot better but there's still a chance of overlap.
The card number for Punishment is 150a and Crime is 150b. Notice the a and b difference.
The hash is just a checksum. It takes the input data and outputs a 512/256/128 bit number. The multiverseid in the hash won't prevent overlap.
This is awesome. If I had the money I'd send Sembiance a box of boosters.
Yes, imageName doesn't change. I've only changed it once for about 2 cards that I had a bug for and had the wrong imageName. So relying on it as part of a UID is a safe thing to do.
As for the split cards, I forgot about those cards. Adding the 'name' field to the UID as well should be sufficient. Not all cards have a multiverseid field, so really just setCode+imageName+cardName should be a unique enough identifier.
Glad you find the sites useful. No need to send me anything, I haven't played MTG in over a year and helping out others is it's own reward