Add all Champions v1.0 learnsets

[SnorlaxMonster]

Change description

Add all Pokémon Champions learnsets (as of v1.0). Data from https://github.com/projectpokemon/champout/blob/main/masterdata/waza_learn.json

Champions is just a battle sim where you can freely swap moves around, so it doesn't really have a concept of "methods" for learning moves. My solution was to define the new pokemon_move_method "null" at index 0. If it would be preferable to make this a new positive index number, or something else entirely, let me know and I can swap it over.

Notes:

• In the game data, there are 261 entries (for 108 unique Pokémon and 61 unique moves) that are currently disabled. For example, Tsareena is currently coded to learn Magical Leaf, but Magical Leaf is disabled in Champions, so it can't actually be taught that move in-game, and if you transfer one in from HOME that knows Magical Leaf, it cannot use it. I have excluded those disabled moves from this PR, but I can add them if that would be preferred.
• Hangry Mode Morpeko is missing 5 moves that Full Belly Mode Morpeko can learn. This has no impact on gameplay, as in the Box (where you can change its moves) it is always Full Belly Mode. All of the other in-battle-only forms have the same movesets as their base forms.
  • I've just left the raw game data as-is, as there doesn't currently appear to be a way to mark this kind of discrepancy in PokeAPI. The similar (but inverted) case in Sun and Moon where Busted Form Mimikyu learns Surf via TM while Disguised Form Mimikyu does not is not currently marked either.
• Vivillon, Florges, Furfrou, Polteageist, Alcremie, and Sinistcha define separate move data for their different forms, although it is all identical. (In the case of Alcremie, Champions only defines separate learnsets for each cream, and does not distinguish between sweets.) PokeAPI does not define separate pokemon_id values for these forms, so I've had to condense these into single entries per Pokémon, but that doesn't make any functional difference.
• Mega Meowstic has the same moves as the base form of Meowstic (which has different moves depending on its gender), but PokeAPI only assigns a single pokemon_id for Mega Meowstic. Since there's no good way to mark this, I've simply not included any moves for Mega Meowstic at all.

AI coding assistance disclosure

No AI was used in the creation of this PR.

Contributor check list

• I have written a description of the contribution and explained its motivation.
• [N/A] I have written tests for my code changes (if applicable).
• I have read and understood the AI Assisted Contribution guidelines.
• I will own this change in production, and I am prepared to fix any bugs caused by my code change.

[jemarq04]

I would say this is more of a move tutor situation. Plus, I don't think the API can handle IDs below 1. Making a local version of the database shows it assigns them to zygarde-cube instead.

[Naramsim]

Yeah, I'd go with a new ID as well. Something like champions-swap, I don't know the best way to sum up this honestly.

[SnorlaxMonster]

Ah, I see, the API is hardcoded to assume the IDs in pokemon_move_methods.csv directly correspond to a 1-indexed list. So adding a method of ID 0 actually causes every learn method to be offset by 1 (with index 0 wrapping around to the end of the list due to how Python handles index -1 of a list).

That seems like a bug to me. It would also break if any entry were to be deleted from pokemon_move_methods.csv while leaving the subsequent IDs unmodified (e.g. if 9,xd-purification was deleted so that it could be merged with 7,colosseum-purification). The same applies for version_groups.csv (but only those two, it seems). Unfortunately, I'm not familiar enough with the codebase to fix it.

However, I agree that in this case it makes the most sense to just add a new entry to the bottom of the list. Any change to that assumption would belong in a separate PR.

[Naramsim]

Good catch, that's dangerous code. A separate PR is needed

[SnorlaxMonster]

I've moved the Champions method to the end of the list (12).

I've called this new method "Train", reflecting that the corresponding menu in-game is called "Pokémon Training" (under the "Train" option from the main menu) or "Train Pokémon" (from the Box).

[jemarq04]

Mega Meowstic has the same moves as the base form of Meowstic (which has different moves depending on its gender), but PokeAPI only assigns a single pokemon_id for Mega Meowstic. Since there's no good way to mark this, I've simply not included any moves for Mega Meowstic at all.

Do you mean that Mega Meowstic has a different learnset depending on if it's male or female? If so, we should make a pokemon resource for each of them and add the relevant move data to each. Otherwise, we should add the move data to the single Mega Meowstic.

[SnorlaxMonster]

Mega Meowstic has the same moves as the base form of Meowstic (which has different moves depending on its gender), but PokeAPI only assigns a single pokemon_id for Mega Meowstic. Since there's no good way to mark this, I've simply not included any moves for Mega Meowstic at all.

