[Login] Support Google 2-Factor #16
Labels
Comments
|
Workaround should be app passwords: |
|
Seeing as most accounts may get banned, it's not really good to use ones real google account with 2-Factor. |
|
Well using better techniques than teleporting should avoid getting banned |
|
Till that you can use an app password: https://support.google.com/accounts/answer/185833?hl=en |
|
I already proposed that as a fallback solution |
Closed
coderplay
pushed a commit
to coderplay/PokemonGo-Bot
that referenced
this issue
Aug 3, 2016
Previously, when user configured use_lucky_egg as true, the bot will use lucky egg even evolvale candidates is zero. That's kinda of waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will try to evolve after sort by cp&iv, but sometimes no good potential pokemon in that batch, it's better delay the evolution after a while. By adding a config item evovle_num_min can cope above two problems. The bot evolves only if evolvable candidates no less than a certain number. 1. Evolve only if evolvable candidates no less than a certain number. 2. Dragoniar's configuration is abnormal in pokemon.json, which lack of "Previous evolution(s)" attribute, while the other middle-tier pokemon has. Fixed some issues after: Refactor evolve_all worker PokemonGoF#2244 1. The refactoring try to sort by pokemon index desc which is not good. For example, why Venusaur which is PokemonGoF#3 should be with lower priority than Pidgey(PokemonGoF#16)? 2. The refactoring always use dict.get(key, {}).get(key, {}) which will eventually return a {} which will cause side effect. It's better fail fast when the dict has no attribute which is unexpected by the developer. 3. The reafctoring try to use cache when the pokemon is not evovlable. That developer doesn't know previously we didn't caculate the candy before evovling, thus caused a lot of failure when evovling. After caculating candy requirements by the refactoring and this patch, the failure rarely happens. Thus cache is not necessary when the pokemon is not evovlable.
coderplay
pushed a commit
to coderplay/PokemonGo-Bot
that referenced
this issue
Aug 3, 2016
Previously, when user configured use_lucky_egg as true, the bot will use lucky egg even evolvale candidates is zero. That's kinda of waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will try to evolve after sort by cp&iv, but sometimes no good potential pokemon in that batch, it's better delay the evolution after a while. By adding a config item evovle_num_min can cope above two problems. The bot evolves only if evolvable candidates no less than a certain number. 1. Evolve only if evolvable candidates no less than a certain number. 2. Dragoniar's configuration is abnormal in pokemon.json, which lack of "Previous evolution(s)" attribute, while the other middle-tier pokemon has. Fixed some issues after: Refactor evolve_all worker PokemonGoF#2244 1. The refactoring try to sort by pokemon index desc which is not good. For example, why Venusaur which is PokemonGoF#3 should be with lower priority than Pidgey(PokemonGoF#16)? 2. The refactoring always use dict.get(key, {}).get(key, {}) which will eventually return a {} which will cause side effect. It's better fail fast when the dict has no attribute which is unexpected by the developer. 3. The reafctoring try to use cache when the pokemon is not evovlable. That developer doesn't know previously we didn't caculate the candy before evovling, thus caused a lot of failure when evovling. After caculating candy requirements by the refactoring and this patch, the failure rarely happens. Thus cache is not necessary when the pokemon is not evovlable.
coderplay
pushed a commit
to coderplay/PokemonGo-Bot
that referenced
this issue
Aug 3, 2016
Previously, when user configured use_lucky_egg as true, the bot will use lucky egg even evolvale candidates is zero. That's kinda of waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will try to evolve after sort by cp&iv, but sometimes no good potential pokemon in that batch, it's better delay the evolution after a while. By adding a config item evovle_num_min can cope above two problems. The bot evolves only if evolvable candidates no less than a certain number. 1. Evolve only if evolvable candidates no less than a certain number. 2. Dragoniar's configuration is abnormal in pokemon.json, which lack of "Previous evolution(s)" attribute, while the other middle-tier pokemon has. Fixed some issues after: Refactor evolve_all worker PokemonGoF#2244 1. The refactoring try to sort by pokemon index desc which is not good. For example, why Venusaur which is PokemonGoF#3 should be with lower priority than Pidgey(PokemonGoF#16)? 2. The refactoring always use dict.get(key, {}).get(key, {}) which will eventually return a {} which will cause side effect. It's better fail fast when the dict has no attribute which is unexpected by the developer. 3. The reafctoring try to use cache when the pokemon is not evovlable. That developer doesn't know previously we didn't caculate the candy before evovling, thus caused a lot of failure when evovling. After caculating candy requirements by the refactoring and this patch, the failure rarely happens. Thus cache is not necessary when the pokemon is not evovlable.
This was referenced Aug 3, 2016
coderplay
pushed a commit
to coderplay/PokemonGo-Bot
that referenced
this issue
Aug 13, 2016
Previously, when user configured use_lucky_egg as true, the bot will use lucky egg even evolvale candidates is zero. That's kinda of waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will try to evolve after sort by cp&iv, but sometimes no good potential pokemon in that batch, it's better delay the evolution after a while. By adding a config item evovle_num_min can cope above two problems. The bot evolves only if evolvable candidates no less than a certain number. 1. Evolve only if evolvable candidates no less than a certain number. 2. Dragoniar's configuration is abnormal in pokemon.json, which lack of "Previous evolution(s)" attribute, while the other middle-tier pokemon has. Fixed some issues after: Refactor evolve_all worker PokemonGoF#2244 1. The refactoring try to sort by pokemon index desc which is not good. For example, why Venusaur which is PokemonGoF#3 should be with lower priority than Pidgey(PokemonGoF#16)? 2. The refactoring always use dict.get(key, {}).get(key, {}) which will eventually return a {} which will cause side effect. It's better fail fast when the dict has no attribute which is unexpected by the developer. 3. The reafctoring try to use cache when the pokemon is not evovlable. That developer doesn't know previously we didn't caculate the candy before evovling, thus caused a lot of failure when evovling. After caculating candy requirements by the refactoring and this patch, the failure rarely happens. Thus cache is not necessary when the pokemon is not evovlable.
coderplay
pushed a commit
to coderplay/PokemonGo-Bot
that referenced
this issue
Aug 13, 2016
Previously, when user configured use_lucky_egg as true, the bot will use lucky egg even evolvale candidates is zero. That's kinda of waste. Meanwhile, if user didn't configured use_lucky_egg, the bot will try to evolve after sort by cp&iv, but sometimes no good potential pokemon in that batch, it's better delay the evolution after a while. By adding a config item evovle_num_min can cope above two problems. The bot evolves only if evolvable candidates no less than a certain number. 1. Evolve only if evolvable candidates no less than a certain number. 2. Dragoniar's configuration is abnormal in pokemon.json, which lack of "Previous evolution(s)" attribute, while the other middle-tier pokemon has. Fixed some issues after: Refactor evolve_all worker PokemonGoF#2244 1. The refactoring try to sort by pokemon index desc which is not good. For example, why Venusaur which is PokemonGoF#3 should be with lower priority than Pidgey(PokemonGoF#16)? 2. The refactoring always use dict.get(key, {}).get(key, {}) which will eventually return a {} which will cause side effect. It's better fail fast when the dict has no attribute which is unexpected by the developer. 3. The reafctoring try to use cache when the pokemon is not evovlable. That developer doesn't know previously we didn't caculate the candy before evovling, thus caused a lot of failure when evovling. After caculating candy requirements by the refactoring and this patch, the failure rarely happens. Thus cache is not necessary when the pokemon is not evovlable.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some Google accounts use 2-factor authorization. Login for 2-factor currently fails.
The text was updated successfully, but these errors were encountered: