Tiddlywinks

Sure, I can send that map. =) I'll include what I have for Colosseum too.

[ATTACH]12954[/ATTACH]

Some of the function names are actually names I've pulled from what looks like error message data or something in some places in the games. (I wrote a bit of a program to search for those patterns and rename the right function. For that matter, I also used the same program to remove those annoying places where Dolphin mistakenly inserts the start of a new function in the middle of another.)

Names that I've made, though, I like to put "q_" (like a substitute for a "?") at the beginning if I'm somehow not confident it's correct, or if I'm even less confident, I'll even just leave the default name and append something at the end so I at least know I've seen it if I run into it again (e.g., like "zz_028b5c8_q_AI_element_set" or "zz_010ae8c_q_Copy_helper").

Edit:

Oh, these might also be useful... Various structure definitions or partitions, some function "maps" (like input->called function, for some that seem to use something like "select case")... And in particular, all the identifications of the r13 pointers I know.

[ATTACH]12955[/ATTACH]

[ATTACH]12956[/ATTACH]

In my slow exploration of the assembly code, I just discovered that string tables are actually supposed to be linked lists (linking one string table to another). It's kind of trivial, but I kind of want to write it down anyway so I have somewhere to look back to if I need to. I'm just gonna lay out the whole thing, in fact, to make it a bit easier...

(This is true in at least, I can't guarantee it is for Colosseum. Certainly, as I mentioned above, the language code isn't really used in the Japanese Colossuem.)

String table structure:

The links can run between different languages of string tables (in the US game, a JP table is linked in the middle of US tables). That seems to actually be a good part of the reason they're linked (though I haven't seen it used to that effect exactly, since I'm not using the PAL game right now where you can actually use different languages).

FWIW, string IDs may have a cap of 0xEA5F, too.

Well, either I glossed over this thread before or I never noticed it. =P

First Battle Bingo Card in common_rel = 0x1CAF

[...]

Size of Bingo Card entry = 0xB6

The Bingo Cards actually start at 0x1CB0 (so your offsets are skewed by +1), and their length is 0xB8 (the last two bytes are just padding).

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.

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.

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 don't know how other randomizers do things, but I'm wondering, did you at all take into account whether some Trainers (mainly the major ones, like Miror B. or Dakim) appear multiple times and may have originally kept some of their Pokemon between one battle and another? Thinking about it, that does sound a bit complicated, but it also seems to me like it would be a nice touch.

Perhaps more importantly, did you randomize absolutely everything, or did you try to make sure that, where a Trainer has a Shadow Pokemon that could have been captured, their alternate Shadow Pokemon/Shadow Pokemon-less teams would look the same? (I guess you could argue this is kind of trivial too, though, depending on how much...fidelity? you want from the "new" game.)

Since it looks like you're taking a look at now You might like the list of pointers into common_rel from my ram dump of . It starts at 0x4E87C8 I believe.

Yup, I've already used that data to split up most of common_rel. =P (There's mostly just a chunk at the end that I've kind of ignored.) I may not know what everything does, but I think I know where it all starts and ends and how they're basically structured. I even discovered EU and JP string tables I sort of missed when I previously gathered up all the string tables.

FWIW, since learning about the symbol map and grasping assembly reads/stores, I've just been jumping around in Colo and trying to identify functions and structures/fields. I've been updating previous posts where relevant. One of the biggest things I found may be how to know exactly where the main party PKMs are in RAM (inserted above); that could be useful for some previous applications.

It wasn't very clear that you found the pointers in the RAM just spent a good few minutes searching common_rel itself. Also don't the pointers start at 0x478DF8 in RAM?

Oh, sorry. The list itself kind of completely slipped my mind. When I saw this response, in fact, I even thought, "Of course it's in common_rel", but nope! :tongue:

