Jump to content

StarsMmd

Innovator
  • Content Count

    696
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by StarsMmd

  1. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** The stats for the Pokémon 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 Pokémon 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 Pokémon 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 Stat Size (bytes) Colosseum Offset XD Offset Level-up Rate 1 0x00 0x00 Catch Rate 1 0x01 0x01 Gender Ratio 1 0x02 0x02 Base Exp Reward 1 0x07 0x05 Base Happiness 1 0x09 0x07 First Evolution 6 0x9C 0xA6 Base HP 1 0x85 0x8F Base Attack 1 0x87 0x91 Base Defense 1 0x89 0x93 Base Sp. Attack 1 0x8B 0x95 Base Sp. Defense 1 0x8D 0x97 Base Speed 1 0x8F 0x99 Type 1 1 0x30 0x30 Type 2 1 0x31 0x31 Ability 1 1 0x32 0x32 Ability 2 1 0x33 0x33 First TM 1 0x34 0x34 First Level-up Move 4 0xBA 0xC4 Name String ID 2 0x1A 0x1A ID of Model Used 2 0x2E ?? ID of Cry Used 2 0x0E ?? ID of Mugshot Used 2 0x10E ?? Egg Group 1 1 0x6E ?? Egg Group 2 1 0x6F ?? Egg Cycles 1 0x17 ?? Height (feet) 1 0x0A ?? Height (inches) 1 0x0B ?? Weight in Pounds x10 2 0x0C ?? (e.g. a value of 0x64 gives a weight of 10.0 pounds) Wild Held Item 1 1 0x70 ?? Wild Held Item 2 2 0x72 ?? ID of Species Name 2 0x1E ?? (e.g. Suicune is the aurora Pokémon) EVs rewarded for defeat are at around 0x91 for Colosseum. My advice for editing the stats without increasing the compressed file size is to remove all the level up moves for the Pokémon that aren't obtainable in the game as that data is never accessed. Each trainer has custom move sets for each Pokémon. 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 Pokémon. 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: View full tutorial
  2. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** The stats for the Pokémon 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 Pokémon 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 Pokémon 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 Stat Size (bytes) Colosseum Offset XD Offset Level-up Rate 1 0x00 0x00 Catch Rate 1 0x01 0x01 Gender Ratio 1 0x02 0x02 Base Exp Reward 1 0x07 0x05 Base Happiness 1 0x09 0x07 First Evolution 6 0x9C 0xA6 Base HP 1 0x85 0x8F Base Attack 1 0x87 0x91 Base Defense 1 0x89 0x93 Base Sp. Attack 1 0x8B 0x95 Base Sp. Defense 1 0x8D 0x97 Base Speed 1 0x8F 0x99 Type 1 1 0x30 0x30 Type 2 1 0x31 0x31 Ability 1 1 0x32 0x32 Ability 2 1 0x33 0x33 First TM 1 0x34 0x34 First Level-up Move 4 0xBA 0xC4 Name String ID 2 0x1A 0x1A ID of Model Used 2 0x2E ?? ID of Cry Used 2 0x0E ?? ID of Mugshot Used 2 0x10E ?? Egg Group 1 1 0x6E ?? Egg Group 2 1 0x6F ?? Egg Cycles 1 0x17 ?? Height (feet) 1 0x0A ?? Height (inches) 1 0x0B ?? Weight in Pounds x10 2 0x0C ?? (e.g. a value of 0x64 gives a weight of 10.0 pounds) Wild Held Item 1 1 0x70 ?? Wild Held Item 2 2 0x72 ?? ID of Species Name 2 0x1E ?? (e.g. Suicune is the aurora Pokémon) EVs rewarded for defeat are at around 0x91 for Colosseum. My advice for editing the stats without increasing the compressed file size is to remove all the level up moves for the Pokémon that aren't obtainable in the game as that data is never accessed. Each trainer has custom move sets for each Pokémon. 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 Pokémon. 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:
  3. ** You may need to understand Part 1 of this tutorial before you can extract the files used in any other parts** This is really easy to do. The moves contained in the TMs (and HMs which aren't actually obtainable in game and their items don't have any data) are just listed one by one in the start.dol file. If you change the move number the move contained in the TM will change. You don't even need to worry about compression. They are each 6 bytes of 0x00 followed by the 2 byte value representing the move. The TM data is located at 0x365018 in Colosseum and 0x4023A0 in XD. (or just search for 0x00 00 00 00 00 00 01 08 00 00 00 00 00 00 01 51 which represent focus punch and dragon claw, the first 2 TMs.) The HMs come right after the TMs. You will also notice that the HMs have an 0x01 for the first byte rather than the 0x00. I haven't tested exactly what effect this has but HMs can't be deleted without the use of the move deleter. It is possible that changing this value to 0x00 like the TMs then that may allow you to delete the move. There is also an HM flag in the move data so I'd set that to 0x00 as well. HMs have no other effect in colo/xd so there is no advantage to counting them as HMs. You may also want to change the text for the TM. If you look at the text for the items the TMs have the text that describes the original move they contain. Part 5: View full tutorial
  4. ** You may need to understand Part 1 of this tutorial before you can extract the files used in any other parts** This is really easy to do. The moves contained in the TMs (and HMs which aren't actually obtainable in game and their items don't have any data) are just listed one by one in the start.dol file. If you change the move number the move contained in the TM will change. You don't even need to worry about compression. They are each 6 bytes of 0x00 followed by the 2 byte value representing the move. The TM data is located at 0x365018 in Colosseum and 0x4023A0 in XD. (or just search for 0x00 00 00 00 00 00 01 08 00 00 00 00 00 00 01 51 which represent focus punch and dragon claw, the first 2 TMs.) The HMs come right after the TMs. You will also notice that the HMs have an 0x01 for the first byte rather than the 0x00. I haven't tested exactly what effect this has but HMs can't be deleted without the use of the move deleter. It is possible that changing this value to 0x00 like the TMs then that may allow you to delete the move. There is also an HM flag in the move data so I'd set that to 0x00 as well. HMs have no other effect in colo/xd so there is no advantage to counting them as HMs. You may also want to change the text for the TM. If you look at the text for the items the TMs have the text that describes the original move they contain. Part 5:
  5. ** You may want to understand Part 1 of this tutorial before you can extract the files used in any other parts** **I haven't found this data in XD yet so it is currently only information on Colosseum. Pokémon that are given to you have their data loaded by the .dol file. For Duking's Plusle, mt.battle ho-oh, agate Pikachu and agate Celebi you can change the Pokémon and its level and its moves will be taken from the last 4 of its natural level up moves at that level. With Espeon and Umbreon you can also edit their moves as you please. For the ones which you can't change their moves, I recommend just changing their level up moves before that level to the moves you want it to have since those Pokémon can only be caught once and without a move tutor level up moves from levels below the level any Pokémon is caught at are useless (as well as level up moves for Pokémon that are unobtainable) don't count for anything else. The following are the starting offsets for the gift Pokémon in Colosseum: Pokémon Offset Value Espeon 0x12DAC8 388000C4 Umbreon 0x12DBF0 388000C5 Duking's Plusle 0x12D9C8 38800161 Mt. Battle Ho-Oh 0x12D8E4 388000FA Agate Celebi 0x12D6B4 388000FB Agate Pikachu 0x12D7C4 38800019 Counting the first byte (0x38) as offset 0 from the start of the Pokémon's data, the Pokémon's species is at offset 0x2 and is 2 bytes long. The Pokémon's level is at offset 0x7 and is 1 byte long. For the Pokémon with editable moves (Espeon and Umbreon) the moves are at offsets, 0x16, 0x26, 0x36 and 0x46 and each is 2 bytes long. I will add the information for XD once I find it. Part 4: View full tutorial
  6. ** You may want to understand Part 1 of this tutorial before you can extract the files used in any other parts** **I haven't found this data in XD yet so it is currently only information on Colosseum. Pokémon that are given to you have their data loaded by the .dol file. For Duking's Plusle, mt.battle ho-oh, agate Pikachu and agate Celebi you can change the Pokémon and its level and its moves will be taken from the last 4 of its natural level up moves at that level. With Espeon and Umbreon you can also edit their moves as you please. For the ones which you can't change their moves, I recommend just changing their level up moves before that level to the moves you want it to have since those Pokémon can only be caught once and without a move tutor level up moves from levels below the level any Pokémon is caught at are useless (as well as level up moves for Pokémon that are unobtainable) don't count for anything else. The following are the starting offsets for the gift Pokémon in Colosseum: Pokémon Offset Value Espeon 0x12DAC8 388000C4 Umbreon 0x12DBF0 388000C5 Duking's Plusle 0x12D9C8 38800161 Mt. Battle Ho-Oh 0x12D8E4 388000FA Agate Celebi 0x12D6B4 388000FB Agate Pikachu 0x12D7C4 38800019 Counting the first byte (0x38) as offset 0 from the start of the Pokémon's data, the Pokémon's species is at offset 0x2 and is 2 bytes long. The Pokémon's level is at offset 0x7 and is 1 byte long. For the Pokémon with editable moves (Espeon and Umbreon) the moves are at offsets, 0x16, 0x26, 0x36 and 0x46 and each is 2 bytes long. I will add the information for XD once I find it. Part 4:
  7. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** Text editing is the easiest thing to do in just about any game that is being hacked. Text editing in colo/xd is also very easy to do but can be very tedious as the text in the game is scattered between many different files. This means that you have to first figure out which file has the text you want, then you may have to unarchive the file if it's in a .fsys file (most of the text is in .fsys files) and if it is in one then you must be careful not to increase the compressed file size for when you recompress it. However, if it isn't in a .fsys file then you can safely write over it without trouble. All the text in-game is in Unicode which takes up 2 bytes per character. so for example the character 'A' is 0x0041. To change this to 'B' you just need to change the second byte from 0x42 to 0x41 and you can ignore the 0x00 between each letter. The easiest place to start is in Start.dol in the "&&SystemData" folder of the ISO file system. This file doesn't get compressed so you can edit the text as much as you like without it increasing the file size, assuming you replace bytes rather than insert new bytes. The dol is really large and most of it isn't text so the text may be hard to find. Try using your hex editor to search for common words. common_rel.fdat in common.fsys also contains a lot of interesting text like the names of all the pokemon and moves. The text is always in a file I call a "string table". It stores each piece of text with an id number. That id number can be used elsewhere in the game to reference that piece of text. I will refer to this later when editing moves and pokemon. You can recognise the start of the string table file because it has the acronym for the language the table is in. My games are the US version so the string tables all start with "US" (0x5553). You can search for this in a file to see if it contains an embedded string table, although it's usually obvious by the presence of unicode text. The table begins with pairs of values. The first 4 bytes is the id I mentioned previously and the second 4bytes is a pointer to the offset from the start of the string table (6bytes before US) to the string referenced by that id. They exist in so many files that I can't list them all but here are some of the important ones. Start.dol has a string table at 0x2CC810 (Colosseum), 0x374FC0 (XD) . common_rel has some string tables, the first one being at 0x59890 (Colosseum), 0x0x4E274 (XD) and the next following consecutively. A few files in fight_common are string tables. The third file in any .fsys containing a map is a string table. This will containing all the NPC dialogue for that map. When changing the text, make sure you only write over one string at a time. You can usually spot the end of a string because it is terminated by 0x00 or 0xFF. Writing passed this will overwrite the next string and mess up the pointers. So either repoint or try to fit you text in the same amount of space. In order to keep the compressed file size small, try to find some other strings which are less important and shorten them. For example, changing the description for the inner focus ability from "prevents flinching" to something like "stops flinches" will decrease the randomness. Also in XD it seems that all the text translations for other languages were included in the US version which is the one I happen to have been hacking. You can probably safely erase all of the text in those files by replacing each character with 0x00 since you'll probably only ever play in one language. I haven't done this myself but I doubt it would cause issues. Part 3: View full tutorial
  8. ** You will need to understand Part 1 of this tutorial before you can decompress the files used in any other parts** Text editing is the easiest thing to do in just about any game that is being hacked. Text editing in colo/xd is also very easy to do but can be very tedious as the text in the game is scattered between many different files. This means that you have to first figure out which file has the text you want, then you may have to unarchive the file if it's in a .fsys file (most of the text is in .fsys files) and if it is in one then you must be careful not to increase the compressed file size for when you recompress it. However, if it isn't in a .fsys file then you can safely write over it without trouble. All the text in-game is in Unicode which takes up 2 bytes per character. so for example the character 'A' is 0x0041. To change this to 'B' you just need to change the second byte from 0x42 to 0x41 and you can ignore the 0x00 between each letter. The easiest place to start is in Start.dol in the "&&SystemData" folder of the ISO file system. This file doesn't get compressed so you can edit the text as much as you like without it increasing the file size, assuming you replace bytes rather than insert new bytes. The dol is really large and most of it isn't text so the text may be hard to find. Try using your hex editor to search for common words. common_rel.fdat in common.fsys also contains a lot of interesting text like the names of all the pokemon and moves. The text is always in a file I call a "string table". It stores each piece of text with an id number. That id number can be used elsewhere in the game to reference that piece of text. I will refer to this later when editing moves and pokemon. You can recognise the start of the string table file because it has the acronym for the language the table is in. My games are the US version so the string tables all start with "US" (0x5553). You can search for this in a file to see if it contains an embedded string table, although it's usually obvious by the presence of unicode text. The table begins with pairs of values. The first 4 bytes is the id I mentioned previously and the second 4bytes is a pointer to the offset from the start of the string table (6bytes before US) to the string referenced by that id. They exist in so many files that I can't list them all but here are some of the important ones. Start.dol has a string table at 0x2CC810 (Colosseum), 0x374FC0 (XD) . common_rel has some string tables, the first one being at 0x59890 (Colosseum), 0x0x4E274 (XD) and the next following consecutively. A few files in fight_common are string tables. The third file in any .fsys containing a map is a string table. This will containing all the NPC dialogue for that map. When changing the text, make sure you only write over one string at a time. You can usually spot the end of a string because it is terminated by 0x00 or 0xFF. Writing passed this will overwrite the next string and mess up the pointers. So either repoint or try to fit you text in the same amount of space. In order to keep the compressed file size small, try to find some other strings which are less important and shorten them. For example, changing the description for the inner focus ability from "prevents flinching" to something like "stops flinches" will decrease the randomness. Also in XD it seems that all the text translations for other languages were included in the US version which is the one I happen to have been hacking. You can probably safely erase all of the text in those files by replacing each character with 0x00 since you'll probably only ever play in one language. I haven't done this myself but I doubt it would cause issues. Part 3:
  9. 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: https://github.com/PekanMmd/Pokemon-Colosseum-Hacking-Resources Some files you'll need: fsys extract and decompress script.txt pokemon lzss recompress script.txt - I. Things you'll need - Download Gamecube rebuilder (or similar program). Download QuickBMS. Any hexadecimal converter (or you can do it all in your head if you prefer). Any free online converter is enough. You may also want a binary converter for XD. [Edit by @evandixon: When set to Programmer mode, the built-in calculator in Windows will work.] A hex editor. (No tools as of the time of writing except my iOS apps which won't be released for the reasons explained in part III) Check out my git hub repository and download the quickBMS scripts. If you want to edit the banner for the ISO download a program called GCBanner. I won't be explaining it here but there are tutorials somewhere online. An emulator will be very useful for testing. Dolphin is really good these days. It plays Colosseum perfectly with the right settings but does have a few glitches with XD. It is convenient having the emulator on the computer you're hacking on because once you build the ISO you can test right then and there. However, computers can rarely produce good emulation speeds. I recently started using Nintendon't on my Wii U and it is brilliant. If you have a Wii or Wii U I recommend finding a tutorial online on installing Nintendon't as the consoles have built in GameCube emulation made by Nintendo themselves and so runs the games perfectly at full speed. - II. Useful knowledge - Learn basic hexadecimal to decimal conversion. As long as you understand what it is a hex converter will do the rest. I will not be covering this myself as there are many tutorials already. A very tiny bit of binary also comes up in XD. If you understand hex you probably get binary too and there are many converters online. Experience hacking other gen III games is very valuable. Hacking other gen games will also be of slight use but gen III does have it's quirks. My git hub repo also has some useful files for looking things up like the ids of each Pokemon so download those files also. ( I haven't put it up yet but will do soon) Less importantly, since the game was originally coded by the Japanese, a lot of the file names are transliterations of the Japanese names. For example, all the Pokemon and NPC models are named by their Japanese names. I happen to speak Japanese and I've found it really useful because it allows me to more easily figure out what is inside a file. Sometimes the name makes it very obvious. Like in field_common.fsys there is a file called "bikkuri". I know this means surprise in Japanese so I was able to make the assumption that this file contains data for when an NPC trainer spots you and the little surprise animation pops up above their head. There are no Japanese characters anywhere so just understanding a bit of the language phonetically helps. Some phrases that might come in handy: Japanese English snatch ball snag ball snatch dan team snagem dark pokemon shadow pokemon gonza gonzap mirabo / mirrorbo miror B. esaba pokespot (literally feeding place) waza move/attack usohachi bonsly gonbe munchlax lugia lugia ( convenient ) runpappa ludicolo relive purify labo lab nakigoe cry (as in a pokemon's 'roar') 10manvolt thunderbolt (literally 100,000 volts) - III. N.B. - The GameCube files are in "big endian". Those used to hacking on other platforms will be used to reversing bytes but there is no need for that at any time on the GameCube. The downside is that this makes opening files on "little endian" computers (as far as I know that's about every computer in common use) a bit trickier. Programs may need to byte-swap when reading and writing values longer than 1 byte in length. The amount of time spent compressing and recompressing files (not to mention the difficulty of emulating GameCube games) means testing can be a long and tedious process so not everything has been tested fully. Also I'll be teaching you 'safe' techniques. I haven't reached the level of repointing to expand the size of data regions. Hopefully when more automated tools are available more possibilities will open up. The preparation section isn't very exciting but is necessary so pay attention. You may find yourself repeating these steps many times before programs are available. In order to minimize repeating tedious steps, try to edit the files as much as possible all in one go before recompressing. Don't forget to be conscious of increasing the file size as I'll mention in the preparation section. All of my tools are iPad apps which I can't release because I doubt it'll be allowed. Even if Apple were to somehow accept them for the App store, Pokemon Company/Genius Sonority would probably complain. The programming was all done in a rush and the UI is pretty poor but I will be releasing the source code for everything so hopefully someone else will make some better tools. Do check out my YouTube videos. They're a bit long but I do go into more depth about many of the concepts and techniques introduced in these tutorials. I especially recommend the fsys and compression video because that is a bit tricky to describe. Since there are few automated processes and it is very easy to make mistakes, make sure you keep backups of your files. Changing just one byte incorrectly can ruin your files. The two most interesting files are the Start.dol and common_rel.fdat (in common.fsys). These two files contain a lot of the important data. They are loaded into the game's ram when the game is loaded which means that anything that can be done in those files can, in theory, also be achieved through Action Replay codes or if you prefer you could do a ram dump, edit the ram directly and then load the edited ram. This includes editing pokemon stats, move data, TMs list, a little bit of text, starter pokemon and gift pokemon and trainer teams(colo only). XD has the physical/special split! It's only used for shadow moves though. I would really like to find a way to incorporate it into all the moves. I'm really hoping someone can crack this. I'm hacking the US versions of the two games. There may be differences if you're using a different region. ================================== Part 1: Extraction,Decompression and Recompression ================================== - I. File extraction - This is how we get individual game files out of the ISO. Run Gamecube Rebuilder. Select: Image >> open. navigate to your gamecube ISO/GCM and open it. In the file browser to the right, right click on 'root' and then click 'extract'. Choose a location to save the folder in on your computer. This will save all the game files in a folder called 'root' wherever you choose to save it. This can take a while but is useful if you want easy access to all the files. Alternatively, if you only want an individual file then you can right click on the specific file you want and extract it in the same way. Edit any of the files, making sure to either keep them in the same folder or put them back later with the same file name. - II. File reimporting and ISO rebuilding - This is how we put the files back into the ISO after we've edited them. Try to make sure the file size is the same as the size of the original file you are replacing. If it is too large then you may mess up our ISO. - importing an individual file- open the ISO image as in part i. find the file you have edited, right click it, click 'import' and load the edited file. - rebuilding whole ISO- If GameCube Rebuilder is still open with an image loaded, select: image >> close. Run GameCube Rebuilder. Select: root >> open, navigate to the 'root' folder you made in part I. Select: root >> save, choose where you want to save your new ISO/GCM and name it. Select root >> rebuild. A new ISO/GCM will be saved as you specified in step 3. - III. fsys extraction and decompression - Most of the game files are compressed and archived in .fsys files (kind of like a .zip or .rar file). This is how we get them out and decompress them in order to be able to edit them. Some files haven't been archived and don't require decompression but most of the useful and interesting ones do. Run quickBMS. Select the "fsys extract and decompression script" (see attatched files or source code on github) and click 'open'. Select your .fsys file and click 'open'. You can select multiple files at the same time and the program will extract from them one at a time. Choose a folder to save the files in and then click 'save' (warning this will most likely extract multiple files so you may want to create a folder for them). You can stay in the same folder if you wish. This script automatically decompresses and adds a '.fdat' file extension to each file extracted. Open the .fdat files in a hex editor or if opening them in a program then you can read the bytes as binary data. If the fsys archive contains multiple files with the same name (which is quite common actually), then simply type 'r' into the command line and then press the return/enter key on your keyboard quickBMS will automatically rename the files with sequential numbers. - IV. File recompression - Of course, once the files have finished being edited they must be recompressed so we can put them back in. Open the file you want to recompress in your hex editor and record the exact number of bytes in the file. Any decent hex editor should show this value somewhere; if not automatically then highlight all the bytes (ctrl + a on windows) and then it should show you how many bytes are highlighted. Make sure you convert this number to decimal if it is in hexadecimal. Open the "pokemon lzss recompress script" (see attatched files or source code on github) in any text editor. A simple one like notepad is best. At the end of the file you will see 2 identical numbers. Replace them with the file size you recorded in step 1 (again remember to convert it to decimal). You should now have two new identical numbers which represent the file size. Save the modified script. (If you are editing the same file a lot without changing the file size it may be convenient to save a separate script for the specific file with a different name so you can reuse that script and skip the first 2 steps.) Run quickBMS and follow the steps in section III above, however, this time run it with the script from step 2 and then the file you are trying to compress. This script will save the file without a .LZSS extension. - V. fsys reimporting - Once the files have been recompressed they now need to be put back precisely where they were found in the archive so that they game can load our new edited data. Make sure your compressed file size is smaller than the original compressed file size. In each section where I edit .fdat files I will share tips on how to effectively do this. In general, if you can make long rows of 00 bytes, for example by deleting text or removing items, EVs, or a whole Pokémon from a trainer, your compressed size will decrease. If you edit data and you aren't creating long rows of 00bytes then you are most likely going to increase the compressed file size. Such is life. If you want to learn more then research how the LZSS compression algorithm works and about 'entropy' in terms of data compression, which is similar to the concept of entropy in physics. In very basic terms, we are trying to decrease the randomness of the data so it compresses better. Open the .LZSS file you want to reimport in your hex editor. Note the exact number of bytes in the file. If you had changed the uncompressed file size then also note that beforere compressing the .fdat file. Open the .fsys file you originally extracted the .LZSS file from (as a .fdat file) in your hex editor. Note the exact number of bytes in the file (in hexadecimal this time). I recommend checking out my youtube video on fsys and decompression as this step gets complicated. Bear with me, this step is hard to explain by typing. However, it is usually very easy to do. The .fsys file is an archive comprising multiple files (or sometimes one file) within it. the files in the .fsys are all separated by some rows of 00 bytes and each one starts with the magic bytes "LZSS" which you can see in the ASCII version of the data in your hex editor. Your task in this step is to figure out which file in the archive is the one you have edited and are trying to replace. Not far from the start of the .fsys file you have the file names of the files in the archive. Use this to figure out the position of your file in the archive. If the file was sequentially named by quickBMS because of name conflicts then the lower numbered ones were the first ones in the archive. You can also figure out which file you want by looking at the header for each file which starts with the "LZSS" and then has the compressed and uncompressed file sizes. Match these with the sizes you expect for your file. Also the data should start with the same bytes as your file since you probably didn't change much at the very beginning of the file so it decompresses the same way. The files I edit a lot "common_rel.fdat" which is the first file in common.fsys, and the text data files for the maps which is the third file in any of the .fsys files for a map. This is true for both games and makes this step easy to figure out. If you somehow got through all the text and managed to make sense of it then it will soon become obvious how to figure all this out. There is a very easily recognised pattern to the .fsys files. If you scroll down just past the file names then you will find data separated by rows of 0x11 bytes (i.e. 11 11 11 11 11 11 11 11 11 11 11 11) in colosseum or just 0x00 (0x0000000000000000000) in XD. The blocks of data which precede each of these rows describes and individual file in the archive and this data is in the same order as the file names and the same order that the files in the archive are saved in. This block of data contains the offset within the .fsys file that the .LZSS file starts as well as both the compressed and uncompressed file sizes. If we have changed any of these values (usually the compressed file size) then we must update this information here or the game will crash even before we reach the title screen. Before you change the decompressed file size value you must add 16 bytes (0x10) to your value because there is also a 16 byte header which isn't part of the LZSS file we created but is in the .fsys file. Scroll to the start of the file in question. The "LZSS" bytes at the start will let you know you're at the start of the file. The 16 bytes starting with "LZSS" are the file header. Again this has the compressed and decompressed file sizes for that file so if you have changed these then update these values once again (remembering to add 16 bytes to your decompressed file size). Always remember you need to update the decompressed file size in two places. Copy all the bytes from your .LZSS file (ctrl + a to highlight all then ctrl + c to copy). Starting from the byte after the header in the .fsys file, highlight as many bytes as the number of bytes you copied from the .LZSS file. Assuming your .LZSS is smaller there will still be some bytes left over from the previous file. Replace these extra bytes with 00 until the end of the previous file. If your file is too large then you willoverlap with the next file, hence the emphasis on keeping your file as small as possible. We can move the next file if necessary as long as we update the pointers in its block of data before the 111111 row corresponding to the next file. I've never actually tested this myself but it seems obvious enough. There are a few bytes between each of the files for tidiness but we can overwrite these if we want to since this won't increase the size of the .fsys file. Again, I haven't tested this but if you wanted to increase the total size of the .fsys file and repointed everything properly then you would probably need to update the ISOs .toc file with the new file size of the .fsys. I haven't done this before though so good luck if you attempt it. The details of the .toc file have probably been documented somewhere before as it is pretty much the same in every gamecube ISO. That's it ! You've successfully extracted, decompressed, recompressed and reimported a game file from a .fsys file. This process is a lot easier to do than describe and not knowing how to do this was the only reason Pokémon Colosseum and XD hadn't been hacked before. Now we can research and edit the game files with ease. Part 2 - View full tutorial
  10. 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: https://github.com/PekanMmd/Pokemon-Colosseum-Hacking-Resources Some files you'll need: fsys extract and decompress script.txt pokemon lzss recompress script.txt - I. Things you'll need - Download Gamecube rebuilder (or similar program). Download QuickBMS. Any hexadecimal converter (or you can do it all in your head if you prefer). Any free online converter is enough. You may also want a binary converter for XD. [Edit by @evandixon: When set to Programmer mode, the built-in calculator in Windows will work.] A hex editor. (No tools as of the time of writing except my iOS apps which won't be released for the reasons explained in part III) Check out my git hub repository and download the quickBMS scripts. If you want to edit the banner for the ISO download a program called GCBanner. I won't be explaining it here but there are tutorials somewhere online. An emulator will be very useful for testing. Dolphin is really good these days. It plays Colosseum perfectly with the right settings but does have a few glitches with XD. It is convenient having the emulator on the computer you're hacking on because once you build the ISO you can test right then and there. However, computers can rarely produce good emulation speeds. I recently started using Nintendon't on my Wii U and it is brilliant. If you have a Wii or Wii U I recommend finding a tutorial online on installing Nintendon't as the consoles have built in GameCube emulation made by Nintendo themselves and so runs the games perfectly at full speed. - II. Useful knowledge - Learn basic hexadecimal to decimal conversion. As long as you understand what it is a hex converter will do the rest. I will not be covering this myself as there are many tutorials already. A very tiny bit of binary also comes up in XD. If you understand hex you probably get binary too and there are many converters online. Experience hacking other gen III games is very valuable. Hacking other gen games will also be of slight use but gen III does have it's quirks. My git hub repo also has some useful files for looking things up like the ids of each Pokemon so download those files also. ( I haven't put it up yet but will do soon) Less importantly, since the game was originally coded by the Japanese, a lot of the file names are transliterations of the Japanese names. For example, all the Pokemon and NPC models are named by their Japanese names. I happen to speak Japanese and I've found it really useful because it allows me to more easily figure out what is inside a file. Sometimes the name makes it very obvious. Like in field_common.fsys there is a file called "bikkuri". I know this means surprise in Japanese so I was able to make the assumption that this file contains data for when an NPC trainer spots you and the little surprise animation pops up above their head. There are no Japanese characters anywhere so just understanding a bit of the language phonetically helps. Some phrases that might come in handy: Japanese English snatch ball snag ball snatch dan team snagem dark pokemon shadow pokemon gonza gonzap mirabo / mirrorbo miror B. esaba pokespot (literally feeding place) waza move/attack usohachi bonsly gonbe munchlax lugia lugia ( convenient ) runpappa ludicolo relive purify labo lab nakigoe cry (as in a pokemon's 'roar') 10manvolt thunderbolt (literally 100,000 volts) - III. N.B. - The GameCube files are in "big endian". Those used to hacking on other platforms will be used to reversing bytes but there is no need for that at any time on the GameCube. The downside is that this makes opening files on "little endian" computers (as far as I know that's about every computer in common use) a bit trickier. Programs may need to byte-swap when reading and writing values longer than 1 byte in length. The amount of time spent compressing and recompressing files (not to mention the difficulty of emulating GameCube games) means testing can be a long and tedious process so not everything has been tested fully. Also I'll be teaching you 'safe' techniques. I haven't reached the level of repointing to expand the size of data regions. Hopefully when more automated tools are available more possibilities will open up. The preparation section isn't very exciting but is necessary so pay attention. You may find yourself repeating these steps many times before programs are available. In order to minimize repeating tedious steps, try to edit the files as much as possible all in one go before recompressing. Don't forget to be conscious of increasing the file size as I'll mention in the preparation section. All of my tools are iPad apps which I can't release because I doubt it'll be allowed. Even if Apple were to somehow accept them for the App store, Pokemon Company/Genius Sonority would probably complain. The programming was all done in a rush and the UI is pretty poor but I will be releasing the source code for everything so hopefully someone else will make some better tools. Do check out my YouTube videos. They're a bit long but I do go into more depth about many of the concepts and techniques introduced in these tutorials. I especially recommend the fsys and compression video because that is a bit tricky to describe. Since there are few automated processes and it is very easy to make mistakes, make sure you keep backups of your files. Changing just one byte incorrectly can ruin your files. The two most interesting files are the Start.dol and common_rel.fdat (in common.fsys). These two files contain a lot of the important data. They are loaded into the game's ram when the game is loaded which means that anything that can be done in those files can, in theory, also be achieved through Action Replay codes or if you prefer you could do a ram dump, edit the ram directly and then load the edited ram. This includes editing pokemon stats, move data, TMs list, a little bit of text, starter pokemon and gift pokemon and trainer teams(colo only). XD has the physical/special split! It's only used for shadow moves though. I would really like to find a way to incorporate it into all the moves. I'm really hoping someone can crack this. I'm hacking the US versions of the two games. There may be differences if you're using a different region. ================================== Part 1: Extraction,Decompression and Recompression ================================== - I. File extraction - This is how we get individual game files out of the ISO. Run Gamecube Rebuilder. Select: Image >> open. navigate to your gamecube ISO/GCM and open it. In the file browser to the right, right click on 'root' and then click 'extract'. Choose a location to save the folder in on your computer. This will save all the game files in a folder called 'root' wherever you choose to save it. This can take a while but is useful if you want easy access to all the files. Alternatively, if you only want an individual file then you can right click on the specific file you want and extract it in the same way. Edit any of the files, making sure to either keep them in the same folder or put them back later with the same file name. - II. File reimporting and ISO rebuilding - This is how we put the files back into the ISO after we've edited them. Try to make sure the file size is the same as the size of the original file you are replacing. If it is too large then you may mess up our ISO. - importing an individual file- open the ISO image as in part i. find the file you have edited, right click it, click 'import' and load the edited file. - rebuilding whole ISO- If GameCube Rebuilder is still open with an image loaded, select: image >> close. Run GameCube Rebuilder. Select: root >> open, navigate to the 'root' folder you made in part I. Select: root >> save, choose where you want to save your new ISO/GCM and name it. Select root >> rebuild. A new ISO/GCM will be saved as you specified in step 3. - III. fsys extraction and decompression - Most of the game files are compressed and archived in .fsys files (kind of like a .zip or .rar file). This is how we get them out and decompress them in order to be able to edit them. Some files haven't been archived and don't require decompression but most of the useful and interesting ones do. Run quickBMS. Select the "fsys extract and decompression script" (see attatched files or source code on github) and click 'open'. Select your .fsys file and click 'open'. You can select multiple files at the same time and the program will extract from them one at a time. Choose a folder to save the files in and then click 'save' (warning this will most likely extract multiple files so you may want to create a folder for them). You can stay in the same folder if you wish. This script automatically decompresses and adds a '.fdat' file extension to each file extracted. Open the .fdat files in a hex editor or if opening them in a program then you can read the bytes as binary data. If the fsys archive contains multiple files with the same name (which is quite common actually), then simply type 'r' into the command line and then press the return/enter key on your keyboard quickBMS will automatically rename the files with sequential numbers. - IV. File recompression - Of course, once the files have finished being edited they must be recompressed so we can put them back in. Open the file you want to recompress in your hex editor and record the exact number of bytes in the file. Any decent hex editor should show this value somewhere; if not automatically then highlight all the bytes (ctrl + a on windows) and then it should show you how many bytes are highlighted. Make sure you convert this number to decimal if it is in hexadecimal. Open the "pokemon lzss recompress script" (see attatched files or source code on github) in any text editor. A simple one like notepad is best. At the end of the file you will see 2 identical numbers. Replace them with the file size you recorded in step 1 (again remember to convert it to decimal). You should now have two new identical numbers which represent the file size. Save the modified script. (If you are editing the same file a lot without changing the file size it may be convenient to save a separate script for the specific file with a different name so you can reuse that script and skip the first 2 steps.) Run quickBMS and follow the steps in section III above, however, this time run it with the script from step 2 and then the file you are trying to compress. This script will save the file without a .LZSS extension. - V. fsys reimporting - Once the files have been recompressed they now need to be put back precisely where they were found in the archive so that they game can load our new edited data. Make sure your compressed file size is smaller than the original compressed file size. In each section where I edit .fdat files I will share tips on how to effectively do this. In general, if you can make long rows of 00 bytes, for example by deleting text or removing items, EVs, or a whole Pokémon from a trainer, your compressed size will decrease. If you edit data and you aren't creating long rows of 00bytes then you are most likely going to increase the compressed file size. Such is life. If you want to learn more then research how the LZSS compression algorithm works and about 'entropy' in terms of data compression, which is similar to the concept of entropy in physics. In very basic terms, we are trying to decrease the randomness of the data so it compresses better. Open the .LZSS file you want to reimport in your hex editor. Note the exact number of bytes in the file. If you had changed the uncompressed file size then also note that beforere compressing the .fdat file. Open the .fsys file you originally extracted the .LZSS file from (as a .fdat file) in your hex editor. Note the exact number of bytes in the file (in hexadecimal this time). I recommend checking out my youtube video on fsys and decompression as this step gets complicated. Bear with me, this step is hard to explain by typing. However, it is usually very easy to do. The .fsys file is an archive comprising multiple files (or sometimes one file) within it. the files in the .fsys are all separated by some rows of 00 bytes and each one starts with the magic bytes "LZSS" which you can see in the ASCII version of the data in your hex editor. Your task in this step is to figure out which file in the archive is the one you have edited and are trying to replace. Not far from the start of the .fsys file you have the file names of the files in the archive. Use this to figure out the position of your file in the archive. If the file was sequentially named by quickBMS because of name conflicts then the lower numbered ones were the first ones in the archive. You can also figure out which file you want by looking at the header for each file which starts with the "LZSS" and then has the compressed and uncompressed file sizes. Match these with the sizes you expect for your file. Also the data should start with the same bytes as your file since you probably didn't change much at the very beginning of the file so it decompresses the same way. The files I edit a lot "common_rel.fdat" which is the first file in common.fsys, and the text data files for the maps which is the third file in any of the .fsys files for a map. This is true for both games and makes this step easy to figure out. If you somehow got through all the text and managed to make sense of it then it will soon become obvious how to figure all this out. There is a very easily recognised pattern to the .fsys files. If you scroll down just past the file names then you will find data separated by rows of 0x11 bytes (i.e. 11 11 11 11 11 11 11 11 11 11 11 11) in colosseum or just 0x00 (0x0000000000000000000) in XD. The blocks of data which precede each of these rows describes and individual file in the archive and this data is in the same order as the file names and the same order that the files in the archive are saved in. This block of data contains the offset within the .fsys file that the .LZSS file starts as well as both the compressed and uncompressed file sizes. If we have changed any of these values (usually the compressed file size) then we must update this information here or the game will crash even before we reach the title screen. Before you change the decompressed file size value you must add 16 bytes (0x10) to your value because there is also a 16 byte header which isn't part of the LZSS file we created but is in the .fsys file. Scroll to the start of the file in question. The "LZSS" bytes at the start will let you know you're at the start of the file. The 16 bytes starting with "LZSS" are the file header. Again this has the compressed and decompressed file sizes for that file so if you have changed these then update these values once again (remembering to add 16 bytes to your decompressed file size). Always remember you need to update the decompressed file size in two places. Copy all the bytes from your .LZSS file (ctrl + a to highlight all then ctrl + c to copy). Starting from the byte after the header in the .fsys file, highlight as many bytes as the number of bytes you copied from the .LZSS file. Assuming your .LZSS is smaller there will still be some bytes left over from the previous file. Replace these extra bytes with 00 until the end of the previous file. If your file is too large then you willoverlap with the next file, hence the emphasis on keeping your file as small as possible. We can move the next file if necessary as long as we update the pointers in its block of data before the 111111 row corresponding to the next file. I've never actually tested this myself but it seems obvious enough. There are a few bytes between each of the files for tidiness but we can overwrite these if we want to since this won't increase the size of the .fsys file. Again, I haven't tested this but if you wanted to increase the total size of the .fsys file and repointed everything properly then you would probably need to update the ISOs .toc file with the new file size of the .fsys. I haven't done this before though so good luck if you attempt it. The details of the .toc file have probably been documented somewhere before as it is pretty much the same in every gamecube ISO. That's it ! You've successfully extracted, decompressed, recompressed and reimported a game file from a .fsys file. This process is a lot easier to do than describe and not knowing how to do this was the only reason Pokémon Colosseum and XD hadn't been hacked before. Now we can research and edit the game files with ease. Part 2 -
  11. Sorry for the delay. i've finally finished writing up eveyrthing i know about hacking colosseum and . I didn't realise quite how much stuff there was to say. I even ended up discovering like 30% more about them while documenting it. I'll be posting a few threads on the forum now so if you read through them and use the information to start researching stuff then that would be great. Also a lot of the stuff is theoretically correct but. Hasn't been tested yet so if research isn't your thing then testing would also be extremely useful. [EDIT] The tutorials have been posted - -hacking-tutorial-part-1-File-decompression-recompression'>http://projectpokemon.org/forums/showthread.php?46250-Stars-Pokemon-colosseum-and--hacking-tutorial-part-1-File-decompression-recompression
  12. Thanks for the interest. I am definitely working on tutorials. I just have so much to explain so bear with me. Should have something up shortly. [EDIT] tutorial has been posted
  13. Yeah after combing through forums for a few months I stumbled across a method for decompressing them and it was pretty easy from there. I'm currently in the process of recording some tuts will post links when they're up. As far as documentation goes I've never added to wikis before but will see what I can do. Your help would be greatly appreciated. Thanks. Also in response to Dio's question. I've edited all the trainer teams (including shadow pokemon), all the TMs, added some moves from gens 4-6 (like scald and dracometeor), edited some pokemon stats, level up moves and abilities (like giving the blaziken line access to speed boost and huge power on azumarill), edited the starting moves of espeon and umbreon. In general I made the game more challenging. Colo was one of the hardest pokemon games as far as they go but was still easy enough if you knew what you were doing. My version has trainers with more competitive teams and I threw in all my favourite pokemon as shadow pokemon so it's a lot of fun. Oh, and I also changed every occurrence of the word 'Snag' to 'Swag' just for the banter =D.
  14. 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:
  15. 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: View full tutorial
  16. I'm actually currently finishing up a mod of pokemon colosseum. I've been researching it for about a year now and I've figured out quite a lot about it. I will be posting tutorials on everything in the coming weeks and I believe a randomiser can be made using my findings. I've also figured out a lot about as well since most of it is the same. All my tools are ipad apps though because I'm actually an ios developer and so they aren't very easy to distribute but I'm sure some of the other programmers out there can use the information to make easily accessible tools. In terms of the textures, the textures in game should be easy to change if you have a program to swap their 'endianess' but I wasn't able to find one before I lost interest. However to change the textures based on whether a pokemon is shadow or not is not feasible right now. I'm hoping my info will inspire more research into colosseum and so hopefully someone will figure it out soon.
×
×
  • Create New...