• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

[FR] Expanding the Pokedex

Ksiazek Bartlomiej said:
But why do not take an courage and start changing system from messy code to Maloc system. For example exported from Emerald.
Click to expand...

Says the guy with no programming experience...... and whom refuses to get any.


No, it is not that easy. That would be removing and porting about 1000 lines of code or more in raw ASM to another game in a way where it might not even work. It would be easier to write a completely new Pokedex in C and insert it.
 
karatekid552 said:
Says the guy with no programming experience...... and whom refuses to get any.


No, it is not that easy. That would be removing and porting about 1000 lines of code or more in raw ASM to another game in a way where it might not even work. It would be easier to write a completely new Pokedex in C and insert it.
Click to expand...
It requires C, or C++? Or is it the same thing? Sorry if that's a dumb question.

The truth is, I've been busy with school, karate, family, and I have been trying to learn how to program in my free time because...I'm going to try and port this, over to Emerald...well, not really port, but give Emerald its own version. SBird has it working for a German Emerald ROM, so why can't it work for an English Emerald ROM? So, I've been learning how to ASM program and a little bit of C++.

@Ksiazek Bartlomiej, I'm not trying to flame you or anything, I'm just saying, you should really look into ASM programming. I looked at it for a brief few minutes. It looks hard at first, but it's pretty simple if you get a handle on it
 
LCCoolJ95 said:
It requires C, or C++? Or is it the same thing? Sorry if that's a dumb question.

The truth is, I've been busy with school, karate, family, and I have been trying to learn how to program in my free time because...I'm going to try and port this, over to Emerald...well, not really port, but give Emerald its own version. SBird has it working for a German Emerald ROM, so why can't it work for an English Emerald ROM? So, I've been learning how to ASM program and a little bit of C++.

@Ksiazek Bartlomiej, I'm not trying to flame you or anything, I'm just saying, you should really look into ASM programming. I looked at it for a brief few minutes. It looks hard at first, but it's pretty simple if you get a handle on it
Click to expand...

C++ is C with object orientated programming tacked on (that is why the syntax is a bit more awkward when compared to other object orientated languages). The compiler for GBA, as far as I know, is only C, but you can apply most of C++, just skip the objects.
 
This could be a huge bug if other are getting this, but Eggs won't hatch when given to the player.
 
It turns out there are two pointers to x254795 in the ROM, which is the 18th byte of the first entry of the base stat table. This is what's causing the eggs to not hatch- they're actually working fine, they just have a nonsensically high number of cycles needed to hatch. I'll add this to the OP real quick. (existing rock eggs won't be fixed because cycle count is determined at egg gen)
 
Last edited:
DoesntKnowHowToPlay said:
It turns out there are two pointers to x254795 in the ROM, which is the 17th byte of the first entry of the base stat table. This is what's causing the eggs to not hatch- they're actually working fine, they just have a nonsensically high number of cycles needed to hatch. I'll add this to the OP real quick. (existing rock eggs won't be fixed because cycle count is determined at egg gen)
Click to expand...

You guys are lucky I keep tabs on this thread.:P In the first post, you said 18th byte. In this one you said 17th. Ummm... The math says 17 to me, but I just need to make sure. I'm adding this to G3HS right now.
 
DoesntKnowHowToPlay said:
Add cries for the new mons. As you may know, cries after Celebi are handled unusually- the limbo slots are all hard-wired to Unown's cry (doubt this is hard to fix but lazy), while slots starting from Treecko use an auxilary table to find their cry. This table is at x2539D4- repoint and extend it. Note that you don't need to repoint the cry table itself- immediately after it is a second, unused copy of the cry table.
Click to expand...
Something about this seems wrong. I don't see any second copies of the table in the disassembly, used or otherwise.

This is the routine that handles converting the internal ID into the cry ID, taken from knizz' disassembly and commented by me:

Code: 
speciesid_conv:
    push {lr}
    lsl r0, r0, #0x10   @ typecasting
    lsr r0, r0, #0x10
    movs r1, r0
    cmp r0, #250        @ slots up to 250 have the same cry ID as the internal ID
    bls loc_8043332
    ldr r0, dword_8043324
    cmp r1, r0          @ is this slot 275 or below?
    bls loc_8043330     @ if so, branch
    ldr r0, off_8043328 @ otherwise, use the table
    ldr r2, dword_804332C
    add r1, r1, r2      @ subtract 276 from ID
    lsl r1, r1, #1      @ and multiply by two, since it's a table of 16-bit values
    add r1, r1, r0      @ then index into the table
    ldrh r0, [r1]       @ retrieve the value
    b loc_8043332       @ and leave
@ ---------------------------------------------------------------------------
dword_8043324:  .long 275
off_8043328:    .long 0x082539D4
dword_804332C:  .long -276
@ ---------------------------------------------------------------------------

loc_8043330:
    mov r0, #200        @ limbo slots use Unown's cry

loc_8043332:
    pop {r1}
    bx r1
@ End of function speciesid_conv

The table at x2539D4 is followed by the first experience curve table - there is no secondary cry table.

Editing this routine to remove the hardcoded cry for the limbo slots is easy: write 00 00 00 00 00 00 00 00 00 00 (that's ten bytes) to x4330C and 00 00 00 00 (four) to x43318, then repoint the table at x4539D4 and expand it - it's now a table with one word for every ID. (You can test to make sure that it worked without repointing the table - you'll know it worked if the title screen makes Blaziken's cry.)
 
Yeah well I have a question about this, if anyone could answer it then great.
I made a thread about it in the beginner's lounge, so here it is.

https://www.pokecommunity.com/threads/325967

or

Spoiler:
 
Got 1 more question: what value do I make the SEEN/CAUGHT pointers?
 
I'm unsure if I should post this in G3HS' thread, but I myself have tried to go backwards from what the tool has done and nothing appears to be amiss.

The extended Pokémon in my ROM have broken altitudes, basically. If I change the value to be > 0, the shadow displays, but the sprite stays where it is. If I set it to 0, the shadow disappears, so that is working. However, regardless of the value, the sprites remain "stuck" to the ground. I've tried re-repointing the altitude table, the 03 E0 byte changes on the OP have been done successfully, and it's obviously registering that there is an altitude value, it just isn't using it.

[PokeCommunity.com] [FR] Expanding the Pokedex


I've also tried editing the altitude using Advanced Series and simply using a hex editor, so the value is definitely changing. I feel like I'm missing a limiting byte or something, but I can't seem to find what it is exactly.

This only happens to the extended Pokémon in my ROM: with Chimecho, it's fine, but with Turtwig, it doesn't work.
 
Zepkhan said:
Got 1 more question: what value do I make the SEEN/CAUGHT pointers?
Click to expand...

All you gotta do is point them to the seen/caught flags. Nothing hard
 
my english is not good, and I can not understand the steps. you can make a video tutorial for me? thanks
 
Doesnt himself told me this so I'm just going to post it here so I don't have to save it somewhere:

For FireRed, to fix cries on expanded mons that use a cry index of higher than 0x200, put 01 1C 11 E0 at x720CA.
 
Chaos Rush said:
Doesnt himself told me this so I'm just going to post it here so I don't have to save it somewhere:

For FireRed, to fix cries on expanded mons that use a cry index of higher than 0x200, put 01 1C 11 E0 at x720CA.
Click to expand...

isn't this in the first post somewhere
 
You must log in or register to reply here.
Back
Top