Open codemonkey85 opened 10 years ago
I almost forgot, moves are included here too.
A bunch of tables need to grow a generation or version group column: pokemon_types, pokemon_abilities, pokemon_stats, type_efficacies... The main hurdle is figuring out a useful API and updating spline-pokedex.
Seems prudent to link to @eevee 's write-up: https://gist.github.com/eevee/6a257a9d42400e2d03f9
...and @duskwuff 's proposed solution: https://gist.github.com/duskwuff/97e1b145b645ce999aa2
Types and efficacy could have this done very easily (by hand) once a schema is agreed upon. Any leads on this matter?
It's worth noting there have been some developments in that department since the last pre-you activity on this issue. The plan for the future is not to use SQL at all, because while all versioning problems can theoretically be solved with it they become exponentially more unwieldy to operate in practice. Here's a proof-of-concept which extracts all the details for Gen 1 from the original ROMs (it tries hard to find all the relevant data even when stuff has been moved around, so in principle it can be used to support ROM hacks and stuff) into the new YAML-based format.
Got it! But will the relational data not be maintained anymore? I did some changes to the TypeEfficacy table (in the csv only) and would like to PR for discussion (if this is even achievable). Of course, it would lead to changes in the docs and probably the Python interface (that is not something I can't just do by myself anyway).
Would you say I am losing my time?
Some types have changed over generations, like the Magnemite family gaining Steel typing, and more notably the recent addition of Fairy types. When using this database for earlier generation games, the types are inaccurate since they only point to the most recent generation's typings. I propose a generation column and extra rows for those Pokemon whose types have changed.