Part 8: Editing Trainers (XD)

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

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

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.

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)

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.

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.

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.

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.