Do you mean that Mega Meowstic has a different learnset depending on if it's male or female? If so, we should make a pokemon resource for each of them and add the relevant move data to each. Otherwise, we should add the move data to the single Mega Meowstic.

Yes. Like all Mega-Evolved Pokémon, Mega Meowstic has the exact same learnset as its base form. But male and female Meowstic have different learnsets, so male and female Mega Meowstic also have different learnsets.

Splitting Mega Meowstic

I've updated pokemon.csv, pokemon_form_names.csv, and pokemon_forms.csv to split Mega Meowstic into separate entries for male and female. I've reused the existing ID for male Mega Meowstic, meaning that female Mega Meowstic is not adjacent (it ends up at the bottom of the list instead). I've also inserted the Mega Meowstic moves I had removed earlier.

In the documentation for Pokémon forms, is_default is described as "True for exactly one form used as the default for each Pokémon." However, it seems like every single Mega-Evolved Pokémon is set to is_default in addition to its base form, and many other multi-form Pokémon have multiple forms flagged as is_default. I've set this field to True for female Mega Meowstic to mirror what all of the other Mega Evolutions are doing, but to me it seems like it should be False for all of the Mega-Evolved Pokémon.

order seems to want forms of the same species grouped together, but is also a simple incrementing integer with no gaps. As a result, to insert a new form of Meowstic I've had to increment the order field for every Pokémon after Meowstic in the National Pokédex. (IMO, this would be better handled similarly to what Champions does internally, where they just allocate the last 3 digits to the form ID and the first 4 to the National Pokédex number, so that inserting a new form doesn't require incrementing all of the others; e.g. Mega Venusaur is 0006001. However, changing that structure would belong in a separate PR, so I've just stuck to what is already there.)

The documentation does actually note "Multiple forms may have equal order, in which case they should fall back on sorting by name", so theoretically it may actually not be necessary to insert a new distinct order value for female Mega Meowstic, but that doesn't appear to be what is actually done in practice.

[jemarq04]

Thanks for the changes. As far as the comments you made, as long as it is in-line with what was done in the past that is good for now. We can always re-evaluate things down the line.

[jemarq04]

I really like your idea for the ordering a lot (maybe a new PR if you're up for it!), but for this PR we should choose one of two options:

1. Set meowstic-female-mega's order to the same as meowstic-male-mega, as the documentation allows that. When I added these new megas I had missed that part of the documentation and that would've made my life much easier lol
2. Keep things as a single increment – throughout this file's changes it's a bit inconsistent. Here you can see it was changed from 1264 -> 1319.

[Naramsim]

I'd go with number 2 compacting the IDs

[SnorlaxMonster]

What I had done was open the CSV as a spreadsheet in LibreOffice Calc, sort by the order column, then filled down.

It looks like currently the Alcremie forms have distinct values for each Cream, but the same cream shares the same order value across Sweets. So alcremie-vanilla-cream-berry-sweet is 1255 and alcremie-ruby-cream-berry-sweet is 1256, but alcremie-vanilla-cream-love-sweet is also 1255.

Not really sure what the best option here is. My current change normalizes everything to be increments of 1 (although I hadn't actually noticed that wasn't already the case). Alternatively, I could keep the equivalence across Sweets for Alcremie forms, and just increment them all by 1 (so all of the Vanilla Creams would become 1256, all of the Ruby Creams would become 1257, etc.).

[jemarq04]

Yes I think for this PR maybe we keep the existing ordering as-is and just increment existing values by 1. I think a re-do of these orderings is probably a good idea at some point, but that’s out of scope for this PR.

[SnorlaxMonster]

While Alcremie was the main culprit, it looks like there are a bunch of other duplicated order values near the bottom of the list too. eternatus-eternamax and venusaur-gmax are both 1291, kubfu and charizard-gmax are both 1292, etc.

For this PR, I'll just increment each of those by 1 as well. Although those seem more broken than the Alcremie duplications.

[jemarq04]

Good catch, sounds good.

[Naramsim]

@SnorlaxMonster Could you pull in the changes and change the 0 move method to the next available grater-than-zero number?

[SnorlaxMonster]

Note that since I created this PR, Champions received the v1.1 update, which adds a bunch of new data to the game, including new Pokémon. I think it probably makes sense to keep this PR as just a v1.0 update, and I can do a v1.1 update in a subsequent PR after this is merged.

[jemarq04]

Yes, that’s a great idea