NNID (Wii U)

Hi ! I'm fairly new around here, and I'm relatively new to rom hacking and to the NDS scene in general, but I'm working on several little projects for Pokemon Mystery Dungeon Explorers of Sky / Time / Darkness, and I thought it would nice to share it with others ! Especially with others with more technical knowledge than I !
I hope this will be useful ! :biggrin:
And be sure to report any bugs, or tidbits of information you have ! Those would prove invaluable !
Feel free to mention whether it worked for you, or not so much ! Any feedback is always great !
You might need 7zip or another 7z compatible program to open the compressed files on this page.
Looking for:
- Need people to write tutorials for some of the tools !
- Need feedback on the tools!
- Need people to discover what some of the "unk" variables in the character sprites do !
- Need info on the NDS's DSP.
The Tools:
Compression/Decompression:
PPMD UnPX
Description: A quick little implementation of a "PX" compressed data decompressor. Its based on Zhorken's Python script for decompressing the character portraits, which happened to be stored as compressed "PX" files ! Just feed it an AT4PX or PKDPX file by drag and dropping, or use the command line argument for specifying the input file and output folder. The result will have an extension appended, or not, depending on whether its currently possible to guess the content. Again, many thanks to Zhorken for finding out about the compression scheme !
Donwload: Version 0.41 : ppmd_unpx_0_41.zip on Github
PPMD DoPX
Description: A compressor to compress files back into PX compressed files, either PKDPX or AT4PX files. Its still pretty new and experimental, so, watch out for bugs ! By default anything compressed is outputed to a PKDPX. To output to a AT4PX, the output filename has to be specified and to end with ".at4px" !
Donwload: Version 0.31 : ppmd_dopx_0_31.zip on Github
Packing/Unpacking:
PPMD Pack File Utility
Description: This tool unpacks and re-packs "pack files". Those are single file that contains many sub-files. Pack files often end with a .bin extension, and they can contain a lot of different types of files at the same time. Mostly for research purpose.
GUI Image:
Donwload: Version 0.53 + GUI 1.2 : ppmd_packfileutil_gui_1_2-0_53.zip on Github
Graphics:
PPMD KaoUtil
Description: This utility allows to both unpack the kaomado.kao file containing all the pokemon portraits, but also to rebuild the file! Basically, you can add new potraits into the game using this tool ! It just extract everything like a zip file if you want. And you just have to add a properly named 4 bits per pixels/16 colors png or bmp image to the folder matching the pokemon you want, before repacking the parent folder again into a ".kao" fle. The first color in the palette is reserved by the game and is forced to pure black, so you have really 15 colors.
Example: For example, here's a crappy little edit of Poochyena's basic portrait. I inserted it into slot 2, which correspond to the emotion named "Grin"! Poochyena by default doesn't have a portrait for this emotion, but by using the tool, I was able to insert this very easily !
GUI Image:
Donwload: Version 0.41 + GUI : ppmd_kaoutil_gui_1_0-0_41.zip on github
Dowload: Version 0.42 No GUI: ppmd_kaoutil_0.42 on github
PPMD GfxCrunch
Description : Handles converting various image formats from the game, including WAN sprites, BGP images, Compressed Pokemon sprites "*.pkdpx", and more to come! It exports animated sprites to XML for easier editing. It also can handle all at once the entire Pokemon sprites containers "monster.bin", "m_ground.bin", "m_attack.bin".
Currently Supported Graphics Formats:
Individual Pokemon sprites "*.wan" file ( Type 1 ).
Compressed Pokemon sprites "*.pkdpx"
Entire Pokemon sprites container "monster.bin", "m_ground.bin", "m_attack.bin"
Currently Partially Supported Graphics Formats:
Prop sprites with orphaned images "*.wan" file ( usually Type 0 or 3 ). Can extract, but wrong resolution and tile/pixel ordering, and can't be re-packed properly.
WAT sprites "*.wat" file. (basically "*.wan" sprites with a different file extension and with their type byte set to type 3) Not tested.
BGP Images. "*.bgp" files.
Currently Unsupported Graphics Formats:
WTE Image container. "*.wte" file.
WTU Color animation data file ? "*.wtu" file.
kaomado.kao. (Use ppmd_kaoutil instead for now!)
Raw at4px-compressed images. (This will never be perfect, because its raw data.)
Raw images. (This will never be perfect, because its raw data.)
Everything else..
Donwload: Alpha 0.13 : ppmd_gfxcrunch_0_13_alpha on GitHub
Stats/Text/etc..:
PPMD StatUtil
Description: A tool for exporting game statistics to XML, and importing them back into the game's files. Making it easy for third party tools developer to make more complete and user friendly utilities, can also be edited by humans directly and opened with anyone's favorite XML editor.(Notepad++ highly recommended) So far has limited support.
Currently supports editing: Move data, Pokemon Data, Item data, Generic game text, Game scripts + game dialog.
Donwload: Alpha 0.23 : ppmd_statsutil_0.23.2 on GitHub
Tutorial/Example: here, also include a few files and tools to make things easier!
Example Video for the Script Editing :
Audio:
PPMD AudioUtil
Description: A tool for exporting, and eventually importing/modifying, audio to/from games using the DSE audio driver, such as PMD2 ! Can output the samples to wav files, or the samples and music tracks to a soundfont and MIDIs, or to MIDIs only. You can specify your own conversion rules for exporting only MIDIs, such as what instruments the native DSE preset translate to when converted into MIDI ! This program REQUIRE you to read the readme btw. Its a console program only, for now. There is so much stuff going on in it that there won't be a GUI frontend for a while..
Please Note: Its still far from perfect!
Currently supports: Exporting Music to MIDI and soundfonts. Exporting MIDIs only. Exporting samples.
Donwload: Version 0.37 (2017/12/14) : latest ppmd_audioutil on Github
Source Code:
All source code for all utilities is available. Its not always pretty, because this codebase is also used for research, and messing around. But its much better than not sharing anything at all, I guess.
Main repository for the actual utilities : ppmdu
Secondary repository for the GUI frontends : ppmdu_gui_frontends
Research Notes:
For the most reliable, tested, and up to date info, check the Project Pokemon Wiki:
http://projectpokemon.org/wiki/Pok%C3%A9mon_Mystery_Dungeon_Explorers
All my current personal research notes files:
File Formats : https://www.dropbox.com/sh/8on92uax2mf79gv/AADCmlKOD9oC_NhHnRXVdmMSa?dl=0
General notes : https://www.dropbox.com/s/ucy2t9hqgtfn0y0/PMD2_GeneralNotes.txt?dl=0
PMD2_MusicAndSoundFormats: https://www.dropbox.com/s/bw0aym9rn22z4wu/PMD2_MusicAndSoundFormats.txt?dl=0
PMD2_MusicTracksAndInfo : https://www.dropbox.com/s/rwjq0s0fvtiamsv/PMD2_MusicTracksAndInfo.txt?dl=0
A bunch of jumbled notes on scripts : https://www.dropbox.com/s/1roqlwkhfqb9amz/PMD2_Scripts_And_Resources.txt?dl=0
Misc Unsupported Utilities
Here are a few little utilities I made to help with researching the ROMs. They're nothing special, and probably not very stable, but they're really handy:
SIR0PtrOffsetsDecoder : Use this to decode a SIR0 pointer offset list, which can help tremendously in finding out more about what a sir0 file contains! Just copy/paste the SIR0's ptr offset list only, and put it into its own separate file, and drag-and-drop that onto the .bat file, it will output the result in "decoded.txt". The program itself only output the result to the console, so use the batch script, or pipe the output!
IntegerListDecoder : Use this one to decode a list of encoded integers. Things like the stats growths in "m_level.bin", the move lists in "waza_p.bin". You can just put all the lists one after the other in a new file, and drag-and-drop that onto the .bat file and all the decoded lists will be outputed to "decoded.txt" !
Pages of Interest:
Todo

