Some routes use the evolutiontree directly instead of this method (with the same name); should probably consolidate but meh
This causes Shedinja to yield the correct evolution chain when called directly (because nothing naturally evolves to shedinja; it's created out of thin air as a clone)
Take the egg short circuit with it to keep things simple
Rather than storing a dictionary of keys, we can abuse the fact that the SCBlock[] is stored in order of ascending block key.
Binary Search doesn't require extra memory like a Dictionary would; also, we only need to find a few blocks.
blanks: {key,size}
fetch: get block by key (index isnt the same between patches, as blocks with different keys get added). The savefile stores them as a SortedDictionary (by key), hence the shifting.
USUM had 20 for both, but XY/AO/SM had only 1 (vivillon had 20); make
them consistent so that our generated evolution paths behave correctly
Add meowstic specific evolution form modifier... so silly
simpler to have it inlined with the sSpecies, for jit optimization
could probably do this with silvally but meh, things work fine now
Closes#2603
All logic in PokeCrypto is separate from the rest of the PKHeX.Core
library; makes it easy to just rip this portion out and reuse in other
projects without needing the entirety of PKHeX.Core logic
optimize out the CheckEncrypted to the actual path, separate methods.
Only usages of this method were with hardcoded Format values, so no
impact
PKX.Generation is 8, which returns SWSH evo tree; evo tree doesn't have
non-galar-native species data, so stuff like Ambipom don't get reversed
properly.
use math.max for tree fetch when appropriate:
- egg generator: pre-evolutions like pichu should be allowed if pk1
- don't fetch format twice, just do math.max
#2603
add in "secret" heal/healPP actions -- do ".Heal=$suggest" to refresh
all stats like it was healed at the pokecenter. I can't think of a good
way to handle invoking of methods (">", but what about parameters?)
Not going to implement this within the base repo as z3 is too large of a
dependency and is platform specific.
If anyone wants to implement as a plugin project, just inject your new
methods via the setters on the static func/action at the top of the 3
classes.
Since z3's searches aren't instant, I'd recommend caching recent results
in a dictionary, as re-parses are common. Something like the Wordfilter
is what you'd be aiming for :)
Closes#2617
Manually modified showdown sets can contain errors (capitalization,
etc). Use the string search api to permit weaker matches, since there's
not going to be any exact-matches-with-different-caps/spaces.
