Search the Community

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

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!

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). (REDACTED BUT EVENTUALLY SOLVED IN 2020) EDIT 6/29/2020: garc location for X/Y found (??), Soul Dew and 510 EV limit removed in ORAS (X/Y/gen 6?). You can also apparently enter more Pokemon than normally allowed (such as 4 Pokemon in a Singles 3v3). [510 EV Limit bypass not reached... sorry my mistake)

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.

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.

NARC file order (CLICK THIS FOR HUGE LIST OF NARC LOCATIONS): Notable files for ROM Hacks: /a/0/0/3 - Story Text /a/0/0/8 - Maps /a/0/1/1 - battle backgrounds /a/0/1/2 - ZoneData /a/0/1/6 - personal.narc (pokemon editing) /a/0/1/8 - level up moves /a/0/1/9 - evolutions /a/0/2/1 - Move data (type, bp, etc) /a/0/2/6 - title screen /a/0/3/0 - Start Menu Sprite /a/0/5/6 - Ingame Scripts /a/0/6/5 - Move Animations /a/0/7/1 - Animated Trainer Sprites (front, vs) /a/0/7/2 - Animated Trainer Sprites (back, send out) /a/0/9/1 - Trainer Data /a/0/9/2 - Trainer Pokemon /a/1/2/4 - Egg Moves /a/1/2/6 - Overworlds /a/1/2/7 - Encounter Tables /a/1/6/3 - In Game Trades /a/2/6/7 - Trainer Mugshots /a/2/7/3 - Hidden Hollow Encounter Table /a/2/8/2 - PokeMart Data /a/2/9/1 - PWT Board Trainer Sprites /a/2/9/6 - Pokedex Ingame Locations /a/0/1/6 indices and structure (personal.narc): Encounter Table: Now has 135 locations. Here's their entry->ingame location: Poké Mart Locations: Credits & Thanks To: personal.narc identification and structure: Codr and magical Location Map of encounter slots: xfr File identification: Kaphotics, magical, Bond697, Codr, veekun, Sanky, Jerry, Andibad

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?

