Skip to content
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

Evolve only if evolvable candidates no less than a certain number. #2421

Closed
wants to merge 215 commits into from

Conversation

coderplay
Copy link

Evolve only if evolvable candidates no less than a certain number.

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.

SteffanLong and others added 15 commits July 24, 2016 23:04
**Short Description:** 
pokemon_spawn_locations.json is a file that I accidentally added to a previous PR, it doesn't have a purpose in the project at the moment.

**Fixes:**
- Remove pokemon_spawn_locations.json
try now no conflict..
added features and shifted most over to wiki
cleaned up some errors.
added me to contrib list :)
* Update ISSUE_TEMPLATE.md

* Update ISSUE_TEMPLATE.md
…emonGoF#2305)

* Fix instance where evolve_all is unicode

* Test for isinstance basestring rather than Unicode || str
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
Copy link
Author

Also fixed some issues after: Refactor evolve_all worker #2244

  1. The refactoring try to sort by pokemon index desc which is not
    good. For example, why Venusaur which is No Pokemon #3 should be with lower
    priority than Pidgey([Login] Support Google 2-Factor #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.

@achretien
Copy link
Contributor

Hi

  1. We don't really care about priority between Pokemon 16 and 3 as they don't use the same candies. It was more about 2 and 1 which are using the same candy family. In my case I would prefer evolving 2 before 1 to get 3. Maybe we should add a flag to choose between behaviors.
  2. I just did use the same method used in the other parts of the code.
  3. We can effectively calculate all the possible evolutions before starting the evolution loop. I also think your method to find candy family better than mine.
  4. We should make a PR with an unminified JSON file to avoid ununderstable change on this file.

@coderplay
Copy link
Author

coderplay commented Aug 3, 2016

@achretien Thanks for your reply. With no offense, probably just different coding style. :) Let me explain more.

  1. I have a further patch to automatically evolve mid-tier pokemons like Ivysaur, Metapod or Pidgeotto which have further evolution. I tried to reserve candies for mid-tier pokemons with better potential (a.k.a better iv/cp) otherwise because the basic tier pokemon like Bulbasaur, Caterpie or Pidgey will be eariler to reach the candy requirement than their upper levels. In order to avoid starvation of the upper evolution, I rely on the sort, otherwise I might need to resort it again among those pokemons in the same family. From the literal meaning of those config options of 'first_evolve_by', there is no pokemon index, right? I think just keep the literal meaning with no surprise is better.
  2. For example, below code will pass an empty inventory_items if one of those key doesn't exist. It might have some side-effect to the subsequence calls.
 inventory_items = response_dict.get('responses', {}).get('GET_INVENTORY',{}).get('inventory_delta', {}).get('inventory_items', {})
evolve_list = self._sort_and_filter(inventory_items)
  1. Yeah, totally agree! It's anti-human. :)

lucasfevi and others added 9 commits August 3, 2016 16:21
* bye bye `logger.log`, hello event system!

* fixing travis build

* trying to fix travis build

* test fixes

* updating remaining `logger.log` calls that should be replaced

* typo

* typos in IncubateEggs event

* improved fort loot event data

* fixing update_location event's distance unit

* fixing some events and log stuff

* adding missing fort_name parameter to lured_pokemon_found event

* fixing a variable inside an event formatted string

* fixing typos and utf8

* trying to fix tests with regards to float precision

* adding command to print all registered events and their parameters

* fixing tests yet again

* trying to fix unicode issues, arrgh!!!

* added a move to lured fort event

* better distance text in move to fort and fixing utf8 in spin fort task

* removing print from websocket server

* start embedded server before creating the socketio_handler

* I hate unicode

* rename and sleep events

* refactoring in how we emit events to avoid code repetition

* PokemonCatch task inherits from BaseTask

* go away, dirty logger.log!

* pep8 and removed logging handler name attribute

* good bye for the remaining logger.log calls

* bye logger module

* no more logger imports!

* removed last few loggers

* removing secret file and fixed variable name in follow cluster

* fixing kwargs for event emit

* trying to fix unicode handling one more time

* now it works!

* fixing more logs and removing debug unicode string

* no logs on websocket server yet

* adding a script to start a standalone websocket server

* more adjusted in websocket to support multiuser

* adding a fallback to logger.log issues a very verbose deprecation warning

* putting back compatibility with json based web ui
* correct parsing evolve_all

