Made_s

The game also contains a bunch of scene files that were used for prerendered scenes, mainly the ending video

Let me know how it went

Can you send me a copy or the location in the iso of the model and the texture (s) you tried to insert?

EDIT: fixed some bugs in model texture tools try again now.

I could get the mesh with textures, materials and so on easily, it's just the HAL DAT (Super Smash Bros Melee's) format hidden under some layers of structures.

I could also get it completely rigged if I was more experienced with Matrices and changing between spaces/coordinate systems/file formats and importing them into programs.

The things I'm looking for are the format of the animations and the arious property sections in these top layers of which I don't know what they do.

I can't really put an other meshes inside these files because the data is all mixed with other parts that I don't know.

Editing vertex positions is really easy though.

Oh, and I'm somewhat progressing onmap hitboxes.

You could replace the cries with the SAMP Tool if you wanted to put in the effort.

This is a collection of a few small Java programs I wrote and have been using to edit some files in Pokemon XD: GoD and I've also recently found out that some of them also work with Pokemon Channel and Colosseum files.

They're mainly just more convenient than manually editing the files.

Almost all of them have size limits because changing file sizes needs modifications to the game's .toc and FSYS list.

• GTX to TGA: Converts .gtx files to TGA images, mainly useful to find out what they are
• I_SF Tool: Inserts/extracts DSP files into/from XD's music FSYS files, the filenames usually begin with "stm_"
• SAMP Tool: The same as above, uses .samp and .sdir files to extract and insert music samples, can be used to replace sound samples for sequenced music (Colosseum) and soundeffects, Pokemon Channel contains some too
• LZSS Tool: Inserts/extracts files into/from .fsys files, filenames should not be changed for the insertion to work
• ModelTextureExtractor/Inserter: Inserts/Extracts textures from model files in the form of .tpl files, the standard offset should usually work for most battle models, the offset needs to be set to 32 for overworld models and maps and to custom ones for some battle models that have particle data before the model
  Insertion has two options of reducing the palette of a TPL using a palette in case it is too large, though both are quite buggy, it's mostly a last resort option
  Again, don't change filenames of extracted textures for the insertion to work
  These should also work for Pokemon Channel's .dat files and Pokemon Colosseum's models
• MoveTextureExtractor/Inserter: Does the same as the model one, but only works directly on FSYS files, I'm really not sure why I wrote it like this
• String Table Editor: Just a more convenient way of editing the String tables, just removes the need to manage offsets and so on, top right corner shows all Special characters, adding a single byte can be done with {} too
• XD THP Tool: Inserts/Exracts THP files from FSYS archives, the filenames usually start with "movie" 

Download: Here

EDIT 22.03.2017: bug fixes to model texture tools