Personal Files - files located at /a/0/0/2 - file contains 4 sections #1 Section - General Data - section is 10 bytes Offset Length Name Description 0x0 0x1 Base HP 0x1 0x1 Base Attack 0x2 0x1 Base Defense 0x3 0x1 Base Speed 0x4 0x1 Base Special Attack 0x5 0x1 Base Special Defense 0x6 0x1 Type 1 0x7 0x1 Type 2 If monotype, this will be the same as Type 1. 0x8 0x1 Catch Rate 0x9 0x1 Base Experience The base amount of experience gained by defeating this Pokemon. #2 Section - Effort Values - section is 2 bytes Offset Length Name Description 0 2 Bits HP 2 2 Bits Speed 4 2 Bits Attack 6 2 Bits Defense 8 2 Bits Special Attack 10 2 bits Special Defense 12 4 Bits Padding #3 Section - General Data (Continued) - section is 14 bytes Offset Length Name Description 0x0 0x2 Held Item (50%) Uncommon held item for wild encounters. 0x2 0x2 Held Item (5%) Rare held item for wild encounters. 0x4 0x1 Gender Ratio Out of 255, this is the approximate number of females you'd encounter 0x5 0x1 Hatch Multiplier This number multiplied by 256 gives you the base number of steps required to hatch an egg. 0x6 0x1 Base Happiness 0x7 0x1 Experience Rate One of six values with preset growth rates. 0x8 0x1 Egg Group 1 0x9 0x1 Egg Group 2 If no second egg group, this will be the same as Egg Group 1. 0xA 0x1 Ability 1 0xB 0x1 Ability 2 Left blank if there's no second ability. 0xC 0x1 Run Chance Used strictly for Safari Zone encounters. 0xD 0x1 Color This is for Pokedex colors. #4 Section - TM's List - This section is 128 bits. - The first 92 bits refer to TMs, the next 8 to HMs, and the last 28 are padding. - If the bit is 1, that TM can be learned by this Pokemon. If it is 0, it cannot. Learnset Files - files located at /a/0/3/3 - file contains 2 sections #1 Section - Learnset - section is 2 bytes for every Move in the Pokemon's learnset - possible limit of 40 bytes, or 20 moves Offset Length Name Description 0 9 Bits Move ID 9 7 Bits Level Learned #2 Section - File End - section is 4 bytes Offset Length Name Description 0x0 0x2 Delimiter Tells the game where to stop reading. Always 0xFFFF. 0x2 0x2 Padding Evolution Files Back To Pokemon ▲ - files located at /a/0/3/4 - file contains 2 sections #1 Section - Evolutions - section is 6 bytes for every evolution method - possible limit of 7 evolutions, or 42 bytes - possible that all 42 bytes are required, and 0x0 if unused Offset Length Name Description 0x0 0x1 Evolution Method One of 26 evolutions methods. 0x1 0x1 Padding 0x2 0x2 Requirement Number This is the level required or the index of the Pokemon, item, etc. required for the evolution method. 0x0 if not needed. 0x1 0x1 Evolved ID This is the index mumber of the Pokemon to evolve into. #2 Section - File End Offset Length Name Description 0x0 0x2 Padding Growth Table Files Back To Pokemon ▲ - files located at /a/0/0/3 - file contains 1 section #1 Section - Growth Table - section is 4 bytes for each level, starting with Level 0 - total size is 404 bytes Offset Length Name Description 0x0 0x4 Experience Requirement Experience required to reach this level. Baby Form Table File - files located at /a/poketool/personal/pms.narc - file contains 1 section - special babies are defined in code in the overlays #1 Section - Baby Form Table - section is 2 bytes for each Pokemon, including alternate forms - total size is 1016 - starts with index 0, making Bulbasaur the second short Offset Length Name Description 0x0 0x2 Baby Index Number This is the index number of the default baby produced from breeding. Move Tutor Table File - files located at /fielddata/wazaoshie/waza_oshie.bin - file contains 1 section - does not include Dragon or starter tutors #1 Section - Move Tutor Table - section is 8 bytes for each Pokemon, including alternate forms - total size is 4040 - starts with index 1, making Bulbasaur the first entry Offset Length Name Description 0x0 0x1 Moves 1-8 (Bitfield) This bitfield is for moves 1-8, moving from least to most significant. 0x1 0x1 Moves 9-16 (Bitfield) This bitfield is for moves 9-16. 0x2 0x1 Moves 17-24 (Bitfield) This bitfield is for moves 17-24. 0x3 0x1 Moves 25-32 (Bitfield) This bitfield is for moves 25-32. 0x4 0x1 Moves 33-40 (Bitfield) This bitfield is for moves 33-40. 0x5 0x1 Moves 41-48 (Bitfield) This bitfield is for moves 41-48. 0x6 0x1 Moves 49-52 (Bitfield) This bitfield is for moves 49-52, with 4 bits of padding. Move Tutor Table - table is in Overlay 001 at 0x23AE0 - does not include Dragon or starter tutors - full table reference in the Appendix #1 Section - Move Tutor Table - section is 4 bytes for each entry, with 52 entries - total size is 208 - changing the values is possible, expanding the table is currently not known Offset Length Name Description 0x0 0x2 Move ID This is the ID number for the entry. 0x2 0x1 BP Cost This is the BP Cost for the entry, 0 if unapplicable. 0x3 0x1 Tutor ID This is the ID of the tutor for the entry.

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.

