The encounter generator was returning always RBY and GSC and that make the ParseMovesGenGB to check only for rb and gs learnset for initial moves, the game returned should be the game for the encounter to make ParseMovesGenGB use the correct learnset table for the initial moves
Closes#1417
Re-enable PKM (abstract class) property searching via Database/MGDB
search
Closes#1412 (can now search or exclude certain formats)
Add auto-detection for all supported saves (rather than gen3+ except
GC/PBR)
Closes#1409, fr entries weren't tab separated
Closes#1408, editor interface was correct (refer to checkbox order
comment in Pokedex4.cs)
Closes#1407, XY species were copypasted to AO's
fix early-verification (introduced in 9864d84), just invert the
fieldsLoaded check. No longer interrupts the pkm loading routine when
changing game locations
fix stadium check (accidentally inverted in bfdf1c5)
Closes#1398Closes#1397
Add global link mission stats (thanks Holla!)
remove some ToArray() linq in favor of direct copies
Relocate encounter suggestion logic to separate class
Closes#1396, addresses other edge cases like entree-non HA & happiny
egg.
Reduce memory usage for evo method banlist (static banlist references)
Fix gen6 mega evo flag truncation
simplify QR encode/decode logic a little
Don't apply transparency if transparency is already 100% (skip the loop)
Add gen5 wild pid/tid-sid correlation check
Fix validation value reset (loading gen3-4 pkm without looking at met
tab causes the met location to get reset); fixed by prematurely
validating before setting the value
Fix gen3 pkm with gen4 contest ribbons in gen4/5 getting flagged
incorrectly
Closes#1349
Add egg memory wiping when ticking as egg,
Add egg memory setting when suggesting encounter info.
Closes#1350
I'd rather have it this way as to not do cross-tab auto edits that the
user may miss.
refer to stackexchange links, makes XDRNG PID/IV search so quick (2^3
instead of 2^8 or 2^16; as fast as a gen3 shiny pokemon (2^13=8192 times
as fast as last release)
throw in some auto-inlining to eliminate some overhead in repetitive
search calls
Only usable for searching Method 4 IV spreads -> seeds;
1,3's search uses the same approach as the 1,2 search
I took the 1,2 search derivation to iterate for the next step, which
allows us to not know anything about the middle rand bits.
optimize a little bit more, move the pre-loop add to the initialization
stage; moving to the precomputed section pays off after 256 calls to the
method
Meet in the middle attack trades some RAM (2^16 flag/byte array) to
reduce future searches by a factor of 1:2^8
profiling yielded >100x speed improvements, even a 2x would have been
impressive ;)
knocks the biggest cpu hog (when searching db) out of the race!
