Part 8: Editing Trainers (XD)

[StarsMmd]

** 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.

DTNR table

Variable	Size (bytes)	Offset
Offset of Trainer Name in DSTR	2	0x00
Shadow Mask	1	0x04
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
Trainer AI?	1	0x13
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

Variable	Size (bytes)	Offset
Pokémon Species	2	0x00
Pokémon Level	1	0x02
Happiness	1	0x03
Item	2	0x04
HP IV	1	0x08
Attack IV	1	0x09
Defense IV	1	0x0A
Speed IV	1	0x0B
Sp. Attack IV	1	0x0C
Sp. Defense IV	1	0x0D
HP EV	1	0x0E
Attack EV	1	0x0F
Defense EV	1	0x10
Speed EV	1	0x11
Sp. Attack EV	1	0x12
Sp. Defense EV	1	0x13
Move 1	2	0x14
Move 2	2	0x15
Move 3	2	0x16
Move 4	2	0x17
Personality ID	1	0x1C

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

Variable	Size (bytes)	Offset
Catch Rate	1	0x01
Level	1	0x02
Pokémon Index in DPKM (Story)	2	0x06
Purification Counter	2	0x08
Shadow Move 1	2	0x0C
Shadow Move 2	2	0x0E
Shadow Move 3	2	0x10
Shadow Move 4	2	0x12

View full tutorial

Edited November 16, 2015 by StarsMmd

[StarsMmd]

In the attached images i mentioned what I erroneously guessed was some sort of unique trainer id. It only recently dawned on me that it was the string table id for the trxt the trainer says when you defeat them. I noticed this in the colosseum data so it's weird that It took me so long to make the connection. there is also the prebattle id (colosseums only) and victory text id (colosseums and mtbattle) like in colosseum.

[EDIT:] So @Tiddlywinks informed me that a trainer's prize money is affected by the highest level of their pokemon. However, even though greevil's team of 6 and the shadow lugia battle just before both contain only level 50 pokemon, his shadow lugia battle awards $300 more. I just checked and this is because the prize money is calculated using the level in DPKM whereas the level used in battle is determined in DDPK. So although the DDPK level overrides the DPKM one, the DPKM one is usually raised a little just to increase the prize money from some shadow pokemon users.

Edited June 30, 2015 by StarsMmd

[StarsMmd]

I ran my first major texts yesterday and something I found was that when the game loads a trainer from a deck it reads until the first empty slot. In other words if you had [ralts][empty][pikachu][empty][empty][empty], the game would only load ralts. If the first entry is empty the trainer will have no pokemon and you'll win the battle as soon as you finish selecting your moves.

Edited November 17, 2015 by StarsMmd

[Tiddlywinks]

The one tricky little thing is the pokemon'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 pokemon's ability is determined by bit 0 which in this case is it's first ability (0x00). The pokemon'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 pokemon is 0x20 (32) bytes long. The first pokemon (which is an empty entry) is straight after the DPKM header which is 16bytes 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 pokemon's moves will be replaced by shadow moves from DDPK if it is a shadow pokemon.

DPKM pokemon data

---------------------------------------------------------------------------------------------------------------------------------------

variable size (bytes) offset

pokemon species 2 0x00

pokemon level 1 0x02

happiness 1 0x03

item 2 0x04

HP IV 1 0x08

Attack IV 1 0x09

Defense IV 1 0x0A

Speed IV 1 0x0B

Sp.Atk IV 1 0x0C

Sp.Def IV 1 0x0D

HP EV 1 0x0E

Attack EV 1 0x0F

Defense EV 1 0x10

Speed EV 1 0x11

Sp.Atk EV 1 0x12

Sp.Def EV 1 0x13

move 1 2 0x14

move 2 2 0x16

move 3 2 0x18

move 4 2 0x1A

personality id 1 0x1C

I've been trying to put the deck data to some minor use, and I've noticed some things...

First, at the end here, you've said the PID starts at 0x1C but that it's only 1 byte long; either it's actually 4 bytes, or it starts at 0x1E (...and then that can't really be called the PID). (Another small mistake: in "(p % 2) % 4 is the gender", you probably meant "(p / 2) % 4 is the gender".)

