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.