Suggestion: fewer excellent throws

[tegob]

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: dec09ff59257c5c0728c3edc957fee5e3b974701

[robertyu]

this is my try, in ./plugins/catch_pokemon/__init__.py , throw_pokeball function. bot.api_wrapper.catch_pokemon(.... change to be spin_modifier=random.uniform(0.1*random.uniform(1,7),1). but I think normalized_reticle_size still too high to easy get pokemon. but I am not sure the value range...

[cantelope]

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 https://github.com/PokemonGoF/PokemonGo-Bot/issues/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.

[xasdf]

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.

[wchill]

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)

[OhJayGee]

currently the bot throws all balls with spin=1, this can be modified via: ./plugins/catch_pokemon/init.py: line 115:

• spin_modifier=1,
• spin_modifier=round(random.random()+.2),

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. ./plugins/catch_pokemon/init.py: line 112:

• normalized_reticle_size=1.950 - random.random() / 200,
• normalized_reticle_size=1.950 - random.random() / 90,

The factor 200 might make the random factor too small - trying a different number to see the difference if any.

[wchill]

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).

[niicojs]

I've started an implementation. For spin, you can can configure a probability of spin (like 0.5 to spin one of of two). Then if you spin, you get a normal distribution centered on 0.8. For example for 3000 spin I get this:

[niicojs]

And I'm thinking of the same thing for normalized_hit_position

[niicojs]

Wow, the server is picky with those messages... I got a perm ban after 1 try with probably wrong values... (Edit: wrong alert, code 3 also mean "your data look like shit" apparently)

[niicojs]

Here is the branch: https://github.com/OpenPoGo/OpenPoGoBot/tree/feature/throw. I lack some real game data to know if this make sense or not.

[wchill]

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.

[niicojs]

We can. But numpy felt like a big hammer for what I've tried to achieve. I'll take a look at the discussion.

[wchill]

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.

[niicojs]

Agree. There is what I did. Default config is a 70% probability of spinning . Then a normalized distribution only if the user is spinning.

[niicojs]

A distribution white a steap curve because if you throw you try to do it good.

[wchill]

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.

[niicojs]

I've read that everything below 0.5 is sent as 0. That is why I did that. We get back to the point where we need real dump to see how the game does it 😀 If <0.5 is not 0 as I thought, then agree bimodal is probably the way to go.

[OhJayGee]

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.

[xasdf]

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.

[niicojs]

I don't have an android device, but agree we need more real data.

[OhJayGee]

oh - and normalised_hit_position seems to be 0 or 1 only as well based on server answers. Either you hit the pokemon or you don't as a result. Should be a distribution safe to be high 90++s for hit.