However, I'm really not sure those 4 bytes at 0x1C would be the PID anyway. Have you actually found the in-battle PKM of a Pokemon and verified that it has the same 4 bytes for its PID as are at 0x1C in the DPKM data? It's just weird to me that most of the time 3 of those 4 bytes are 0x00.

Also, from my examination of the story deck, it looks like Greevil's Shadow Exeggutor (entry 0x02BE in DPKM) should be male, but

shows it to be female. It's possible that's because it's a Shadow Pokemon and therefore it gets randomized regardless--in fact, I also notice that everything in the Story deck has all 0 IVs and EVs, and I'm fairly confident that Shadow Pokemon do get random IVs, so that may well be the case. I will note that the handful of non-Shadow Pokemon I've tried to check in videos have apparently had the right gender, but that's hardly conclusive. (Short of finding the code where deck data is turned into a PKM, the best way to be sure would be to check the same Pokemon (in its first appearance preferably) multiple times; preferably something with a lopsided ratio and its gender set as the less common one (e.g., a female Bulbasaur), or at least with a 50/50 ratio.)

I also played around with the Battle Now mode's Quick Battles, looking for deck data I could actually edit in RAM, and it seems this deck does actually get read into RAM at 0x00D9FC30. Interestingly, if you keep selecting a "challenge level" and then declining to use the assigned team, the Pokemon's stats (including gender) actually get randomized. And this is reflected in the RAM. Then I noticed that all of the 0x1F bytes in its DPKM data were 0x80.

So it looks to me like that high bit of 0x1F is a randomizer flag for IVs/EVs/0x1E (Nature/gender/Ability). When I turned 0x1F to 0x00, the IVs/EVs/0x1E indeed stopped randomizing (though it looks like 0x1E's Ability bit will be forced back to 0 if it's set to 1 when the Pokemon only has one Ability).

Another weird thing... It looks like if you set both the "female" and "genderless" flags (e.g., 0b110 at 0x1E), the game will apparently randomize the Nature... This may be unintended behavior, though, because when I set that for Geodude and started cycling Quick Battle teams, the game would always take an extra second or two to load the team if it turned out to have Geodude on it.

TL;DR: I think 0x1C-1D are unknown, 0x1E is Nature/gender/Ability like you've already explained, and 0x1F is a randomizing flag. I don't think a "personality value" is in the DPKM data, per se.

[StarsMmd]

I've been trying to put the deck data to some minor use, and I've noticed some things...

(Another small mistake: in "(p % 2) % 4 is the gender", you probably meant "(p / 2) % 4 is the gender".)

Whoops, thanks will fix that now.

First, at the end here, you've said the PID starts at 0x1C but that it's only 1 byte long; either it's actually 4 bytes, or it starts at 0x1E

However, I'm really not sure those 4 bytes at 0x1C would be the PID anyway.

Yeah I called it the pid because I didn't have a better name but it definitely isn't the pid. I used the name because it is used to calculate the ability, gender and nature and I think this will affect the pid that is generated at the end of the day because it will need to match these values. I read somewhere that the game literally just keeps trying new values until they match.

Also, from my examination of the story deck, it looks like Greevil's Shadow Exeggutor (entry 0x02BE in DPKM) should be male, but

shows it to be female. It's possible that's because it's a Shadow Pokemon and therefore it gets randomized regardless--in fact, I also notice that everything in the Story deck has all 0 IVs and EVs, and I'm fairly confident that Shadow Pokemon do get random IVs, so that may well be the case. I will note that the handful of non-Shadow Pokemon I've tried to check in videos have apparently had the right gender, but that's hardly conclusive. (Short of finding the code where deck data is turned into a PKM, the best way to be sure would be to check the same Pokemon (in its first appearance preferably) multiple times; preferably something with a lopsided ratio and its gender set as the less common one (e.g., a female Bulbasaur), or at least with a 50/50 ratio.)

All shadow pokemon have random genders. There is even footage of Zook's zangoose having different genders between the 3 times you see it because it's final value isn't set until you battle him yourself.

