** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts**
First of all I would like to point out again that I spent most of my time testing Colosseum and only recently began to decode XD as well. I haven't actually tested a lot of the stuff in this section but most of it seems obvious enough for me to assume I was right. A lot of stuff is similar to Colosseum anyway so its easy to extrapolate. I did test a little bit thought so I'm confident it works.
Now, in XD, the trainer data is split up across several files which you will find in the deck_archive.fsys file. This contains 2 identical versions of each .bin file within. One just has _EU added to the file name, maybe its loaded in the PAL version instead of the other one. I don't know. However, it looks like you can get away with editing just the regular one and worst case scenario, the files are identical so you could just edit one, duplicate it and replace the _EU version with the duplicate. A big issue with these files is that it is hard to decrease their compressed file sizes. Their data is so much more compact than the data in the Colosseum files and just about every byte of data is actually important. It may be more effective to make a larger .fsys archive and edit the .toc of the iso. However, I speculate that if you are playing the US version of the game, the EU versions of the files are never loaded up. If that is the case then these files could be reduced to 1 byte (or maybe even removed completely), effectively doubling the space available in the .fsys file.
The .bin files are as follows:
- DeckData_Bingo: This contains the data for the Pokémon used on the battle bingo cards. Unfortunately, changing the moves and stats of pokemon will have a butterfly effect on these challenges and may ruin some of them as they were often quite precise.
- DeckData_DarkPokemon: This contains some information about the Shadow Pokémon. The Pokémon itself is detailed like a normal Pokémon in DeckData_Story. The DDPK file just has things like the shadow moves to replace some of their regular moves with until purification, their purification steps and their adjusted catch rate. In case you haven't read the note in the Pokémon stats section, each shadow Pokémon has a catch rate with it's data which I believe override's their regular catch rate. They're usually the same though (a few are different). The file specifies which Pokémon in DeckData_Story each of the shadow data accompanies.
- DeckData_Story: This contains the data for all the trainers and their Pokémon in the story line. Unlike Colosseum the trainer data was easy to find as the files in XD have useful magic bytes and simple headers.
- DeckData_Colosseum: The data for the trainers and Pokémon the story mode Colosseum challenges.
- DeckData_Hundred: The data for the trainers and Pokémon on mt.battle in story mode
- DeckData_Imasugu: The data for the trainers and Pokémon if you choose "quick battle" on vs. mode. (imasugu literally means "right now")
- DeckData_Sample: These are Pokémon teams that are quite random and I don't believe they appear in the game at any point. Especially being called 'sample' it can be assumed that these were teams which genius sonority just used to test the game during development and never took out.
- DeckData_Virtual: These are the trainers and Pokémon that appear in the battle CD challenges in story mode. Unfortunately, changing the moves and stats of Pokémon will have a butterfly effect on these challenges and may ruin some of them as they were often quite precise. Each CD has 2 teams in this file. One is the opponents team and one is the team that you are given for the CD.
I have edited the data for the Salamence you get in the first sim battle right at the start of story mode and tested a few things so my data should be fairly accurate.
In all the decks apart from DeckData_DarkPokemon, there are 4 sections; DTNR (Deck trainer), DPKMN (Deck Pokémon), DTAI (maybe something like Deck trainer AI?) and DSTR (Deck string). The first 16 (0x10) bytes are the DECK file's header. The first 4 bytes of this header are the magic bytes "DECK". The next 4 bytes are the size of the file in bytes.
The first row of each section is the header. The first 4 bytes are the magic bytes identifying the start of that section. The next 4 bytes is the size of that section in bytes (including the header itself which is 16 (0x10) bytes) and the 4 bytes after that are the number of entries there are in that section.
DTNR contains the data for each trainer in that file. Each entry in DTNR is 56 (0x38) bytes. Each trainer has six slots for Pokémon. An id number for each Pokémon is specified and the Pokémon at that index in DPKM (or DDPK as the next note will explain) will be used as that Pokémon. The byte at 0x4 is what I call the "shadow mask" it is a bit mask of the trainer's Pokémon. If you convert the number to binary each of the last 6 bits represents one of the trainer's Pokémon. If the bit corresponding to a Pokémon is 1 then the Pokémon will be treated as a Shadow Pokémon and loaded from DeckData_DarkPokemon's DDPK section instead of the DPKM section and so the id used to reference that Pokémon is actually a reference to its entry number in DDPK. Every other Pokémon is specified by an id which references a Pokémon from DPKM. i.e. an id of 1 will be the Pokémon which is the first entry in DPKM unless the bit for that Pokémon is set in which case it will refer to the first entry in DDPK (which refers to a Pokémon in DPKM, in this case it points to the Teddiursa which is entry 28/0x1C in DPKM). A shadow mask value of 0x01 (0b0001 in binary) means the first Pokémon is a Shadow Pokémon whereas 0x6 (0b0110 in binary) means the 2nd and 3rd are Shadow Pokémon.
The first entry is empty so the first trainer in a DTNR section starts at 0x38 bytes after the end of the DTNR header. Since the DTNR section comes first in all the decks that have one, it is always 0x58 bytes from the start of the file.
There is an id value for each of the trainer class names and each of the trainer class models. (The name hunter refers to both male and female hunters but the they have separate models). I haven't figured out which numbers correspond to which classes yet though but 0x11 is the cipher peon class name while 0x10 is the model for blusix. It won't be very hard to compile a list since you can tell which trainer each entry is by their team, it's just tedious.
|Offset of Trainer Name in DSTR||2||0x00|
|ID of Trainer Class Name||1||0x05|
|ID of Name String||2||0x06||The ID refers to text in the string table in common_rel|
|ID of Trainer Class Model||1||0x11|
|DPKM Index of 1st Pokémon||2||0x1C|
|DPKM Index of 2nd Pokémon||2||0x1E|
|DPKM Index of 3rd Pokémon||2||0x20|
|DPKM Index of 4th Pokémon||2||0x22|
|DPKM Index of 5th Pokémon||2||0x24|
|DPKM Index of 6th Pokémon||2||0x26|
The next section of the DECK is the DPKM section. This contains the data for individual Pokémon. There aren't too many gimmicks here. You get the data for that Pokémon like moves, gender and nature. This section specifies nothing about whether or not a Pokémon is a Shadow Pokémon or not. The extra data for the Shadow Pokémon is in the DDPK section of DeckData_DarkPokemon and that data specifies which Pokémon in the DPKM file of the story deck it adds to. Remember that the Pokémon's level will be overridden by the level specified in DDPK if it is a shadow Pokémon.
The one tricky little thing is the Pokémon's personality id. Genius sonority did things a little differently from game freak. I tested it out using the value for the Salamence in the sim battle at the start of a new game and comparing to the gender, nature and ability it had since these were the only 3 variables I wasn't able to find yet. To see what is happening you need to convert the personality value to binary.
Sim Salamence personality value - 0x6A = 0b01101010
bit 7 6 5 4 3 2 1 0
value 0 1 1 0 1 0 1 0
The Pokémon's ability is determined by bit 0 which in this case is it's first ability (0x00). The Pokémon's gender is determined by bits 2-1 which in this case is female (0x1 = 0b01). Male is 0x00 and genderless is (0x2 = 0b10). The nature is determined by bits 7-3 which in this case is jolly (0xD = 0b01101).
To programmatically get each of these values you take the original number 'p'. p % 2 (modular division) gives you the ability. (p / 2) % 4 is the gender. p / 8 is the nature.
Each Pokémon is 0x20 (32) bytes long. The first Pokémon (which is an empty entry) is straight after the DPKM header which is 16 bytes long.
N.B. I haven't tested the order of the IVs and EVs but I've assumed they're in the same order as Colosseum. This also coincides with the order of the natures so it's a pretty safe assumption. Also the Pokémon's moves will be replaced by shadow moves from DDPK if it is a Shadow Pokemon.
DPKM Pokémon data
|Sp. Attack IV||1||0x0C|
|Sp. Defense IV||1||0x0D|
|Sp. Attack EV||1||0x12|
|Sp. Defense EV||1||0x13|
The DSTR section doesn't seem very useful so I won't go into much detail. Basically, each trainer has a string which goes with them. Each trainer in DTNR has 2 bytes which say which offset in DSTR their code name starts at. The only use this has is that it can give you a hint as to where the trainer appears in-game. The code names usually start with the id of the map that the trainer is in like s1 (outskirt stand), d1 (shadow lab) or m5 (Pokémon hq lab). You may be able to reduce the compressed size of the DECK files by deleting all the DSTR code names since I don't think they are loaded by the game but I don't know if that will have any side-effects yet.
The other deck type is DeckData_DarkPokemon. Each shadow Pokémon has its regular Pokémon data saved in DeckData_Story's DPKM section like any other normal Pokémon. The shadow data in DeckData_DarkPokemon's DDPK section specifies the Pokémon it complements. The trainer that has the Shadow Pokémon sets the shadow mask bit telling the game that the Pokémon in that slot is referencing DDPK rather than DPKM and then that entry in DDPK has a reference back to one of the Pokémon in DPKM which is the Pokémon that will be the Shadow Pokémon.
The header is 16 (0x10) bytes long. The first 4 bytes of this are the magic bytes "DECK" followed by 4 bytes which give the file size in bytes. The only section in this file is the DDPK (Dark Pokémon which is Shadow Pokémon in Japanese ). The header is 16 (0x10) bytes long and each entry is 0x18 (24) bytes long. The first entry is empty after which there is an entry for each Shadow Pokémon and a whole bunch left over. You could technically add more shadow Pokémon and I think XD may handle the caught Shadow Pokémon a bit better than Colosseum does so it might actually be as simple as adding another entry to this file. However, it is already extremely hard to decrease the file size of the decks so that must be considered.
The catch rate overrides the catch rate of the Pokémon in it's data in common_rel and it's level overrides the level specified in DPKM in DeckData_Story. Like with just about everything else in XD, i haven't tested this but I think each Shadow Pokémon gets a purification counter, kind of like the steps an egg needs to hatch in other games in the series. The higher this value, the harder the Pokémon is to purify. The Shadow Pokémon can be given between 1 and 4 shadow moves.
DDPK data table
|Pokémon Index in DPKM (Story)||2||0x06|
|Shadow Move 1||2||0x0C|
|Shadow Move 2||2||0x0E|
|Shadow Move 3||2||0x10|
|Shadow Move 4||2||0x12|
Edited by evandixon
Update table formatting