tfw they store full egg data there too -- show that in the sidebar
Tested on C & GS (english), assumedly works fine for other languages
(based on the disassembly?)
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
