Snipping improvements

[YvesHenri]

Snipping now makes sure the target still exists before attemping to catch it;
Spawnpoint and encounter IDs are set/updated whether they're null/blank. This allows the bot to interact with crowd-sourced based apps, since mostly of them dont provide these info, like this one I forked and updated for this bot: https://github.com/YvesHenri/PogoLocationFeeder.

[mention-bot]

@YvesHenri, thanks for your PR! By analyzing the annotation information on this pull request, we identified @mhdasding, @Napator and @chrisle to be potential reviewers

[MZorzy]

altitude?
can snipe from map.pikabot ?

[YvesHenri]

To snipe from http://maps.pikabot.org/ (social), just enable the 'enable_social' flag, but since it's kinda buggy & slow, you can alternatively use the application I posted above.

This commit does not interfere with the old snipping system, instead its an improvement to easily use other third-party JSON results.

[solderzzc]

@YvesHenri buggy and slow ? how did you test the social sniper ?

[solderzzc]

How do you check the sniping pokemon ? You don't have it in the nearby list.

[YvesHenri]

Check against what? If the nearby_pokemons list doesnt contain the target, exists will be kept false, meaning it doesnt or never existed (some feeders provide outdated data). The empty nearby_pokemons list gets extended at line 311, as we can see.

[solderzzc]

This is wrong, you won't have the pokemon in the nearby_pokemons list when encounter by sniping style.

[YvesHenri]

Can you tell me why? I've been testing this for a whole day and results are impressive. Did you even test it?

[YvesHenri]

@solderzzc I honestly dont know why as I havent really dove into the social code part, but if you use both methods, you'll see that social is fairly slower than this feeding app method. Also, by buggy I mean there are LOTS of improvements to be done to it and meanwhile the method above will do it. Anyways, the above changes should not impact on anything. My plan is to refactor this whole file to accept a certain JSON format (global) responses, no matter where you get it from (social, crowd-based websites etc), by being able to specify an address and maybe the corresponding JSON attribute names.

[solderzzc]

@YvesHenri Social sniper isn't slow, but need keep slow by the reason you know. If you want to try, you can set snipe_max_in_chain to a much higher value to see what will happen.

https://github.com/PokemonGoF/PokemonGo-Bot/blob/master/pokemongo_bot/cell_workers/move_to_map_pokemon.py#L343

[YvesHenri]

@solderzzc Changing snipe_max_in_chain does not make social any faster. It does not change how frequent you get feeds. It just takes advantage of the data (doesnt matter if data came from social, or wherever else). What I'm talking about is how frequent social provides you info (and good ones), against the above app. Tell me whats faster, X reports from a single source (social), where X is the number of python bots (this one) with social enabled, or Y reports from multiple sources (multiple bots, multiple crowd-based apps etc), where Y is the number of bot users, legit players + crowd-based apps/websites and more? I don't get why it wouldn't be approved, since it doesnt interfere with the current snipping methods. I took care to leave everything as it is. Everything should work just like before this change.

[solderzzc]

@YvesHenri Ok, let's leave the faster/slower argument aside.
My question is that will the pokemon info(not found by you) be in the nearby_pokemon list?
Also, do you have suggested map server lists as well?

[YvesHenri]

