according to the disassembly it all makes more sense; a small block and
a large block are stored in RAM
util calc helps convert between contiguous section offset to a chunked
offset
eg: emerald daycare starts at large 0x3030, which converts to
chunk4@0x1B0
reduce pk3/ck3/xk3 logic, share AbilityBit property within _K3, and when
loading, type check (favored over hardcoding individual load cases)
pull some non-gui code from PKMEditor to core/etc for general data
fetching
Yeah forgot that extremely bad RNG rolls (0,0,0,0,0) leaves 510
remaining, and the last EV can't have that much
rework loop to be simpler & quicker by checking the last IV for validity
only
(don't bother keeping it unrolled
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)
Closes#2040 , adds test cases:
invalid bulbasaur.wc3: hidden ability
invalid charmander.pcd: hidden ability
valid camerupt: gen3->4 unevolved mismatch
valid leafeon: pcd mismatch -> evolved now matching
should be much easier to maintain; methods are reused with less overall
nesting
reduce nesting (evo.RequiresLevelUp is checked twice, only check once
and handle path)
compact some methods
seal some classes
add a little xmldoc to exposed members
Encounter used to be used to determine if the original encounter was
valid; we now store the encounter object and checking is fast enough --
we don't really care to short-circuit individual verification steps
anymore.
This commit implements IsDaycareOccupied for generation 1 saves. The
byte which tracks if the daycare is occupied should normally only be
0x01 or 0x00, so I decided that all other values mean that the daycare
is probably corrupted and thus not occupied. SetDaycareOccupied is not
implemented, since I am not sure what other flags the game normally sets
in this scenario and daycare is read-only anyway.
The GUI displays the Pokemon's index to the right for some reason, but I
don't have saves to test this for other generations, so it might be
unrelated to this change.
gender: take top 4 bits of gr:
31 = 0x1F = 1
63 = 0x3F = 3
127 = 0x7F = 7
191 = 0xBF = 11
See the pattern? If we change the compares from >= to >, we -1. All
numbers match except for the 25/75 ratio pkm... which unveils the
problem.
Simplify the calc for these using the logic above, which fixes the error
and makes the code easier to read!
Thanks SystemError for assisting :)
easy modification which isn't 'random' resulting in a slightly higher
chance of retaining the current gender if possible. threshold values can
change genders (1f:7m), but is slicker overall
Checks.cs initially started out small, but over the years it has grown
to handle multiple types of checks. With all these checks next to
eachother, it's hard to see the overall groups. Splitting them up
(potentially further?) allows for more focused maintenance &
understanding.
Not sure if I'm happy with the overall bandaids used (checks no longer
done within LegalityAnalysis so variable repointing is excessively
used), but I'm happier the way it is now compared to the huge Checks.cs