Field Encounters - located at /a/0/3/7 for HeartGold and /a/1/3/6 for SoulSilver - contains 12 sections #1 Section - Encounter Rates Offset Length Name Description 0x0 0x1 Field Rate Encounter rate in tall grass or walking. 0x1 0x1 Surfing Rate Encounter rate while surfing. 0x2 0x1 Rock Smash Rate Encounter rate when using Rock Smash. 0x3 0x1 Old Rod Rate Encounter rate when using the Rod. 0x4 0x1 Good Rod Rate Encounter rate when using the Good Rod. 0x5 0x1 Super Rod Rate Encounter rate when using the Super Rod. 0x6 0x2 Padding Color #2 Section - Field Encounter Levels 0x0 0x1 Slot 1 Level Level of the Pokemon encountered in Slot 1. 0x1 0x1 Slot 2 Level 0x2 0x1 Slot 3 Level 0x3 0x1 Slot 4 Level 0x4 0x1 Slot 5 Level 0x5 0x1 Slot 6 Level 0x6 0x1 Slot 7 Level 0x7 0x1 Slot 8 Level 0x8 0x1 Slot 9 Level 0x9 0x1 Slot 10 Level 0xA 0x1 Slot 11 Level 0xB 0x1 Slot 12 Level #3 Section - Field Encounter Pokemon (Morning) 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x2 Slot 2 Pokemon 0x4 0x2 Slot 3 Pokemon 0x6 0x2 Slot 4 Pokemon 0x8 0x2 Slot 5 Pokemon 0xA 0x2 Slot 6 Pokemon 0xC 0x2 Slot 7 Pokemon 0xE 0x2 Slot 8 Pokemon 0x10 0x2 Slot 9 Pokemon 0x12 0x2 Slot 10 Pokemon 0x14 0x2 Slot 11 Pokemon 0x16 0x2 Slot 12 Pokemon #4 Section - Field Encounter Pokemon (Daytime) 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x2 Slot 2 Pokemon 0x4 0x2 Slot 3 Pokemon 0x6 0x2 Slot 4 Pokemon 0x8 0x2 Slot 5 Pokemon 0xA 0x2 Slot 6 Pokemon 0xC 0x2 Slot 7 Pokemon 0xE 0x2 Slot 8 Pokemon 0x10 0x2 Slot 9 Pokemon 0x12 0x2 Slot 10 Pokemon 0x14 0x2 Slot 11 Pokemon 0x16 0x2 Slot 12 Pokemon #5 Section - Field Encounter Pokemon (Evening) 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x2 Slot 2 Pokemon 0x4 0x2 Slot 3 Pokemon 0x6 0x2 Slot 4 Pokemon 0x8 0x2 Slot 5 Pokemon 0xA 0x2 Slot 6 Pokemon 0xC 0x2 Slot 7 Pokemon 0xE 0x2 Slot 8 Pokemon 0x10 0x2 Slot 9 Pokemon 0x12 0x2 Slot 10 Pokemon 0x14 0x2 Slot 11 Pokemon 0x16 0x2 Slot 12 Pokemon #6 Section - Hoenn/Sinnoh Noise Encounters Offset Length Name Description 0x0 0x2 Hoenn Slot 1 Hoenn Slot 1 Pokemon index number. (Little Endian) 0x2 0x2 Hoenn Slot 2 0x4 0x2 Sinnoh Slot 1 Sinnoh Slot 1 Pokemon index number. (Little Endian) 0x6 0x2 Sinnoh Slot 2 #7 Section - Surfing Encounters Offset Length Name Description 0x0 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x1 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x2 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x4 0x1 Minimum Level Slot 2 0x5 0x1 Maximum Level Slot 2 0x6 0x2 Pokemon Slot 2 0x8 0x1 Minimum Level Slot 3 0x9 0x1 Maximum Level Slot 3 0xA 0x2 Pokemon Slot 3 0xC 0x1 Minimum Level Slot 4 0xD 0x1 Maximum Level Slot 4 0xE 0x2 Pokemon Slot 4 0x10 0x1 Minimum Level Slot 5 0x11 0x1 Maximum Level Slot 5 0x12 0x2 Pokemon Slot 5 #8 Section - Rock Smash Encounters Offset Length Name Description 0x0 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x3 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x4 0x2 Pokemon Slot 2 0x6 0x1 Minimum Level Slot 2 0x7 0x1 Maximum Level Slot 2 #9 Section - Old Rod Encounters Offset Length Name Description 0x0 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x1 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x2 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x4 0x1 Minimum Level Slot 2 0x5 0x1 Maximum Level Slot 2 0x6 0x2 Pokemon Slot 2 0x8 0x1 Minimum Level Slot 3 0x9 0x1 Maximum Level Slot 3 0xA 0x2 Pokemon Slot 3 0xC 0x1 Minimum Level Slot 4 0xD 0x1 Maximum Level Slot 4 0xE 0x2 Pokemon Slot 4 0x10 0x1 Minimum Level Slot 5 0x11 0x1 Maximum Level Slot 5 0x12 0x2 Pokemon Slot 5 #10 Section - Good Rod Encounters Offset Length Name Description 0x0 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x1 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x2 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x4 0x1 Minimum Level Slot 2 0x5 0x1 Maximum Level Slot 2 0x6 0x2 Pokemon Slot 2 0x8 0x1 Minimum Level Slot 3 0x9 0x1 Maximum Level Slot 3 0xA 0x2 Pokemon Slot 3 0xC 0x1 Minimum Level Slot 4 0xD 0x1 Maximum Level Slot 4 0xE 0x2 Pokemon Slot 4 0x10 0x1 Minimum Level Slot 5 0x11 0x1 Maximum Level Slot 5 0x12 0x2 Pokemon Slot 5 #11 Section - Super Rod Encounters Offset Length Name Description 0x0 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x1 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x2 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x4 0x1 Minimum Level Slot 2 0x5 0x1 Maximum Level Slot 2 0x6 0x2 Pokemon Slot 2 0x8 0x1 Minimum Level Slot 3 0x9 0x1 Maximum Level Slot 3 0xA 0x2 Pokemon Slot 3 0xC 0x1 Minimum Level Slot 4 0xD 0x1 Maximum Level Slot 4 0xE 0x2 Pokemon Slot 4 0x10 0x1 Minimum Level Slot 5 0x11 0x1 Maximum Level Slot 5 0x12 0x2 Pokemon Slot 5 #12 Section - Swarm Encounters Offset Length Name Description 0x0 0x2 Field Swarm Field Swarm Pokemon index number. (Little Endian) 0x2 0x2 Surfing Swarm Surfing Swarm Pokemon index number. (Little Endian) 0x4 0x2 Good Rod Swarm Good Rod Swarm Pokemon index number. (Little Endian) 0x6 0x2 Super Rod Swarm Super Rod Swarm Pokemon index number. (Little Endian) Headbutt Encounters - located at /a/2/5/3 for HeartGold and /a/2/5/2 for SoulSilver - contains 5 sections #1 Section - Tree Allocation Offset Length Name Description 0x0 0x1 Headbutt Trees Number of trees defined in section #4. 0x1 0x1 Padding 0x2 0x1 Special Trees Number of trees defined in section #5. 0x3 0x1 Padding #2 Section - Normal Headbutt Encounters Offset Length Name Description 0x0 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x3 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x4 0x2 Pokemon Slot 2 0x6 0x1 Minimum Level Slot 2 0x7 0x1 Maximum Level Slot 2 0x8 0x2 Pokemon Slot 3 0xA 0x1 Minimum Level Slot 3 0xB 0x1 Maximum Level Slot 3 0xC 0x2 Pokemon Slot 4 0xE 0x1 Minimum Level Slot 4 0xF 0x1 Maximum Level Slot 4 0x10 0x2 Pokemon Slot 5 0x12 0x1 Minimum Level Slot 5 0x13 0x1 Maximum Level Slot 5 0x14 0x2 Pokemon Slot 6 0x16 0x1 Minimum Level Slot 6 0x17 0x1 Maximum Level Slot 6 0x18 0x2 Pokemon Slot 7 0x1A 0x1 Minimum Level Slot 7 0x1B 0x1 Maximum Level Slot 7 0x1C 0x2 Pokemon Slot 8 0x1E 0x1 Minimum Level Slot 8 0x1F 0x1 Maximum Level Slot 8 0x20 0x2 Pokemon Slot 9 0x22 0x1 Minimum Level Slot 9 0x23 0x1 Maximum Level Slot 9 0x24 0x2 Pokemon Slot 10 0x26 0x1 Minimum Level Slot 10 0x27 0x1 Maximum Level Slot 10 0x28 0x2 Pokemon Slot 11 0x2A 0x1 Minimum Level Slot 11 0x2B 0x1 Maximum Level Slot 11 0x2C 0x2 Pokemon Slot 12 0x2E 0x1 Minimum Level Slot 12 0x2F 0x1 Maximum Level Slot 12 #3 Section - Special Headbutt Encounters Offset Length Name Description 0x0 0x2 Pokemon Slot 1 Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Minimum Level Slot 1 Minimum level of Pokemon in Slot 1. 0x3 0x1 Maximum Level Slot 1 Maximum level of Pokemon in Slot 1. 0x4 0x2 Pokemon Slot 2 0x6 0x1 Minimum Level Slot 2 0x7 0x1 Maximum Level Slot 2 0x8 0x2 Pokemon Slot 3 0xA 0x1 Minimum Level Slot 3 0xB 0x1 Maximum Level Slot 3 0xC 0x2 Pokemon Slot 4 0xE 0x1 Minimum Level Slot 4 0xF 0x1 Maximum Level Slot 4 0x10 0x2 Pokemon Slot 5 0x12 0x1 Minimum Level Slot 5 0x13 0x1 Maximum Level Slot 5 0x14 0x2 Pokemon Slot 6 0x16 0x1 Minimum Level Slot 6 0x17 0x1 Maximum Level Slot 6 #4 Section - Normal Tree Definitions - section is repeated (x-1) times - x is equal to Headbutt Trees in Section #1 - each repetition represents a singular "tree" - each section is six sets of coordinates - unused coordinates are always 0xFFFFFFFF Offset Length Name Description 0x0 0x2 X1 Coordinate X map coordinate of first tile in the "tree". (Little Endian) 0x2 0x2 Y1 Coordinate Y map coordinate of first tile in the "tree". (Little Endian) 0x4 0x2 X2 Coordinate 0x6 0x2 Y2 Coordinate 0x8 0x2 X3 Coordinate 0xA 0x2 Y3 Coordinate 0xC 0x2 X4 Coordinate 0xE 0x2 Y4 Coordinate 0x10 0x2 X5 Coordinate 0x12 0x2 Y5 Coordinate 0x14 0x2 X6 Coordinate 0x16 0x2 Y6 Coordinate #5 Section - Special Tree Definitions - section is repeated (x-1) times - x is equal to Special Trees in Section #1 - follows same rules as Section #4 Offset Length Name Description 0x0 0x2 X1 Coordinate X map coordinate of first tile in the "tree". (Little Endian) 0x2 0x2 Y1 Coordinate Y map coordinate of first tile in the "tree". (Little Endian) 0x4 0x2 X2 Coordinate 0x6 0x2 Y2 Coordinate 0x8 0x2 X3 Coordinate 0xA 0x2 Y3 Coordinate 0xC 0x2 X4 Coordinate 0xE 0x2 Y4 Coordinate 0x10 0x2 X5 Coordinate 0x12 0x2 Y5 Coordinate 0x14 0x2 X6 Coordinate 0x16 0x2 Y6 Coordinate Safari Zone Encounters - located at /a/2/3/0 - contains 16 sections #1 Section - Object Arrangement Allocation Offset Length Name Description 0x0 0x1 Tall Grass Encounters The number of tall grass encounter slots for Object Arrangement. 0x1 0x1 Surfing Encounters The number of surfing encounter slots for Object Arrangement. 0x2 0x1 Old Rod Encounters The number of Old Rod encounter slots for Object Arrangement. 0x3 0x1 Good Rod Encounters The number of Good Rod encounter slots for Object Arrangement. 0x4 0x1 Super Rod Encounters The number of Super Rod encounter slots for Object Arrangement. 0x5 0x3 Padding Always 0x0 #2 Section - Tall Grass Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #3 Section - Tall Grass Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Tall Grass Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Tall Grass Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #4 Section - Object Arrangement Requirements (Tall Grass) - section is equal to 1/3 the length of Section #3 - or 4 bytes multiplied by Tall Grass Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #3 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity #2 Section - Tall Grass Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #3 Section - Tall Grass Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Tall Grass Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Tall Grass Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #4 Section - Object Arrangement Requirements (Tall Grass) - section is equal to 1/3 the length of Section #3 - or 4 bytes multiplied by Tall Grass Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #3 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity #5 Section - Surfing Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #6 Section - Surfing Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Surfing Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Surfing Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #7 Section - Object Arrangement Requirements (Surfing) - section is equal to 1/3 the length of Section #6 - or 4 bytes multiplied by Surfing Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #6 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity #8 Section - Old Rod Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #9 Section - Old Rod Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Old Rod Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Old Rod Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #10 Section - Object Arrangement Requirements (Old Rod) - section is equal to 1/3 the length of Section #9 - or 4 bytes multiplied by Old Rod Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #9 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity #11 Section - Good Rod Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #12 Section - Good Rod Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Good Rod Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Good Rod Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #13 Section - Object Arrangement Requirements (Good Rod) - section is equal to 1/3 the length of Section #12 - or 4 bytes multiplied by Good Rod Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #12 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity #14 Section - Super Rod Encounters - section contains 3 sub-sections for time-of-day encounters - each 4 bytes represents a slot, with 10 slots per time of day Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Daytime 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color 0x4 0x2 Slot 2 Pokemon 0x6 0x1 Slot 2 Level 0x7 0x1 Padding 0x8 0x2 Slot 3 Pokemon 0xA 0x1 Slot 3 Level 0xB 0x1 Padding 0xC 0x2 Slot 4 Pokemon 0xE 0x1 Slot 4 Level 0xF 0x1 Padding 0x10 0x2 Slot 5 Pokemon 0x12 0x1 Slot 5 Level 0x13 0x1 Padding 0x14 0x2 Slot 6 Pokemon 0x16 0x1 Slot 6 Level 0x17 0x1 Padding 0x18 0x2 Slot 7 Pokemon 0x1A 0x1 Slot 7 Level 0x1B 0x1 Padding 0x1C 0x2 Slot 8 Pokemon 0x1E 0x1 Slot 8 Level 0x1F 0x1 Padding 0x20 0x2 Slot 9 Pokemon 0x22 0x1 Slot 9 Level 0x23 0x1 Padding 0x24 0x2 Slot 10 Pokemon 0x26 0x1 Slot 10 Level 0x27 0x1 Padding #15 Section - Super Rod Encounters (Object Arrangement) - section is equal to 4 bytes, multiplied by Super Rod Encounters in Section #1, multiplied by 3 - section contains 3 sub-sections for time-of-day encoutners - each 4 bytes represents a slot, with (x) slots per time of day, x being Super Rod Encounters in Section #1 Offset Length Name Description Morning 0x0 0x2 Slot 1 Pokemon Slot 1 Pokemon index number. (Little Endian) 0x2 0x1 Slot 1 Level Level of the Pokemon in Slot 1. 0x3 0x1 Padding Color Daytime 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding Evening 0x0 0x2 Slot 1 Pokemon 0x2 0x1 Slot 1 Level 0x3 0x1 Padding #16 Section - Object Arrangement Requirements (Super Rod) - section is equal to 1/3 the length of Section #15 - or 4 bytes multiplied by Super Rod Encounters in Section #1 - each 4 bytes represents a slot, corresponding to the equivalent slot in Section #15 for each time of day Offset Length Name Description 0x0 0x1 First Object Type First Object Type requirement. Valid vaules: 0x1 Plains, 0x2 Forest, 0x3 Peak, 0x4 Waterside. 0x1 0x1 First Object Quantity The number of objects of the first type required. 0x2 0x1 Second Object Type This is for an optional second type requirement. Additional valid value: 0x0 No Requirement. 0x3 0x1 Second Object Quantity

