Reticle randomization, real app emulation, delay between requests

[jmoriau]

Hi,

A few questions:

• I noticed that in your CatchPokemon request the reticle size is hardcoded:

                            self.api.catch_pokemon(encounter_id=encounter_id,
                                                   pokeball=pokeball,
                                                   normalized_reticle_size=1.950,
                                                   spawn_point_guid=spawnpoint_id,
                                                   hit_pokemon=1,
                                                   spin_modifier=1,
                                                   NormalizedHitPosition=1)

Same goes for:

hit_pokemon, spin_modifier, NormalizedHitPosition

Isn't it super suspicious to always hit with the same parameters ?
Wouldn't it be better to randomize all the parameters, you could use a weighted random to get 70% excellent catch, 15% great, 10% nice, 5% miss.
Even better would be to randomize those weigthts at each run with a +- 10% difference, because after a few hundred pokemon if you have a 69.9999% execelent, 15.0000001% great etc. would also be suspicious (although much harder for them to detect than it is right now).

This is one of the main reasons which makes me think that, for now, it's too risky to use on your main account and at one point when they're not busy working on the servers infrastructure anymore they're just gonna run a few queries and mass ban everyone with 100% perfect pokeball throws and all the botting will have been for nothing.

• I checked the code and found no mention of CheckAwardedBadges (or your python equivalent), the real app runs this request and 4 others (GetInventory, GetHatchedEggs, GetInventory, DownloadSettings) with every heartbeat. Aren't you worried that if you don't simulate at least a little how the real app behave it will be too easy to detect ?
• In the real app your requests rate is limited by the animations, for example when you evolve a pokemon you can't do anything else for about 15+ secs, when you load a pokestop details (before spinning it) it takes at least 1.5 sec or when you throw a pokeball it takes 1 to 6 secs depending on the outcome before you can do anything.
  Do you respect (at least a little) these delays ? I didn't look very deep, maybe you do but it doesn't seem like it. Because that would also be such an easy way for them to detect botters, check time laps between request and for example if you search a pokestop right after issueing an evolve command => again easy ban.

Other than that it looks really good 👍

[GepLik]

Hello jmoriau,

The behaviour your are describing doesn't exist any more, at least in the dev branch. The type of throw and the spinning force are now randomized , thanks to the dev #1205. It is not fully customisable for now as I stated in the thread, and I am currently working on the weighted parameters to allow to customise the throws at will. I was also worried about the time delay, but it require much more work as this apply for every other parts of the bot too, so it will come later I guess.
Also, due to this bug tejado/pgoapi#157, all the throws are normal throws for now on dev branch.

[jmoriau]

That's great for the pokeball throws, but the delays is really something that should be added before any new feature, at this point there are already plenty of features, the plan now should be to stabilize the code, add a layer of abstraction to queue the requests with varying delays and add the same heartbeat requests than the real application.

After that it should be a bit safer to use.

[GepLik]

The development is driven by the community. If someone wants to stabilize the version and work on the delay, he/she can. And it will surely come soon enough.
To get back to the throwing topic, I have fixed the throw type in the PR #2130. I will clean my code for the randomisation of the type, and will submit a PR asap too.