Connect forms with evolution

[AndryCola]

I've noticed that it's impossible to determine how a Pokémon form evolves. Sure, you can search for this information by species, but that doesn't allow you to link a specific form to its evolution condition. So, I've created a new CSV file that I'd like to add, but I can't do it on my own.

The CSV structure looks like this: file: pokemon_form_evolutions.csv fields: pokemon_id, species_id, form_id, evolution_id, is_alternative_evolution

I've already created this file and added the data with the most recent updates.

[Naramsim]

Can you post the first few lines of the CSV file you want to add?

[Naramsim]

You would have to implement the logic for exposing the new data

[AndryCola]

Can you post the first few lines of the CSV file you want to add?

pokemon_id,specie_id,form_id,evolution_id,is_alternative_evolution 2,2,2,1,0

[AndryCola]

You would have to implement the logic for exposing the new data

Yes, I would have done it, but I still don't have the skills to implement the new feature. So I'm forced to ask someone in the repo.

[FallenDeity]

@AndryCola here is a script i wrote for obtaining evolution chain including regional forms, and other branching evolutions as well

https://github.com/FallenDeity/PokeLance/blob/master/examples/evolutions.py

and here is the output result of the script in the script i have noted down all such tricky evolution lines if you feel i have missed any please let me know

evolutions.json

So far i havent really needed any drastic changes to implement this except for a few keyword filters since as you have mentioned the evolution chain is slightly hard to parse in a few cases 😅 especially with the forms added

[joseph-bayer]

@AndryCola here is a script i wrote for obtaining evolution chain including regional forms, and other branching evolutions as well

https://github.com/FallenDeity/PokeLance/blob/master/examples/evolutions.py

and here is the output result of the script in the script i have noted down all such tricky evolution lines if you feel i have missed any please let me know

evolutions.json

So far i havent really needed any drastic changes to implement this except for a few keyword filters since as you have mentioned the evolution chain is slightly hard to parse in a few cases 😅 especially with the forms added

Thank you so much for sharing this! It's really cool to see that there's a way to do this.

[Genschere]

I guess I'm late to the party. I had the same problem so I solved it for myself last November. The difference with my approach is that I kept the layout of the original table and simply added the columns evolve_from_pokemon_form_id and evolve_to_pokemon_form_id instead of the species column.

pokemon_evolution_new.csv

The only thing that is not included here are the regional forms that evolve depending on the current region (like alola-pikachu). I can understand if you have no use for it anymore but I think it is easy to replace the original base data with this.

[GreatNovaDragon]

It is only a patchwork fix for the larger issue the current datamodel provides, that was based upon the thought that was valid before sun and moon that individual forms cannot be its own species.

[Genschere]

The problem actually exists since Diamond and Perl. The 3 different forms of Burmy evolve into 3 different forms of Wormadam. The current model isn't reflecting what form of Burmy evolves into what form of Wormadam. It can be matched by the form identifiers but that's not a clean solution.

My approach simply connects the form ids for the evolution. Except for the regional forms that have the same evolution method, the data should be clean and complete and doesn't require any other changes anything in the model. In _pokemonspecies.csv the column _evolves_from_speciesid could be dropped though.

[GreatNovaDragon]

It doesnt, cause its still Burmy evolves into Wormadam.

Anyways the approach doesnt work with my attempt in #1037 to establish its supposed fuse pokemon_species and pokemon fields, cause that solves most form-based problems that arose since at least 2016.

[Genschere]

Why not? They are actually unrelated because if you fuse pokemon and pokemon_species it leaves pokemon_forms untouched and my approach moves the relation in pokemon_evolution from pokemon_species to pokemon_forms. I don't see any incompatibilities there. I think they actually complement each other nicely.

[GreatNovaDragon]

I'll just quote myself directly from the issue

An Base assumption that veekun did for pokemon_species, which was valid before Sun and Moon introduced regional variants ,was that Forms are a rare occurance with no pokedex entries or own evolution lines. Therefore, for gameplay only things, the pokemon model was created and for dex purposes, the pokemon_species model was created. Since Sun and Moon, gamefreaks handling of forms massively changed. Beginning with Sun and Moon, and expanded in Sword and Shield, Regional Variants have been introduced, which are basically an own species but with the same dex number and name, but in the case of things like Paldean Wooper or Galarian Meowth, evolve into an entire different species than the "Base" pokemon, in the case for Wooper it doesnt evolve into Quagsire but Clodsire. Additionally to Regional Variants existing and having their own dex entries, Forms itself gained their own Pokedex entries, so the base assumption of "Forms not having pokedex entries or evolution lines" is just wrong now.

So, you could just separate pokemon_species into the different forms, or just straight up fuse all the data into the pokemon entry, cause at the point of separation of pokemon_species into the different forms, it would display the same entity but by two different things, which i dont think is good Object oriented Design

[Genschere]

Okay, so you want to merge the pokemon_forms with this as well. I still don't see the problem. In my data (latest DLC data is still missing) pokemon_species has 1017 entries pokemon has 1292 entries pokemon_forms has 1450 entries The current model links the ids from pokemon_species with 1017 entries (which is incomplete and inconsistent).

If you merge all three into one you will end up having 1450 entries (plus latest DLC data). My model links the ids from these 1450 entries and is complete (with the regional same evolution methods inconsistency). So basically if you merge all this data, you'll end up with the result I provided for the evolutions.

[GreatNovaDragon]

I wanted to write a long paragraph, but yes, i want a singular model that shows all 1473 existing forms facing the public, and this is basically best achieved when gotten rid of pokemon_species and pokemon_forms and meld that data into the pokemon model.

i was frankly not aware of the actual pokemon_forms.csv existing, cause most of the problems come from pokemon_species having a base assumption that is just simply wrong now.

Ultimately it doesnt matter to me how its solved in the backend, if i just have a singular Pokemon endpoint, and dont need to ask for additional forms and species endpoints, and the easiest solution is fusing these CSVs with the amount of entries taken from the bigger table.

[Naramsim]

Hi guys, if you like we can start working on a V3beta version! If you are volunteering we can start writing some code.

On my side, I can only help you with the deployment part, since I don't really have time to implement such complicated things now. We can start anew and use or drop Django, same goes for CSVs, we could switch to other formats. Reply if we can on you!

I'll copy this comment over at #1037.