goiv-devs / goiv Goto Github PK

(Moved fromxZise/14)

PokemonNameCorrector::getCandyNameEvolutionCostGuess tries to guess the current pokemon by matching the evolution cost that was read to the expected evolution cost for the species in the evolution line. However, purified pokemon cost less to evolve, which means these number won't line up and the function will fail, additionally, there are pokemon that when traded cost 0 candy to evolve, which also breaks this function

    compileOnly 'org.projectlombok:lombok:1.16.20'
    annotationProcessor 'org.projectlombok:lombok:1.16.20'

compileOnly line can be removed as annotationProcessor will do the work

In the Power Up screen after appraisal, the icon for regular candy is used to represent XL candy needed.
We should get/make an XL Candy icon to use instead

A great feature would be scanning during the catch of a pokemon to see possible IV and estimated level (including needed candy to power up)

(Moved from #xZise/8)

It seems that when dealing with the manual calibration screen, the app forgets to adjust for the fact that the screenshot is not full screen, leading to a plethora of issues.

First of all, if you press manual adjustment after recalibrating, all the fields are displayed in locations that are unrelated to the displayed screenshot. This seems to be because they are being placed relative to the device's screen, instead of relative to the screenshot.
Furthermore, once you complete calibration, the scan hardly works, probably again because of a bug in the adjustment between fullscreen and screenshot location

Here's a bunch of screenshots I took to try and help show this.

First, how the fields move around between auto and manual calibration

Auto scan results	Initial manual calibration	after manual calibration

next, here is an image extracted from within the app running of debug mode, where I've drawn where its attempting to find each value. They are unlabled, but its possible to understand what its looking for in each one. I'm showing the final manual calibration again for comparison, and its quite obvious that all the fields are squished up an to the left of where they should be, with things closer to the bottom right corner being moved more.
I'm not 100% sure why this is the case, but my guess is that the app isn't properly accounting for the size of the border around the screenshot when initially displaying and then storing the manual config, and instead just storing the absolute location of the fields relative to the device screen

Where the app is looking	manual calibration

If you open the clipboard tab and then enter settings menu from there, changes to the toggles controlling different clipboard strings for single result / prefect IVs don't take affect until backing out of the clipboard tab and reentering it.

Rename the "master" branch to "main" to remove unnecessary references to slavery and replace them with more inclusive terms.
https://github.com/github/renaming

    implementation 'com.android.support:support-v4:27.1.1'
    implementation 'com.android.support:appcompat-v7:27.1.1'
    implementation 'com.android.support:preference-v7:27.1.1'
    implementation 'com.android.support:recyclerview-v7:27.1.1'
    implementation 'com.android.support:design:27.1.1'
    implementation 'com.android.support:cardview-v7:27.1.1'
    implementation 'com.android.support:palette-v7:27.1.1'

Should migrate these libraries to the androidX versions of the libraries for future compatibility

Currently, anything defined as a separate form by the Game Master is imported into GoIV.
This needlessly raises the complexity and fragility of form detection and makes the manual drop-down needlessly long.

Some attempt should be made to filter forms that are mechanically identical (in terms of stats)
I'd appreciate feedback about how to handle it in the manual drop-down.
Currently, next to each option it names the form (e.g. Deerling - Spring Form, Deerling - Winter Form)
Should we now list all forms on the line? (e.g. Deerling - Spring/Winter Forms) I'm afraid this will make the lines too long.
If so, I assume it makes sense to filter costume form names?

Stretch goal: Add a generic no-evolve costume form where relevant so that the Power Up tab after appraisal doesn't suggest evolving pokemon that can't be evolved (e.g. Halloween Bulbasaur)

Popup button should always request calibration if calibration version is outdated

JCenter has been deprecated,

https://jeroenmols.com/blog/2021/02/04/migratingjcenter/

Should migrate away from jcenter -> mavenCentral()

    implementation 'com.android.support.constraint:constraint-layout:1.1.0'
    implementation 'com.android.support:support-annotations:27.1.1'
    implementation 'com.google.guava:guava:24.1-android'
    implementation 'com.google.code.gson:gson:2.8.2'

    testImplementation 'org.mockito:mockito-core:1.10.19'

These libs should be updated to the latest versions (Use renovate or something to help keep these up to date)

No point having a min API lower than 23.
Normal Pokemon Go app has Min of Android 6 (23) so might as well match that (and make life easier)

(Moved from xZise/6)

The first field you select when manually calibrating won't properly load the values for the sliders, meaning both of them stay at the far left. If you don't set both sliders yourself, when you tap to the next field, it will save the 0, 0 values for the first field, turning it into a tiny sliver that can't be selected, which also makes it impossible to fix this after the fact other than by starting the process over

For future updates we need target sdk 31+

https://developer.android.com/google/play/requirements/target-sdk
Starting in November 2022, app updates must target API level 31 or above and adjust for behavioral changes in Android 12.

(Moved fromxZise/12)

A pokemon being shadow or purified can affect the cost for powering up pokemon, OcrHelper::refineLevelEstimate should account for this. Fixing this probably involves scanning for power up stardust cost and using that too, although that could cause issues with lucky pokemon...

com.crashlytics.sdk.android:crashlytics:2.9.2@aar is deprecated,
Migrate to Firebase Crashlytics 17

Target SDK needs updating to 30 (Android 11)
This is the latest version (currently) of Android so gives you access to the latest platform features and compatibility.
Min SDK version can stay where it is

Seems to be flaky at detecting the right evolution / form, should be looked into

(Moved fromxZise/13)

Currently, the Evolve Cost scan function (OcrHelper::getPokemonEvolutionCostFromImg) has some logic to avoid accidentally reading garbage from the new attack button. Similar logic needs to be introduced for the mega evolve button.

I think the way the new attack button is detected is by looking for a stardust cost. Since Mega Evolving doesn't require a stardust cost, this fails for it.

Also, since the attacks now appear between the power up and new attack buttons, I think this logic can be removed

Pokemon GO dropped support for Android 6, so we can as well.
https://niantic.helpshift.com/hc/en/6-pokemon-go/faq/3455-discontinued-support-for-android-6/