StarsMmd

From looking at the values for the AI of the trainer I'm assuming that a higher value doesn't necessarily correspond to a more intelligent AI. It would make sense for the Mt.Battle masters on battle mode to have the highest AI value in the game but this is not the case. My best guess is that the game was programmed with predefined strategies. Like you said some of the more important characters would get unique values which are tailored to their team while the generic characters are just assigned the default strategies. For example, I believe that Justy's pokemon are all very likely to use double team and Evice's Slowking will use skill swap on his Slaking. I've found that sometimes, I'll give a trainer some really creative sets like baton pass sets but they just end up spamming their attacking move.

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

Hahaha it's pretty funny that we both had the same idea! I'm sure it'll become obvious eventually. The scripts definitely aren't assembly if you compare them to start.dol but yeah it's hard to figure them out. You can tell what they're doing you just can't tell how right now. The easiest way to test would be change values and see the results ingame but that process would be so tedious. Maybe one day... And yeah the code for controlling your opponent is one of my favourites. Very useful indeed. Also I had a look on bulbapedia to see what else is affected by a pokemon's nature. The only other known effect is the effect on a pokemon's pokeblock flavour preferences. A lot of useless data like egg groups and egg cycles are carried over from the gba games so I wouldn't be surprised if most of the unknown values in the nature data were for the pokeblock data. Also near the beginning of common_rel you will notice the ascii text for the names of all the sounds in the game from fanfares to background music. If you were to list these you could assume they're in the same order as the indexes used to reference them. You could figure out the index of miror b.s music from this and see if you can find it in those structures. There's no way to know that the songs are listed in order but it's quite likely.

This is really interesting stuff. I didn't even think about structures like the natures and trainer classes. I think I actually stumbled across the trainer class one in but didn't realise it's significance. I assumed the prize money was a value stored with each individual trainer like in the gba games iirc. You said you think the trainer data probably starts an entry earlier and I think you're probably right. From what I've been seeing recently a lot of tables start with an empty row for index 0. e.g. the move data and pokemon stats tables both start with empty rows since there is no pokemon or move 0. However the type data (and I'm assuming natures too) don't have that empty row since 0 is a valid type value for the normal type. Where you said the data may start an index later at 1, I can't remember what you're referring to since it has been a while since I looked at colo but it probably does start at 0 even though it's unused because 0 is a possible value that could be assigned for that variable. On my very first editing attempt, I was changing the hex for some trainers manually using my hex editor and I accidentally set the value for a trainer's pokemon to a value between celebi and treeko. It took me a while to notice because rather than crashing the game or anything, the game just ignored that pokemon. As you will know, arrays in programming start at index 0 so it is a valid index and the game just ignores empty entries. oh and in case you were wondering, the indexes between celebi and treeko will work if you fill those entries with values first. Also, I don't know if you noticed but most trainers send their pokemon out in the same order as they are specified in the data. However, on rare occasions they will send them out in a different order. Most shadow pokemon are last in their teams but a few are first in their teams and yet they are still sent out last. Sometimes a trainer will just send their pokemon out in random order which changes each time you battle them. I was wondering if you'd seen any values that could specify this. I thought it could be the value in the pokemon list that is always between 0-3 but this had no effect on their ordering. As for where the game specifies which trainer is in which map, the second file in the .fsys for each map is the file with all the scripts for that map. In this file is very easy to piece together because it contains a lot of human readable text in it. However, the equivalent file in colosseum has no such text and so I don't know what any of it means but it probably serves a similar purpose. The 3rd file in the map .fsys files is a string table of the strings that appear in that map. In if you search for any if the string ids contaibed in the third file, in the second file they will appear. You could try searching for the trainer IDs in this file. The ID is most likely the same as the index in the trainer data Finally, since you're clearly really into this research I recommend taking a look at gecko and ar codes for pokemon colosseum. There is so much that was figured out years ago from looking at the ram. Usually they just figured out the really obvious data but sometimes you may find something interesting. like One code for came with a list of all the values for the trainer models.

Thanks for that. I just want to look through and make sure I haven't missed anything. You managed to parse every single file so your code can handle anything that the game contains. Mine currently only works perfectly for common_rel, tableres2 and start.dol but will crash on things I hadn't seen like 0xFFFF08. I haven't used java in a while but I think I can still understand it.