Looking for a kangaskhan with this moveset : Fake Out Seismic Toss Body Slam Ice Punch I already did my researchs but didn't found the information to gen this pokemon Looking forward for a response !

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.

The type effectiveness table is in code.bin (in ExeFS this time) @ 0x497554 In 1.1 update it's 0x499550 I couldn't find the info, so I found it myself. Here it is for others who have been looking.

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.

I have a lot of information on which I'll be adding to this post. I've been writing an app to streamline the hacking process and I've pretty much completed the logic and just need to complete the UI now. As a result there is a lot of code that is quite useful as a reference. It's all in the swift programming language which I doubt many people here use but it should be simple enough to figure out what it all does. Here's a link to the repository : -Code'>https://github.com/PekanMmd/Pokemon--Code Part 1 of my tutorials: -hacking-tutorial-part-1-File-decompression-recompression'>http://projectpokemon.org/forums/showthread.php?46250-Stars-Pokemon-colosseum-and--hacking-tutorial-part-1-File-decompression-recompression I'll be updating this post with more details. Enumerations: Constants: Texture Editing: Data Tables: Gift and Trade Pokemon:

Maybe this was already known but I couldn't find anything about it on the Internet, so here I go. I think I may have found something weird about how the Counter / Mirror Coat / Metal Burst trio behaves against damage-reducing berries (including the Chilan Berry). Note that this behavior is for Gen IV only (Gen V onwards it behaves like one would expect it to.) What is already known: Counter sends back to the attacker 200% of the damage taken by a physical attack, and fails against special attacks and Ghost-type Pokémon. Mirror Coat sends back to the attacker 200% of the damage taken by a special attack, and fails against physical attacks and Dark-type Pokémon. Metal Burst sends back to the attacker 150% of the damage taken by an offensive move, provided the attacker was faster this turn. What I accidentally stumbled upon: Damage-reducing berries, when activated, doesn't touch the actual damage value (like it does with Focus Sash for example), rather it seems that the calculation for halving the damage is done separately from the actual damage value read by the game. Hence for example if a move was supposed to deal 200 HP damage, the berry will activate and will deal instead 100 HP damage (rounded down), but the game doesn't update the damage value (it still reads it as -200). Thus if a damage-reducing berry was activated this turn and the user happens to use one of the "Sends back to attacker" move, it will deal 200% damage (150% damage if Metal Burst) of the value stored in-game instead of the actual damage dealt. That is in this example, Counter/Mirror Coat (Metal Burst) would deal 400 HP (300 HP) damage and not 200 HP (150 HP) like one would expect! If this was already known, I'm sorry and you can slap me a thousand times.