Ok, let me explain again. It checks whether the pokemon param still exists by looping the nearby_pokemon list (which is nothing but the meta cell's wild and non-wild pokemons info) by their IDs. That list gets populated at line 311, like I said above. If thats not what you're wondering, I then deffinitelly dont really know why you're so confused.

[solderzzc]

I really want to know the API sequence difference.
The snipe is very dangerous if send too many API request to server, we don't know how they can currently detect the snipe behavior, previous snipe is just call encounter then set to previous location, even not call heart_beat. The nearby pokemon only can be updated by get_map_object api call, go through your code, there's no such api call, it made me very confusing.
By the analysis I've done, I think your priority is Walk to pokemon but snipe to pokemon is not fully tested.

[solderzzc]

Feel free to reopen, let me close it for now.

[joelgreen]

@solderzzc I believe he is calling the get_map_object api via this line:

https://github.com/YvesHenri/PokemonGo-Bot/blob/ee3a0cdce7eca1db27ccb245e1e35cbdd89c7660/pokemongo_bot/cell_workers/move_to_map_pokemon.py#L305

Which calls this code:

https://github.com/YvesHenri/PokemonGo-Bot/blob/ee3a0cdce7eca1db27ccb245e1e35cbdd89c7660/pokemongo_bot/__init__.py#L687

That calls the find_close_cells(self, lat, lng) method, which contains the get_map_object api call.

This change should allow sniping of pokemon which do not have encounter_ids, most online sources do not include the encouter_id.

It will also protect against users sending malicious or incorrect data through the social feature by first verifying the pokemon exists.

After reviewing the code, I'm going to go ahead and reopen the PR.

[solderzzc]

@joelgreen There're two kinds of snipe:

1. Walk to
2. Teleport
   I'm ok with snipe 1.
   But for teleport, you want to update the map then encounter it?

[MZorzy]

walk to , or keep the car and run to ;-)

[joelgreen]

For snipe type 2, the bot already supports teleport to pokemon if they have the encounter ID. But if the encounter id is missing or invalid the snipe fails, this will request the nearby map cells to get the correct encounter_id.

Events are as follows:

1. Teleport to pokemon
2. Request map cells
3. Encounter pokemon
4. Teleport back
5. Catch pokemon and carry on as normal

This does not trigger a softban, and should have no effect on snipe detection (they know easily regardless). The only concern is to make sure not to request the map cells more than once every 10 seconds.

I've been using similar logic to snipe since before the first hardbans. Since then none of my snipe accounts have been banned, but I expect this will ultimately lead to bans no matter what.

If you want to keep map cell requests to a minimum, you could only request when the encounter id is missing, but you will still have to solve the case that the pokemon data is invalid.

[solderzzc]

@joelgreen That's what I was concerning. We can't request map cell from long distance. Just like bit torrent, you can always cheat to the central tracker, but you can also ban the IP which spammed people. The broker core was already done based on mosca. I can share code with you if you want.

[joelgreen]

@solderzzc If you trust the social source, then I would recommend for @YvesHenri to update this PR to only request map cells if the encounter_id is not present.

This would make it so everything works the same for the social code, but allow for integration of online sources as well.

[solderzzc]

@joelgreen Currently we only have thousands online, I have 3 millions pokemon location saved in one week. We can definitely introduce legit verification based on location/others report/etc.. but there's no spammer at the time. So at least for now, we can trust social source. Everyone contribute, that's the community.

[joelgreen]

@solderzzc It would be interesting to have the bot check the map cells for pokemon from unverified IPs, then share back to the social. Use those results to verify or ban the source. It would only require a rare minority of snipes to actually request the cells.

[joelgreen]

@solderzzc Sniping from the list used by the app @YvesHenri forked (http://pokeapi.pokesnipe.de/) these are some of my pokemon after one night of botting from level
[removed]

[solderzzc]

@joelgreen good night, talk to you more detail tomorrow.

[YvesHenri]

@solderzzc The whole snipping thing is dangerous, regardless what. The bot itself is dangerous. You know that (I hope). Requesting an invalid pokemon encounter/catch is not any safe.

Snipping shall be fully refactored. Assuming most of targets are almost always farther than 1k, moving to it (and also picking forts) is just as pointless.

Please don't close this for no reason.

[solderzzc]

@YvesHenri Agreed, we need a credit system, you need change the PR to not get map data when using social sniper.

[joelgreen]

@YvesHenri Can you refactor this to only request the map cells if theres no encounter_id by default, and allow a config option to always check the map cells, then resubmit? This should provide the most flexibility, while also not forcing users who trust the social data to request extra map cells.

@solderzzc Like you mentioned, we need to request the map cells for pokemon from the map chat, and other maps, as well as online lists. This code will allow for that.

[solderzzc]

@joelgreen The bot send two kinds of data, one to map-chat the other to the bot network. The copy send to map-chat will not have encounter-id, but there's encounter-id in the data send to bot network.

[YvesHenri]

Agreed. Fixed.

[solderzzc]

Looks good for me. Just need resolve conflicts.

[solderzzc]

@YvesHenri will submit another PR.