Ok, most of the text is in the pchall.bmg file in the /en/pch folde ( it's probably something else instead of en for other releases).

It's a String table which starts with the magic bytes "MESGbmg1" followed by the total file size.

following are the two 4 byte values 0x00000002 and 0x01000000, not sure what they are for yet.

At 0x20, there are the magic bytes "INF1" for the offset section which contains offsets for every String in the file followed by the offset (relative to the start of this section, so just add 0x20) for the section of the file that contains the Strings . It can just as well be interpreted as the sizeof this section.

Next is a 2 byte value containing the amount of Strings in the file and another value that seems to always be 0x0004 and another one that's either 0x0001 or 0x0000.

0x10 bytes relative to the section start is where the list of offsets start. These offsets are relative to the start of the String data in the next section.

At the start of this second section the first thing are again some magic bytes "DAT1" followed by a 4 byte value containing the size of this section or the offset to the end of the file relative to the section start.

The String data starts at 0x8 relative to the section start.

The following Strings are regular C strings with the exception of the character 0x5E, which starts a highlighted part of a String, tking the following byte as a parameter (I don't know which corresponds to what) . This highlighted part is terminated by two 0x5E in a row.

I was able to extract and insert textures of models using some things I wrote for Pokemon XD, I'll be posting those in a different Thread soon.

I'm still working on video replacements and I could try to find the text data if you want that.

The only reason I can think of why this would happen is that the Invalid Pokemon Flag is checked by the game, this might also set the Egg flag, since it's probably considered a Bag Egg. Is it a regular or a Shadow Pokemon? I don't know whether Shadow Pokemon can gain EVs. Also how did it gain those 2 attack EVs if you couldn't use it after the edit ?

What values did you change ?

I'm not sure, I know how most of the format works now but I'd have to look into the Battle revolution format to find out how similar they are, I know they don't have the same structure but if they're not too different I could probably import models from there with a bit of data shifting.(PBR might also use shaders for textures/surfaces which might make the imported models look very different in that aspect)

The biggest problem is the animation data, I still don't know how it works in .

Then there are particles contained in model files. I could just leave them out but models like Charizard would probably look weird.

It's very possible to do it, but there are things that need to be done/found out first.

DO you know how to change the file sizes in the iso so you can add bigger files ?

I'm still working on documenting the whole model file format ( the most of it is the HAL DAT format but some top level structures that are specific for and the animation data are undocumented) but since I already know enough to write the model texture extractor/inserter you wanted I did just that.

Extractor : Link

Inserter: Link

They work pretty much the same as the ones for move textures, with the change that you need to specify the offset of the main data ( not the start of the data) so 0xE80 for normal model files, not 0xE60 ( you need to enter them in decimal, so 0xE80 would be 3712) .

Also the list of files you are about to process is always reset when you drop files into the window, so you have to drag all the files you want to process at once.

There are some files that (for some reason I don't know yet) have a GPT1 section ( the one I was talking about in the move files) before the model data, for now you'll just have to put the Offset to the actual model data, I'll probably put out a fix once I know what to do with that.

(My guess is that these are particles that are present on the model since I found this in Articuno's file, which probably has some kind of ice particles on it. Do you know whether it does?)

You have the option between merging or throwing out one of the currently most similar colors until the palette fits in the case that a palette is too big, the merging process might produce weird colors you don't want in the textures, but this is just a kind of last resort since converting textures with the .bat usually already decreases the palette by quite a bit and gives you enough freedom for modifications. Most textures don't use palettes anyway. I'll probably fix the merging thing when I have the time.

The Program should work with Maps, Battle models and Overworld models.

If there are any Problems/Errors with this, please tell me about them and I'll try to help.

*EDIT: made the programs more user friendly

Ok, I finished the Inserter program and it should now be working.

The fixed Extractor is Here .

The Inserter is Here .

I wrote up a (unfortunately) rather long tutorial on how to use them for someone in the group which shouy ex how they're used well enough (though you can be more free with it as it will tell you about any problems as usual):

To Extract Textures ( You'll have to do this to insert anything, you can only insert edited versions of the extracted files as the replaced textures must retain their dimensions and texture type) :

Use the MoveTextureExtractor jar , enter the name of the .fsys file and click Extract Textures.

This should extract all contained textures.

(Please have the .fsys file,the textures and both programs in the same folder)

Please don't modify the filenames of the textures (they're in the .tpl format )

Then use the conversion program by selecting any texture you want to convert and dragging it onto the .bat ( you can do this with multiple ones at a time)

Then just edit the resulting .png images. (I think they're all greyscale so using color probably won't do anything and youshouldn't do it)

Then delete the old unconverted texture versions of the files you edited and drag the .png's onto the .bat.

This will create new texture files of the images.

Put those resulting textures back into the folder with the jars.

Then open the MoveEffectInserter jar and drag and drop all textures you want to insert at a time into the top box.

Enter the filename of the original .fsys and click Insert File(s).

If it doesn't give you any errors they should now be inserted

This took me quite a while longer than what I expected but I really wanted to get the Drag and Drop feature to work because you seemed to like the clean design of the Extractor ( I was also sick of entering file names for every single thing I do )

I might make all these texture things into one thing later just so I don't have to spam you with posts with little jars every time I find something new.

Maybe this could be used to make your attack animation replacements look better ?

I'll continue research into model files, I'll tell you if I find something useful/significant.

(You can ignore the following for the EDIT)

Like I said, the wimgt tool uses .tpl files and converts them to .png. It's run in command prompt.

If you don't remember, you can find it Here .

If you want to automate it for converting things automatically (You'll need to use wimgt for the model textures too (you don't need to, but it's the fastest way to do it that I know of)), the source code is Here , the relevant part mainly Here .

The command is: wimgt dec [imagename].tpl --dest [destinationimagename].png

The command for converting back into the respective format:

wimgt enc [imagename].png --dest [destinationimagename].tpl --transform tpl.[format]

(format is just the formatname in lower case letters) This is why I kept the format name in the filename, so you don't have to look into the file to find it out.

*EDIT: I found a better way, I found This .bat that uses the wimgt tool and let's you convert multiple files at once ( when you open the .bat it tells you how to use it) without needing to bother with acommand prompt. It works both from and to .png . This needs a small modification in my program though , the format has to be given as a number, this fix will be included with the inserter.

So, the extractor part is finished, it extracts any texture in GPT1 sections it can find in an FSYS file (you don't have to decompress it before) and saves them as .tpl files. The filenames are in the format [Name of original file]_[GTP1 section]_[Texture header]_[Texture]_[Format].tpl .

The filename and format are just for your information, the others will be used to put it back in in the reinserting program I'm writing, meaning that you should probably keep the name when converting.

Here's the Link.

Of course, this is all just an option, I don't really see what you'd need to modify move textures for, but if you want you have the option.

Those textures (at least the ones I found) are just I8 textures (greyscale), the game uses black as the alpha channel, they're easy to find manually, but I have no idea how I'd find them in a program since I didn't find any pointers pointing to them and some didn't have a header that I could find, there also seem to be different formats for these effect files.

Does Dolphin dump move effects? And if yes, does it dump them as greyscale?

(Since they are greyscale I couldn't help but try it with This , so at least that works fine )

*EDIT: The files can contain different texture formats, it's easy to tell from the headers.

*EDIT: Some of the files store their textures in a section called GPT1, which I somewhat documented Here .

This should be enough info for me to automate files with this structure, the sections I couldn't figure out yet are only a problem if there are textures that have different values at those positions.

*EDIT: So I found out that files can contain multiple GPT1 sections, probably to match them to different things, as they're mostly used in files that also contain model or animation data.

I was also right about the first value of the texture header, it's the number of tetures and the offset at the end is that one texture in case of it being 0x01, if it's for example 0x0B, then there will be 11 offsets and the row of 0xFF works as a filler like in the texture list. This is likely done to reduce the amount of redundant headers, since the textures of one texture header all use the same format and dimensions.

Also if the row in either the texture list or a texture header is filled completely there are no 0xFF s.

The textures that aren't contained in these GPT1 sections seem to be handled in a similar way to the textures in model files.

I'll post a program that extracts these textures into a format that the wimgt tool can use once I get my Java edit of the LZSS script to work.

I am currently trying to find the ASM routine that loads in model data to maybe find out how it uses the pointers, I already know where it loads it into memory, it loads the complete file if I'm correct , but I can't get the memory breaks in the debugfast version to work.

I tried both Dolphin 3 and 4 and neither seems to break when it edits a memory adress at which I set a breakpoint ( yes, I did set it to read/write).

Do you know of this issue and any way to fix it ?

*EDIT: I tried getting a texture from a move file and I'm wondering whether this texture is usually this squeezed or I did something wrong :Link ( This is from the megahorn file)

these battle effect textures all seem to be somewhat squeezed, ithink I'm doing something wrong but I don't know what.

*EDIT: Nevermind, I solved the second one This looks a lot better

So I fixed some bugs in the program and rewrote all the scripts to make them much faster, pretty much removing any waiting time. It's not that this is really good code now ( maybe it is, I wouldn't know), just a whole lot better than what I wrote before.

The only part that's not been tested by me or someone else is the insertion of soundeffects because I wouldn't know where to find them in the game.

Jar Download

Again, if there are any problems using it, especially when something doesn't work , just ask me about it.

Well, it might be done like that for loading reasons, let's just hope it's not done that way.

I'll see if I can find something, I don't really see a reason for that info to be outside the file, but maybe there's some kind of table in a different file that has loading data like the number of textures for every Pokemon for some reason .

There are also some models that contain RGBA8 textures, but I'll just have to adjust the amount of bytes read per pixel.

I also (probably) confirmed ( not that it was hard, I was just lazy ) that the first pointer doesn't always poin to the first texture pointer, so the information on what the pointers in the main table point to is probably stored elsewhere (maybe even still in the file).

And I think several files have multiple texture lists.

Also, while looking through a Pokemon Colosseum Iso, I found out that Colosseum stores its music as midi files with the samples being stored like the sound effects, this means that the samples can be extracted by my sound effect extractor, the files are snd_music.samp and snd_music_sdir.fdat and the midi files are stored in bgm_archive.fsys, but it also means that you can't directly replace tracks like in , and I doubt you know how to do this with sequenced tracks like these.

These files are out of our reach to competently replace.

Technically the MusyX SDK is out there so you could replace it with other midi music you make in there but that requires professional knowledge.

I wrote the part of the program that writes/reads to/from the files that are used/made by the wimgt program, so when we have a way to get the data we don't have to worry about that anymore.

Another thing, the stuff the first pointer in the main pointerlist points to looks very different in the overworld files.

*EDIT: I'm pretty sure the first pointer in the overworld files doesn't point to texture pointers.

*EDIT: Also reading the texture pointers of the Battle model files might be more complicated than I thought it would be...

SO I'll have to find a way to reliably read and stop after I read all the texture pointers (finding them is not so hard because they're all in the main pointer table, there might be irregularly many pointers between the texture pointer pointers though( I'm not sure)) and find out where the texture pointers are in the overworld files.

But I can't think of aything for the stop point right now, so I'll take a break till tomorrow, maybe you can think of something, this is what I tried : Link