• Content count

  • Joined

  • Last visited

  • Days Won


StarsMmd last won the day on June 17

StarsMmd had the most liked content!

Community Reputation

43 Excellent


About StarsMmd

  • Rank
    Gamecube Hacker
  • Birthday 09/18/94
  1. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts**-hacking-tutorial-part-1-File-decompression-recompression'> images: First of all I would like to point out again that I spent most of my time testing colosseum and only recently began to decode XD as well. I haven't actually tested a lot of the stuff in this section but most of it seems obvious enough for me to assume I was right. A lot of stuff is similar to colosseum anyway so its easy to extrapolate. I did test a little bit thought so I'm confident it works. Now, in XD, the trainer data is split up across several files which you will find in the deck_archive.fsys file. This contains 2 identical versions of each .bin file within. One just has _EU added to the file name, maybe its loaded in the PAL version instead of the other one. I don't know. However, it looks like you can get away with editing just the regular one and worst case scenario, the files are identical so you could just edit one, duplicate it and replace the _EU version with the duplicate. A big issue with these files is that it is hard to decrease their compressed file sizes. Their data is so much more compact than the data in the colosseum files and just about every byte of data is actually important. It may be more effective to make a larger .fsys archive and edit the .toc of the iso. However, I speculate that if you are playing the US version of the game, the EU versions of the files are never loaded up. If that is the case then these files could be reduced to 1 byte (or maybe even removed completely), effectively doubling the space available in the .fsys file. The .bin files are as follows: In all the decks apart from DeckData_DarkPokemon, there are 4 sections; DTNR (Deck trainer), DPKMN (Deck pokemon), DTAI (maybe something like Deck trainer AI?) and DSTR (Deck string). The first 16 (0x10) bytes are the DECK file's header. The first 4 bytes of this header are the magic bytes "DECK". The next 4 bytes are the size of the file in bytes. The first row of each section is the header. The first 4 bytes are the magic bytes identifying the start of that section. The next 4 bytes is the size of that section in bytes (including the header itself which is 16 (0x10) bytes) and the 4 bytes after that are the number of entries there are in that section. DTNR contains the data for each trainer in that file. Each entry in DTNR is 56 (0x38) bytes. Each trainer has six slots for pokemon. An id number for each pokemon is specified and the pokemon at that index in DPKM (or DDPK as the next note will explain) will be used as that pokemon. The byte at 0x4 is what I call the "shadow mask" it is a bit mask of the trainers pokemon. If you convert the number to binary each of the last 6 bits represents one of the trainer's pokemon. If the bit corresponding to a pokemon is 1 then the pokemon will be treated as a shadow pokemon and loaded from DeckData_DarkPokemon's DDPK section instead of the DPKM section and so the id used to reference that pokemon is actually a reference to its entry number in DDPK. Every other pokemon is specified by an id which references a pokemon from DPKM. i.e. an id of 1 will be the pokemon which is the first entry in DPKM unless the bit for that pokemon is set in which case it will refer to the first entry in DDPK (which refers to a pokemon in DPKM, in this case it points to the teddiursa which is entry 28/0x1C in DPKM). A shadow mask value of 0x01 (0b0001 in binary) means the first pokemon is a shadow pokemon whereas 0x6 (0b0110 in binary) means the 2nd and 3rd are shadow pokemon. The first entry is empty so the first trainer in a DTNR section starts at 0x38 bytes after the end of the DTNR header. Since the DTNR section comes first in all the decks that have one, it is always 0x58 bytes from the start of the file. There is an id value for each of the trainer class names and each of the trainer class models. (The name hunter refers to both male and female hunters but the they have separate models). I haven't figured out which numbers correspond to which classes yet though but 0x11 is the cipher peon class name while 0x10 is the model for blusix. It won't be very hard to compile a list since you can tell which trainer each entry is by their team, it's just tedious. DTNR table The next section of the DECK is the DPKM section. This contains the data for individual pokemon. There aren't too many gimmicks here. You get the data for that pokemon like moves, gender and nature. This section specifies nothing about whether or not a pokemon is a shadow pokemon or not. The extra data for the shadow pokemon is in the DDPK section of DeckData_DarkPokemon and that data specifies which pokemon in the DPKM file of the story deck it adds to. Remember that the pokemon's level will be overriden by the level specified in DDPK if it is a shadow pokemon. 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 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 The DSTR section doesn't seem very useful so I won't go into much detail. Basically, each trainer has a string which goes with them. Each trainer in DTNR has 2 bytes which say which offset in DSTR their code name starts at. The only use this has is that it can give you a hint as to where the trainer appears in-game. The code names usually start with the id of the map that the trainer is in like s1 (outskirt stand), d1 (shadow lab) or m5 (pokemon hq lab). You may be able to reduce the compressed size of the DECK files by deleting all the DSTR code names since I don't think they are loaded by the game but I don't know if that will have any side-effects yet. The other deck type is DeckData_DarkPokemon. Each shadow pokemon has its regular pokemon data saved in DeckData_Story's DPKM section like any other normal pokemon. The shadow data in DeckData_DarkPokemon's DDPK section specifies the pokemon it complements. The trainer that has the shadow pokemon sets the shadow mask bit telling the game that the pokemon in that slot is referencing DDPK rather than DPKM and then that entry in DDPK has a reference back to one of the pokemon in DPKM which is the pokemon that will be the shadow pokemon. The header is 16 (0x10) bytes long. The first 4 bytes of this are the magic bytes "DECK" followed by 4 bytes which give the file size in bytes. The only section in this file is the DDPK (dark pokemon which is shadow pokemon in japanese ). The header is 16 (0x10) bytes long and each entry is 0x18 (24) bytes long. The first entry is empty after which there is an entry for each shadow pokemon and a whole bunch left over. You could technically add more shadow pokemon and I think XD may handle the caught shadow pokemon a bit better than colo does so it might actually be as simple as adding another entry to this file. However, it is already extremely hard to decrease the file size of the decks so that must be considered. The catch rate overriddes the catch rate of the pokemon in it's data in common_rel and it's level overrides the level specified in DPKM in DeckData_Story. Like with just about everything else in XD, i haven't tested this but I think each shadow pokemon gets a purification counter, kind of like the steps an egg needs to hatch in other games in the series. The higher this value, the harder the pokemon is to purify. The shadow pokemon can be given between 1 and 4 shadow moves. DDPK data table xd trainer editing 1.rar xd trainer editing 2.rar
  2. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** -hacking-tutorial-part-1-File-decompression-recompression'> images: trainer offsets: shadow pokemon original offsets: For each trainer there are 6 pokemon entries but not all of the slots have to be used. After 6 slots of pokemon, there is one unused entry then the first slot of the next trainer is right after that. This means that you can start at the first trainer and to get to the next trainer all you need to do is jump 7 slots. This also means that you can easily give any trainer up to 6 pokemon without having to repoint or expand the data. (Of course the more pokemon you add the larger the compressed file size will become). Each pokemon has a byte which you can set to make it a shadow pokemon. That byte is effectively the flag that gets set when you catch that pokemon and just by setting the flag the game will consider it to be a shadow pokemon and your partner will react to it (even if she hasn't actually joined you yet). I don't actually change this because setting this flag to an unused flag just means every time you fight that trainer they will have the shadow pokemon no matter how many times you catch it. If you use a flag that is used by the game then you will affect the trainers who's teams rely on that flag. So if I set the flag to the same flag that Evice's tyranitar uses, then when I reach Evice he won't use the team with shadow tyranitar, he'll just use the replacement one. Also each team that has a shadow pokemon has an exact copy of the shadow pokemon. So if you want to change one of its moves you will have to change that move on every team that it appears on which can sometimes be up to 4 teams. I made a program that takes the changes to one and applies it to all of the other iterations automatically. In the source code there is a .json file containing all the default occurrences of each shadow pokemon. The source code also contains a .json file with details for each trainer in the game. Since I don't know where the trainer data is saved I had to fill it in manually. I recorder the name, trainer class, in-game location and file offset for each of the trainers. The first trainer in colosseum (Folly at the phenac city entrance) is in the common_rel at offset 658820 (0xA0D84). Each Pokemon is 80 (0x50) bytes long and so each team is 480 bytes long and to go from the start of one team to the start of the next team you jump 560 bytes (because there is an empty pokemon inbetween). The actual first pokemon entry is at offset 0x9FE28 but the first few are a bit dodgy, maybe used when they were testing the game. Folly's pokemon start at the 0x31 (49th) pokemon entry. N.B. The trainers don't change their teams based on the shadow pokemon you've caught but based on the flag set when it was caught. So when you catch a trainer's shadow pokemon, the next time you fight them the game loads up a different team so you will find trainers who have two different teams, one for if you've caught their shadow pokemon and one for if you haven't even if the "caught" team is just the same team without the shadow pokemon. When I was still trying to figure the game out, the trainers were the first thing I researched and the first thing I discovered. This meant that at the time I was documenting it and writing my programs I didn't have everything fully figured out yet. I noticed that each pokemon has the value (0x0004) in it at a certain point and so I used this to search for pokemon before I realised they were all next to each other and the distances between them were just unused pokemon. All of the offsets in this section are relative to this 0x0004 value which is actually 12 bytes into the pokemon's data. If you want you can subtract 12 bytes from each of the start offsets I use in the trainer data json files and then add 12 bytes to each of the offsets in the Pokemon.swift object from the source code (the same offsets in the table below.) I just stuck with it because it would be tedious to update all my code (I'll do it eventually). The pokemon's ability can be either 0 or 1, each representing one of the two abilities set in the stats for that pokemon. You can't give it any ability. For values of other variables like genders, items and natures check out the enumerations in the source code on git hub. For the values of the pokemon's ability, nature, gender, EVs and IVs you can set the value to 0xFF (255) and the game will automatically replace those values with randomly generated values. All the shadow pokemon had 0xFF for those values by default. The "FF Offsets" detailed below are the bytes which are set to 0xFF for any pokemon that isn't in use. I'm not sure if it's required by the game but my program will fill them in automatically for me when I delete a pokemon from a trainer while setting all the other necessary values to 0. However if you do something as simple as putting an invalid species for the pokemon like pokemon number 0 or pokemon number 252 (which is one of the empty slots in gen III) then the game will play as usual but the team will be loaded without that pokemon. However, if you set proper stats for the pokemon in slot 252 including choosing one of the models and names already available in the game files then the pokemon will be playable. You could use this for something like making a duplicate of a pokemon except it has different abilities and that way you could in essence have a pokemon with up to 4 different abilities because you could use the two species interchangeably. You could also make something like meowstic/gallade/frosslass where you make a copy of a pokemon except one of them is all male and the other is all female. You could then give them different level up moves or different evolutions depending on which one it is. In the future, if we crack the model formats we could probably use those slots to add new pokemon without having to replace old ones. Just to clarify, the offsets for each variable are relative to the "four offset" at 0x12 from the actual start of the pokemon so the first variable is documented as being at an offset of -12 from the 0x0004 but is really at an offset of 0x00 from the pokemon start. I will also add the "true offset" which is relative to the actual start of the pokemon but if you are comparing with my source code on git hub then use the four offset. Trainer Pokemon data table Typically a trainer will send their pokemon out in the order they are specified in the data. However, sometimes, and for reasons I don't know yet, a pokemon will be sent out in a different order to that specified. Usually they are shadow pokemon. Most are simply added to the team last but some are added first and still get sent out last every time. Some are added first and come out first as expected. Sometimes a trainer will randomly mix up their pokemon order in different battles (like after a soft reset). More research is required. Editing the trainer teams is really fun and creating lots of interesting teams will likely be the main goal in many hacks. However, the more you change, the more likely you are to be increasing the compression size as you start to mkae lots of unique pokemon, while the original has a lot of repetition since it didn't feature that many, especially not from gen I. The battle mode trainers are made to be more competitive, but the story mode trainers never have any IVs or EVs on them (hence they're almost all so pathetically weak) although they sometimes have beneficial natures. They almost never have held items either. Almost no trainers have 6 pokemon and they don't all know 4 moves. This means that the process of making the teams more fun, varied or competitive will almost definitely result in a much larger compressed file size. By far the best way to decrease the compressed file size is to put 0x00s over all the pokemon in battle mode if you don't mind not having it in your hack. This will give you enough space to go wild. By doing this my common_rel is 7kb smaller than the original even though I've changed and added so many pokemon as well as editing a lot of moves and stats. You can choose to just remove moves, items, evs and/or ivs or even 1 or 2 pokemon from battle mode teams rather than removing all of their pokemon completely in order to have a more competitive story for a less competitive battle mode. You can also rely on remove data from other parts of the file like the moves, stats and text since there are all of them in the same file. Finally, you could delete some pokemon from some of the less important story mode characters. There are zigzagoons and hoothoots that were going to get OHKO'd anyway so might as well save the space. I'm sure we'll soon find out how to safely increase file sizes and then we won't have to make these trade-offs but I think it's worth it for now. While writing this documentation I have just finally found where the trainer data is stored in colosseum! It is in the common_rel file with the first trainer being at offset 0x92F04. The order of the trainer data seems to differ from the order of the trainer teams though. Each entry is 52 (0x34) bytes long. The id of the trainer's name string refers to text in the common_rel string table. There are 3 optional string ids at the end of each trainer's data. The first being what they say before the fight (usually only used in colosseums since the you don't see those battles are initiated automatically), the second is what they say if they win (usually only for colosseums and mount battle because anywhere else you just "black out")and they third is what they say if they lose. These strings are found in the string tables in fight_common.fsys's "fight" and "tool_fight" files. Each trainer also has an index for their in-battle model and their trainer class. I will compile a list of these indexes eventually. The index of the trainer's first pokemon also gets 2 bytes. The pokemon at index 1 starts at offset 0x9FE28 (a value of 0x31 means the 49th pokemon entry including the empty rows between trainer teams). Each trainer can also have up to 8 items like potions and x-attacks. Trainer data table Part 8: -hacking-tutorial-part-8-Editing-Trainers-()&p=204374#post204374'> colosseum trainer editing.rar colosseum trainer shadow trainer
  3. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts**-hacking-tutorial-part-1-File-decompression-recompression'> Editing moves works pretty much like in the gba games. You can attempt to make new moves by mixing and matching the different move effects available and manipulating accuracy, damage etc. I remember seeing a post on a forum somewhere where someone posted every genIV - VI move that was possible to remake using gen III effects so you can try searching for that if you want ideas. The move data is pretty much the same in colo and XD but differs slightly for a few bytes. A significant difference is that XD has the gen IV style physical/special split on shadow moves. Also of note is that all the shadow moves are simply recorded as normal type moves and the battle routine automatically calculates the move effectiveness as a shadow move (always neutral in colo; super effective on non-shadow pokemon, not very effective on shadow pokemon in XD) when it detects a move that is meant to be a shadow move. There doesn't appear to be any marker for the shadow moves in the move data. The game seems to decide based on the id of the move (i.e. move 0x164 in colo which is shadow rush and moves 0x164-175 in XD which are the shadow moves starting with shadow blitz and ending with shadow half). The full move list is availabe on github. There is also a list of each of the move effects (same as in RS/FRLG) in order and an enumeration for each of the possible values for the target. A lot of data that was represented by 1 bit in the gba games gets a whole byte in these games. Each move has a series of flags in its data like whether or not it is blocked by protected or affected by the king's rock. Set the value to 1 for true or 0 for false. I represent these boolean variables by putting a '?' at the end because a full description takes up a lot of room on the table. The first move (pound) is in common_rel.fdat at offset 0x11E048 in colo and offset 0xA2748 in XD. The size of each move is 0x38 (56) in colo and in XD. The offsets are how many bytes from the first byte of the move's entry the data for that variable is. N.B. Setting the physical/special flag on a normal move is not enough to make it adopt the physical/special split. It sucks, I know... Also HMs aren't available in the game and the only effect they have is that they can't be deleted without a move tutor. Removing the HM flag should allow the moves to be deleted. However, this hasn't been tested yet and there is also an HM flag in the TM and HM list in the start.dol which could have an effect. Damage seems to be part of a move effect. This means that no matter how much base power you give a move, if the move's effect is the same as leer's then it will decrease the target's defense and do no damage. You would need to use rock smash's effect which is damage as well as lowering defense and you could change the effect accuracy as you like. Move data table Interestingly there is an entry after shadow half in XD 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 XD move. It's name id also points to the text "????" Part 7: -hacking-tutorial-part-7-Editing-Trainers-(Colosseum)&p=204373#post204373'>
  4. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** -hacking-tutorial-part-1-File-decompression-recompression'> The stats for the pokemon follow a similar but slightly different format in each game. Most of the data is self-explanatory and it all works the same way as in ruby and sapphire. The data starts with bulbasaur as you might expect, there are empty entries between celebi and treeko just like in ruby and sapphire. The order is the same as the ruby and sapphire order with the gen III pokemon is a slightly different order to their national dex order. Chimecho is at the end in colosseum and in XD there is an empty entry after chimecho and then the entry after that is bonsly. Bonsly's data isn't complete; for example it's missing the level up rate data (since it only appears as a bingo card in-game). If you fill in the rest of bonsly's data then bonsly will function like any other pokemon in the game. Even more interestingly the entry after that has data for munchlax. The string id for the name of that entry points to the string "munchlax". However, even less data is filled in for this row. I've focused mainly on colosseum so I haven't done many tests on XD but munchlax doesn't have a pkx model (pkx_gonbe.fsys with gonbe being its japanese name) which I think are the models used in battle. Its possible that filling in its data would allow it to be used but I haven't tried yet. Take a look at my source code on github and look for the "PokemonStats.swift" object. The data The first stats (bulbasaur) are in common_rel.fdat at offset 0x12336C in colo and offset 0x29ECC in XD. The size of each pokemon's stats is 0x11C in colo and 0x124 in XD. The offsets are how many bytes from the first byte of the pokemon's entry the data for that stat is. Each pokemon has a series of level up moves which are each 4 bytes long. The first byte is the level and the 3rd and 4th bytes are the move with the second byte being apparently unused. Each pokemon has enough space for about 20 level moves. (of course adding more will increase the file size.) Also the TMs and HMs work differently from the GBA games. You find in colo/xd that a lot of data that was represented by a single bit in the GBA games now gets a whole byte. The TMs and HMs each pokemon can learn are assigned one byte each. If that byte is 1 the pokemon can learn the move, if it's 0 then it can't. The HMs come straight after the TMs. Some of the XD data isn't filled in yet because I hadn't recorded the data I wasn't interested in. N.B. In XD the shadow pokemon data in DeckData_DarkPokemon seems to have a byte for a separate catch rate. That would mean that the catch rates in the pokemon stats are probably overriden and only take effect for the pokespot pokemon. I haven't tested this but a lot of the values at that offset are the same as the catch rate of the original pokemon with only a few being slightly different but still matching typical catch rates. Pokemon stats data table My advice for editing the stats without increasing the compressed file size is to remove all the level up moves for the pokemon that aren't obtainable in the game as that data is never accessed. Each trainer has custom move sets for each pokemon. You can also remove all wild held items, egg groups and all egg cycles, as well as level up rates and evolution data for unobtainable pokemon. This is less important in colosseum because you can erase all the battle mode trainers and that gives you enough space for just about anything you like. If you require battle mode or you're hacking XD (where the trainer data is in different files) then this can be useful. Part 6: -hacking-tutorial-part-6-Editing-Move-data&p=204371#post204371'>
  5. I can finally start posting all the data I have so far on hacking Pokemon Colosseum and Pokemon XD. There is a lot of it so it will take a while. Here is the first part. This is very important as it is a prerequisite for almost anything you want to hack in these games. Before I get into the details of the hacking I have some hints and tips that you should read. ===================== Prerequisites ===================== Some useful files for looking up data: Abilities Common Values Item List Pokemon IDs Pokemon Moves Especially useful is the list of pokemon ids since they aren't always the same as their pokedex order. Those used to hacking gen III may already be aware of this since it is unique to the gen III games. The source code for my editing tools: Some files you'll need: fsys extract and decompress script.txt pokemon lzss recompress script.txt - I. Things you'll need - - II. Useful knowledge - - III. N.B. - ================================== Part 1: Extraction,Decompression and Recompression ================================== - I. File extraction - - II. File reimporting and ISO rebuilding - - III. fsys extraction and decompression - - IV. File recompression - - V. fsys reimporting - Part 2 - pokemonreferencedata.rar
  6. I'm going to be making some video tutorials on hacking Pokémon Colosseum and XD, and here is a video just to show a bit of the stuff I've done. P.S. Haven't made many videos before so it isn't great 😅 Part 1:
  7. Pokemon XG: NeXt Gen

    That's not supposed to happen. Which version is that on and do you have any AR codes on? Wild Chansey's at pokespots hold them. :-) Somewhere along the line I changed the exp rate for the beldum evolution line to make them easier to level up. That means the exact exp requirements for each level are different. There will be a lot of inconsistencies when using old saves on new versions. There is an event rayquaza that also learns v-create. ;-) I think I took it out but will look into putting it back in somewhere I've been spreading my time between testing the new version and working on the hack tools. I think 1.0.7 should be mostly okay and I've fixed the bad kinds of bugs which crash the game. It's not 100% tested but I'll attempt to upload it soon and hopefully not too many bugs crop up. On the bright side, I've put in the foundational work so I can do some cool stuff in the future. I'm looking into adding more post game content and quests so I've been making sure my tools are powerful enough to facilitate this.
  8. Unfortunately I don't know anything about hacking those games but maybe @psy_commando can help with that?
  9. Pokemon XG: NeXt Gen

    I will work on that :-D
  10. Pokemon XG: NeXt Gen

    Sorry, it will still be a little longer. I have a few more things I'd like to add to flesh out the game a bit more. I resumed university a couple of weeks ago as well so haven't had as much time as I'd like. Shadow Lugia was kept low. It's a bigger jump because there are going to be quite a few changes. It was originally just bug fixes but now there's also new content. Each time I look at the code, I find something new and I just think to myself "hmm, how can I use this to make the game better?" and then end up spending a week on a new feature. I can't help it. Yes, I'd definitely recommend playing on nintendon't. There aren't too many other options and there's no way to play it without homebrew software like nintendon't. You can try playing around with the graphics settings in Dolphin to see what works best. You can also try Dolphin 5 if you aren't already on it. This is a bug when emulating XD on Dolphin. All you need to do is change one of the settings. Go to: Options > Graphics Settings > Hacks and slide the "Texture Cache" slider to "Safe". If it says the files don't match then it means you may have a slightly different version of the ISO to the one I used. They have to match exactly. Make sure it's the US version and hasn't been trimmed or anything like that.
  11. I'm glad you managed to get it working :-) Yes it does remove the likes of syther/onix evolutions and just makes them regular level 40 evolutions. I actually have no clue what would happen with slowpoke at level 40. I didn't consider it. Maybe max happiness would be a better alternative for trade evolutions. Alright, I'll work on that ;-) I don't think they can be converted. I will be making some pre-randomised patches though so feel free to use one of them.
  12. Pokemon XG: NeXt Gen

    I'll probably tinker around a bit more and take some footage and screenshots and publish them properly. Just wrapping up some stuff for XG and the XD hack tools. Off the top of my head: An old, unused screenshot of gateon port which shows the main character in a different outfit and slight differences to the area itself. A bunch of old screenshots of various maps showing subtle differences from their final versions. An unused room which is almost identical to one of the rooms in the S.S. Libra except the textures are very different and it has a wooden pattern all over. The battle intro to the deep colosseum still exists but I wasn't able to load it meaningfully. A reference to the under in the world map "The Under. An abandoned underground town." but there is no real data for it. There are still a lot of test files and files copied over from colosseum so I'm sure I'll find more stuff.
  13. Do you know which version of OSX you're running?