Open xZise opened 3 years ago
I Think we can solve this with a minor refactor. Right now, the flow of data is that OcrHelper::getCandyNameFromImg
returns a single string it thinks is the candy name, and then that eventually gets sent to PokemonNameCorrector::guessBestPokemonByNormalizedName
to try and match it to an actual pokemon name.
The refactor would make it so that getCandyNameFromImg
would return a list of scan attempts, to try and cover all the options. Then guessBestPokemonByNormalizedName
would compare the quality of the best match for each of these attempts and return the optimal one. Then, in case it was a Mega Energy pokemon name, we'd run it through the evolutionCandyName
resource to get the actual candy name.
This presents several problems:
Re 2: I think we can make this work by using the current calibration logic to find the horizontal slice of screen that needs to be checked, and then using the middle third for the 3 item case, and using the right half for the 2 and 4 item cases. I'll try to mock it up and do some tests
When there is Mega Energy or Candy XL for the Pokémon the current recognition doesn't really work anymore.
Originally it was always this:
When Mega Energy was introduced it was displayed in three columns. Additionally it doesn't use the family name for the Mega Energy but instead the name of the Pokémon to be evolved. So it would be "Snover Candy" but "Abomasnow Mega Energy". It would also split the name into two lines usually.
It could also be in the following form:
And lastly if all four items are present they are presented in a 2 by 2 grid: