feat: Audit and add all divergent/regional evolution lines - #1656
feat: Audit and add all divergent/regional evolution lines#1656FallenDeity wants to merge 7 commits into
Conversation
jemarq04
left a comment
jemarq04
left a comment
There was a problem hiding this comment.
This is great! Whenever I've updated the evolutions I've left these "form" fields pointing to Pokemon as they were initially, but this is so much cleaner! Plus the solution for Toxtricity is very clean. I added a few comments and questions here.
As a separate thought, I'm not sure that I am loving the condition expression? It is difficult to read and we don't translate this in any way before it's served. Adding a single field that acts as an arbitrary expression seems too complicated and reads confusing. I know that these are odd conditions to the evolutions, but I feel like we can find a better way to model it. Maybe just additional unique evolution triggers?
|
a few thoughts of mine of the expression side 
this is what an expression looks like in the evolution chain it is a postfix/rpn expression https://en.wikipedia.org/wiki/Reverse_Polish_notation parsing it to a human readable form is trivial and it gives quite a few benefits over an infix expression the expression is actively evaluable by any client consumer programming language agnostic this is not a fixed trigger it depends on values and we can let consumers decide how they are going to display the expression hence variable information and data types are tagged under evolution-variable, they can either make it into human readable via stack operation or evaluate it based on conditions without unsafe elements like evals etc also kind of another distinction is a trigger is a specific event to be met to lead to evolution while condition expression is like a baseline condition that has to be met its not guaranteed pokemon will not release a scenario where there is an expression as such and an event too like even rn a new trigger only would combine level-up + another condition |
|
Vivillon can be easily handled too, but with many lines. The main issue would be Alcremie, awful case, which needs more columns in the trigger file (?) |
|
dont think we need to handle vivillon since any spewpa can evolve into any form based on real world region unless we want the real world mapping we can skip it evolved_form null should just be a catch all to any vivillon form, same for milcery again unless we want all permutation of which sweet + swirl/spin found an exhaustive list for future reference if we ever need to come back to this: https://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_with_form_differences |
…ndant wurmple chain form references
|
Handling Scatterbug → Spewpa → Vivillon should be 40 rows. The key question was whether the pattern is decided at evolution or earlier. Bulbapedia, on the Scatterbug page:
So Scatterbug and Spewpa already carry the pattern from the moment they're generated, even though they look identical. These are 20 real internal forms, and the database already has all of them (20/20/20). A river Scatterbug always yields a river Vivillon. Structurally this is the same as Flabébé → Floette → Florges, where the branch didn't hesitate to add 5+5 rows. Cost: 20 rows off row 342 (spewpa, lvl 9) + 20 off row 341 (vivillon, lvl 12). Two warnings if you take it on:
|
Ah ok, I had not heard of the postfix notation before now and coming from a math/physics background this was a very confusing expression haha! I suppose I now understand the reasoning behind this, but I'm not sure that I'm 100% onboard either. The data we serve is (at least I believe it is) human readable. For example, one could provide the allowed natures being proposed here as a bitmask assuming the user would parse it themselves, but its better to provide it in a human readable way as a list of nature resources as you've done. On the suggestion to use triggers, they have also been used to describe very specific evolutions. For example, we could have stored Gimmighoul's evolution as I'm not totally against using the expression and variables, so if this is the best approach then we should go for it and explain things appropriately in the documentation. I just wanted to see if there were any other options. Maybe we can ping some others to see what they think on this? @Naramsim @notblisy |
3 participants
Change description
Went through a list of complicated/branched evolutions and regional ones to make sure everything being served by pokeapi is accurate and information regarding it is complete
This adds some new evolution information
condition_expression: for some formulaic ones like tandmaus form, dundunsparce, wurmple etc which rely on encryption constant/individual valuesneeds_one_of_natures: for toxel -> amped/low-key (this is 25-bit bitmask field for the natures)base_formandevolved_formfrom pokemon to pokemon-form rationale behind this is pokemon form is the complete store of all variants and some specialized ones which evolutions depend on like burmy, sinistea etc which are more cosmetic variants with no stat changes or differences other than look but they are canon for required evolution base and next forms so moving everything to pokemon form helps with cosmetic evolution dependencies and also acts the same for ones with technical differences since they point to the respective pokemon entry for stats/moves etc without introducing new form specific fields for this use case and future proofs use for more such evo linescases are some pre forms might be cosmetic like burmy but permanent when wormadam, or both pre and post like sinstea line where they have the fake one and the legit one
References:
Context
Fixes: #1199 #1315 #966 #1037
#1086 partially my understanding goes like this pokemon-species is the biological species in the pokedex its concept and lore, then pokemon further adds the mechanical context like stats, movepools, game timeline etc, followed by form which finally adds the cosmetic layer and points back to pokemon if there is a mechanical change so fallback is in order from that abstraction layer
I dont think species should be removed since some regional variants like paldean wooper etc still use the national dex 174 id and not some 1000+ they share similar egg cycles, hatch rate and pokedex based stuff I am of the opinion we can specialize based on the abstraction layer as mentioned above with some minor details we can move around like mentioned below. going with a unified model destroys all abstraction and generates tons of dups of stuff with only cosmetic changes or visual like vivillon, alcremie etc
#1026 partially again since some points do make sense but species should still exist since thats the lore or universal stuff it holds like pokedex has only one entry for rotom and then it differs bw diff mechanical forms removing species would be duplicating all of that, same for gmax, megas etc or any variant pokemon like deoxys, the evo chain changes rn currently solves both of above issues pertaining to this
some arguments such as gender diffs is not technically valid since there is no stat diff and there is visual diffs which is already present as sprites in pokemon form and pokemon
partial because color_id is valid that changes for regional it should go under pokemon-form since its cosmetic imo
prolly a few others since evo chain linking has been a pain point bought up multiple times this should solve that but I agree current pokemon evolution chains are now no longer linear so if anyone is working with similar to what i linked as a tree below they WOULD have to use something like a tree or a graph with trigger conditions as edges if they want a robust solution.
AI coding assistance disclosure
Used AI to review/summarize some of the bulbapedia and pokeapi.fr site pages for proses and info, locate some csv records and flows etc
Contributor check list
A cli tree constructed from our evolution chain data for some of the complicated lines for review
Details