-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
BUG cluster #2184
Comments
@marco208 you mean that the bot closes after sometime ? Why not use a bash script to restart it if it quits ? |
I think what he's saying is that it'll run for a bit, then it'll start giving you the "Server seems busy" error. I've seen this too just this evening. It'll go fine for a few min, then it'll start getting that message. If I let it sit for a while, it'll go longer, but still hit this wall eventually. UPDATE: Latest logs show that I get this error every single time when the bot "arrives at destiny" which is what the OP's log says too [00:13:34] Move to destiny. 2 lured pokestops will be in range of 50m. Arrive in 56.1677103184m. |
Could that happen because of niantic throttling (look at #2171)? Because I can't recreate. |
I have this happen occasionally, it could very well be due to rate limiting as @MFizz suggests |
It happens to me only on Windows server 2012, while running OK on windows 8 with same configuration, same account, within same network. |
It looks like the "follow cluster" task relies on the bot's fort cache. The bot currently loses the fort cache when the server responds with no forts in the cell update. You're less likley to run into this issue if you have more forts around you that are being spun by you or have lures being placed or expiring around the time of the "follow cluster" task's tick/update. If no forts have been updated since your last cell update request, the server's cell response will not include any forts which will currently clear the bot's internal fort data. If the "follow cluster" task is trying to make a call to the server based on a null fort reference, then the server is going to time-out or reject the request. I fixed this in #2269 It seems like the failure to retain fort data is causing several issues. |
Expected Behavior
stay connected
Actual Behavior
disconnects
Steps to Reproduce
use cluster
[07:54:32] No lured pokestops in vicinity. Search for normal ones instead. Move to destiny. 3 lured pokestops will be in range of 50m. Arrive in 16.7865123168m.
[07:54:36] No lured pokestops in vicinity. Search for normal ones instead. Move to destiny. 3 lured pokestops will be in range of 50m. Arrive in 15.6602194739m.
[07:54:41] No lured pokestops in vicinity. Search for normal ones instead. Move to destiny. 3 lured pokestops will be in range of 50m. Arrive in 9.98004002201m.
[07:54:45] No lured pokestops in vicinity. Search for normal ones instead. Move to destiny. 3 lured pokestops will be in range of 50m. Arrive in 5.99300669829m.
[07:54:48] Arrived at destiny. 3 pokestops are in range of 50m.
[07:54:50] Server seems to be busy or offline - try again - 1/5
[07:55:00] Server seems to be busy or offline - try again - 1/5
[07:55:08] Server seems to be busy or offline - try again - 1/5
^C[07:55:09] Exiting PokemonGo Bot
[07:55:09]
[07:55:09] Ran for 0:03:39
[07:55:09] Total XP Earned: 50 Average: 820.58/h
[07:55:09] Travelled 0.31km
[07:55:09] Visited 1 stops
[07:55:09] Encountered 0 pokemon, 0 caught, 0 released, 0 evolved, 0 never seen before
[07:55:09] Threw 0 pokeballs
[07:55:09] Earned 0 Stardust
[07:55:09]
[07:55:09] Highest CP Pokemon:
[07:55:09] Most Perfect Pokemon:
The text was updated successfully, but these errors were encountered: