Klick'r 4.0.0-beta02

[Nain57]

Important

This is a beta build.
It might be unstable so please backup your scenarios before updating to this version. It will be only available on direct download here, and not on PlayStore/FDroid.

Bug Fixes:

• [i18n] Misspelled values-pt-rBr folder prevents pt-BR overlays strings from loading #876
• Color detection #874
• MRU wonky #845
• False positives when matched region loses saturation but keeps similar grayscale structure #865
• Invalid disabled FPS limit
• Crash during beta01 start when installated over an old versions with a scenario containing a Notification Action referencing a Counter
• Fix OCR model vulnerabilities from dependabot

Note: Yes i know, tutorials are disabled. I have been working on my side to create new ones and they will be integrated in the next beta.

---

This discussion was created from the release Klick'r 4.0.0-beta02.

[vibhor1102]

@Nain57 Seems like the release APKs somehow missed out from being included in 4.0.0-beta02 Assets section. I only see the source code in assets section

[Nain57]

The creation of the release note is trigerring the GitHub action that builds the version. This can take approximatively 30 minutes.
Edit: Build state: https://github.com/Nain57/Smart-AutoClicker/actions/runs/28101874758

[Nain57]

Version is uploaded !

[vibhor1102]

@Nain57 Alright, thanks.

If you'd like to make the workflow more accurate for end user, you can explore into it creating the APKs first and then creating the release.
Check out https://github.com/vibhor1102/Smart-AutoClicker/blob/main/.github/workflows/release.yml containing the workflow i adapted and settled on for my forked repo. The key improvements were in inclusion of cache, and automatically creating the release once the APKs are built.

PS: My forked release from beta1 to beta2 completed in 12 minutes, largely due to cache.

[Mohamed-ayman-901]

This is going near perfection

[CarlFK]

)

I can activate this for the version downloaded from the Play store, but not the beta downloaded from GitHub.

Let me know if you need more details and screenshots, I would provide them now but it's kind of cumbersome and hopefully you know what the problem is without them.

[vibhor1102]

Go to Klick'r app info. There's likely a toggle at the bottom called "Allow restricted settings" it something similar. Try enabling it and then re-giving the permission to display over other apps.

PS: This additional step is only required for sideloaded apps, and therefore, lines up with your observations.

[CarlFK]

Got it.

Not that it matters now, but once I select that, I don't see a way to revoke it.

To get those screen shots I un/re-installed the app.

[entwatchtube]

As you can see number detection is not working when there is a comma in between them now am i doing something wrong or using incorrectly cause it works fine without one which doesnt have a comma

[entwatchtube]

Oh and i m using detection at max resolutioion

[vibhor1102]

I believe it's through an OCR model. So, internally, the model would output a detected number or a string, and that's what is compared to the user-inputted number. However, that OCR output is never shown to users, and I believe it's the real issue and the lack of transparency in this case. The "try condition" more could be reworked to clearly show this output by the OCR model in real time to help us debug our text/number conditions. The % based "difference threshold" seems unused in text/number conditions.

The feature is also new and a huge leap forwards in 4.0.0, so expect refinement for the same in next versions (hopefully 🤞).

[Nain57]

Hi and thank you for your feedback.

Good catch, i haven't thought about this kind of display of numbers, i have created a ticket for that: #966

[Nain57]

Fix will be implemented in beta04.

The problem is, the current algorithm is detecting 43.944 (forty three), so as a workaround, in previous beta, you can change your condition to adapt to this bug: For "43,944" you were using"43944", but if you use "43.944", it will work.