Please be sure to hide any PSMD spoilers within spoiler tags, until the game is released in all regions !
About This Thread:
This thread is mostly for posting on-going research notes/progress and findings for the Pokemon Mystery Dungeon Gates to Infinity and Pokemon Super Mystery Dungeon games.
Both games use very similar formats, and work generally the same way, which is why they both share the same thread.
Information:
Here are links to interesting posts in the thread, and to external websites.
How to extract PMD:GTI rom's content
How to batch decompile the lua scripts
A nice little cheat sheet + Lua primer for those interested!
Lua 5.1 experimental sandbox escape exploit
Notes:
Here are some links to notes, or to the wiki on the various file formats and etc of the games.
SIR0 format
Megadrifter's notes on the IMG format
Utilities:
Here are some utilities for dealing with the file formats in PSMD/PMD:GTI :
...
Current Problematic Issues:
Here are some of the things that are currently holding us back right now:
No way to test modifications/investigate on a 3DS/emulator. My 3DS isn't unlocked. So having someone with one willing to try things out would be nice! (EDIT: Actually,thanks to ironhax I can run homebrew on it now But not much else )
This post will fill up as time goes.

Not sure if this is the right place as I don't know how much of a breakthrough this is so mods please let me know if this should be moved elsewhere. There's been multiple posts asking about how to remove the banned Pokemon restrictions on Battle Maison in X/Y/ORAS (Some people are even offering bitcoin incentives to have this figured out). I've spent pretty much the entire day working on this/trying to figure this out but for the life of me could not, so to have this day not go to waste I'd like to share some of the progress/things I found out and discovered along the way. Hopefully someone out there can pick this project up and finish working on it.
So how do you remove the Battle Maison restrictions? My conclusion, after a lot of experimenting, is that you have to edit the DllBattlePartySelect.cro file. Here are my reasons:
1) After messing with that .CRO file, I rebuilt romfs using PK3DS, loaded the patch using Hans, and my game was running completely fine up until the point where the Battle Maison lady asks me to select Pokemon. The game freezes at a black screen and I'm forced to power off.
2) I messed with DllBattlePartySelect.cro by reading it through a Hex editor. Call me crazy, call this a conspiracy theory, but there are 31 instances of the Hex-value sequence "FE FF EB" in that file, and there are exactly 31 Pokemon banned in Battle Maison.
Now I know it's been said before that CRO files can't be edited, and if they do then the game just crashes, but after some research I came across this thread and heard people saying that CRO editing works with Luma3DS (I use Gateway3DS for launching Hans using homebrew). So I spent time setting up Luma and between the CRO resigner and Luma I couldn't get anything to work lol. After patching static.crr with cro_tool.exe the game wouldn't boot so I used the old static.crr, and patching the romfs into a .cia file for Luma3DS didn't work either...
So in short, editing DllBattlePartySelect.cro by modifying the 31 iterations of the "FE FF EB" hex values is my best guess at figuring out how to remove Battle Maison restriction (I am using Alpha Sapphire, sorry if that becomes relevant). The million-dollar question is figuring out how to edit CRO files using a Hex Editor without having the game crash. Maybe Kaphotics or SciresM would know how to do this. I know there are some CRO editing capabilities that Pk3DS has, but still no way to edit that golden DllBattlePartySelect.cro file.
Edit 9/24: Solved for ORAS. Still need to find the garc location for X/Y (if anyone really cares). As well as for SuMo's Battle Tree. 80% sure this will be the same for Ultra Sun and Moon, but it would be naive for me to say that about a game that hasn't even been released yet.
EDIT 9/25: Confirmed working for Sun and Moon. tl;dr: GARC location for ORAS is a/1/7/0, for SuMo it is a/1/3/7. Replace the bytes quoted by Kaphotics with 0's and you're good to go!
EDIT 9/26: You can now remove Soul Dew clause in Gen 6 games, rendering the banlist completely lifted! The only type of Pokemon to still be banned in Battle Maison is one whose total EVs exceed 510 (this is allowed in SM, don't ask).

My friend has started a project he calls NDSCracker. Simply put, the NDS ROMs don't have a completely-defined documentation all together in one place. Lots of data on The Project Pokémon techdocs? Certainly. Good data across several forums? Yes. Over 80% of the ROM completely described in just one spot online? Not yet. This is our goal, but we only have six people actively working all of this out. We need the help of the ROM hacking community.
We need more people ready to break down the NDS gen IV ROMs - specifically Platinum - and document it well, otherwise Pokémon ROM hacking might be permanently stuck in gen III. Sure FireRed is beautiful, but why not we go further? People like mikelan98 have proven just how much can be done with enough effort in gen IV, and he's also contributed a considerable amount of data (in Spanish, but hey - data's data).
If you'd like to contribute to the project, or even just watch from the sidelines and screw around with the team, please join us on Discord.

