jbatonnet / goontap Goto Github PK

Several test screenshots exhibit an inability to read the candy name.

The Googulator, ProdigiesNation and Rokes screenshot sets don't read any candy name at all, while VLFPH and perhaps others include the word "candy" in the candy name (which on one image, gets misread as "canoy", requiring a workaround).

A more robust way of reading the candy name is needed.

We detect the bottom of the level arc by looking for the lowest white pixel on the left side of the arc area.
This gives us an incorrect (too low) location when the marker is at the very bottom of the arc, due to the
left edge of it hanging off.

Due to this, the level angle feedback gets placed visibly below the marker, and as you drag the Pokemon level bar, it clearly rides below the arc, instead of following it exactly.

This is mostly a cosmetic issue, as valid level angles are fairly sparse at the bottom end. However, it could become a bigger issue if Niantic ever decides to release more player levels. The easiest fix would be looking for a bulge at the 0° end of the arc, and if found, adjusting the arc bottom slightly upwards.

Yesterday I acquired a Lugia with IVs 13/13/15 att/def/sta from a raid. I powered it up to level 27.5 using rare candies, and got a CP of 2792. Suddenly, Go on Tap reported it to have IVs 14/10/15. Digging further, I found that Go on Tap reports Lugia's correct IVs if I manually adjust the CP to 2791.

The cause appears to be slightly inaccurate CP multipliers. I took the whole CP multipliers from the current GAME_MASTER, and recalculated the half multipliers using the known interpolation formula, and suddenly, I get the correct CP of 2792 for my Lugia.

Currently the following formula is used to calculate the position of the level marker on the arc:
public static double GetLevelAngle(double level, int playerLevel) => (Constants.CPMultipliers[level] - 0.094) * 202.037116 / Constants.CPMultipliers[playerLevel];

This is incorrect, as it assumes that the dot is at the end of the arc when level == playerLevel. However, the dot will be at the end when level == (playerLevel + 1.5).

I believe the correct formula is:

public static double GetLevelAngle(double level, int playerLevel) => (Constants.CPMultipliers[level] - 0.094) * 180.0 / (Constants.CPMultipliers[min(playerLevel, 39.0) + 1.5] - 0.094);

I'm not sure if 180.0 is indeed exact (the arc doesn't look exactly like a perfect semicircle to me), or whether the min() is really needed around the playerLevel clamp (I have no screenshots from level 40 accounts to check - I'm assuming it's needed since the max allowed pokemon level is 40.5, which is already attainable at player level 30; levels 41 and 41.5 are unimplemented), but it certainly looks like a more accurate predictor of where the dot will appear.

A few extreme examples, all of which represent fully powered-up pokemon (Pl = player level, Po = pokemon level):
Pl 1.0, Po 2.5 => old formula: 212.0334805 (off the scale, extreme overshoot)
Pl 4.0, Po 5.5 => old formula: 167.5404837 (extreme undershoot)
Pl 31.0, Po 32.5 =>old formula: 178.7632002 (slight undershoot)

All of this come out to exactly 180 with the new formula.

A real-life, not-fully-powered case:
I'm level 31, and have a pokemon powered up to level 30. Go on Tap wrongly detects it as level 31.5 (slight overshoot), manually adjusting to where the circle most closely matches the dot yields level 31 (barely perceptible overshoot). Manually adjusting to level 30 shows significant undershoot.

Automatic detection: Pl 31.0, Po 31.5 => old formula: 177.1213036, new formula: 178.3467437
Manual adjustment: Pl 31.0, Po 31.0 => old formula: 176.2953506, new formula: 177.5150762
Correct level: Pl 31.0, Po 30.0 => old formula: 174.6332321, new formula: 175.8414582

Notice how close the old formula for level 31 is to the new formula for level 30 - just barely higher, consistent with the almost undetectable overshoot seen after manual adjustment.

From reading the code, it looks like the GetLevelAngle function is only used for drawing the feedback circle & dot; actually detecting the dot position is done separately. If you can, please let me know where that code is located, and what formula it's currently using.