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

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

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

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.

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

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!

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

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

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.

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.

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