API: Inconsistent behavior when searching for id of a card with alternative artwork

[Larikk]

I have two queries. Both target the id of a card with alternative artwork.

https://db.ygoprodeck.com/api/v7/cardinfo.php?id=57728571 (Crush Card Virus) https://db.ygoprodeck.com/api/v7/cardinfo.php?id=46986415 (Dark Magician)

The first one "redirects" me to the main entry with all artworks. The id is 57728570 which differs from the query.

The second one returns me a card with the same id and only the the alternative artwork.

Is that intended? If yes, is there some system behind it?

(I prefer the "redirection" btw.)

[AlphaKretin]

I'm not staff and don't know the inner workings of the API, but some information that might be helpful: Dark Magician and Polymerization are unique cases where one of their alternate arts have a unique passcodes on the printed card, where all other alternate arts have the same passcode and systems like YGOProDeck have a different ID solely to differentiate. This would be an explanation for the divergent behaviour here.

[Larikk]

@AlphaKretin Thanks for the info but that does not seem related to that :/

Decode Talker for example behaves like Dark Magician: https://db.ygoprodeck.com/api/v7/cardinfo.php?name=Decode%20Talker https://db.ygoprodeck.com/api/v7/cardinfo.php?id=1861629 https://db.ygoprodeck.com/api/v7/cardinfo.php?id=1861630

There is even an extra '\r' character in the description of one of them so my guess would be that the alternative artwork is a completely separate card in the database.

systems like YGOProDeck have a different ID solely to differentiate

I did not know that, I thought that came from Konami. Would it not be super problematic if Konami ever releases a card with an id that is already unofficially taken? Or is there an offical buffer between ids?

[AlphaKretin]

Thanks for the info but that does not seem related to that :/

Decode Talker for example behaves like Dark Magician:

No worries, sorry that it didn't end up helping. That behaviour is indeed strange. There's a chance it's a case-by-case basis where the alternate art version needs to be set up to redirect based on an alias and it's not applied consistently?

I did not know that, I thought that came from Konami. Would it not be super problematic if Konami ever releases a card with an id that is already unofficially taken? Or is there an offical buffer between ids?

I'm not aware of an official buffer between ids, I believe it's somewhat taken on faith that with literally 10 million possibilities, the chances of 2 being next to each other at all, let alone in the specific case of a card with an alt art, is vanishingly low and while we can't be sure Konami may, in fact, go out of their way to avoid it. No shade on Alan here, I believe he's working with established conventions, but foresight isn't necessarily the highest priority in parts of this community.

[AlanOC91]

Sorry for the delay in this!

I've found the issue and it's released to the beta_id field. However I will need to do a bit more investigation before pushing out a full fix (to make sure I'm not inadvertently breaking something). Crush Card Virus works because each entry references each other within their own beta_id field.

The way I had the query coded was that it will also show all alternative arts when you query by card name but because we are querying by ID now, it can only find other references to the ID you are querying (hence why Crush Card Virus works since it's cross referenced).

Definitely fixable but if you want to avoid it immediately then you can potentially just query the name rather than the ID.

Also thanks to @AlphaKretin for stepping in! Much appreciated.

[Larikk]

Thanks for looking into it Alan!

you can potentially just query the name rather than the ID

That issue came up while I was working on a YDK file importer where I only have IDs. I do not spawn the response directly but store the cards in a cache where they are indexed by their ID and retrieve them later by that ID. That failed with CCV because the card ID did not match the ID the user wanted. I can work around that easily though by checking the artwork IDs when handling the response.

Just to clarify: After your fix will requesting by ID work like with CCV or Dark Magician/Decode Talker? The former would be more convenient for me (I could add an option to spawn a card with all of its artworks later on without doing additional requests) but I can work with both approaches.

I will need to do a bit more investigation before pushing out a full fix

I'm in no hurry regarding that and can work around the current behavior so please dont inconvenience yourself with that if you are busy with other stuff :)

---

Btw, I dont know if you care about what other people do with your API but I use it to create booster packs and import cards in Tabletop Simulator (3D sandbox for arbitrary board and card games). It looks like this atm:

https://i.imgur.com/NWSSPBO.mp4 https://i.imgur.com/p7dngqb.png

[n1xx1]

I also came across this problem.

When you query sets by their name with cardinfo.php, you get inconsistent ids for some cards with alternate artworks. For example for Starter Deck: Yu-Gi-Oh! 5D's, in the cardlist you have Spellbinding Circle with id 18807108, but when you query another set like Starter Deck: Yugi Reloaded it's the correct one (18807109). However in both cases using the cardsetsinfo.php endpoint with the set code, yields the latter one (5DS1-EN034 and YSYR-EN041).

I can easily circumvent this issue by making a call to cardsetsinfo.php for every card with multiple artworks, but I don't want to overload the website for no reason.

I can provide a list of the problematic cards I found if needed.

Thanks.

[Larikk]

@n1xx1

A little bit off-topic and just as a warning: With that approach you won't get duplicates in your cardlist/deck as far as I know (Example: Structure Deck: Fury from the Deep has only 31 hits.) Starter Decks generally do not have duplicates but I'm not sure if that is true for all of them. That may not be an issue for your use case but I wanted to let you know that.