I also played around with the Battle Now mode's Quick Battles, looking for deck data I could actually edit in RAM, and it seems this deck does actually get read into RAM at 0x00D9FC30. Interestingly, if you keep selecting a "challenge level" and then declining to use the assigned team, the Pokemon's stats (including gender) actually get randomized. And this is reflected in the RAM. Then I noticed that all of the 0x1F bytes in its DPKM data were 0x80.

That's interesting actually. I noticed all the shadow pokemon either had 0x40 or 0x80 in the byte just before what I called the "pid" but couldn't figure out what it meant. I think it makes sense that it randomises the values. That's like how the values in colosseum worked where the high bit randomised the value.

There are two possibilities. The "pid" field is 2 bytes long and the high bit for those 16bits is what randomises that value and the IVs are randomised by default.

However there is no high bit set for the IVs of shadow pokemon so the second possibility is that the 0x40/0x80 byte itself randomises all the fields that need randomising.

First, at the end here, you've said the PID starts at 0x1C but that it's only 1 byte long; either it's actually 4 bytes, or it starts at 0x1E...

Just by the way, I often document fields as being fewer bytes than they actually are because the game never used all the bytes. For example, string ids are all 4 bytes but there aren't any ids longer than 2. I documented them as 2 bytes because when I was editing values by hand it was easier to find the values by eye if I skipped the extra 00s. Also, when I moved to writing programs, I used the smaller sizes to speed up the programs.

My sizes are usually based on convenience rather than accuracy, so if you do have any doubts about the size you're probably right .

Have you actually found the in-battle PKM of a Pokemon and verified...

In a similar manner, I have barely tested any of my research. It's all based on presumptions. With all the information I have from people hacking other games and my brief spell hacking pokemon colosseum, a lot of it was pretty obvious. I have played what I've got so far of my hack though and everything seems to be working as intended so I know it's mostly accurate.

There are a couple of things I wasn't able to deduce though:

1. I fought the first trainer in the game when I started with 2 starters but it was still a single battle. I haven't looked into it yet but there is something that determines whether a battle is a single battle or not, as opposed to being a result of having 1 pokemon each.

2. I know how to give shadow pokemon to trainers that wouldn't usually have them. However, what happens if you catch/defeat them? Do they automatically go to miror b.? Also what determines which trainers keep their shadow pokemon? (e.g. greevil)

3. If one was to increase the total number of shadow pokemon by adding one to DeckData_DarkPokemon.bin, would miror b.'s final battle adjust to be after you've caught all shadow pokemon in the file or is he hard coded to battle you after you catch exactly 82/83 (I forget the number)

[Tiddlywinks]

That's interesting actually. I noticed all the shadow pokemon either had 0x40 or 0x80 in the byte just before what I called the "pid" but couldn't figure out what it meant. I think it makes sense that it randomises the values. That's like how the values in colosseum worked where the high bit randomised the value.

That is interesting, but it's actually only about 1/4 of Shadow Pokemon that have 0x40 or 0x80 at 0x1D. And over half actually have 0x00, so either there's not a randomization flag there, or they don't all get randomized... There also seem to be a couple of non-Shadow Pokemon with nonzero values at 0x1D (entry 0x28E, an Exploud, and 0x12B, a Castform).

There are a couple of things I wasn't able to deduce though:

1. I fought the first trainer in the game when I started with 2 starters but it was still a single battle. I haven't looked into it yet but there is something that determines whether a battle is a single battle or not, as opposed to being a result of having 1 pokemon each.

Unfortunately, I haven't discovered anything like the "battle" table I found in Colosseum. But, FWIW, I rather suspect that the table at 0xF40C in common_rel is versus types.

8 bytes per entry, 37 entries.

0x00: participants on each side (so total participants equals double)

0x01: maximum number of Pokemon per participant

0x02: Pokemon controlled by each participant

(That's actually from the Colosseum table I've already determined is versus types. This table looks essentially similar, except that where the last 4 bytes were a string ID in Colo, they don't seem to be in ; but in short, I've never confirmed this table.)

