• 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!
  • PokéCommunity's Easter Egg Hunt is now on! If you're interested in looking for some eggs and earning badges, click here!
  • Our weekly protagonist poll is now up! Vote for your favorite Conquest protagonist in the poll by clicking here.
  • 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

Quick Research & Development Thread

I recently replaced the battery in my old Ruby Version cart, as it had run dry due to age. Some things have been working fine since the replacement (clock's running, Shoal Cave works like it's supposed to). Other things, however, are displaying symptoms very reminiscent of the old Berry Glitch that used to plague Ruby & Sapphire versions (berries won't grow, lotto tickets don't work). Now, I can't imagine the R/S/E programmers devoting much effort to elegantly restoring all the RTC related functionality after a dry battery has been replaced so finding these glitches after going through the effort to repair my cart are kind of disappointing but unsurprising.

I'm wondering about the feasibility of dumping my save using a tool like GBA_Backup_Tool and using some hacking tools to determine what's gone wrong with my save, perhaps comparing it with a healthy save, then fixing it and dumping it back to the original cart. Has fixing a bug like this ever been tried before?
 
Keegsu said:
I recently replaced the battery in my old Ruby Version cart, as it had run dry due to age. Some things have been working fine since the replacement (clock's running, Shoal Cave works like it's supposed to). Other things, however, are displaying symptoms very reminiscent of the old Berry Glitch that used to plague Ruby & Sapphire versions (berries won't grow, lotto tickets don't work). Now, I can't imagine the R/S/E programmers devoting much effort to elegantly restoring all the RTC related functionality after a dry battery has been replaced so finding these glitches after going through the effort to repair my cart are kind of disappointing but unsurprising.

I'm wondering about the feasibility of dumping my save using a tool like GBA_Backup_Tool and using some hacking tools to determine what's gone wrong with my save, perhaps comparing it with a healthy save, then fixing it and dumping it back to the original cart. Has fixing a bug like this ever been tried before?
Click to expand...
I think this is more of a question then actual research but I shall answer it anyway. I recall R/S had some problem making it so that time based events would stop work properly after a year. They did later on have ways to fix this. You can link it up to XD gale of darkness and it will fix it I believe. Also you can link it up to FR/LG and do something and it will also get fixed. I can't remember if Emerald does the same or if Colosseum had a fix. Google and research it, I can tell you there is definitely no need to dump your save.
 
Gamer2020 said:

I think this is more of a question then actual research but I shall answer it anyway. I recall R/S had some problem making it so that time based events would stop work properly after a year. They did later on have ways to fix this. You can link it up to XD gale of darkness and it will fix it I believe. Also you can link it up to FR/LG and do something and it will also get fixed. I can't remember if Emerald does the same or if Colosseum had a fix. Google and research it, I can tell you there is definitely no need to dump your save.
Click to expand...

Perhaps I should clarify- I did those patches ages ago, hence my referring to the "old Berry Glitch," as it's not a glitch that should be around any more. This is a copy of Ruby version that I've owned since 2003-2004 and it has done plenty of trading with FR/LG carts and with Colosseum on the same save that still exists. I even tried loading the patch program in my copy of FR and patching the game just in case I somehow managed to avoid getting the patch after all, and the Ruby cart comes up with an "Unable to update" message which I can't imagine is indicative of anything other than that it's already been updated.

The weird thing that's going on here, and the reason I gravitated towards the Research forum and started thinking about dumping my save (which I've done now, I'm just too inexperienced/stupid at hex-editing gba saves for the moment to actually do anything with the dumped save other than play it in VBA), is that I've somehow managed to replicate the effects of a glitch that should have been patched out of the game years ago. The obvious answer to "how" is that I'm experiencing continuing effects of the battery running dry despite putting in a new battery because the game doesn't know how to restart particular features after they've broken due to the battery (not due to the aforementioned glitch that Nintendo patched out themselves) and I want to research exactly what happened. There's one person in the Gen III Q&A thread who's mentioned experiencing the same issue under the exact same circumstances but overall it's not something that's been documented because the rare folks who actually change the dry lithium cells in their RSE carts mostly seem to just start new games once they do so.

What I want to do with the save file I've dumped is unpackage it and take a look at what's going on with the Loamy Soil data using a hex editor and see if there's anything insane going on with the minutes remaining variables for my berry bushes or if there's anything else amiss. Right now I lack the means to unpackage it though there's plenty of useful reference information on Ruby/Sapphire save file data structure on furlocks-forest (which I can't link yet since the board software won't let me until I've posted more).