Previously, 

```
 "evolve_all": "Pidgey, Caterpie, Weedle",
```

would only evolve Pidgey. This PR fix that.

* fix parsing evolve_captured
* Adding Raven to send exception reports to Sentry

* Removing test exception

* Removing incompatible python3 analytics library

* Using logger.log

* Using the correct logger
added information about the API changes and where to find information.
* Added bot broken message at top of page.

* Changed REAME.md to mirror PokemonGoF#2590

* Reordered
vdubus and others added 27 commits August 12, 2016 00:44
For better sorting on pokemon's name, format iv_pct on 3 digits.
* Fix typo in config

* Fix all configs

* Fixed __init__.py thanks to @hklcf
…okemonGoF#3593)

* Update setup.sh

* fixed for mac creating encrypt.so

* for now just do wget or curl

* this is all in the setup.sh

* updated instructions to reflect setup.sh changes

* Update installation.md

* Update CONTRIBUTORS.md

* Update setup.sh

* Update installation.md

* Update installation.md

* Update installation.md

* added missing submodule update

* Update installation.md

* Update installation.md

* Update installation.md

* Delete install.sh

* Update .gitignore

* Update installation.md

* Update setup.sh

* Update installation.md

* Update run.sh

add `source bin/activate` if someone forget to use virtualenv.
…GoF#3411 (PokemonGoF#3496)

* Fix PokemonGoF#3411. Update inventory info before every catch try otherwise old values used

* Revert "Fix PokemonGoF#3411. Update inventory info before every catch try otherwise old values used"

This reverts commit f7678da.

* Modify pokemon_catch_worker.py to use Inventory class

* Fix forgotten line

* Fix one more forgotten line

* Added check if we really used berry or not

* Fix KeyError in inventory.py
When we have no items of type, there are no "count" key in the dict.

* Revert "Fix KeyError in inventory.py"

This reverts commit ed2769c.

* Revert "Added check if we really used berry or not"

This reverts commit 42e9d9c.

* Revert "Fix one more forgotten line"

This reverts commit 5fda3c4.

* Revert "Fix forgotten line"

This reverts commit a8edc57.

* Revert "Modify pokemon_catch_worker.py to use Inventory class"

This reverts commit 5b6e4d3.

