Unonw-A is missing a bunch of sprites

[Skycoder42]

Describe the Bug

Of all the unonw forms, on unown-a (pokemon-form/201) is missing sprite data. It only has two backsprites, all other fields are null.

The interesting part here is, that all other forms (pokemon-form/10001 and above) do have full sprite data available. unown-a is the default for, so one could argue that is no problem, as the pokemon resource should have all sprites of that one as well. However, the unown pokemon resource (pokemon/201) is inconsistent in that manner. It does have sprite data, and most of the point to unown-a images, but the artworks for example are of unown-f, not a, meaning there is currently no way to get the A-Artwork via the API, even though all the others are available.

Note: I did not look into it yet, but that might have to do with #1681 . @FallenDeity may you can confirm whether that is a preexisting issue or a problem introduced by your change?

Steps to Reproduce

• GET https://pokeapi.co/api/v2/pokemon/201 -> Artwork is Unown F
• GET https://pokeapi.co/api/v2/pokemon-form/201 -> Artwork is missing
• GET https://pokeapi.co/api/v2/pokemon-form/10001 -> Artwork is Unown B

Resolving the Bug

Anyone is open to making a PR for this issue.

[FallenDeity]

which set of sprites are u looking at official-artwork?

I added 201 form sprites here but not 201 itself so thats was incorrect from before https://github.com/PokeAPI/sprites/pull/282/changes

a pr updating this is needed https://github.com/PokeAPI/sprites/blob/master/sprites/pokemon/other/official-artwork/201.png

regarding the missing in form that is a bug yeah i am not falling back properly the defautl form has -a identifier but 201 is the default there is no separated 201-a so that fallback needs to be handled

[Skycoder42]

I agree, updating the sprite of 201 would at least make it consistent. But is the fact that unown-a (pokemon/201) has no sprite data attached to it? I guess it is fine if the intended logic is "default form sprites are identical to the pokemon", but that is inconsistent to pokemon that have unnamed default forms. Case in point.

• https://pokeapi.co/api/v2/pokemon-form/200: Is the default form of misdreavus, same number as the pokemon, no form_name. It has all it's sprite data filled with the identical URLs as the ones from https://pokeapi.co/api/v2/pokemon/200
• https://pokeapi.co/api/v2/pokemon-form/201: Is the default form of unown, same number as the pokemon, has a form_name, unown-a. Most of its sprite data is missing, only some URLs are present, all ending in .../201-a.png.

This looks unintentional to me. Could that be a bug in the new logic?

[FallenDeity]

i did mention the reason in my earlier comment it needs a fix, also most of them are not missing versions is mostly fine its the official artwork and showdown etc ill fix that in a pr soon or feel free to make a pr too :) meanwhile u can fallback to pokemon endpoint

the logic for sprite lookup basically needs a small change where we check if its is_default we use the name directly for lookup else we add form suffix

[Skycoder42]

Okay, thank you very much for your quick reply!