Gen 5 Sprite Sync & Rename Variety

[anhthang]

• Sync Gen 5 Pokémon sprites from the default sprite folder and rename all form/variety assets to match the correct Pokémon IDs
• Add image dimension validation and rename to sprite_audit.py with a structured report summary

[anhthang]

I'm not sure keeping ‎⁠black-white⁠ in sync with ‎⁠sprites/pokemon⁠ is a good long‑term idea, since it effectively duplicates the same assets.

We should probably find a better way to store or link these sprites (e.g. sharing a single source of truth and referencing it per game) so we don't have to maintain multiple copies in sync.

[Naramsim]

I'm not sure keeping ‎⁠black-white⁠ in sync with ‎⁠sprites/pokemon⁠ is a good long‑term idea, since it effectively duplicates the same assets.

We should probably find a better way to store or link these sprites (e.g. sharing a single source of truth and referencing it per game) so we don't have to maintain multiple copies in sync.

True that we have this duplication. Some options:

• is it possible to create a link? Something like 'ln -s'? We could try and see if the images are still served by GitHub
• we could get rid of the black-white folder and in the API link the root sprites for that game.

[anhthang]

@Naramsim Yes, that's what I was thinking as well. I'd like to propose the structure below

• Instead of keeping ‎black-white in sync, we can create a ‎default folder under ‎sprites/pokemon and have ‎black-white point to it (for example via ‎ln -s)
• All folders currently under ‎other would be moved to the root (sprites/pokemon)

sprites/pokemon/
├── default -> versions/generation-v/black-white
│
├── versions/
│   ├── generation-i/
│   ├── generation-ii/
│   ├── generation-iii/
│   ├── generation-iv/
│   └── generation-v/
│       └── black-white/
│           ├── back/
│           │   ├── female/
│           │   └── shiny/
│           │       └── female/
│           ├── female/
│           └── shiny/
│               └── female/
│
├── official-artwork/
├── home/
├── dream-world/
└── showdown/

With this change, we'd also need to update the API so the default link points to ‎sprites/pokemon/default instead of ‎sprites/pokemon, which keeps a single source of truth and lets us switch to any default sprites version later.

What do you think about this structure overall? I'm wondering if it should be included in this PR or handled in a separate one.

[Naramsim]

Hi, we cannot use the default folder you mention. The images are hot linked by thousands of projects, if we move them we break those. So we must keep available the root sprites where they are available now.

[anhthang]

I tried creating a symlink for ‎⁠/pokemon⁠, but it ended up creating ‎⁠black-white⁠ inside instead. I also tried using a ‎⁠default⁠ folder. In both cases I can ‎⁠ls⁠ and see the files locally, but I can’t fetch them via raw.githubusercontent.com. It seems GitHub doesn’t serve files through symlinks, so this approach might not work for us.

Here's the test branch I used: https://github.com/anhthang/sprites/tree/symlink-gen5/sprites/pokemon

[Naramsim]

Yeah, then the last option is deleting the sprites in the generation-v/blackwhite folder and change the API to serve them from the root folder.

Or we leave everything as is and we accept the duplication.

[Naramsim]

Alright, I checked some sprites and they look fine.

I saw that some of them got replaced as the example below:

But I think the new sprite should be the correct one. Could you confirm?

As for the code, I'll leave @FallenDeity to review it if he has some time.

[anhthang]

@Naramsim The new sprites come from the Smogon Gen 9 sheet, while the old ones are from KingOfThe-X-Roads, if I’m not mistaken. They’re also closer to the official artwork.

[anhthang]

Yeah, then the last option is deleting the sprites in the generation-v/blackwhite folder and change the API to serve them from the root folder.

Or we leave everything as is and we accept the duplication.

The black-white folder still serves animated sprites and icons, so I think it's fine to keep it as is for now. In the future, once we can safely deprecate some legacy paths, we can properly restructure the sprites folder.