Alternatively, there's the possibility I'm a complete idiot and it really is something simple I can patch using official Nintendo stuff and I just haven't done enough Google research. Somebody talk me down from my insane scheme if you think this is the case.
 
Some fun music hacking info..
There are fanfares (I guess I'll call them that) and songs. The difference between them is that if you start a fanfare on one map and go to the next, the fanfare will overlap with the new music. It will sound like a blended mess. If you insert a music track that you want for a city or route over it, then it'll still keep the characteristics of the fanfare. This is not good because the music will blend if you go to another map. To fix this, you must find the track's pointer in the song table. This can easily be found by looking at the "Table" offset in Sappy. So, you have the pointer. There are four bytes after the pointer. 00 00 00 00 means it's a song. 02 00 02 00 means it's a fanfare. If you want to make a song a fanfare, vice versa, then you change the bytes to what you desire. Now, you can replace the futile "You Fail It" tracks with great route music, or some other fanfare you want to replace.

Also, make sure you do this for every song table you have. You only have one if you haven't made another, by the way. :D
 
I didn't think this warranted an entire thread, mainly because I'm sure someone else has figured this out by now.

In Gen V games, the stat calculations system was overhauled, and stats are recalculated after every battle. This is all well and good, and I wouldn't touch it in any case, but one thing caught my eye...Deoxys's stats are calculated after every battle as well, even in Gen III. Only Deoxys. Why would they waste such a perfectly good system for ONLY Deoxys? I expect it's because of the forme-changing, but they could've expanded the system for everything!

Surely, since the system is already in place, it's a very simple matter to change it from affecting just one Pokemon to affecting all of them. Does anyone know anything about what someone might be able to do to fix this?
 
Quick Question:
Thanks to pichu2000's Tutorial I know that the data that links the data (maps, events, scripts and texts) is stored in the file a/0/1/3. Where is the data stored in DPP / HGSS?
And a second question: Are the commands used for scripting the same in DPP and HGSS?
 
Hey guys I have a question, do you guys now where the Trainer Card Sprite Table is?

I wan't to repoint the sprite being loaded when your male and change it to another number for example sprite #90...

I would appreciate if you guys can help me, and I know that there's a command in Jpan's Engine but I wan't to do it without applying the patch so can you guys help me?

NOTE: This is for the male sprite I don't need to repoint the Heroine sprite... :)
 
Hey, I'm not sure if this'll be noticed, but I'm givin' it a shot:

Does anyone know the location of either A) the code that makes Mew and Deoxys use/set the obedience bit, or B) the area that performs the check for the obedience bit in Pokemon Emerald? I'm planning on sprucing up my Pokemon Emerald Randomizer program, and I'd love to get that issue out of the way, as randomized wild pokemon imply possible legitimate Mew and Deoxys usage.

I've searched the forums and found a solution to fix wild Mews' obedience bit in FR/LG, but couldn't find Deoxys and additionally couldn't find anything similar in Emerald's code. Granted, I'm really lost in terms of ASM without a decent GBA debugger, but any help on this matter would be greatly appreciated. I've done ASM hacking on GBC before, so I'm not afraid to get my hands dirty. I figure that it's a simple replacement of a few bytes with NOOP, assuming the location of the check is known.

Lookin' forward to a response, I hope! Thanks for taking a peek. :)
 
Artemis251 said:
Hey, I'm not sure if this'll be noticed, but I'm givin' it a shot:

Does anyone know the location of either A) the code that makes Mew and Deoxys use/set the obedience bit, or B) the area that performs the check for the obedience bit in Pokemon Emerald? I'm planning on sprucing up my Pokemon Emerald Randomizer program, and I'd love to get that issue out of the way, as randomized wild pokemon imply possible legitimate Mew and Deoxys usage.

I've searched the forums and found a solution to fix wild Mews' obedience bit in FR/LG, but couldn't find Deoxys and additionally couldn't find anything similar in Emerald's code. Granted, I'm really lost in terms of ASM without a decent GBA debugger, but any help on this matter would be greatly appreciated. I've done ASM hacking on GBC before, so I'm not afraid to get my hands dirty. I figure that it's a simple replacement of a few bytes with NOOP, assuming the location of the check is known.

Lookin' forward to a response, I hope! Thanks for taking a peek. :)
Click to expand...
FR Obedience checks:
Deoxys: 0x0801D3EC
Mew: 0x0801D402

There ya go.
 
Last edited:
How hard/easy would it be to insert the Sevii Islands into HG/SS?

Seems like it'd be something someone has already done.
 
NintendoBoyDX said:
Obedience checks:
Deoxys: 0x0801D3EC
Mew: 0x0801D402

There ya go.
Click to expand...

Thanks for the reply, but are these for FR/LG or for Emerald? I know for sure the Mew address corresponds to the address in FR/LG, but after messing around with the same addresses in Emerald, nothing seemed to do the trick. :(
 
CriticalKYUC said:
How hard/easy would it be to insert the Sevii Islands into HG/SS?

Seems like it'd be something someone has already done.
Click to expand...

Very difficult. We've barely got events and maps editable yet. Completely adding something new is no easy task yet.
 
Jambo51 said:
Second up, this is the battle string loader hack I made. It intercepts the "failed" part of the loader. That is, it branches out from what the loader would otherwise consider to be a bad number to load from and skip.

Spoiler:


As you can see, it has checks to try and catch a "bad" location given in the RAM location I set aside for the new functionality. All it can catch, sadly, is if you leave the RAM location empty, or if you try to use an invalid ROM location. The rest, I have to leave to the user.

I've written the routine such that it supports 32MB ROMs as well, so you don't have to worry about that either.

To insert the actual routine, navigate to 0xD77BE and change the code to 03 49 08 47, then go to 0xD77CC and change the pointer to the insert location of the routine, plus 1 for THUMB mode of course.

Now, using it. It's as easy as this: Using the storebyte command of the battle script functionality (0x2E), store the bytes of the ROM pointer in little endian ordering, into the RAM address 0x0203C020. Then, you call the battle string printer as such:
Code: 
10 84 01 39 40 00

The routines will take care of the rest!
Click to expand...
For some reason it's not working correctly. It just freezes the game.

This is what I've done:
1. Insert the routine at 0x71EA35
2. Change the bytes like you said at 0xD77BE
3. Change the bytes at 0xD77CC so that it points to 0x71EA36
4. Inserted a text string at 0x71EA85
5. For my battle script, it goes like:
Code: 
02 03 09 0A 48 01 03 00 2E DE 3F 02 02 14 89 C1 00 69 1D 08 12 40 00 [B]2E 20 C0 03 02 85 2E 21 C0 03 02 EA 2E 22 C0 03 02 71 2E 23 C0 03 02 08 10 84 01 39 40 00 3D[/B]

And yes, I have made sure that I've assigned my custom attack to the custom battle script. It executes the animation, and I checked in VBA's Memory Viewer that it correctly updates the Attack Stat modifier like what I wrote in my custom script, and it even does the stat change animation like I made it so, but it doesn't display my custom message, instead it just freezes after that. The part that I bolded is the code that should display the custom text.
 
Chaos Rush said:
1. Insert the routine at 0x71EA35
Click to expand...
There's your problem. ASM routines need to be inserted at offsets ending with 0, 4, 8, or C. Move the routine, then repoint the pointer.
 
I didn't think this warranted a thread of its own, and I couldn't think of anywhere better to put it, but this is how to enable a different fanfare for the Key Items in Emerald (As standard, it uses the same fanfare as normal items, which is a bit boring).

Firstly, Compile and Insert this script somewhere in your ROM, anywhere will do:

Code: 
#dynamic 0xF00000

#org @main
fanfare 0x212
return

Obviously, you can swap out the track it plays for any other fanfare in the Emerald ROM, but this one happens to suit it rather well.

Note down this pointer, and the navigate to 0x271B60 and change the pointer to point to your new script. Voila! Job done.
 
This is a document containing all the LZ77 compressed data in pokemon emerald U.S. 1.0 rom.
key
xxxxxx-?????
^ ^
offset description of what it looks like or is
xxxxxx+-xxxxxx,xxxxxx:??????????????????????????????????????????;xxxxxx:???????????????
^ ^ ^ ^ ^ ^
offset(tiles) offsets(raw or pallete) description of what it looks like offsets(raw or pallete)^
description of what it looks like ---------------------------------------------------------------- >^
It doesn't space correctly, sorry!
 
Last edited:
I wasn't sure where to post this but it seems like a good spot. I was wondering if there's some RAM locations documentation available for the third generation games (such as the player's money, inventory, etc.). I found some on the second generation games on Data Crystal but I haven't been able to find much looking for the third generation games (specifically Pokemon Ruby) so I was hoping if someone could lead me in the right direction.
 
Has anyone thought of removing the Pokemon animations in Emerald for some extra free space? I've always found them watered down and disappointing after Crystal's multi-frame animations, and it would cut any sprite work I decide to do in half.

I'd assume we'd have to cut out the routine that switches frames and plays that stupid thing that warps the sprites, and then cut down the images to the standard one frame.

Has anyone attempted this?
 
Last edited:
You must log in or register to reply here.
Back
Top