Hahaha that's a fair point! This is really cool though. I'm assuming you wrote a program of sorts to dump all text right? If so, could you upload the source code for that as well. Mine isn't complete yet and it would be great to see how you did it (if you don't mind of course). You don't seem to have mentioned any such code but you'd have to be pretty dedicated to do all of this manually . Also, from the values I'm seeing, it looks like 0xFFFF08 almost definitely changes the font colour of the text. The next 4 values are RGBA values which determine the colour.

Yeah, I noticed they were 2 bytes each but I just ignored it since the maximum value for an EV is only 1byte. 0xFFFF does make sense for randomising the value as it is used as a randomiser value for a lot of variables. I didn't consider that since the game never randomises EVs. I lost interest in colosseum when I realised I could implement the phsyical/special class split in so I probably won't get around to testing your theory but if/when you do I'm curious to know. And yeah sorry, I spent about a week typing up everything I knew on notepad and then copy and pasted it onto the forums at about 5am in the morning so I probably made a few mistakes along the way. I will correct that now, thanks for pointing it out. I should probably post my discoveries as they come rather than piling them up... I think I'll post some updates soon.

That's really amazing! I don't know how you found the patience for that. I wrote an app that lets me type in an id and it automatically searches for me (and can replace strings) although It only searches the major ones right now because I couldn't be bothered to track down all the other files. The details of the special characters is really great too (that 7 byte one though 8O). I was dreading the day I'd have to go and find those. I'd really love to use your text dump as a reference if you make it available and maybe you could include a list of the fsys files that each table comes from?

I gave up on the logo textures for a while but then I stumbled across a texture which the header states is 4bpp and indexed. The pointer to the palette points to a 16 colour palette confirming that the image is indeed 4bpp. This reinforced what I said earlier about the 5th byte in the header being the bpp for the texture. So I decided to investigate the logo again with the following assumptions: 1. The 5th byte indicates that the image is 4bpp. 2. The first four bytes indicate 640x480 dimensions for the image. This makes sense as it gives a 4:3 aspect ratio and the image is displayed full screen. This also adds reinforces the 4bpp info since the number of bytes in the texture is half of 640x480 meaning each byte must be 2 pixels. 3. Tiledggd assumes that the image is indexed if you specify 4bpp. Therefore, I decided to add a palette to the end of the the file. I made a 16 colour palette where each colour in the palette was the 16bit equivalent of the 4bit colour that would lead to that index. With a tile size of 8x8, this resulted in the following image: You can see the rough outline of the nintendo logo but it is still very messy. Try looking at the image through a phone's camera from a distance and you can quite clearly see the nintendo logo. Like you said earlier, it makes more sense for 4bpp images to be indexed. The logo looks white from a distance and clearly not red like it is when it's viewed in-game. From all of this I've come to the conclusion that, although each pixel is indeed 4bits, they aren't colours. My best guess is that each 4bit pixel only contains a 4bit alpha channel. I know that in iOS development you can load an image as a 'template'. In simple terms this ignores the colour values of each pixel, leaving just alpha values. The image can then be assigned a 'tint colour' and each opaque pixel will be displayed as that colour. I reckon that the file only contains alpha values and is only assigned the colour red when it is loaded. The image would then probably be placed in front of a black background. I updated the palette so that the index each 4bit value will be converted to has the 8bit equivalent of that alpha value and a red channel of 0xFF. This simulates the effect of adding the red colour to each pixel later. This is what I got: However, I'm definitely still missing something. From the distribution of opaque and transparent pixels it looks like the pixels aren't properly aligned. Maybe I've got the wrong tile size or I've made an incorrect assumption somewhere. I think the way forward will be to change the values of some of the bytes and see how they look when the game loads them. That's going to be really tedious and I'm not interested enough to do that right now. nintendo logos.rar

In the attached images i mentioned what I erroneously guessed was some sort of unique trainer id. It only recently dawned on me that it was the string table id for the trxt the trainer says when you defeat them. I noticed this in the colosseum data so it's weird that It took me so long to make the connection. there is also the prebattle id (colosseums only) and victory text id (colosseums and mtbattle) like in colosseum. [EDIT:] So @Tiddlywinks informed me that a trainer's prize money is affected by the highest level of their pokemon. However, even though greevil's team of 6 and the shadow lugia battle just before both contain only level 50 pokemon, his shadow lugia battle awards $300 more. I just checked and this is because the prize money is calculated using the level in DPKM whereas the level used in battle is determined in DDPK. So although the DDPK level overrides the DPKM one, the DPKM one is usually raised a little just to increase the prize money from some shadow pokemon users.

I've been messing around with dolphin's debugger on . It turns out that the physical/ special split was really easy to use on all moves instead of just shadow moves. ( I converted the implementation to only 5 lines of action replay code). of course actually editing each move to incorporate the physical special byte is a bit more effort but I've tested it and it works almost perfectly since it was already in the game just largely unused. It is to be noted that the flash fire ability just boosted the pokemon's special attack when using fire moves in this gen (since fire moves were expected to always be special. This means flash fire only boosts special fire moves with the split. I need to test whether it would boost attack instead ifni edit fire type to be physical. Another interesting thing I've found is that setting a move's accuracy to 0 doesn't provide perfect accuracy like in the gba games but rather (more intuitively) just results in always missing. The interesting thing though, is that you can set the accuracy to more than 100 and that value is displayed. I set dragon claw to 200% accuracy and at -2 accuracy still had 100% accuracy. I don't know if this is the case in any other games. haven't seen anyone try it. [EDIT:] So I tested flash fire and it seems its hard coded to boost special attack (oh well).

I've been looking at the string tables in and have some updates. Each string is terminated by the value 0x00 spanning 2bytes. There are also some 'escape' characters (a bit like \n, \t or \\ in programming). They start with 0xFFFF followed by one or 2 bytes determining the special string or character that it will be replaced with in game. 0xFFFF00 and 0xFFFF03 seem to add a new line (so basically \n) . I think the gba games have 2 different ones as well; one which just continues the text on the next line and one which does the same but also scrolls up a row in the text box. Might be something similar. I don't know exactly what the rest do but some clearly fill in the player's name, the name of the npc meant to say that line or variable text like item or pokemon names. 0xFFFF07 and 0xFFFF53 always have one extra byte after them taking a total of 4 bytes for the special character. Every other special character I've seen so far is 3 bytes. The regular characters are 2 byte unicode characters and the strings are 'null terminated' (end in 0x0000). Colosseum is probably exactly the same but I haven't checked.

Just a quick update. I found the recompression script I've been using on a forum somewhere like a year ago and it's been really tedious to use. I just did some research on quickBMS scripts and I've amended the script to be a little easier to use. This new script automatically calculates the file size so you don't need to update the script every time you want to compress a different file. This also means that multiple files can be compressed on one run of quickBMS. The new script:

Hey, I don't know much about RNG or save editing but I do work on editing the game files in the ISO directly. From what I've read I think the save files are encrypted in some way which means it would be almost impossible to copy the hex from one save file to another. The game has a way of checking that everything in the save file makes sense and as soon as you change something it will say the save is corrupted and make you start again. However, there are alternative methods of getting the pokemon you want: 1. Action replay codes. It's very easy to find action replay codes to give you any pokemon you want. You can find the unencrypted AR codes and modify them to give you the exact pokemon you want. 2. RAM editing. If you're playing on the dolphin emulator you can run it in debug mode and edit the game's ram directly. If you search, you should be able to find the ram offsets of your party and change the data to whichever pokemon you want. Then you can save and that pokemon will be in your save file permanently. (Note that this is exactly what action replay codes do, just they do it automatically.) 3. Edit the game files directly. This method is a lot lengthier but if you wanted you could edit the ISO you're playing so that the first shadow pokemon is the pokemon you want. In theory, you could change it so that eevee is the pokemon but I haven't been able to figure out where the game stores this quite yet. I spend a lot of time using the first 2 methods when I want to run quick little tests so I would recommend those for a small job like adding one pokemon. Of course these depend on having either an emulator or AR device.

It's been a while since I played on a gamecube but don't all the ngc games use that same nintendo logo athletes e start. It would seem that every game is required to include that image and display it as soon as the game loads. incolo/xd it is bundled in a .fsys file which is as far as I know a file format which only thise games use. It's possible that each game chooses how to handle displaying the logo and if so, comparing with ither games may shed some light on what's going on. I'll see if I can extract it from some ither ISOs and compare.

I don't mean a 2 colour palette. I mean each pixel is 4 bits. 1 bit alpha, 1 bit red, 1 bit green and 1 bit blue. I feel like this gives really basic colours and since each pixel is only half a byte, the images are actually pretty high resolution. They could for instance alternate between blue and black pixels to produce a dark blue when viewed on a screen, since our eyes wouldn mix the pixels. This is mainly a theory but it fits with the file headers saying its 4bits per pixel and would explain the weird alternating patterns that don't show up when the images are viewed in game. What do you think?

I thought so. I think the header says its 4bits per pixel ( so one bit per channel) and it isn't indexed . That means each colour is only half a byte but tiledggd has a minimum of 2 byte colours. The nintendo logo only has black and red while the genius sonority logo only has white and blue. 2 very simple colours for each. So I assume each pixel only needs half a byte. Do you know any tile viewers that can handle 4bit colours?

Sweet. you're really good at this. Okay, so there's just one more if you don't mind. I n "genius_logo.fsys" and "nintendo_logo.fsys" there are the images that come up when the game starts up. I've been comparing the headers between the other two texture file types we've seen. The ones have 0x8 at around the 5th byte and are 8 bits per pixel. The colo ones have 0x10 for the same byte and are 16 bits per pixel. Therefore, I believe the logos are 4 bits per pixel from the header. The first 4 bytes are the width and height (usually) and for the logos they are 640x480. The combination of these works out in Tiledgggd. However, once again I get a good enough image to see what the image is meant to be but I can't get it to show perfectly. I really thought I could figure this one out...

Ah that makes sense. The palettes in use that format as well. If it turns out to just be 2 byte colours then that should be easy enough to convert to a bitmap. It would be rather tedious to do again though so I think I'll pass on this one for now.

It worked ! Also, could I get you to look at the textures in colosseum and tell me what you think? They have a slightly different format which is almost identical but without any pallet data as far as I can tell. Thought you might have some insight as to where the pallets may be. I was thinking maybe a pallet that colosseum shares for all the textures? I've noticed a lot of these textures are reused in .

I've been refining the code so haven't tested yet but was just about to. I'm pretty confident since tiledggd opened it the same way with the same settings. Hopefully there aren't any tricks I haven't noticed.

I was feeling up to the challenge so I wrote an app for replacing a texture with an edited png. It wasn't particularly difficult after all. Forgive the crappy fairy type image. I was improvising using the colours from the pallet. I've noticed that the pallets repeat a lot of colours so it should be possible to replace those colours with whatever we like. Just need to keep the compressed file size in mind.

Had a look at the textures again and if you include the alpha value in TiledGGD the images are perfect. The garbled pixels you mentioned are actually transparent. The results:

I haven't looked into them too much but as far as I can tell they're scripts. They have clear "function-like" names and the respective code isn't asm. Refer to part II in this thread - '>http://projectpokemon.org/forums/showthread.php?46260-Stars-list-of-things-which-still-need-research-in-Pokemon-Colosseum-and-Pokemon-. I think I also attached some images in the second research images rar file. As for the textures I guess I'll try comparing them with known gamecube formats but I could probably have a go at writing my own code if it comes to it. TiledGGD has revealed a lot about the format already and I may be able to reuse the original file header if the new image is similar enough. I'm still writing my hacking tools so that won't be a priority for a while though. I've just finished writing some code that can automatically look up string IDs which will be very helpful for data-mining. The string IDs pop up in so many different data structures and are by far the easiest way to identify the data.

Thanks for all the information. It should be a great help. As for the symbols, I know that Start.dol in has random function names scattered around but I don't know how they correspond to the code. Also you'll find that the maps have scripts which have good headers so it's easy to match the script names to the script data itself. Btw, does TiledGGD have a way to reimport an image after editing it? can't seem to figure it out.