Idea: Evolution chains to include Version information

[helblinglilly]

I have recently run into this issue - I don't think it's possible to determine in which version an evolution chain has been added or rather: is applicable to. This can be especially problematic when dealing with location based evolutions such as Eevee or Nosepass.

At the moment, if I wanted to only show evolution details that are version-specific, I can check if the 'from' and 'to' national dex IDs, but nothing beyond. For entries such as locations that only exist in certain versions it becomes very difficult to filter this data accurately.

Eevee can evolve into Leafeon by visiting:

• Eterna Forest: D/P/Pl and BDSP, and therefore 2 generations
• Pinwheel Forest: BW and BW2
• Route 20 in Kalos: XY

I believe both of those problems could be addressed by adding a field in the evolution chain:

evolution_details: [],
evolves_to: [],
is_baby: false,
species: {...},
id: 133,
// New
versions: [
  {
    name: 'black',
    url: 'https://pokeapi.co/api/v2/version/17'
  }
]

This would add a lot of extra data to the response. Another idea is to do something similar to the current /pokemon/id endpoint with past_types?

I'm suggesting such an approach because the issue is not limited to locations, in which case another solution might be more appropriate. See: https://bulbapedia.bulbagarden.net/wiki/Category:Pok%C3%A9mon_that_have_had_their_evolution_method_changed

I would be happy to help out with this where I can

[Naramsim]

hmm, I see your point! But I'm not sure if we can even implement it the way you're suggesting. I don't think there's a link between versions and evolution_chains in our current data schema. This means we would need to implement the code and add in the data. Feel free to try it but we cannot give you much support :(

[helblinglilly]

I've not worked with the data scheme and such before, so even just that is really helpful to point me in the right direction.

Will play around with it over the next week and update on here where I get up to.

[tepiloxtl]

I have stumbled into this issue while working on my own thing. I don't know much about this project, but I might take a shot at implementing this

One thing I'm seeing is that to implement this Id either have to duplicate entries in pokemon_evolution.csv or add entirely new csv with evolution id to version id mapping to map many game versions to one evolution, not sure which approach would be more welcome here

[jemarq04]

Didn’t notice this was an open issue! I was actually thinking about this recently - I think a new field for version group for an evolution would be great. Since most evolutions added in a given version group remain for every other game, we could also add a a is_default field as well. I think this would mean we wouldn’t have to duplicate every entry when a new version is added. Both would be added into pokemon_evolution.csv and would need to be updated in the relevant python files.

Take a shot at it if you’d like - I’ve done a lot of updates to this as well so I can give advice if you have trouble

[tepiloxtl]

Adding is_default would be a good idea for majority of evolution chains, but I don't think theres actually a good way to determine which pokemon exists in which version of the game, except for pokemon_game_indices.csv, which is very out of date now. Then I think the worst case scenario where there still be a lot of duplicate entries will be eeveelutions

[jemarq04]

The default field would still be helpful in those cases. For example, the “default” way to evolve to Leafeon is now a Leaf Stone, but leaving the past evolutions with the Moss Rock is desired so we preserve all information. That’s why I think doing both a is_default and a version_group_id would be needed to best describe a Pokémon’s current and past evolution methods.

Another example is Quilava into Typhlosion has an evolution we added very early on - this would have version group gold-silver and is_default should be 1. However, I believe the level requirement was different in Legends Arceus - so in this case, the version group would be for that game and the default field would be 0. Now we have both evolutions accounted for alongside a clear indicator of what evolution is considered the “main” one as we move forward into new games

[tepiloxtl]

Oh, so you mean, in the data returned from API, we only explicitly state game version for all the non-default evolution methods, and for the default one we just say "is_default: true" and let the user work out which games that relates to. I guess that's fine too. I'll try this in the coming week

[jemarq04]

Well no, the API would provide both of these fields. We don’t filter based on the content of the fields, we just display them all. Each entry in the CSV file should add these two new fields, and we would provide both in API requests. If an application using our API wants to filter based on our setup (such as in the way you described) that would happen elsewhere.

TLDR If the default value is 1, we would still provide the version group. It essentially stands for the version group that added this evolution method

[jemarq04]

Actually, I’ve been working on some schema changes for the evolutions for some clarity on regional evolutions (following up what I had mentioned in #1396), but I think it can be solved simply with a new field. Since I’d be adding a new field to this CSV file already, would you mind if I added these changes as well? I already have the scripts to do so with my working branch.

Of course, since you brought this up in the issue you can take a look if you’d like. I don’t want to make the changes if you would rather do it yourself.

[tepiloxtl]

It's totally fine by me, I'm more about the result of that data being there rather than who and how :)