PokemonSpecies.form_description -> PokemonFamily.description.
More prep for combining the Nidoran and Volbeat/Illumise families.
Again, not strictly necessary. The justification is that families will
need a description and having both columns is silly.
Had to combine a few descriptions. Shellos & Gastrodon and Deerling &
Sawsbuck were easy since they were almost duplicates anyway (supporting
the merge!). Burmy & Wormadam were less similar, so i just pasted them
together. They could probably use a rewrite.
Prep for combining the Nidoran and Volbeat/Illumise families.
This isn't strictly necessary, but it makes sense for the evolution
tables to be "Pokemon"-prefixed since, hey, evolution is a Pokemon
thing.
This solves two problems: first, the relationships are now defined in
the class they apply to, rather than in a separate section of the module,
and second, their metadata -- both creation arguments and extra info such
as `description` (or, later, possibly, info for API properties) -- is
stored.
Some code in spline-pokedex orders by `id`, which has worse consequences
than it may seem (e.g. instead of defaulting to most recent games, the
comparifier defaults to XD). This is the first step to fixing that.
- the Session has a `pokedex_link_maker` property, whose `object_url`
method is used to make URLs in Markdown
- pokemon.names_table.name is now an ordinary Unicode column
- pokemon.name is a MarkdownString that is aware of the session and the
language the string is in
- pokemon.name_map is a dict-like association_proxy of the above
- move.effect works similarly, with transparent $effect_chance substitution
as before
There are now (well, have been for a while) multiple ways to evolve
a Pokémon from its unique parent, so the current schema wasn't working.
The parent Pokémon has moved back to the main pokemon table, and
pokemon_evolution has grown an artificial primary key.
New evolution methods for Milotic, Leafeon, Glaceon, Magnezone, and
Probopass have been added.
English and Japanese. Woo!
The text dump contained a bunch of duplicate location names (possibly
for the Entralink?). I've merged them in the locations table, but
location_game_indices still has the duplicates—that is, a location can
now have multiple game_index values in one generation (necessitating a
small schema change).