You're right, it does seem to start at 0x478DF8. I don't know how I made that mistake... I had the right start for the EU version (which was actually my default resort for a while, because the standard Dolphin version would always freeze when trying to load the US version), but when I went to the US version, somehow I didn't reach far enough back. I didn't even realize the mistake I had made when I noticed that my lists for each version had different sizes. :frown: I actually tried to go through everything in common_rel anyway (like I said, I was mostly able to see the patterns of each table anyway, and therefore where they ended), but I should probably try to double-check that part I missed sometime.

Also I've been wondering how the game decides if the opponents pokemon's HP is visible. It's definitely visible on mt.battle on battle mode but not in story mode. It's probably one of the unknown bytes somewhere in the tables you found. Or maybe it's just incorporated in the battle type values or something. Did you notice this?

I'd cast my first bet on the battle type, but I really don't know. I had actually never noticed the opponent's HP being visible anywhere, so it never crossed my mind to look for it.

It really it is a feature that calculates it for you. I don't know how much you know about using debug mode so I'll start from the beginning. It also shows you the code in hex and in assembly and you can place breakpoints and all that.

When in debug mode, choose the 'Symbols' option in the top menu and then 'Generate Symbol Map'. This will get dolphin to name all the functions for you and they will come up in different colours making it easy to see where each one starts and ends.

If you look at the 'code' tab. You will see 4 boxes on the very left. The second one shows the names of the functions (Dolphin automatically names them based on their offset and you can change the name to whatever you like if you figure out what it does). The third box shows the functions the current function branches to and the 4th box shows which functions branch to the current function.

You can click on any of these and it'll take you straight to that function. Also if you're looking at the code itself you can right click on a branch instruction and there's an option to follow that branch and dolphin will take you to the instruction it branches to.

I had a lot of trouble finding a good ASM tutorial as well but then I stumbled across a really good one on the super smash bros melee forums. It uses melee and Sonic adventure 2 battle as examples but it is really easy to follow and should teach you everything you need to know. There aren't any prerequisites either, so I'm sure you'll get it. This one video is all I needed to get started. Here's the link:

I hope you give it a go. It's a few hours long but well worth the time. Good luck!

Well damn, I'll have to play with that feature... I haven't paid a whole lot of attention to Dolphin's menus, I've mostly only noticed the more or less obvious icons and interface stuff. Though it's also possible even if I did see that Symbols menu I may not have realized what it did.

I'll have to take a look at that video too. There's definitely a couple things I'd like to find. Thanks!

The game often checks for shadow moves in the ASM and probably determines whether it should display the icon or not in the code.

For I guessed how the game may check for a shadow move. I'd already tried copying the exact entry for a shadow move and putting it over a regular move and that didn't make it a shadow move so I knew it wasn't in the move data table. The next obvious answer was that the game simply compared the index with 0x164. So I searched Start.dol for the value 0x164 which led me to the instruction "0x2c000164" which is "cmpwi r0,356". I found the same instruction in the RAM on dolphin in debug mode and used break points to test it. A neat feature is that you can see which functions call the function you're looking at. Finding a similar function could be helpful to you. For example, the main part of my phsyical/special split implementation was finding the function that determined the category of a move. I knew it had to check if the move was a shadow move or not so I looked at each of the functions that called the function for checking. I found the function and simply ignored the check so that it always ran the code that checks the move data rather than the move's type.

Another helpful way to find ASM functions is to see which values in the RAM are being edited by Action Replay or Gecko codes. You can then begin to look into which functions branch to and from eachother. This helped me find the shiny calculation function. Seeing a bunch of XORs and a comparison to the value '8' were a dead give away.

Unfortunately it doesn't seem that displays the contest data. I thought of using it to display an image of the move's status rather than contest category.

I probably don't really care that much if it's some assembly. I've generally been having trouble reading the assmebly to any great extent, but I may see if I can find some simpler introductions than the very technical/jargony instruction set documentations I've been trying to reference.

