More fields in past_values for moves
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 5.4k
- Forks
- 1.2k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 21
Description
Hey,
first of all, I am not sure if this is a bug or simply not implemented yet.
When looking at the data for moves, I saw that some move changes are not represented in the API.
If a move has changed behavior for stat changes or ailment chance, it still has a past_values entry but with nothing meaningful inside.
Examples:
-
Fire Blast:
The move's burn chance has changed from 30% to 10% after gold-silver. There is a past_values entry for gold-silver, but the ailment_chance change is not shown. All other values inside the entry are null, so it would seem, nothing is changed at all. -
String Shot:
String Shot's status effect has changed since gen VI from speed -1 to speed -2. Here is also a past_values entry, but with no meaningful changes listed. The entry is for sun-moon instead of x-y, but that seems to be an issue with the veekun entry that is wrong.
So in summary there should also be fields for meta, stat_changes and effect_entries inside a past_values entry to also reflect changes that are not just power, accuracy, pp or type.
Maybe the effect_changes field was intended to be used for this purpose, but is currently always empty (at least in the few examples I have checked). However, it would be better to just list all the changes in the past_values entry anyway, imo.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by comparing the move endpoint data for Fire Blast and String Shot with their documented historical changes. Check how past_values currently represents power, accuracy, PP, and type, then determine how meta, stat_changes, and effect_entries should be represented; done means those historical changes are exposed meaningfully in the API.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100