That would be the holy grail. That and a Wonder Card distro ROM.
EDIT: Topic was started when theSLAYER moved posts discussing 10 ANIV carts after a couple members mentioned they had some and would be willing to share the generation algorithm (the thing a lot of people here actually want, myself included) but not the actual ROMs.
EDIT 2: Considering the scope of this topic has expanded beyond 10ANNIV/10 ANIV research, I decided to rename it.

I've tried to modifiy the cheat code for have the complete phonebook.
Editing the quantity of added numbers with this code:
94000130 fcff0000
62111880 00000000
b2111880 00000000
d5000000 00000000
c0000000 00000001 THIS IS THE CHANGED BYTE
d8000000 0000c0fc
d4000000 00000009 THIS IS THE CHANGED BYTE
d2000000 00000000
d0000000 00000000
The first hacked code change the quantity of numbers to 77, that is the max numbers that you can record (when before was 4C in hex instead of 4D 'cause starts with the 0), after the hack add 2 numbers, 'cause I changed the 4C byte with 01.
The second hacked code before was 01, and this mean that add numbers in importance order (I think) but if you change with 0-2-3-4 etc. add for the other numbers after MUM always the same number. Then you can fill your phonebook with 77 MUM numbers and then if you try to add someone else you don't receive error messages, but the phonebook will not updated.
This hacked code actually change the first two numbers in the phonebook with MUM and BILL, 'cause BILL is the 10th (hex 09) pokégear official number, then as example if you want to delete YOUNGSTER JOEY (I know that you want!) you can move his number in 2nd position and overwrite with BILL's number.
IMPORTANT:
JOEY will try to add you again, then the flag is in the same phonebook list, if is deleted ask you again to add him.
However the code could be dangerous, you have to put MUM number in first position to overwrite with the right number and you have to overwrite JOEY with a number that yet you don't have.
In my case BILL is perfect, 'cause I don't added him yet, but if you already have him in your phonebook you can duplicate his number... Not is right...
However I discovered that if a number is deleted or overwrited the trainer ask you to add again. But I don't have a code for delete as example the last number in the phonebook.
Will be wonderful found a way to clear specific trainer's numbers, maybe with their script that verify if you added them and ask you also to delete their numbers when you talk with.
Someone can work into to discover a way to edit as example JOEY script?

Map Files
- located at /a/0/6/5
- contains 5 sections
#1 Section - Header
- section is 20 bytes
Offset
Length
Name
Description
0x0
0x4
Movement Permission Size
The size of the Movement Permissions in Section #3. Always 0x800.
0x4
0x4
3D Object Size
The size of the 3D Objects defined in Section #4.
0x8
0x4
NSBMD Model Size
The size of the embedded Model (NSBMD) file in Section #5.
0xC
0x4
BDHC Size
The size of the embedded Terrain (BDHC) file in Section #6.
0x10
0x4
Unknown Section Size
The size of the section of unknown data in Section #2.
#2 Section - Unknown Data
- data in this section serves a currently unknown function
- data is unique to HG/SS and theorized to be Pokemon size permissions
Offset
Length
Name
Description
0x0
.
#3 Section - Movement Permissions
- data is always 2048 bytes, two bytes for each tile, and all maps are 32x32 tiles
- tile data is ordered from left to right, bottom to top
Offset
Length
Name
Description
0x0
0x1
Special Permission
Allows for special permissions. A rather incomplete list can be found in the Appendix.
0x1
0x1
Movement Permission
Three valid values: 0x0 No Restriction, 0x4 No Special Permissions (Ignore First Byte), 0x8 Solid/No Movement
#4 Section - 3D Objects
- section is 48 bytes per object defined
- 3D Objects Size in Section #1 will be the total size of this section in bytes
Offset
Length
Name
Description
0x0
0x4
Object ID Number
A complete list of Object ID numbers can be found in the Appendix.
0x4
0x2
Y Fractional
Variable allowing fractional Y-axis positioning. (Defaults to 00 00.)
0x6
0x2
Y Coordinate
Position of the object on the Y-axis.
0x8
0x2
Z Fractional
Variable allowing fractional Z-axis positioning. (Defaults to 00 00.)
0xA
0x2
Z Coordinate
Position of the object on the Z-axis.
0xC
0x2
X Fractional
Variable allowing fractional X-axis positioning. (Defaults to 00 00.)
0xE
0x2
X Coordinate
Position of the object on the X-axis.
0x10
0xC
????
This section serves a currently unknown function.
0x1D
0x4
Width
The size of the object on the Y-axis.
0x21
0x4
Height
The size of the object on the Z-axis.
0x25
0x4
Length
The size of the object on X-axis.
0x29
0x7
????
This section serves a currently unknown function.
#5 Section - NSBMD Model
- NSBMD Model Size in Section #1 will be the total size of this section in bytes
- this is the 3D model of the map itself
- NSBMD model specifications aren't listed here.
#6 Section - Terrain (BDHC)
- BDHC Size in Section #1 will be the total size of this section in bytes
- BDHC file specifications are detailed here.
Terrain Files (BDHC)
Credit and thanks goes to Mikelan98 for finally cracking these files.
This section will have a ton of notes, as the format is very complex. Refer to Mikelan98's guide for help.
- located at the end of map files, found at /a/0/6/
- contains 7 sections
#1 Section - Header Data
Offset
Length
Name
Description
0x0
0x4
Magic ID
#BDHC (0x42444843)
0x4
0x2
Points Size
The number of points defined in Section #2.
0x6
0x2
Inclines Size
The number of inclines defined in Section #3.
0x8
0x2
Heights Size
The number of heigths defined in Section #4.
0xA
0x2
Plates Size
The number of plates defined in Section #5.
0xC
0x2
Strips Size
The number of strips defined in Section #6.
0xE
0x2
Access Lists Size
The number of access lists defined in Section #7.
#2 Section - Points
- section length will be 8 bytes multiplied by Points Size from Section #1
- each 8 bytes follows the format below
Offset
Length
Name
Description
0x0
0x4
Padding
Color
0x4
0x4
X Coordinate
X Coordinate for first point. (Little Endian)
0x8
0x4
Padding
0xC
0x4
Y Coordinate
Y Coordinate for first point. (Little Endian)
Notes:
- These coordinates define points on the map.
- Maps are always 32x32 tiles.
- Coordinates are defined from the center of the map.
- The coordinates for the center four tiles are:
- Northwest:
00 00 FF FF, 00 00 FF FF
- Northeast:
00 00 00 00, 00 00 FF FF
- Southwest:
00 00 FF FF, 00 00 00 00
- Southeast:
00 00 00 00, 00 00 00 00
- Coordinates south and east will increase. Coordinates north and west will decrease.
- The coordinates of the outside corners are:
- Northwest:
00 00 F0 FF, 00 00 F0 FF
- Northeast:
00 00 10 00, 00 00 F0 FF
- Southwest:
00 00 F0 FF, 00 00 10 00
- Southeast:
00 00 10 00, 00 00 10 00
#3 Section - Inclines
- section length will be 12 bytes multiplied by Inclines Size from Section #1
- each 12 bytes specifies a type of incline
Offset
Length
Name
Description
0x0
0x12
Incline Type
Specifies a type of incline.
Notes:
- It is assumed that the 12 bytes define coordinates in some way.
- Because it is not fully understood, here is a list of known inclines:
- Flat Plate:
00 00 00 00 00 10 00 00 00 00 00 00
- North Stairs:
00 00 00 00 50 0B 00 00 50 0B 00 00
- East Stairs:
B0 F4 FF FF 50 0B 00 00 00 00 00 00
- West Stairs:
50 0B 00 00 50 0B 00 00 00 00 00 00
#4 Section - Heights
- section length will be 4 bytes multiplied by Inclines Size from Section #1
- each 4 bytes specifies a height
Offset
Length
Name
Description
0x0
0x2
Fractional Z Coordinate
Variable allowing fractional Z-axis positioning. Defaults to 00 00 (Little Endian)
0x2
0x2
Z Coordinate
Vertical positioning coordinate. Defaults to 00 00. (Little Endian)
Notes:
- Up on the Z-axis subtracts, while down on the Z-axis adds.
- Fractional coordinates are divided by -65536, e.g., 00 80 = 32768/-65536, or -0.5.
- Add both variables for final height, e.g., 00 80 FF FF = -0.5 + 1 = +0.5
Formulas:
In the Spanish version of the tutorial Mikelan98 wrote, he posted some formulas for determining the heights you need to define in this section when dealing with specific types of slopes. They also allow one to figure out how to make formulas for other types of slopes. Here, I'll translate them.
- Northward Stairs:
Height = 0xB505 * (-(y)-(h))
- Westward Stairs:
Height = 0xB505 * (x-h)
- Eastward Stairs:
Height = 0xB505 * (x-h+1)
- Where:
- x = the position of the stairs on the X-axis, unless the tile is more than one tile long, in which case you would use the tile that is lower on the Z-axis
- y = the position of the stairs on the Y-axis
- h = the height of the bottom of the stairs + 1
#5 Section - Plates
- section length will be 8 bytes multiplied by Plates Size from Section #1
- each 8 bytes section builds a plate using definitions from the previous three sections
Offset
Length
Name
Description
0x0
0x1
First Point Index
The index of the Point used for the northwesternmost corner of the plate.
0x1
0x1
Padding
Color
0x2
0x1
Second Point Index
The index of the Point used for the southeasternmost corner of the plate.
0x3
0x1
Padding
0x4
0x1
Incline Index
The index of the Incline used for this plate..
0x5
0x1
Padding
0x6
0x1
Height Index
The index of the Height used for this plate.
0x7
0x1
Padding
Notes:
- The indexes for these are simply the order in which each previous section was defined.
- For Points, if you're using the first two Points to construct a plate, you would use 00 & 01.
- This creates a rectangular plate between the coordinates defined, with the defined inclination and height.
#6 Section - Strips
- section length will be 8 bytes multiplied by Strips Size from Section #1
- each 8 bytes section builds a plate using definitions from the previous three sections
Offset
Length
Name
Description
0x0
0x2
Padding
Color
0x2
0x2
Lower Bound
The southernmost tile of the strip. (Little Endian)
0x4
0x2
List Elements
The number of list elements from Section #7 to use. (Little Endian)
0x6
0x2
List Start
The index of the first list element from Section #7 to use. (Little Endian)
Notes:
- The first Strip begins at the northenrmost horizontal "strip" and ends at the first defined Lower bound.
- The second Strip begins at the next tile south of the first Lower Bound and ends at the second defined Lower Bound.
- The List Start index works the same as the indexes in Section #5.
- List Elements counts elements including List Start.
- More information is noted after Section #7 - Access List.
#7 Section - Access List
- section length will be 2 bytes multiplied by Strips Size from Section #1
- each 2 bytes is a list entry
Offset
Length
Name
Description
0x0
0x2
Plate Index
The index number of a plate from Section #4.
Notes:
- The Plate index number references Plates in the order they're defined, the same as in previous sections.
- The Plates in this list are referenced in the section above, and they're accessed, once again, by index number.
- The Plates are ordered in groups, and individual plates generally appear multiple times.
- The Plates in this section that are referenced in the previous section, are plates that can be accessed from that strip.
- More information and visuals can be found in Mikelan98's guide.

So, I hacked the pokewalker.... I dumped RAM when I was on the transfer screen, and looked through it with a GameBoy tile editor. I found something interesting... The graphics for the Pokewalker are stored on HG/SS This also includes a DECOMPRESSED sprite of Spinda (because of the way the game handles his spots). So, this led me to conclude, the game transfers the Pokemon sprites when it connects, (and probably the sprites for that route youre on) I'd have to assume that if you transfer your pokemon back. The only time it transfers the menu Icons and misc sprites is the first time you sync it, or after you erase it, then sync again.
I did this by hacking the sprites with AR, I made a code that will copy data from a hacked gba save file to the RAM.

I didn't want to necro this thread but what I found might be useful information to anyone who plays on Battle Subway. Just so you know I've only tested this on Pokemon White 2, but this should in theory work on all other Gen 5 versions (note MeroMero's different narc locations for BW vs BW2).
If you follow that thread (and read the replies too), you will see that, for Black 2 and White 2, you have to use a Hex Editor on a\1\0\6 (in this case). In this case, I am using HxD so this next sentence will make sense if you're also using it: After changing all the sequences laid out in that thread, I changed the second "B0 0E" to "00 00". This can be found in Offset (h) row 000000B0 columns 0C and 0D.
After you change those 2 Hex values, recompile using PPRE beta 0.14 and try playing in Battle Subway
You will notice that Soul Dew is no longer banned and you can use the same pokemon multiple times, holding the same items, and you can even play with 4, 5 or even all 6 of the pokemon on your team. As far as I know, this removes every single restriction on Battle Subway, so you will not only be able to play with banned pokemon, but you can essentially... go all out with whatever haha.
Hope this helps!

I recently started using Ohana3DS to extract assets from ORAS and noticed it's tedious to find a particular pokemon's model and texture. These files are found in folder a/0/0/8, and are labelled with file_#### instead of pokemon names. I searched around for an easy way to find which file goes with which pokemon, like a search function or list, but haven't found anything. Has anything like this been made yet? If yes then it should be made more public.
Well anyway I started mapping the files to pokemon on my own, and it's pretty crazy. There are over 8000 files! So I'd like some help with this, and possibly make it a public project to identify all the model and texture files in a/0/0/8.
Here's what I've got so far: https://github.com/mradocy/pokemonModelList.
I've also discovered some things that would make this easier. About half the files can't even be opened in Ohana3DS, so that reduces the work a lot. There all also patterns with how the files work. In general, it seems a pokemon consists of a block of 8 files. These blocks tend to contain the following files:
Pokemon model (geometry) (.pc file)
A (<10 KB) .pf file that can't be opened.
The texture of the pokemon (.pt file)
The texture (shiny version) of the pokemon (.pt file)
A .pt file that can't be opened, size varies a lot
A medium (<100 KB) .pb file that can't be opened
A medium (<100 KB) .pk file that can't be opened
A small (<10 KB) .pc file that can't be opened
Also, does anyone know what the significance of these extra files are? Are they animations?
Note there are separate blocks for different forms of pokemon, which includes gender differences. This makes it hard to come up with a general formula for mapping pokemon to their corresponding files.
Even if there was such a formula, there is still value in attempting to open the files. It'll be useful for bugtesting Ohana3DS; for example finding pokemon whose textures don't render correctly, or at all (Charizard, for instance).
So would anyone like to help? A list like this would be very handy to have. Most importantly, if someone already did this please share it before we do a lot of work for nothing... (wouldn't that be embarrassing huh?)

If a Pokémon uses Endure, is supposed to take damage equal or superior to its current HP, and happens to consume a held damage-reducing Berry the same turn Endure is used, then:
_the Enduring Pokémon won't be left with Math.floor(Expected damage / 2) HP , nor 1 HP if Expected damage >= 2 * current HP;
_but instead will be left with Math.floor(Current HP / 2) + 1 HP, or 1 HP if Current HP <= 2.
In other words this tells us that Endure, if successful, is checked before damage-reducing Berries, which is obviously a bad design.
A similar problem happens with Counter, Mirror Coat and Metal Burst (possibly Bide as well) where the damage sent back is doubled from the damage that was to be taken BEFORE damage-reducing Berries are checked (showcased here).

I have visited the IRC many times and asked for advice on how to help with Save Research and Development on various Pokemon games and their respective systems. However, all of my notes were erased when my laptop messed up (currently undergoing repairs). I would like to help out if at all possible, but I would like to know if I have everything I need and if not, what would be next step/software and hardware I need? I wanted to make this thread for others who might be eager to help and to have it all in one thread. I apologize to those who have talked with me in IRC before about this and that it may need to be mentioned again.
Here is what I own, all of which are authentic and working:
Pokemon Games:
Hardware:
Any help would be greatly appreciated. Also I could not find any thread (at least as much as I looked being exhausted) that would teach people who would like to help on how to aid with research all in one source. I would like to apologize if this was already asked, but I figured it would be alright since I am also unsure if what I have is enough, etc.
Pictures here and here

The first post will be the patch and instructions and the second will be a look into how I managed to do this.
Using this will be a little bit complex for now until the new version of Kazo's trainer editor shows up. I don't know if he'll be doing it or if I'll be doing it, but it will be available at some point soon-ish. Until then, there are basic instructions in the text file and obviously you can ask questions in here.
So what we've got here is the first implementable hack for 5th gen Rom hacks. For now it will just be for B2W2, but will eventually be for BW as well. As the title states, it lets you pick the nature for opposing trainers' pokes.
http://hack.thundaga.com/trainer_nature.7z
Also, here's a pic of what I was talking about in the text file:
The red square is byte 0x4B, the one you're supposed to edit.

It's been a loooong time, but finally, I've discovered how the BDHC files work. Please, if you are gonna copy this post in other site, give credits! First of all, I have to thank JayT, who discovered how is the file structured in different parts.
Now, I'm gonna explain what does each part.
Part P
Sets the coordinates of certain points, used later to build rectangles or "plates" of different heights in the Part S. The structure of each element is the following one:
00 00 XX XX 00 00 YY YY
XX XX are the coordinates in the X-axis, and YY YY the Y-axis ones. Keep in mind that the origin of coordinates is located at the midpoint of the map, not in a corner. This means that the lower right corner always use positive numbers, but the upper left corner instead must use negative numbers.
Remember that FF FF = -1, FE FF = -2, FD FF = -3...
The four tiles in the midpoint of the map are (FFFF, FFFF), (0000, FFFF), (FFFF, 0000) and (0000, 0000) respectively.
Thus, the point of the upper left corner is:
00 00 F0 FF 00 00 F0 FF
And the lower right corner:
00 00 10 00 00 00 10 00
Part Q
It may be related to the stairs, but I need to investigate further. I've already solved this part, but I've still got to translate it to English
Part R
It sets the different heights where the hero can be in different rectangles or "plates". The structure of the elements of this part is:
MM MM ZZ ZZ
ZZ ZZ refers to the complete-tiles height, ie; for example if the character is at a neutral level, then ZZ ZZ = 00 00. If we climb some stairs and now we are in a height +1, then ZZ ZZ = FF FF (at higher height, instead of growing, it decreases) . If we were at a height +5, it would be FB FF. And if for example we were at -2; 02 00.
MM MM measures, instead of full tiles, 65536-ths of tile. For not to talk complicated things; MM MM = 00 80 if the character is in a lake (it would be half a tile down, ie -0.5 tall) and MM MM = 00 00 if the character is anywhere else.
For example, if we have:
00 80 FF FF
it would mean:
FF FF = Height +1
00 80 = Height -0.5
Total height = +0.5
Part S
Link points of Part P to create the "plates" or rectangles, and assigns a height of an element of Part R.
AA 00 BB 00 QQ 00 RR 00
AA is the number (in hex) of the Part P element where the point of the rectangle in the upper left corner is. Remember that the first element is 00, the second is 01, the third is 02...
BB is the number (in hex) of the Part P element where the point of the rectangle in the lower right corner is.
RR is the number (in hex) of the Part R element which establishes the height of the plate.
If in Part P, for example, we have this:
00 00 F0 FF 00 00 F0 FF
00 00 10 00 00 00 10 00
And in the Part R we have:
00 00 FE 00
00 00 01 00
In the S part we have to write:
00 00 01 00 00 00 00 00
so we create a plate covering from (-16, -16) to (16, 16) (ie, the whole map) and setting a height in the Z axis +2. If instead out:
00 00 01 00 00 00 01 00
It would be the same as the previous one, but with a height of -1.
Part T
It divides the map in horizontal strips. Everything must be divided so if we move vertically (up or down) and thus we get in/out of a lake, stairs or similar, we must also be entering a new strip. It's hard to explain; the game can not detect when you enter an area with different height when you move vertically in the same strip (horizontally no problem) so you have to create a new separate strip. As I know it's hard to understand, here's a little picture:
There is an element for each strip there. The structure of each element of Part T is:
00 00 YY YY NN NN UU UU
Where YY YY is the Y-axis line where the lower limit of the strip is. NN is the number of elements of the Part U that are taken, and starting counting from element number UU UU. Do not worry, I'll explain later.
For example, a map where there were two strips, one in the upper half and one in the lower half, would be:
00 00 00 00 NN NN UU UU
00 00 10 00 NN NN UU UU
Part U
It is a list or enumeration of adjacent plates/rectangles to the strip with which it is linked in Part T. That is, if I'm in the strip 00, Part T load a number of elements of the Part U where there are numbered all the plates where the player is or can access, from this strip.
The structure of the elements of Part U is:
SS 00
where SS is the number (in hex) of the Part S plate. Part U have many elements of these, and they are usually "segmented" in "zones". In Part T is loaded the number of items to be taken (NN NN) and the number it starts counting (UU UU).
For example, in Part U we have:
00 00
01 00
02 00
04 00
00 00
03 00
04 00
And in the T part we are:
00 00 YY YY 04 00 00 00
00 00 YY YY 03 00 04 00
Then, from the first strip, we are or we can access the plates 00, 01, 02 and 04, while from the second strip we are or we can access the plates 00, 03 and 04. Remember they are all adjacent plates, ie, plates belonging to the strip and the ones which are in the limits but do not belong to it (ie, those plates whose height the game has to load while the player is in the strip).

I have managed to successfully read and save Pokemon Box saves and have them load without issues on the actual game.
An editor actually does exist for Pokemon Box with source code Here which is what I based some of my findings on however this program doesn't have saving. Thank you Kaphotics for finding it.
Save File Structure:
Size: 0x76000 (+64 if it contains GCI data)
0x0 - GameCube Memory Card Data
0x02000 - Save Slot 1
0x30000 - Save Slot 2
Save Slot Structure:
Size: 0x2E000
0x0 - Array of 23 blocks of data. There is no data after that.
Each save file contains 23 blocks from start to finish. There is no leftover data.
Save data is stored in an almost identical fashion to the GBA games.
Block Structure:
Size: 0x2000
Variables:
0x0 - ushort ChecksumA in big endian
0x2 - ushort ChecksumB in big endian
0x4 - u32 BlockID in big endian (from 0-22 inclusive)
0x8 - u32 SaveCount in big endian
0xC-0x1FFB - Actual Data
0x1FFC - u32 Footer (unsure what this is used for)
Calculating the Checksum (In C#):
uint checksum = (ushort)((ushort)BlockID + (ushort)(BlockID >> 16) + (ushort)SaveCount + (ushort)(SaveCount >> 16));
for (int i = 0xC; i < 0x1FFC; i += 2) {
// Read the next ushort in big endian then add it to the checksum.
uint word = (uint)(((uint)RawData[i] << 8) + RawData[i + 1]);
checksum += word;
}
ChecksumA = (ushort)checksum;
ChecksumB = (ushort)(0xF004 - (ushort)checksum);
Actual Data Structure:
Size: 0x2BEA0
0x04 - u32 CurrentBox in little endian. (The last box the player was viewing before saving)
0x08 - Start of Pokemon Boxes, Each Pokemon is listed every 84 bytes until the last Pokemon in box 25
0x1EC38 - Start of box names, each is spaced 9 bytes appart and uses Gen 3 GBA Character Encoding and is 9 bytes in length.
A name starting in 0 or 255 is empty and the default name for that box should be used.
0x1ED19 - Start of box wallpapers. Each wallpaper is 1 byte in length. Each wallpaper's id corresponds to its order in the menu.
GBA Pokemon Character Encoding
First load each block then order them from lowest to highest block id.
Then dump each block's actual data into a single array and use that as the save file containing your data.
Pokemon Data Structure:
Size: 0x54 (84 bytes)
0x00-0x4F - Gen 3 GBA PKM Data
0x50 - u16 Trainer ID of sender in little endian
0x52 - u16 Secret ID of sender in little endian
GBA PKM Data Structure
Saving Pokemon Box:
Saving is pretty straight forwards assuming you're reading the file correctly. You don't need to increment the save count or anything and you only need to update the most recent save slot. Keeping the order the blocks were in works when saving the game and loading it on Pokemon Box. I haven't had anyone test it with sorting the blocks.

At the request of @Nebaku I poked around the files for pokemon battle revolution a couple of weeks ago. I don't really have the time to do a proper write up atm but thought I'd at least post some basic information for now in case anybody wanted to play around with it.
If you haven't seen my thread on extracting files from .fsys archives in colosseum and then check it out in this thread -hacking-tutorial-part-1-File-decompression-recompression'>https://projectpokemon.org/forums/showthread.php?46250-Stars-Pokemon-colosseum-and--hacking-tutorial-part-1-File-decompression-recompression
The useful part is part III of the tutorial as pokemon battle revolution also has .fsys files in the same format.
You can extract the .fsys files from the iso using dolphin but I haven't actually tried importing into gamecube ISOs so I don't know if there are any good programs for doing it automatically.
Unfortunately afaik all the files in the .fsys archives in PBR are named "(null)". It's super annoying but we can't do anything about that. The file names usually give hints as to what they may contain so without them there's a lot of guess work involved.
I spent some time looking through the files in common.fsys since that's where all the useful stuff is in colo/xd. If you use my BMS script from the thread linked above, and choose the option to automatically rename files with repeat file names, since all of the files are called "null" you get a bunch of files named (null)xxxxxxxx with a hexadecimal number in place of the xs. I will refer to the files by their file number since they don't have useful names.
The files from null - null0x20 are data tables, some of which I've figured out. null 0x21 is in the same format as the scripts from pokemon (-scripting'>https://projectpokemon.org/forums/showthread.php?47577--scripting). I haven't tried disassembling it yet though. The rest of the files are textures. mes_common.fsys contains a string table which follows the same format as in colo/XD except with different escape characters.
Info on the data tables:
Header :-
number of entries at offset 0 (number of rows)
entry size at offset 4 (length of each row of data)
first entry at offset 0x10 (offset to start of the data/end of header)
file size (minus header size) at 0x14
file size (including header size)at 0x18
base stats in common.fsys in null_00000008.fdat :-
entry size 0x34 (52)
first entry at 0x3c0(index 0)
offset length data
c 2 string id in mes_common
12 1 base stats (1 byte each )
18 1 types (1 byte each)
common null1 list of countries.
common 4, type weakness table. 00 super effective, 01 neutral, 02, not very effective, 03 no effect, 04/05 unknown but only used for type indexes after the last one used. interestingly there are extra type indexes making a total of 32.
common null6 list of clothing for avatars.
null9 same number of entries as pokemon (0x1f5 501)
evolution table.
entry size 0x2a 42
offset length data
0 2 evolution type (e.g. 04 by level up)
2 2 level/condition
4 2 target species
common null0x13 item list?
common null0x18 list of avatar clothing.
common null0x1e moves list
offset length data
0x00 2 effect
0x08 2 nameid
0x0a 2 description id
0x0f 1 base power
0x10 1 type
0x11 1 accuracy
0x12 1 base pp
0x13 1 effect accuracy
0x14 1 priority
0x15 1 some kind of mask. probably flags which include category. last bit is phys/spec so an odd value here is physical while an even value here is special/status
Bear in mind that none of this is confirmed. These are just the notes I wrote a couple of weeks ago after a few hours of looking at the hex. I didn't test any of them but tbh it's all pretty obvious just by looking at the data since it's all really similar to colo/XD in terms of the format.
Sorry that the information isn't very well structured but I'll aim to write tools for Colosseum, XDGoD and Battle Revolution once I'm done with my end of year exams.

Basically the title spells it all.
This thread is dedicated to using RAM editing or even using Hex Editors
To allow unused Sprites to serve a purpose in the game.
Basically this thread can be considered an extended version and derivativeof here: http://projectpokemon.org/forums/showthread.php?t=1416
I decided to focus not just on Arceus, but on other unused sprites, if any known.
From what I know the currently unused pokemon sprites are as of the following:
Shellos: http://veekun.com/dex/pokemon/shellos/flavor
Gastrodon: http://veekun.com/dex/pokemon/gastrodon/flavor
??? Arceus: http://veekun.com/dex/pokemon/arceus/flavor
BETA Shaymin and Giratina: http://bulbapedia.bulbagarden.net/wiki/Platinum_beta
What we do know is for Arceus to Stay in Curse (???) type,
It's ability must not be MULTITYPE or it will transform back to normal type if not equipped with the correct item.
Using the offset of 0x00000040 for HEX editor,
The value for Curse Arceus is found to be at least, 4C - 4F.
(4D is my preference though).
I'm currently trying to get the Shellos and Gastrodon,
And on Platinum (using 0x00000040=4D) Gastrodon appears weird, Shellos unsucessful.
If anyone manages to come up with any values,
Note the value under which offset, and also which game (D/P or Pt)
My Current List in mind:
Gastrodon
Shellos
Shaymin (Pt)
Beta Origin Giratina (Pt)
Curse Arceus
Cherim (Sunny 'mode' without activating Sunny Day)
Substitute?
DP sprites in Pt

In land_data.narc the length of the second block is supposed to be multiple of 0x30. This is true for all maps except for nr 483 (m_dun2405_00_01c). It has the lenght 146(0x92) instead of 144(0x90). That means there are 3 buildings and two additional bytes (0x0d 0x0a)
Why?!
(I use the Pokemon Diamond ROM)

Well, I've been wondering lately what makes a wurmple evolve into a cascoon and what makes it evolve into a silcoon. Although I do know that in platinum you can catch both forms and their evolutions I was just wondering for research sake. Most places I've seen have said that it is completely random. However, I am persistent. I do believe that there is a way to guarantee the evolution into either a cascoon or silcoon. So I am calling on all that are willing to join me in the quest to find the answer.
Also if you breed two silcoons together does it guarantee a wurmple which will evolve into a silcoon. Or does it just make a silcoon. I am wondering the same thing about cascoons. I have been performing my own research on it but help would be appreciated.
If you do help try evolving it at different times. Possibly that could effect. Or maybe the level, if you press b you can keep the pokemon from evolving I am not sure if that is permanent though. Plus if a pokemon is holding an everstone it stops the evolution until everstone is removed. Maybe natures have something to do with it.
PLEASE HELP I would like to know the answer
*Could someone tell me if this is in the appropriate place on the forums because I'm not sure.