When you say that a nice "feature" is you can see what functions are calling what you're looking at, you don't mean that Dolphin has some "feature" that will determine that automatically, do you? Did you just mean something like you can look for instructions that jump to the start of your function (though I think finding that may be a little complicated too)?

I did use one of the AR codes just like you describe already, but with my general trouble reading the assembly, I haven't been eager to try it a lot.

It occurs to me I may have misunderstood your meaning a bit. If you just meant to zero out the whole table, then that wouldn't have any problems; the game doesn't generally have any trouble if given an invalid string ID, and the appeal/jam fields are certainly fine with 0. What I initially figured--and which I now realize would bring its own problems--was that you meant to delete the table, as in, all the data that used to be after the table would now appear that much earlier. At any rate, my main worry was that if you replaced the table with some new data and weren't careful about it and ended up with the "wrong" value in the description string field, you could get some pretty weird "descriptions". But aside from that, appeal/jam seem not to have any issue with random values.

It also just occurred to me that the Contest category (Smart/etc) has to be defined too, and that turns out to be offset 0x15. Oddly, it seems there may also be something that overrides the category in a move entry, because I tried changing the category for Shadow Rush and that ???? but they persisted with no-icon or the "???" icon. (Changing 0x15 worked just as expected for Bite, though.)

The contests stats aren't actually that 'useless' from a hacking point of view. Since this data is irrelevant it can all be replaced in order to optimise the lzss compression. Decreasing the file size is always nice.

Not exactly all of it. Unless you go so far as hacking the move displays and/or the code that loads the contest stats, you'll at least need to keep one entry around so you can just set the index for all the entries to 0 and it has sensible data to read.

Even though it's not in the list of tables I -hacking-tutorial-part-7-Editing-Trainers-(Colosseum)&p=205678&viewfull=1#post205678'>found in Colosseum's common_rel, I noticed that the move table starts one entry earlier than you said it does above (at 0x11E010). Also...

Interestingly there is an entry after shadow half in which doesn't appear in the game and has a little bit of data missing. If you navigate to the string its name id points to then you find the text "????". The move is unselectable in battle probably because it doesn't have an animation set in it's data and one probably doesn't exist for it. The id for the string of its description points to the text "this move can't be used because the heart's door is shut"

Similarly in colosseum there is an entry after shadow rush with incomplete data which shares a few values with the move. It's name id also points to the text "????"

This is certainly in the games. Shadow Pokemon can only use Shadow moves at first, so this "????" is a placeholder that just hides the other moves until the Pokemon has been purified enough. (I'm not exactly sure at what point that move ID gets substituted over the Pokemon's actual move, but it doesn't seem to be in the PKM at all (it always gives the Pokemon's "real" moves).)

And this is fairly useless, but one thing I found in that list of tables in common_rel was the Contest stats. In the Colosseum moves table, byte 0x14 in an entry is an index into this table, defining that move's Contest stats.

Contest stats (Colosseum):

• In: common.fsys\common_rel.fdat
  
• Start: 0x14BCA8
  
• Entry size: 0x08 (dec 8)
  
• Entry count: 51
  

Offsets...

I found a list of pointers to tables in common_rel that includes all four of the ROM tables I described above. It starts at 0x478E58 in common_rel, and the addresses are all offset by 0x807628A0 (for the US ROM). There are some "empty" pointers, though, and I don't know if it might actually be multiple lists.

Going by those pointers, the Trainer data does start one entry earlier, at 0x92ED0 in common_rel instead of at 0x92F04. It also suggests that the address you gave for the "start" of the stats table in -hacking-tutorial-part-5-Editing-Pokemon-stats'>part 5 is one entry late, and they really start at 0x123250.

A bunch of the "tables" are pretty indecipherable beyond maybe telling how big the entries are. I was able to identify string IDs in some of them, though. Some of those were still hard to figure, though... But I did manage to figure out a few new tables pretty well, too.

First, let me just identify the ones that had string IDs but that were difficult to figure out otherwise, in case somebody might feel like taking a look at them...