For a while I thought to myself, there should be a ROM hack format that patches individual files in the ROM, instead of the ROM itself. Meanwhile, psy_commando had a similar idea (I'm making a new thread so that one will be exclusively for PMD2). The current discussion for those who haven't read it: I've been working on upgrading Sky Editor to make making ROM hacks like these easier, and before I actually write code for making patches, I think it's time that we ROM hack tool developers discussed and made a standard. Here's my proposition: a "mod pack" zip contains one or more smaller mods and the patching tools. A "mod" zip contains all the data needed for 1 patch. Having various smaller mods allows them to be reused in other packs, and to let users pick which mods to apply to their ROM. For example, maybe in Rutile Ruby or Star Sapphire, what if I hypothetically wanted the increased XP curve, but didn't want any changes to items. I could then apply the "XP Curve" mod, but not the "Item Balance" mod. Here's a more technical proposition: File structure of the Mod zip (probably called .ndsmod or .3dsmod): /Mod.json Contains information about the mod like Name, Author, Target ROM, etc. Lists IO operations that need to be done (maybe I want to swap /Data/Sound/BGM/bgm0045.smd and /Data/Sound/BGM/bgm0003.smd or delete the entire /TOP directory) Can optionally list other mods that must be applied before or after this one. (For mods of a mod; patching files that are added by other mods). (Optional) /Patcher.exe Optional patcher in case weird file types are included, or to allow for randomizers. Usage: "patcher.exe [directory]", where directory is the path of the ROM directory (the one containing arm9.bin, arm7.bin, and the Data and Overlay directories). /Files/ Contains certain kinds of patch files in the same directory structure as ndstool extracts them. Ex. /Files/Data/BACK/expback.bgp.xdelta is an xdelta patch for the file at /Data/BACK/expback.bgp Ex. /Files/Data/FONT/kaomado.kao.kaopatch is a special file the patching utility knows how to handle that adds more images inside the file at /Data/FONT/kaomado.kao. The advantage over a binary difference is that multiple mods can independently add images without interfering with each other. Ex. /Files/Data/Back/MyBackground.bgp.file is a brand new file to be added at /Data/Back/MyBackground.bgp Any directories present anywhere in the folder hierarchy in /Files will be added in the appropriate place. File structure of the Mod Pack zip: /Pack.json Contains information about the mod pack like Name, Author, Target ROM, etc. /Patcher.exe and/or /Patcher.bat and/or other comparable OS specific patcher file. Should probably be required to support command line arguments (patcher.exe [inputFile] [outputFile]). /Mods/ - contains one or more mod zips. /Tools/ - contains any tools or executables needed by the patcher. Exact name doesn't matter as long as end users don't need to worry about its contents. /Tools/FileFormats.json Maps executables (or comparable files like .py) that know how to handle individual file patches to the proper extension, like the .kaopatch example above Ex. Could have an entry for .kaopatch that points to "/Tools/RomEditor.exe -kaopatch -i {Input} -o {Output}", where {Input} and {Output} are replaced with input and output paths. Ex. Could have an entry for .kaopatch that points to "/Tools/KaoPatch.exe" where usage "kaopatch.exe [inputFile] [outputFile]" is implied This format is designed for NDS Roms, but should also work with 3DS Roms (as long as the patcher is included). Formats of the .json files can be finalized later. This format should be as legal as xdelta patches unless I've overlooked something. Feel to post questions/comments/concerns about any aspect of it, especially if you're a ROM hacking tool developer or a ROM hack developer. [Edit 8/2] Updated details to match my current development.

Hey I was going through some scripts in my HeartGold ROM with PPRE yesterday when I found something quite interesting. When you open the map editor and open the map "Burned Tower R1-02" there's three scripts. The first one just checks a flag and the second one triggers Raikou and Entei to roam, the third one, however, is quite interesting. This is its code: Fanfare 1500 Lockall Faceplayer Cryfr 245 0 Waitcry Setflag 164 [b]WildBattle2 245 40 0 [/b] Clearflag 164 CheckTrainerLost 0x800c If 0x800c 0 CheckLR 1 func_4 StoreEmbStatus? 0x4002 If 0x4002 3 CheckLR 1 func_5 If 0x4002 4 CheckLR1 1 func_6 Releaseall End As you can see in the bold part, it uses the command WildBattle2 245 40 0. Now 245 is the number for Suicune in the Pokedex. Does that mean it was originally planned for Suicune to be catchable right in the Burned Tower like in Crystal? Interestingly enough, the flag 164 that it sets before and clears after the battle is the one that is also checked in the first script. As I said, I have only started to look into this yesterday so I don't have much knowledge about scripting in general (it's very hard to even find information about scripting for the fourth generation) but I guess my assumption is right? Well the command clearly triggers a battle with Suicune, that's for sure. Is there a way that we can find out the means to trigger this script in the game? Lastly I want to say that I'm sorry if this is an already well-known fact but a quick google search before posting this didn't bring up any results. I'd like to have your opinion on this. For reference, the ROM I looked into was the US version of HeartGold and I can guarantee that it was not modified in any way. I do not know if that script is also present in SoulSilver, might have to look into that.