* Modify pokemon_catch_worker.py to use Inventory class and fix PokemonGoF#3411
* Add Use Ultraball (PokemonGoF#1)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add Use Ultraball if No Other Balls (PokemonGoF#2)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add New Contributor

* Revert "Add Use Ultraball" (PokemonGoF#4)

* Use Ultraball If No Other Balls (PokemonGoF#3)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add New Contributor

* Remove 'use_ultraball' event.

* Remove `use_ultraball` event call

* Update & add avoid catching Pokemon if no pokeball

* Update conflict contributors

* Add get `min_ultraball_to_keep` from config file

* Improved `min_ultraball_to_keep` with condition

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Add `min_ultraball_to_keep` option

* Remove count all pokeballs

* Resolved Conflicts
…nd evolve (PokemonGoF#3738)

* Add and Remove pokemon from the inventory cache when catch and release

* Add dealing with evolved pokemon also

* Add the evolved pokemon
MoveToMapPokemon behavior 
related to issue PokemonGoF#3736 (discussed with @k4n30)
* added bool option to cache recent forts -crf --forts.cache_recent_forts (default true)

saves recent_forts in data/recent-forts-{username}.json on spin

loads recent_forts from same file on start up

bot doesn't start a new recent_forts on every reset

* forgot contributor

* typo fix no_cached_forts

* changed all events related to caching forts to debug level

* caching of forts happens on sigterm/exception

handling of SIGTERM
-Note handling of SIGTERM in python2.7 with multi threads is not reliable.  Child thread can recieve SIGTERM and it is not handled in pokecli.py; pokecli.py continues to run.
* Add Use Ultraball (PokemonGoF#1)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add Use Ultraball if No Other Balls (PokemonGoF#2)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add New Contributor

* Revert "Add Use Ultraball" (PokemonGoF#4)

* Use Ultraball If No Other Balls (PokemonGoF#3)

* Add `use_ultraball` event to Event Manager

* Add use ultraball if pokeball + greatball = 0

* Add New Contributor

* Remove 'use_ultraball' event.

* Remove `use_ultraball` event call

* Update & add avoid catching Pokemon if no pokeball

* Update conflict contributors

* Add get `min_ultraball_to_keep` from config file

* Improved `min_ultraball_to_keep` with condition

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Added `min_ultraball_to_keep` option

* Add `min_ultraball_to_keep` option

* Remove count all pokeballs

* Resolved Conflicts

* Change from `items_stock` to `ball_count`
…or 'nickname_template' option (PokemonGoF#3756)

* Add type information and classes

 - New classes:  Type, Types
 - Usage of new classes anywhere in the Inventory
 - Tests coverage

* Improve API for pokemons in Inventory

 - Added new class PokemonInfo for the static information loaded from json
 - API improved,  added capture_rate and flee_rate
 - All covered with tests

* Minor refactoring of inventory.py

 - Item class (moved to other instance classes) to keep file structure
 - Code style

* Rewrite NicknamePokemon to use new Inventory sysem + add a lot of new keys for 'nickname_template' option + tests & documentation

* Update documentaion for the new NicknamePokemon

* Update documentaion for the new NicknamePokemon (again :)
editet Manual install Mac section
* `catch_randomize_reticle_factor`
* `catch_randomize_spin_factor`
* catching every single pokemon nearby

* catch lured pokemon in all forts nearby

* adding run_interval to some tasks to avoid running all the time and minimum tick time of 5 seconds

Tasks inheriting from BaseTask should use `self._update_last_ran` and
`_time_to_run` if they want to implement the time based running. The
config to set a custom timer is named `run_interval`.

* added config to ignore item count for Spin and MoveToFort

this works good with the `run_interval` configuration added to
TransferPokemon and RecycleItem

* spinning all pokestops in range

* fixing loop in spin fort task

* First basic features of the pokemon optimizer

* For now, dry run only

* Add cygwin to supported platform and improved log readability (PokemonGoF#2948)

* Add cygwin to supported platform and improved log readability

* fixed formatting

* - Add dry_run and use_lucky_egg in config
- Evolve all pokemons together and only if enough for a full lucky egg (90).
- Keep enough candies for consecutive evolutions of best pokemons
- Only evolve the lowest rank of a family

* Add lucky egg support when enough pokemon to evolve

* fixing returns

* - Support Eevee evolution scheme
- Rename "use_lucky_egg" parameter in the more accurate "evolve_only_with_lucky_egg"

* Revert "Merge remote-tracking branch 'origin/faeture/xp-improvements' into pokemon_optimizer"

This reverts commit ff1f5e4, reversing
changes made to e8fd901.

* - Fix an issue in evolve_pokemon task
- Use common inventory
- Add configuration example

* Add missing inventory refresh at the end of the process

* Add missing inventory refresh after catching a pokemon

* Add parameters "transfer" and "evolve" to activate/deactivate corresponding action. If both false, this is equivalent to a dry_run.
Add parameters "use_lucky_egg" to allow task to use a lucky egg before evolve.
Add parameter "minimum_evolve_for_lucky_egg" to add a requirement on the number of evolution before using a lucky egg.

* Move some functions around

* Default lucky egg to false + had again parameter "evolve_only_with_lucky_egg"

* Fix qn issue with egg counting
Add configuration parameter to allow customization of how pokemons are ranked in a family

* Update configuration example

* Upgrade to latest inventory

* Fix bug

* Add parameter "use_candies_for_xp" to activate/deactivate usage of candies to maximize xp
Add comments in the configuration example

* Add dps, dps_attack and dps_defense in available sorting keys. So you can now keep the best move.
Add more comments in config
Display ncp and dps for released and evolved pokemons

* Update inventory when releasing and evolving pokemons

* Display Pokemon Bag count update
* Fix looping between equidstant pokestops

* :D
…3833)

* Format iv_pct on 3 digits

For better sorting on pokemon's name, format iv_pct on 3 digits.

* Fix Nicknaming documentation sample usage

Fix some nicknaming samble usage around the iv_pct which it now
formatted on 3 digits.
* Ignoring compiled test python file of PyCharm

* Now spinning fort keeps track of cached inventory

* Now the pokemon_catch_worker keeps track of cached  ITEMS (and only items, not pokemon) inventory

* Minor improvements of the new inventory

* Fixed key error

* Minor improvements of the new inventory

* Fixed attribute non existent

* Removed duplicated import
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment