See previous commit for discussion; it's easier to read and maintain
this rather than have the precomputed min/max comparisons.
LevelMin - minDecrease <= min && max <= LevelMax + maxIncrease;
See EncounterArea7b:
Since we know min and minDecrease (0) before doing the linq filter we
can precompute the lowbound, same for highbound; but this isn't
immediately obvious to the reader. The perf cost is pretty much
negligible in the big picture, so leave it in the more readable state.
Thanks @fattard & @ammako !
#2389
The inputs to "IsLevelWithinRange" are the highest value the
lowest-level can be, and the lowest value the highest level can be...
seems confusing (hence the original error).
If a slot is 6-7, with a wild encounter (flute), we can go +/-3 from
6-7, which is 3-10.
With an encounter of level 5, the inputs are: 5+3, and 5-3 (8, 2).
Since 8>lvlmin and 2<lvlhi, we can get a level 5 pkm from the slot
(using a negative flute yielding a -1 adjustment).
I could probably refactor it to be a 3-input signature (lvl, lvlneg,
lvlpos), and have it do LevelMin - lvlneg <= lvl && lvl <= LevelMax +
lvlpos
I should probably refactor these methods to do minLevel & maxLevel (so
baseSpecies.Level to CurrentLevel for pkm that lost their original met
data) but nothing needs the extra logic at this time.
Extract Species Name logic to SpeciesName
Extract Language logic to Language
Remove FormConverter wrapper for string[] fetch
Rearrange some logic to more appropriate locations, update access
modifiers / types
Move some pkm array methods to arrayutil, make generic
PKX.GetVCLanguage was a dupe of _K12.GuessedLanguage() so just expose
the method
PKX is now back to pkm data manip only
Now logic is reasonably split, and each format of area has its own way
of yielding slots
Too much junk with checking flute boosts or catch combo applicability;
just let the area dictate how slots match.
split some methods with optional parameters=null
add more xmldoc
replace some magic numbers -> enum/const references
consolidate common array operations (span soon maybe?)
SetPINGA{S}(pk, criteria) -> pid,iv, nature, gender, ability (stats
future?)
memes aside, this is where criteria data is forced
Split N encounterstatic (has fixed PID and special flag) from
EncounterStaticPID
be explicit that the string is empty rather than possibly missing
disallow encrypted export for BK4 (they're not encrypted), removes type
check
simplify replaceall in showdownset (don't call ReplaceAll 4x, just get
valid chars and rebuild)
simplify get ribbon sprite name (precompute ToLower and appended values
Check max case for level first, then iterate upwards (eliminates inner
if)
change wc* nature to sbyte (update comparisons, 0xFF too magic-y)
use Rand.Next(x) instead of (0, x)
all usages besides fetching a 32bit random value should use rand.next
remove unnecessary do-while loop for calculating random EVs (always
returns 510 in total)
continued simplification
core.cs is pretty much the following:
misc one-off junk
moveset fetch
encounter table fetch
evo chain fetch
might eventually move things around a bit further for cleanliness so
that misc meta junk is the only thing that remains in core.
fix b2w2 egg base levelup reference (not bw, b2w2!), doesn't really
matter much except for better indication (possibly?)
remove some unnecessary linq ToArray() calls
continue relocating code out of Core
Store 4g giratina held item for enc->pkm legality
revise usages of GetSaneGender
Rearrange some logic
Better handle impossible version encounters (gen4)
gen 1-5 done, stuck on 659 - bunnelby egg...?
Handle Faraway Island Mew, handle DP Darkrai/Shaymin & Arceus, handle
not-distributed WC3s.
Now stopping at dex 154 -- one full generation of PKM species IDs can be
completely spawned directly from IEncounterable data!
Fix/add missing gameversion references (BU instead of BW,
pokewalker=HGSS)
increase reuse of pidgenerator & add more generating methods.
seems like it's generating pkm fine besides the PID edge cases, which is
nice