With that out of the way, on to the good stuff...

Snag List messages:

• In: common.fsys\common_rel.fdat
  
• Start: 0x14675C
  
• Entry size: 0x08 (dec 8)
  
• Entry count: 505
  

The format of this is a bit like the Trainer Pokemon data. All of the entries are grouped into "sets" that are terminated by an empty entry (with all bytes 0, that is). This means the sets can (and do) have variable length. There are 97 such sets, one apparently for each defined Shadow ID (like in the Shadow IDs structure in RAM I described above).

Each entry seems to describe the message that is shown at a certain point in time in the Snag List. For most Pokemon, their "set" just has four entries that have the strings "No information", "No information", "Encountered in\n[location]! But SNAG failed!", and "SNAG succeeded in\n[location]!" (respectively), but a few sets have some extra entries/messages between those first and last two.

Offsets...

Battle data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x10B808
  
• Entry size: 0x38 (dec 56)
  
• Entry count: 566
  

This actually defines some of the things I was hoping to find before in the Trainer data, like the music and battle stage. This data is kind of an intermediary step between the Trainer data and (I presume) whatever structure defines what battles are in a map.

Offsets...

Versus types:

• In: common.fsys\common_rel.fdat
  
• Start: 0x92E98
  
• Entry size: 0x08 (dec 8)
  
• Entry count: 7
  

This is used in the battle data above. It probably sees some sort of use elsewhere too, but I don't know where/how exactly right now.

Offsets...

And the last thing I found is a limited maps description.

Map/met data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x8D540
  
• Entry size: 0x04C (dec 76)
  
• Entry count: 196
  

Offsets...

I also found a table of -hacking-tutorial-part-6-Editing-Move-data&p=205679&viewfull=1#post205679'>contest stats.

I tried to do some digging into the heart gauge and ended up exploring the whole PKM structure. I guess this isn't exactly ROM research, but I think it's better to keep things mostly in one place, and this thread is kind of about Colosseum Pokemon already. I started this with some hints from psycommando's memory notes and finished it off with the help of this thread (especially some of the origin stuff and the Contest stats).

At different times, there may be a few different copies of a Pokemon's PKM floating around in RAM, but I haven't really bothered trying to differentiate them. I've also seen them in different places for different loads or saves or whatever. In one case (for in-battle I think), the PKM is also a bit longer but, again, I haven't really looked closely at it at all. The PKMs should also appear in the save file, but, one way or another, I don't think they're in a conveniently readable format, so I haven't found them in there.

I think I've also figured out how to know exactly where the PKMs are during runtime (the main ones at least; I really don't have the first idea right now how any of the copies might be related to the main ones). In short, in the US Colosseum, the pointer to the start of player data (or I think that's what it is) is stored at 0x8047ADB8 in RAM (in EU Colosseum, the pointer is at 0x804C8268; I haven't looked at JP). The PKM for the player's first party Pokemon starts at +0xA0 from the start of the player data. (In between that and the start comes other stuff like the player name and full Trainer ID.)

The above is really all you need to know to find party PKMs, but if anyone wants to figure it out from scratch (like for the JP Colosseum maybe), here's what you'd need to do... First, you have to know what r13 is set to. This holds a special address that defines where a bunch of other pointers are, and it's set when the game loads and is never altered. You can find that address by combining the bytes at offsets 0x336, 0x337, 0x33A, and 0x33B in Start.dol, or at those offsets plus 0x3000 in RAM. Then you need to search for the 16-byte sequence "38630070 4E800020 28030000 4C820020" (in RAM or in Start.dol), which should only have one match. Combine the bytes at +0x22 and +0x23 bytes from the start of that match, then add that to the r13 address and subtract 0x10000 (the 0x22/23 bytes are actually a negative/signed value, but this works a bit more directly and just as accurately). The result of that calculation should be the location of the pointer to the start of the player data.

PKM structure

• In: RAM, or presumably save files
  
