Skip to content

Unonw-A is missing a bunch of sprites #1687

Description

@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.

Activity

  1. added theissue type on Sep 26, 2026
  2. FallenDeity commented on Sep 26, 2026

    @FallenDeity
    Contributor

    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

  3. Skycoder42 commented on Sep 26, 2026

    @Skycoder42
    Author

    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?

  4. FallenDeity commented on Sep 26, 2026

    @FallenDeity
    Contributor

    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

  5. Skycoder42 commented on Sep 26, 2026

    @Skycoder42
    Author

    Okay, thank you very much for your quick reply!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions