Tool: [Gen III] Repoint Master ALPHA - Repointing made too easy!

For the people who are lazy and/or want a fully automated way to repoint things, I present to you: Repoint Master!

(Screenshot: When I can...)

Features:
* Repoint data and automatically replace all the pointers
* Find some free space automatically
* Save a backup before repointing (works, but is touchy)
* Option to wipe the original data
* Some extra safety: Checking that the values you entered are valid, that the free space is actually free, and warnings about stuff.
* Fast repointing; lightweight program
* Open Source!

Planned: Presets, Advanced Pointer Search, ROM expansion, other improvements...

Important notes:
* USE AT YOUR OWN RISK. I did my best to prevent errors, including user errors, but this tool still remains an advanced & powerful tool to be used with care. I am not responsible if this messes up your ROM!
* All of the numbers are in hexadecimal, including the lengths! There is no way to insert a decimal number! The only decimal number is the reported number of pointers changed.
* This is an Alpha version. I have tested it, but not enough to make me satisfied. Be careful when the offsets are overlapping!
* Currently this program only recognizes 0xFF as free space. See this:

ThomasWinwood said:

As I understand it the issue is that Emerald uses 00 for free space while also having blocks of 00 which are NOT free space - using that will gradually corrupt music data. (To be honest I'm not sure why that's the case - a 00 byte has to be deliberately written since PROMs default to FF for bytes not written.) Searching for free space by looking for runs of a particular byte is poor form anyway, since it's not impossible for meaningful data to consist of long runs of the same value.

At any rate, this thread on PHO indicates the free space (identified thus far) in Emerald is in the ranges 0x9C0B20-0xAFFFFF, 0xDE4018-0xE3CF48 and 0xE3CF64-0xFFFFFF.

Click to expand...

Please let me know if you find any bugs, or have any questions about how it works!

Supported platforms:
I'm really sorry, anyone who doesn't use Windows, but I only have experience with GUIs in C# / MS Visual Studio. If you want to port this to another platform, feel free to use the source code that I provide.

Windows XP, Vista, 7, 8, and 8.1 are supported. However, you need to install the .NET Framework version 4.
Note to Windows XP users: You must use .NET Framework 4. Not any newer version.
If you have problems with .NET Framework: Repair the installation of .NET Framework 4 Client Profile.

Download:
The files are attached below:

Wow, this seems like a pretty sweet tool. I'll try it out when I get the chance for sure!
Its good to see that there's a repointing tool now. ^^

Yay! Another gen 3 tool!
Good job! Ang good luck! :)

tURuI said:

* Only 0xFF is free space! It is a common misconception that Emerald uses 0x00 as free space. Once I can, I will link to a thread by Chaos Rush which explains this. This program only recgonizes 0xFF as free space.

Click to expand...

As I understand it the issue is that Emerald uses 00 for free space while also having blocks of 00 which are NOT free space - using that will gradually corrupt music data. (To be honest I'm not sure why that's the case - a 00 byte has to be deliberately written since PROMs default to FF for bytes not written.) Searching for free space by looking for runs of a particular byte is poor form anyway, since it's not impossible for meaningful data to consist of long runs of the same value.

At any rate, this thread on PHO indicates the free space (identified thus far) in Emerald is in the ranges 0x9C0B20-0xAFFFFF, 0xDE4018-0xE3CF48 and 0xE3CF64-0xFFFFFF.

ThomasWinwood said:

As I understand it the issue is that Emerald uses 00 for free space while also having blocks of 00 which are NOT free space - using that will gradually corrupt music data. (To be honest I'm not sure why that's the case - a 00 byte has to be deliberately written since PROMs default to FF for bytes not written.) Searching for free space by looking for runs of a particular byte is poor form anyway, since it's not impossible for meaningful data to consist of long runs of the same value.

At any rate, this thread on PHO indicates the free space (identified thus far) in Emerald is in the ranges 0x9C0B20-0xAFFFFF, 0xDE4018-0xE3CF48 and 0xE3CF64-0xFFFFFF.

Click to expand...

Thanks for the info! I'm not sure if I can implement it in this tool, but I'll add it to the first post for now