• Start: Varies...
  
• Size: 0x138 (dec 312)
  

Offsets...

Like I said, I was looking for heart gauge/purification stuff, and in the PKM description above, I said that the size of a bar of the heart gauge depends on the Pokemon's Shadow ID. I also found the table that controls that in RAM.

Shadow IDs structure

• In: RAM
  
• Start: Varies...
  
• Fingerprint (2nd entry): 00 00 01 00 01 4F 00 00 FF FF 00 1E 00 00 00 00 00 00 00 00 00 00 00 00
  
• Entry size: 0x18 (dec 24)
  
• Entry count: 97 (or 65,536?)
  

I also tried looking as well as I knew how through ROM files, but for the life of me I can't seem to find the exact same table. And if it's built from something else I have no idea/can't tell where that data might be located.

There may not also be a strict end to this table except the maximum Shadow ID. It seems like the Shadow ID in the PKM may just be an index (0-based) into this table, and so long as the game can read a nonzero "bar factor" at a given index, the heart gauge will work fine. I think all the "entries" beyond the initial explicitly defined 97 just have 0s in them, but all you have to do is enter a nonzero "bar factor" for a given entry (even, say, the very last one) and if you give a Pokemon that Shadow ID its heart gauge will display just fine.

Offsets...

I also tried looking for a way that met location indices were associated with their strings (edit: it's actually in the "map/met" table below), as well as how/where the National Ribbon got assigned its string, but I wasn't able to find either of those things...

Ah so we were right about the priority, we just needed to factor in the AI as well! Do you happen to know if there are any AI values that actually switch pokemon during the battle?

No clue. I'd only know by seeing it happen (I haven't) or by reading a bunch of assembly that I don't even have the first clue where to find.

It turns out the send-out order can just depend on the AI. Normally, Willie will always send out his male Zigzagoon (the first one) first, then his female Zigzagoon. But when I gave him Dakim's AI, he sent them out randomly. On the other hand, if I gave him Dakim's first team (at Mt Battle; original order is Entei ("priority" 3), Metang (2), Marshtomp (0), Golem (0), and Camerupt (0)) with his default AI, Willie would send out Entei and Metang. So then I let him run for a while with Dakim's AI too, and I saw him send out Metang+Golem, Metang+Marshtomp, and Metang+Camerupt (though this last only came after like a dozen tries, so maybe there's some probability involved). Entei would always end up last in the party, too.

Playing with various teams and values for the "priority" byte, it's apparent that Pokemon with priority 3 get shoved to the end of the party. Pokemon with priority 2 "fight" it out for the first spot, by which I actually mean one of them is randomly chosen to be sent out first. Any priority 2 Pokemon that "lose" basically get relegated to priority 3. The Pokemon within priority 3 (including "losers" from priority 2) are ordered randomly. Pokemon with priority 0 basically don't move, and I can't actually tell any difference between that and priority 1. The Pokemon within priorities 0 and 1 (together) are ordered randomly. Anything above 3 also seems to be, practically speaking, equal to 3. (I actually tried parties with 0xFE and 0x03 together for a while, but in a dozen tries, all I got was 0xFE then 0x03 in the last two slots; but with 0xFF and 0x03 I did get them in either order. So either I'm just getting "bad" luck with 0xFE or everything above 3 doesn't necessarily get randomized with it.)

I can't say if this only holds for Dakimn's AI (0x56) or if any AI that reads and uses those priority bytes will use them in the same way. Maybe one of them clearly distinguishes 1 from 0 somehow (since it is used naturally sometimes; I haven't tried to check the AIs used where that happens, though). At the very least I imagine many AIs that use the priority bytes act the same.

I also still don't know what the byte after the priority byte does, in particular whether it plays any part in the order the Pokemon is sent out.

In other news, it turns out the game definitely stops reading as soon as it sees the first empty entry after the "first Pokemon" index from the Trainer data. This can result in a kind of amusing battle with no Pokemon on the opponent's side that ends as soon as you make any move (or when your turn is over, depending on which actions you take)... The game also stops reading after 6 Pokemon (or else there's just no way to access any more than 6).

And in yet other news, I also figured out that 0xFF isn't strictly necessary to randomize a Pokemon's IVs and such. Strictly speaking, I doubt it even "makes" anything random. I edited it into my big post above.

Also I had a look on bulbapedia to see what else is affected by a pokemon's nature. The only other known effect is the effect on a pokemon's pokeblock flavour preferences. A lot of useless data like egg groups and egg cycles are carried over from the gba games so I wouldn't be surprised if most of the unknown values in the naturehttp://projectpokemon.org/forums/showthread.php?46258-Stars-Pokemon-colosseum-and--hacking-tutorial-part-7-Editing-Trainers-(Colosseum) data were for the pokeblock data.

Also near the beginning of common_rel you will notice the ascii text for the names of all the sounds in the game from fanfares to background music. If you were to list these you could assume they're in the same order as the indexes used to reference them. You could figure out the index of miror b.s music from this and see if you can find it in those structures. There's no way to know that the songs are listed in order but it's quite likely.

If anything, I would actually bet that stat boosts and Pokeblock flavor preferences would work from the same values, just applying it to different contexts (like either Attack or Spicy flavors). And besides, I don't think any of the other offsets had a distribution of values that could even match the Pokeblock preferences like the stat modification offsets do.

I'll have to keep those sound names in mind if I get around to looking for them. Thanks.

Also, I don't know if you noticed but most trainers send their pokemon out in the same order as they are specified in the data. However, on rare occasions they will send them out in a different order. Most shadow pokemon are last in their teams but a few are first in their teams and yet they are still sent out last. Sometimes a trainer will just send their pokemon out in random order which changes each time you battle them. I was wondering if you'd seen any values that could specify this. I thought it could be the value in the pokemon list that is always between 0-3 but this had no effect on their ordering.

Yeah, I saw these

