You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The idea behind that was that a null field meant that the slot was previously empty. For the Bulbasaur example, that's saying that until that generation Bulbasaur didn't have a hidden ability in slot 3. I added that detail to the docs for the model: https://pokeapi.co/docs/v2#pokemonabilitypast
That being said, if you have other ideas on how to do this we can definitely explore it.
ah I see that was a bit confusing so it shows null to say the slot was empty till that particular generation or the pokemon didn't have that ability, but as such then don't we also require an equivalent record saying even the 2nd normal ability slot is null or empty upto the most recent generation for a more complete view (in case of bulbasaur for example)
I think a better way to indicate this might be just adding version groups on the abilities > ability fields is that feasible that way we can see which generation that ability came to be, and the past ability fields can have the concrete records of historic abilities then its a diff bw past ability slot + vg vs current ability slot +vg if past ability has nothing then it was null for that slot till that vg
this seems cleaner over a record null holding slot for all normal and hidden abilities for gen 3 and gen 5 intro since its more like a global pokemon setting than per pokemon
Yes, you're right that we should also have something to show that slot 2 was empty for Bulbasaur and other related cases - this was a change I added myself and it seems like I missed some entries.
I'm open to updating abilities with what you're suggesting (adding a version group to pokemon_abilities.csv), in which case pokemon_abilities_past.csv and its related endpoint can likely be removed. If we do something like this, I think we'd want to also want to update pokemon_past_stats.csv and pokemon_past_types.csv to be consistent.
Additionally, the moves are done in a very different way, so it would be nice if we could converge on a consistent format across these endpoints. I'll ping @notblisy since this was touched on in another issue recently (#1423).
Activity
jemarq04 commentedon Aug 2, 2026
The idea behind that was that a
nullfield meant that the slot was previously empty. For the Bulbasaur example, that's saying that until that generation Bulbasaur didn't have a hidden ability in slot 3. I added that detail to the docs for the model: https://pokeapi.co/docs/v2#pokemonabilitypastThat being said, if you have other ideas on how to do this we can definitely explore it.
FallenDeity commentedon Aug 2, 2026
ah I see that was a bit confusing so it shows
nullto say the slot was empty till that particular generation or the pokemon didn't have that ability, but as such then don't we also require an equivalent record saying even the 2nd normal ability slot is null or empty upto the most recent generation for a more complete view (in case of bulbasaur for example)I think a better way to indicate this might be just adding version groups on the abilities > ability fields is that feasible that way we can see which generation that ability came to be, and the past ability fields can have the concrete records of historic abilities then its a diff bw past ability slot + vg vs current ability slot +vg if past ability has nothing then it was null for that slot till that vg
this seems cleaner over a record null holding slot for all normal and hidden abilities for gen 3 and gen 5 intro since its more like a global pokemon setting than per pokemon
jemarq04 commentedon Aug 25, 2026
Yes, you're right that we should also have something to show that slot 2 was empty for Bulbasaur and other related cases - this was a change I added myself and it seems like I missed some entries.
I'm open to updating abilities with what you're suggesting (adding a version group to
pokemon_abilities.csv), in which casepokemon_abilities_past.csvand its related endpoint can likely be removed. If we do something like this, I think we'd want to also want to updatepokemon_past_stats.csvandpokemon_past_types.csvto be consistent.Additionally, the moves are done in a very different way, so it would be nice if we could converge on a consistent format across these endpoints. I'll ping @notblisy since this was touched on in another issue recently (#1423).