Thread: Research: FireRed Pokédex Hacking
View Single Post
Old May 1st, 2011 (3:42 PM). Edited May 1st, 2011 by Full Metal.
Full Metal's Avatar
Full Metal Full Metal is offline
C(++) Developer.
Silver Tier
Join Date: Jan 2008
Location: In my mind.
Age: 20
Gender: Male
Nature: Timid
Posts: 805
Send a message via Windows Live Messenger to Full Metal
In all honesty, it would probably be easier to just modify the routine that loads it.
Getting rid of it would be a pain in the arse.
Originally Posted by knizz View Post
0300500C is pointing to the second of three savegame blocks that change position to avoid overusing certain parts of the memory. The data in it is tightly packed.

08104AB0 uses 08104AFE or 08104B14 depending on whether R1 is 0 or 1.

R1=0 loc_08104AFE:
LDR     R0, =saveblock2
LDR     R0, [R0]
ADDS    R0, #0x5C @ Start of second flagdata
ADDS    R0, R0, R4 @ R4 contains flag-nr (=pokemon-nr minus 1) divided by 8
LDRB    R1, [R0]
ANDS    R1, R6 @ R6 has only one of the first 8 bits set
CMP     R1, #0
BEQ     loc_08104BB0

R1=1 loc_08104B14:
LDR     R0, =saveblock2
LDR     R2, [R0]
MOVS    R0, R2
ADDS    R0, #0x28 @ Start of first flagdata
ADDS    R0, R0, R4 @ R4 like above
LDRB    R1, [R0]
ANDS    R1, R6 @ R6 like above
CMP     R1, #0
BEQ     loc_08104BB0
Because the first data starts at 0x28 and ends at 0x5C you only have enough place for (0x5C-0x28)*8 pokemon. (=416) Unless you know how to repoint in savegames you have these size constraints.
Think you could point us to the routine that saves the seen/caught flag data?

★ full metal.

I like to push it,
and push it,
until my luck is over.
Reply With Quote