videos of and was pretty much mind-boggled that he apparently sent out completely different Pokemon at the start. I was looking at those 0-3 values too, and I was half convinced they were "send out priority" levels (since Dakim's Pokemon in that battle all had 0 except for Houndoom at 3), but then I saw where Dakim sent out Metang (value=2) and Golem (value=0) first, and he seems to do so consistently in other videos. So no, I can't tell right now (and may not figure out) what might control that stuff...

As for where the game specifies which trainer is in which map, the second file in the .fsys for each map is the file with all the scripts for that map. In this file is very easy to piece together because it contains a lot of human readable text in it. However, the equivalent file in colosseum has no such text and so I don't know what any of it means but it probably serves a similar purpose. The 3rd file in the map .fsys files is a string table of the strings that appear in that map. In if you search for any if the string ids contaibed in the third file, in the second file they will appear. You could try searching for the trainer IDs in this file. The ID is most likely the same as the index in the trainer data

I did actually look at those script files a bit, but beyond finding string IDs and noticing some patterns around them, I wasn't able to decipher anything. I've been able to handle assembly like the pokered disassembly before, but if the data in those files is assembly (I do at least understand that it's a different beast from pokered for Colo/XD), I'm having trouble understanding it so far.

Finally, since you're clearly really into this research I recommend taking a look at gecko and ar codes for pokemon colosseum. There is so much that was figured out years ago from looking at the ram. Usually they just figured out the really obvious data but sometimes you may find something interesting. like One code for came with a list of all the values for the trainer models.

I have seen some of those codes and lists. I'm even using a very nice one that lets me control the opponents to facilitate my investigation of unknown offsets via RAM manipulations with the Dolphin debugger. :biggrin: I also had a bit of fun playing around with one that let me change a connection to any location in for a while.

I've parsed out a few things about Trainers and their Pokemon that were missing from above. I'm just gonna repeat some of what you've already written above, just so I can make complete thoughts. It's possible some things are off, like what I've assumed to be the first and last entries of a data set. Any static values might also actually have some meaning, but they're impossible to figure out just from looking at the raw data.

One thing I realized is that, if string IDs are really 4 bytes long like you describe in your tutorial part 2, then they're probably 4 bytes in all other structures too. I was able to use the Dolphin debugger to test this, changing an NPC's string ID from 0000NNNN to 1000NNNN and when I tried to speak to them they didn't say anything (the dialogue window flashed briefly, like it wanted to print but didn't have anything to print).

You also said, StarsMmd, that every 7 entries is the team for a different Trainer, but it turns out that's not strictly true, because one of Ein's teams starts at 2814 and then Eagun's starts at 2822 (everything after that then continues the pattern of 7 entries per "team"). I kind of wonder if, when the game loads a team, if it just reads the first 6 Pokemon entries from that index, or if it reads to the first "empty" entry, or what; I wonder what would happen if you tried to put one "empty" entry right in the middle of a "team", or if you didn't put any empty entry for like 20 entries. At any rate, it's apparent that the game doesn't strictly care what index you give it to start (though it may care what comes after that).

Also, the early Trainer/Trainer Pokemon indices may get used for externally sourced data, like e-Reader card Trainers and versus battles, given the strings associated with those Trainers.

Trainer class data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x90F70
  
• Entry size: 0x0C (dec 12)
  
• Entry count: 42
  

Offsets...

Trainer data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x92ED0
  
• Entry size: 0x34 (dec 52)
  
• Entry count: 819
  

This data could possibly start one "entry" farther back, at a "round" 0x92ED0. All of the bytes for that entry would be 0 except for offset 0x00, which would be 2. I don't know of any way to say for sure that it can't start there... Maybe if I found whatever structure defines which Trainer/team is in a map.

Offsets...

Trainer Pokemon data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x9FE28
  
• Entry size: 0x50 (dec 80)
  
• Entry count: 5510
  

Offsets...

And, just because the Pokemon data uses Natures and I'm not sure of a "good" place to post this...

Nature data:

• In: common.fsys\common_rel.fdat
  
• Start: 0x122E60
  
• Entry size: 0x28 (dec 40)
  
• Entry count: 25
  

Offsets...

I'd wager you're right about 0xFFFF08 changing the font color.

I certainly did write some Java. It's in pieces and the output of one doesn't always feed right into the next... I guess I can, though. Here. (Lemme also disclaim that it's probably not written to a professional standard:tongue:.)

If you run any of it, it might be helpful to know that I like to use Excel (Calc, actually) to sort and prune my intermediate output files where it's necessary. That's the nice thing about using tabs as delimiters, super easy to put into and take out of a spreadsheet.:wink: In one program, I'm also throwing much more than is remotely useful to stderr, I just haven't felt like cutting it out... (You could in fact pretty well remove anything I'm printing to stderr at this point.)

FYI, it usually takes me about 20-30 minutes to search through every file extracted from any given ROM. The other programs don't even take a minute to run, though, I think. Also FYI, one of my intermediate steps sees me writing a file for every table, and I did this because (at the moment, at least), I have a notion of only opening the file(s) I need and reading strings from there. Pretty much the only reason I went beyond that stage was to make it into a convenient text dump.

Patience? I saw somewhere around here you said you've been working on these games for about a year, I think. That's patience! But when someone tells me, "This is basically how strings work" (especially being something as simple as text), man, I can absolutely go to town figuring the little bits that are missing and making something of it. :biggrin:

I don't have a problem releasing the text dumps I made, I was just being paranoid about rules/etiquette here. I don't really expect any problems, though, so here are the files of all the strings I ripped. For some reason, I'm having real trouble uploading most of the Colosseum files individually (even though I previously uploaded almost the same files with no problem), so I just packed all the languages (US, FR/GE/IT/SP/UK, JP) together into an archive; I figure US/English will probably be of most interest anyway.

• Colo: US, All languages
  
• : _en_decoded.txt'>US, _US_EU_JP_decoded.zip'>All languages
  

Those files do have every table (that I found), so there will be some duplicate IDs/strings. But I think I've included enough information to be useful to you/anyone playing with these games. Like I said above, it's not really possible to look for the Japanese Colosseum tables directly, so it's possible I missed some oddballs there. I in fact did find one table I had missed when I did some manual checking.

I was looking at the Colosseum Trainer Pokemon data, and I noticed a couple of things.

First, I think the EVs take 2 bytes each. For one thing, they have the space. (HP EV would start at offset 0x22, Attack EV would start at 0x24, etc...) If you think about it, 255 (0xFF) is a valid EV value. If EVs can be randomized like you say, then it would make sense that you couldn't mix that trigger (0xFF) up with a valid value; so I think their random value is actually 0xFFFF. I haven't tested it for a few reasons, perhaps mostly because I wouldn't know how to check the Pokemon's EVs to know when they've actually been randomized.

The other thing is, you missed the Pokemon's moveset. All four of the Pokemon's moves are given at offsets 0x36, 0x3E, 0x46, and 0x4E, respectively, with each taking 2 bytes.

I started looking at this after I happened to see your post a while ago, and I ended up ripping the string tables from all of the different-language ROMs. I kind of took the statement that "They exist in so many files that I can't list them all" as a challenge.:tongue: But I don't really hang around here, so I'm not entirely sure if it would be okay for me to link the "text dumps" I made? I included the string ID for each string, thinking it'd be an easy thing for people to grab and use to match string IDs in move data and stuff if they want.

For those interested, a few things I learned...

The string tables in the Japanese Colosseum actually don't have a reliable language code like 0x5553 ("US", for the US ROM). A couple of tables have 0x0001 in that position, but most are just 0x0000, meaning it's really hard to search for those by identifying the header. (In , the string tables in the Japanese ROM use the code "JP". And if anyone is interested, the other languages use "FR", "GE", "IT", "SP", and "UK" (United Kingdom/EU English).) Most tables list the same IDs in the same order, though, independent of the ROM, so that's a fairly reliable way to find most of the string tables in the Japanese Colosseum. There are some that have some differences, though; in particular, not every string ID used in one ROM is always used in another (a good example is 0x44F2, present in EU ROMs only).

It might go without saying, but a given ID refers to the same thing between different ROMs (JP/US/EU). As an example, Bulbasaur's species name has ID 0x03E9 in US, UK, French, German, Italian, Japanese, and Spanish string tables. Some string tables have copies in multiple files, though, and in a few cases, the same string ID may have slightly different text in one location than it does in another. For instance, string 0x3BFF in the US Colosseum in most places says a save file "could not be created", but in one place it says "could not be made".

As you say, StarsMmd, most of the special 0xFFFF "characters" use 3 bytes total. Those that use a total of 4 bytes are where 0xFFFF is followed by 0x07, 09, 38, 52, 53, 5B, or 5C. One seems to use 7 bytes total: where 0xFFFF is followed by 0x08. And as near as I can tell, all these "characters" are indeed basically the same between Colosseum and . I've put the functions as I know them in a spoiler below (the first line is 0xFFFF00, the next is 0xFFFF01, and so on, and lines with "--" are unused). Some are easy enough, but at some point, I got frustrated with trying to pin down all of them, so I just started identifying most of them as "unknown" or something suitably generic:tongue:. 0xFFFF59 (bubble_or_speaker) and 0xFFFF6A (maybe_speaker_ID_toggle) are interesting. Often times 0xFFFF59 will print a speech bubble before a character's dialogue; if 0xFFFF6A is used, though (I've only seen them together, 0xFFFF6AFFFF59), it seems to reveal the character's identity so that any use of 0xFFFF59 thereafter prints the character's name instead (without needing to use 0xFFFF6A again).