Edit: And on second thought, if you didn't change Naps' team, it could also be that it won't start a double battle if one Trainer only has one Pokemon.

2. I know how to give shadow pokemon to trainers that wouldn't usually have them. However, what happens if you catch/defeat them? Do they automatically go to miror b.? Also what determines which trainers keep their shadow pokemon? (e.g. greevil)

AFAIK, Miror B. gathers Shadow Pokemon for Trainers you can't rebattle. That could be all it effectively is. There doesn't seem to be any standout common denominator in the deck data for the Shadow Pokemon Miror B. can pick up.

[StarsMmd]

That is interesting, but it's actually only about 1/4 of Shadow Pokemon that have 0x40 or 0x80 at 0x1D. And over half actually have 0x00, so either there's not a randomization flag there, or they don't all get randomized... There also seem to be a couple of non-Shadow Pokemon with nonzero values at 0x1D (entry 0x28E, an Exploud, and 0x12B, a Castform).

Ahh and I thought I finally had it figured out. I guess it's still a little bit of a mystery.

It's possible that shadow pokemon are randomised by default but the option is still available for all pokemon. If you look at the way DeckData_DarkPokemon works, you see that the pokemon in DeckData_Story are completely independent from their shadow data. The additional shadow data just holds a reference to the pokemon. This means that the process of changing any shadow pokemon is trivial as it only requires changing the reference. The pokemon being referenced doesn't need any modification and will be automatically randomised.

Maybe the programmers originally randomised the data manually like they did in colosseum and then later decided to do it automatically and we're just seeing leftovers that weren't removed since they don't make a difference anymore. It is also possible that the castform and exploud were meant to be shadow pokemon (or at least the pokemon that were in those slots at the time) at a very early stage in development and they forgot to take off the randomisation value.

Of course, this is just speculation though.

[Tiddlywinks]

DeckData_Bingo: This contains the data for the pokemon 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.

This is weird. Um...are you sure about this one? Either your DeckData_Bingo has a lot different data than mine, or, I don't know...is this just a (big) presumption, like you mentioned before?

In the data I see, there's only one (valid) team and only six Pokemon. That right there is already a red flag when each of the Battle Bingo cards have more than six Pokemon on them. And two of the deck's Pokemon aren't even a species that appears in Battle Bingo apparently.

Honestly, by what I see, I really have no idea what data the Battle Bingo Pokemon come from, or what DeckData_Bingo might be for (if it wasn't just abandoned at some point). I did try searching a bit to see if I could find that team somewhere (either on Bulbapedia or related strictly to Battle Bingo), but honestly the data's a bit weird already, what with lv15 Slaking and Tyranitar.

[StarsMmd]

This is weird. Um...are you sure about this one? Either your DeckData_Bingo has a lot different data than mine, or, I don't know...is this just a (big) presumption, like you mentioned before?

In the data I see, there's only one (valid) team and only six Pokemon. That right there is already a red flag when each of the Battle Bingo cards have more than six Pokemon on them. And two of the deck's Pokemon aren't even a species that appears in Battle Bingo apparently.

Honestly, by what I see, I really have no idea what data the Battle Bingo Pokemon come from, or what DeckData_Bingo might be for (if it wasn't just abandoned at some point). I did try searching a bit to see if I could find that team somewhere (either on Bulbapedia or related strictly to Battle Bingo), but honestly the data's a bit weird already, what with lv15 Slaking and Tyranitar.

Oh yeah... I made a presumption based on the file name but the data in that file is completely useless and was probably just for the developers to test stuff. At the time I thought there might have been some gimmick to the file like how DeckData_DarkPokemon is unique. However, that data is not used in the game at all. I think DeckData_Sample is also an old file just for testing.

All the battle bingo data is in common_rel. I think I made a post about it. If not, I'll write one up today. ? I should probably update some of my posts now that I've actually tried more stuff out.

Edit: yeah I posted it in this thread -Info-dump'>http://projectpokemon.org/forums/showthread.php?46590-Pokemon--Info-dump although I really did just 'dump' the info. Most of it doesn't look very pretty but the battle bingo data is explained in the 'data tables' spoiler.