-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion: fewer excellent throws #192
Comments
this is my try, in |
Does the suggested spin_modifier actually work? It seems that I get API errors when I put a float there. But setting this to 0 or 1 works. There's some discussion of spin_modifier and normalized reticle size in the PokemonGo-Bot that we branched from, with their code at https://github.com/PokemonGoF/PokemonGo-Bot/pull/1205/files and discussion at PokemonGoF/PokemonGo-Bot#2488. According to the discussion, normalized_reticle_size should be between 1.0 and 1.95 and spin_modifier should be between 0.0 and 1.0. But from what I see, a fractional spin_modifier is trouble. Still haven't figured out what normalized_hit_position means. |
Bot should also drop the ball (would that be hit_pokemon=False?) from time to time to be more human-like. This can be restricted to just dropping red balls. |
What should the distribution of reticle size and spin be? Reticle size can probably be a slightly skewed normal distribution, but spin might be a little trickier. (Thinking of a bimodal distribution for that one) |
currently the bot throws all balls with spin=1, this can be modified via: ./plugins/catch_pokemon/init.py: line 115:
which would make the spin probability about 70% and non-spin 30%. The reticle size is already a little bit random - though I have to admit that I quite understand the logic as the API is said to send reticle size between 0..1.
The factor 200 might make the random factor too small - trying a different number to see the difference if any. |
Not quite what I meant here; for spin I meant something like https://upload.wikimedia.org/wikipedia/commons/e/e2/Bimodal.png Most players either choose to explicitly spin or not spin and often switch between the two, hence that distribution (IMO). |
And I'm thinking of the same thing for normalized_hit_position |
Wow, the server is picky with those messages... I got a perm ban after 1 try with probably wrong values... |
Here is the branch: https://github.com/OpenPoGo/OpenPoGoBot/tree/feature/throw. |
I recommend you use numpy for this instead of using built-in random.gauss. There was a bit of a discussion in the Slack regarding why. |
We can. But numpy felt like a big hammer for what I've tried to achieve. I'll take a look at the discussion. |
Yes, but my reasoning is that spin is not actually a normal distribution; most people don't "halfway" spin if you know what I mean. Either they do or they don't, so the distribution actually isn't normal. |
Agree. There is what I did. Default config is a 70% probability of spinning . Then a normalized distribution only if the user is spinning. |
A distribution white a steap curve because if you throw you try to do it good. |
Arguably the distribution is bimodal. One peak around, say, 0.05 (since even straight throws by humans will have a little bit of spin) and the second around 0.8 or whatever. |
I've read that everything below 0.5 is sent as 0. That is why I did that. |
actually when you try to send anything but 1 or 0 for spin then you get a server error msg (btw: the 3 coming back is not a perma-ban, it's an actual error that goes away if you send 0 or 1 again for spin. (with whatever the distribution is being rounded to 0 or 1. Now on the reticle size - that indeed is sent as a float. |
Guys, just a random thought... Just like we know that only valid spin values are 0.0 and 1.0, what if they have a set of possible valid values for other float fields, i.e. you may have seen reticle size values 1.0, 1.45 and 1.95 but that doesn't make all values from 1.0 to 1.95 valid. For example what if official game client has a code to exclude 1.23-1.28 range for reticle size, etc. You get the idea... so easy to ban third party clients that just send random values. It would be better to capture the API requests with MitM (for example using Xposed on Android) while playing with official app and then using actual encountered values for bot API calls. All my OpenPoGo based bots were banned after they reached lvl 20+. I was running with super conservative settings, different IPs and so on. I wonder if anyone has better experience. I will start fresh with https://github.com/rubenvereecken/pokemongo-api and current version of AeonLucid POGOProtos as a base, and go very slow from there, making sure every API request I send has correct values filled in. |
I don't have an android device, but agree we need more real data. |
Expected Behavior
The bot shouldn’t consistently trigger “excellent throw” bonuses.
Actual Behavior
The bot consistently triggers “excellent throw” bonuses. This results in better exp/hr, sure, but it also makes it quite obvious that a bot is being used. No human throws that well every time.
There should be an option to determine how perfectly the bot throws its Pokéballs on a scale from, say, 0 (human-like, even misses sometimes on common Pokémon) to 5 (never misses, always triggers an “excellent throw” bonus, i.e. the current behavior).
Steps to Reproduce
N/A
Other Information
OS: N/A
Git Commit: dec09ff
The text was updated successfully, but these errors were encountered: