Official DAT Texture Wizard (current version: 6.1.4)

[CeLL]

@ DRGN I'm coming to you because after two weeks of studying every hack and mod thread on this forum, you seem to be the guy to come to about _9 images. Your png -> tpl -> MnSlChr wizard is a masterpiece. My current project is updating all of my CSPs to match the modded textures they correspond with. I've found a bunch of really nice costume-modded CSPs in threads just from combing through them, but there are so many I'm missing. And I would just make my own because I have a handle on the process but Dolphin doesn't run on my computer due to graphics card limitations.

TL;DR - Is there a CSP dump where people have been sharing?

Also what's the best way to share images and files of stuff I've been working on? Everyone seems to use mediafire for files, but I don't know how people post images.

http://smashboards.com/posts/18081206

 

[Anutim]

TL;DR - Is there a CSP dump where people have been sharing?

Also what's the best way to share images and files of stuff I've been working on? Everyone seems to use mediafire for files, but I don't know how people post images.

This is a WIP, I believe but here you will find a lot of CSPs.

You can use mediafire for images as well, which is what I like to do for dolphin dumps where I need the actual name of the file. Otherwise just use imgur. Best option, imo.

 

[f_un]

Thanks dudes, this helps a lot.

 

[DRGN]

@ DRGN I'm coming to you because after two weeks of studying every hack and mod thread on this forum, you seem to be the guy to come to about _9 images. Your png -> tpl -> MnSlChr wizard is a masterpiece. My current project is updating all of my CSPs to match the modded textures they correspond with. I've found a bunch of really nice costume-modded CSPs in threads just from combing through them, but there are so many I'm missing. And I would just make my own because I have a handle on the process but Dolphin doesn't run on my computer due to graphics card limitations.

TL;DR - Is there a CSP dump where people have been sharing?

Also what's the best way to share images and files of stuff I've been working on? Everyone seems to use mediafire for files, but I don't know how people post images.

If it's for a bunch of images, like with CSPs, I think the best method is to make a zip file of them, so that way they're together in one download, and all the images keep their file names.

 

[Doq]

TL;DR - Is there a CSP dump where people have been sharing?

Not even gonna link the same thing a third time

Also what's the best way to share images and files of stuff I've been working on? Everyone seems to use mediafire for files, but I don't know how people post images.

Dropbox works beautifully for TPLs and filename-specific files. As for images, if you don't care about the name of it, Imgur is a great place for that.

 

[Xeofreestyler]

Hi, I'm having some problems, not sure why the DAT texture wizard isn't working.
When I do things manually, I always get:
"The following images were not processed because proper offsets were not given or not found. --full filepath of texture-- "

I tried doing it in a folder structure similar to Steelia's, I tried putting the txt and png in the same folder and I tried both of these in the offsets txt (found in steelia's pack, under 58 marth cape logo ):
GALE01_484dbed5_14.png --> 00061320
or
C:\Users\Alexander\Desktop\Melee Toolkit\Liquid Texture Hack\GALE01_484dbed5_14.png --> 00061320

None of those methods worked, so then I tried using 'scan folder structure'. Perhaps this wasn't meant to be used when just replacing one file? (I had done most in Melee Toolkit already, but I couldn't replace marth's cape logo there so I came here like Achilles told me)

When pressing ok it gave me this error:
http://i.imgur.com/lbn2hUH.png
(I don't actually have Python34, only Python27, but I assume this should work standalone?)

That's what happens when I select the folder that holds Placements.txt and a folder called 58 with the aforementioned file. Placements.txt has nothing else but "58 - 00061320"
58 holds a png called GALE01_484dbed5_14.png

I'm a bit stumped, would appreciate a little help. Thanks.

 

[Achilles1515]

Hi, I'm having some problems, not sure why the DAT texture wizard isn't working.
When I do things manually, I always get:
"The following images were not processed because proper offsets were not given or not found. --full filepath of texture-- "

I tried doing it in a folder structure similar to Steelia's, I tried putting the txt and png in the same folder and I tried both of these in the offsets txt (found in steelia's pack, under 58 marth cape logo ):
GALE01_484dbed5_14.png --> 00061320
or
C:\Users\Alexander\Desktop\Melee Toolkit\Liquid Texture Hack\GALE01_484dbed5_14.png --> 00061320

None of those methods worked, so then I tried using 'scan folder structure'. Perhaps this wasn't meant to be used when just replacing one file? (I had done most in Melee Toolkit already, but I couldn't replace marth's cape logo there so I came here like Achilles told me)

When pressing ok it gave me this error:
http://i.imgur.com/lbn2hUH.png
(I don't actually have Python34, only Python27, but I assume this should work standalone?)

That's what happens when I select the folder that holds Placements.txt and a folder called 58 with the aforementioned file. Placements.txt has nothing else but "58 - 00061320"
58 holds a png called GALE01_484dbed5_14.png

I'm a bit stumped, would appreciate a little help. Thanks.

If you're just doing one texture that is not a palette, I would just do it semi-manually. Feed your PNG into the PNG-to-TPL program, open the TPL it created in a hex editor, copy from 0x40 down to the bottom, and then paste at the placement line in the Marth texture dat file. Done.

 

[DRGN]

Hi, I'm having some problems, not sure why the DAT texture wizard isn't working.
When I do things manually, I always get:
"The following images were not processed because proper offsets were not given or not found. --full filepath of texture-- "

I tried doing it in a folder structure similar to Steelia's, I tried putting the txt and png in the same folder and I tried both of these in the offsets txt (found in steelia's pack, under 58 marth cape logo ):
GALE01_484dbed5_14.png --> 00061320
or
C:\Users\Alexander\Desktop\Melee Toolkit\Liquid Texture Hack\GALE01_484dbed5_14.png --> 00061320

None of those methods worked, so then I tried using 'scan folder structure'. Perhaps this wasn't meant to be used when just replacing one file? (I had done most in Melee Toolkit already, but I couldn't replace marth's cape logo there so I came here like Achilles told me)

When pressing ok it gave me this error:
http://i.imgur.com/lbn2hUH.png
(I don't actually have Python34, only Python27, but I assume this should work standalone?)

That's what happens when I select the folder that holds Placements.txt and a folder called 58 with the aforementioned file. Placements.txt has nothing else but "58 - 00061320"
58 holds a png called GALE01_484dbed5_14.png

I'm a bit stumped, would appreciate a little help. Thanks.

The lines you put in the offsets text actually go in the Source Textures text field in the program. Also, you don't even really need a placements file (those are just for convenience when doing many textures at once, or any operations you think you're going to be doing several times). All you need is this:



(Although I just guessed on the destination/.dat file. You'll need to change that to point to yours.)

Did you read the user guide? I ask because I might rewrite parts of it, so I want to know if there are parts of it that are unclear or confusing.

As for the bug you found; I knew about it and know how to fix it, but I just haven't gotten around to it yet since I've been working on a few other things. It's there because when I looked at Steelia's packs, I always found folders named with a number with a short description, e.g. "02BootHeel" or something. And to look for numbers of any number of digits (e.g. 1 as well as 100), it looks through the name and stops at the first non-number. In other words, I didn't plan for folders that don't have the descriptive part and are only numbers. I'll fix this in the next release. In the meantime, if you were to change your folder name to "58e" or something it would work. But this folder structure method isn't really needed for a single texture like what you're trying to do.

 

[Xeofreestyler]

Ohhh okay, I got it now. Thanks guys! I managed to replace the file.

I think my misunderstanding was more due to the fact that I was working on that at 5 am in the morning ... I just simply wasn't thinking straight (and I specifically removed the descriptive name from the 58 folder, for some reason I thought that it had to match the numbers and nothing more)

Now I just have to figure out how to get this white glow off of wh Marth's cape... Time to dig through the color formats.

 

[Starreaver1]

Okay so apparently I'm pretty terrible at following instructions related to texture hacking lol. Can someone please explain to me how to write in batches of CSP data using placement files? I've been doing it manually but I'd rather just have one placement file that I can use every time I wanna write in CSPs.

 

[DRGN]

Does this help? Please let me know if a part isn't real clear (I'm hoping to improve the documentation that's out there for this).

Spoiler: ’Creating “Placements” files’

First I'll explain Steelia's placements files that come with his texture packs (found here) which should work with the 'Scan folder structure' feature in DTW. His placements files were created for his folder structures, which relate a folder to an offset. Here's an example line in the placements file:

28 - 00064c60

The 28 is the numeric ID of the folder that the image is in. For example in this case it represents the texture in the folder "28HelmetEmblem" in Captain Falcon's pack. The 00064c60 is the offset where the texture is to be overwritten into your DAT or USD file. The two points of data are then separated by a dash (spaces are optional).

You can also do the same thing for any images by themselves without any special folder structure. This is done by using the texture IDs (texIDs) of the textures, which are found in the file names. For examples, the files "GALE01_58408ead_3.png" and "txt_0065_14.tga" have texIDs of _58408ead and _0065, respectively. So if you wanted to associate the above example with the offset 00064c60, the simplest line would be:

00064c60 - _58408ead

(This means you need to keep that texture ID intact in the file name too, which is where DTW looks for it.)

Or you could just add the texID to the line in Steelia’s placement file rather than start a new file (so then the same placements file can be used for his folder structures OR textures by themselves); just add it to the line with another dash separator. The TGA’s texID could be tacked onto there too if you want (and the order of all of these parts doesn't matter). So you could have, for example:

28 - 00064c60 - _58408ead - _0065

As for the MnSlChr Placements file, I have one attached that's in a much more readable format than the old one. I only have the texture IDs for Samus, Young Link, and Zelda in there though, because those are the only CSPs I've made so far. You'll need to add the IDs for the textures you want to do. But if you do, please re-upload it so others can use it too.

 

[Starreaver1]

I think we found earlier that our texIDs were different, and that there are a billion different reasons that would make them different for different people.
Also, can you use that placement file without having all your TPLs/PNGs in separate folders, just need to add the texIDs? I had them in separate folders before, I'm not sure what I was messing up.

 

[DRGN]

I don't know how many different texture IDs there are. If there aren't that many (especially due to people using common/default settings), then it could still be useful since you can associate as many IDs as you want to one offset. Or you could just use it for personal use anyway. If you add to it, I still wouldn't mind getting a copy.

And no, you don't need separate folders.

 

[Starreaver1]

I'll send you the text file once I'm done, appended with what Dolphin settings I used. Thanks for the help.

 

[CeLL]

Finding _8 or _9 textures is a serious pain in the arse. When you convert the unaltered ripped texture file to TPL, it will have basically no matching values in the DAT to the original texture... As a result, what you need to do is look around for values that follow the same pattern.

For example, here are the first three lines of a random _8 file I converted:

88 88 88 8a 88 88 88 ae 88 88 88 ae 88 88 88 8d
88 88 88 88 88 88 88 88 88 88 88 88 ee da e8 ee
ee e8 e8 ee ee de 8e e8 fe ee 8e e8 ed ee e8 ee

And now, here are the first three lines of the actual file in the DAT:

00 00 00 01 00 00 00 1b 00 00 00 2b 00 00 00 05
00 00 00 00 00 00 00 00 00 00 00 00 bb 51 b0 bb
bb b0 b0 bb bb 5b 0b b0 9b bb 0b b0 b5 bb b0 bb

Notice the pattern? Both have changes in their values in nearly all the same areas (88 88 88 8a and 00 00 00 01 from the first four bits of hex, or ee da e8 ee and bb 51 b0 bb at the end of the second line). It's a very diligent process that can require a lot of going back and forth.

Likewise, when a _14 file is converted, it will not match up 100% with its DAT counterpart, but it will be much, much closer than a _8 or _9. What I do is I take small snippets of hex from the TPL (around 4~8 bits), and try to match it up to anything in the DAT.

Using the _14 file you supplied, here are the first 3 lines:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
00 04 40 02 00 00 55 aa 00 04 40 02 00 00 55 aa
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

And here are what the first 3 lines of the actual offset look like:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
60 01 00 04 55 55 aa ff 60 01 00 04 55 55 aa ff
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

Note how the 1st and 3rd lines match up with one another perfectly, but the 2nd lines differ very slightly, enough to where you wouldn't be able to find a match if you tried searching using that hex.

Hopefully that provided a little bit of insight In any case, for that _8 file you posted, the offset can be found here: 00002880 (2 lines, 16 colors MAX)
And for that _14 file, offset is: 00000880
Unlike most files, both are found in MnSlMap.usd (NOT MnSlMap.dat, that's the Japanese version).

Okay I made a little script that takes two paletted images and tells you if they are the same. I tested it with the TPL in this quote and a couple CSPs. Also I did a brute force kind of thing on IfAll.usd and found that Fox's neutral stock icon's image data is at 0xC4260, but that took well over half an hour on my computer, for even a small texture.

If there is a way to narrow down what could be the start of a texture, I can make it that much faster. To find that texture I literally tested if the texture started at every byte in the file up to that one. If I can get it to a reasonable time, I can add functionality to find other textures (just copy the data and search in the file, right?) and a GUI.

Oh but it can't find their palattes because I don't understand palettes and doing the same thing didn't find them.

 

[DRGN]

Okay I made a little script that takes two paletted images and tells you if they are the same. I tested it with the TPL in this quote and a couple CSPs. Also I did a brute force kind of thing on IfAll.usd and found that Fox's neutral stock icon's image data is at 0xC4260, but that took well over half an hour on my computer, for even a small texture.

If there is a way to narrow down what could be the start of a texture, I can make it that much faster. To find that texture I literally tested if the texture started at every byte in the file up to that one. If I can get it to a reasonable time, I can add functionality to find other textures (just copy the data and search in the file, right?) and a GUI.

Oh but it can't find their palattes because I don't understand palettes and doing the same thing didn't find them.

Sounds cool. How do you use it? What's it written in?

And yeah, there are ways to narrow down the start of a texture. In fact, I've thought about a program to look for such things and potentially pull textures of any image type straight from a dat file. I just haven't gotten to playing with the idea yet since I have several things on my plate right now (all of which look delicious). But maybe we could combine these things.

Essentially, you find the relocation table by the offset in the file header, then use it to look up various pointers. Theoretically, you could follow each pointer, which then (sometimes?) lead to another pointer. If you're being led to texture, then you should come to the image header, containing the width, height, and image type in a consistent pattern.

 

[CeLL]

Sounds cool. How do you use it? What's it written in?

And yeah, there are ways to narrow down the start of a texture. In fact, I've thought about a program to look for such things and potentially pull textures of any image type straight from a dat file. I just haven't gotten to playing with the idea yet since I have several things on my plate right now (all of which look delicious). But maybe we could combine these things.

Essentially, you find the relocation table by the offset in the file header, then use it to look up various pointers. Theoretically, you could follow each pointer, which then (sometimes?) lead to another pointer. If you're being led to texture, then you should come to the image header, containing the width, height, and image type in a consistent pattern.

Okay, what is the image header like? Is it the same as the image header in a TPL?

Also let me make sure I understand the relocation table. So at 0x4 is the offset for the relocation table, and at 0x8 is the number of pointers, and then the relocation table itself is just that many back to back 4-byte pointers?

 

[DRGN]

Okay, what is the image header like? Is it the same as the image header in a TPL?

No, unfortunately it's not the same. For example, if you look at the image below, at 1166B0 in EfCoData.dat, you'll find this:

The highlighted part is: pointer to the image data (4 bytes), width (2 bytes), height (2 bytes), image type (4 bytes). 0x80 = 128, so the image's dimensions are 128x128, and the image type is 3. Unfortunately I don't know where the header even ends or what more values are. You might also notice that there's a pointer in there that points to this header (00116690). I'm not quite sure why a pointer points to one place, just to direct you to another slightly different place.

Also let me make sure I understand the relocation table. So at 0x4 is the offset for the relocation table, and at 0x8 is the number of pointers, and then the relocation table itself is just that many back to back 4-byte pointers?

Yes, but you'll need to add 0x20 to the pointer for the relocation table, because the offset you're reading there is relative to the start of the data block, not the start of the file (so it's excluding the file header, which is 0x20 long). All offsets that you find in the files will need this 0x20 added to them. I wrote some examples using the relocation table here. Scroll down on the EfCoData tab and you'll find a little section called "Following a few offset trails..." which I think might help. Let me know if you figure out anything new.

 

[CeLL]

No, unfortunately it's not the same. For example, if you look at the image below, at 1166B0 in EfCoData.dat, you'll find this:
View attachment 36950
The highlighted part is: pointer to the image data (4 bytes), width (2 bytes), height (2 bytes), image type (4 bytes). 0x80 = 128, so the image's dimensions are 128x128, and the image type is 3. Unfortunately I don't know where the header even ends or what more values are. You might also notice that there's a pointer in there that points to this header (00116690). I'm not quite sure why a pointer points to one place, just to direct you to another slightly different place.

Yes, but you'll need to add 0x20 to the pointer for the relocation table, because the offset you're reading there is relative to the start of the data block, not the start of the file (so it's excluding the file header, which is 0x20 long). All offsets that you find in the files will need this 0x20 added to them. I wrote some examples using the relocation table here. Scroll down on the EfCoData tab and you'll find a little section called "Following a few offset trails..." which I think might help. Let me know if you figure out anything new.

Okay so for images does it always follow the pattern you have of Pointer (in RT) -> Pointer (in image data header?) -> Pointer to image (in image data header) -> Image? And Image would be the actual image data, not part of a header or anything?

 

[DRGN]

Okay so for images does it always follow the pattern you have of Pointer (in RT) -> Pointer (in image data header?) -> Pointer to image (in image data header) -> Image? And Image would be the actual image data, not part of a header or anything?

Yeah, the actual image data. As for the first question, I don't know, that's something that will need to be tested. The examples that I have there are the only ones I remember trying.

 

[CeLL]

Yeah, the actual image data. As for the first question, I don't know, that's something that will need to be tested. The examples that I have there are the only ones I remember trying.

Okay I looped it going from pointer to pointer until it got to one that wasn't in the relocation table, and found Fox's stock icon in 11 seconds :O

 

[CeLL]

The time scales a LOT with larger textures though. I'm trying to make it so that when it's analyzing a candidate, it stops as soon as the result is different from the texture's, instead of doing the whole thing.

Fun fact 14 pointers in IfAll.usd's relocation table point to Fox's neutral stock icon image data.

 

[DRGN]

Cool. What are you writing this in? If you're using a for loop you should be able to break out of, or skip, an iteration with an if statement checking certain conditions.

 

[CeLL]

Cool. What are you writing this in? If you're using a for loop you should be able to break out of, or skip, an iteration with an if statement checking certain conditions.

Python. And now massive textures take only a trivially longer time to find than small textures. :D

I just need to finish up the GUI now, might be able to finish it when I get home tonight.

(But it still can't find separate palettes)

 

[DRGN]

Cool. I wrote DTW in Python 3.4, with tkinter for the GUI. At some point I need to get around to uploading the source code.

 

[Starreaver1]

@ DRGN I has something for you.
Textures dumped using compiled Dolphin 4.0-720-dirty with all default settings (OpenGL, texture cache set to fast, etc.)
Edit I think this was mentioned earlier but I think it'd be really cool if there were a program that could just be like, I wanna replace this texture with this, and it does it with a couple clicks (kinda like the Melee Toolkit I suppose).

 

[DRGN]

@ DRGN I has something for you.
Textures dumped using compiled Dolphin 4.0-720-dirty with all default settings (OpenGL, texture cache set to fast, etc.)
Edit I think this was mentioned earlier but I think it'd be really cool if there were a program that could just be like, I wanna replace this texture with this, and it does it with a couple clicks (kinda like the Melee Toolkit I suppose).

Oh, cool, thanks!
Yeah, that would be cool. Idk, I might do something like that. The downside is that you'd have to download the textures you'd be seeing in it, so the download would be huge. But it could also be that the downloads are separate/option, and in groups. In other words, texture packs like Steelia's. And since the placements files in Steelia's packs work with DTW, do we kinda already have that? Right now, you can download a texture pack for Falcon, for example, edit whichever textures you want in the subfolders (leaving the edited version in the same folder as the original), then open up DTW and use the 'Scan folder structure' function and the placements file that comes in the pack, and all the textures you edited and their offsets should pop up in the program. It's just that the 'I wanna replace this texture with this' part is done in the folders, rather than in the program's GUI. People might not realize that it's this easy though, since there's no guide on the whole process yet.

 

[CeLL]

No guarantees, but here it is. Still takes a second to find stuff but it's still relatively fast (took like 15 seconds to find 3 CSPs at the same time)

You can do as many TPLs and DATs/USDs as you want at a time, but since it checks every DAT for each TPL until it finds it, I suggest not have multiple of both, i.e. just one DAT and multiple TPLs or one TPL and multiple DATs. Otherwise you waste time looking for TPLs in DATs they aren't in.

http://www.mediafire.com/download/qt1vm3sf530y75o/Texture_Finder_1.04.zip

I'm hoping a tutorial is not needed, it's pretty simple.

Edited edit: currently only does _8, _9, and textures without palettes. Idk if it will work with _a's. I'm trying to get CMPRs working.

 

[DRGN]

No guarantees, but here it is. Still takes a second to find stuff but it's still relatively fast (took like 15 seconds to find 3 CSPs at the same time)

You can do as many TPLs and DATs/USDs as you want at a time, but since it checks every DAT for each TPL until it finds it, I suggest not have multiple of both, i.e. just one DAT and multiple TPLs or one TPL and multiple DATs. Otherwise you waste time looking for TPLs in DATs they aren't in.

http://www.mediafire.com/download/w0056p181lg4uqa/Texture_Finder.zip

I'm hoping a tutorial is not needed, it's pretty simple.

Awesome! Is it designed for non-paletted textures too? Do you plan to post the source code? I'd be interested to check it out and see what else can be done with it.

So far I just tried it with Dr. Mario's black costume and MnSlChr. But after I click Find Texture(s), nothing happens. I also tried a _14 texture, but got an error. It was Falcon's Helmet insignia (texture 28 in Steelia's texture pack) with PICaNr, which output this in the log:

Spoiler

Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\Kevin\Python33\lib\tkinter\__init__.py", line 1489, in __call__
File "Texture Finder.pyw", line 265, in findAll
File "Texture Finder.pyw", line 305, in find
File "Texture Finder.pyw", line 48, in TPL
ValueError: read length must be positive or -1

 

[CeLL]

Awesome! Is it designed for non-paletted textures too? Do you plan to post the source code? I'd be interested to check it out and see what else can be done with it.

So far I just tried it with Dr. Mario's black costume and MnSlChr. But after I click Find Texture(s), nothing happens. I also tried a _14 texture, but got an error. It was Falcon's Helmet insignia (texture 28 in Steelia's texture pack) with PICaNr, which output this in the log:

Spoiler

Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Users\Kevin\Python33\lib\tkinter\__init__.py", line 1489, in __call__
File "Texture Finder.pyw", line 265, in findAll
File "Texture Finder.pyw", line 305, in find
File "Texture Finder.pyw", line 48, in TPL
ValueError: read length must be positive or -1

I actually have buttons commented out in the source for switching between palette and no palette, but I have no idea what the difference would be, if any, on finding them. The error you got was the attempt to read the palette data, which it calculated to be either negative or 0, since it doesn't have a palette.

About Doc, that's odd, when I just now dumped Doc's black CSP in Dolphin and converted it with your converter, then put the TPL and an MnSlChr.usd in, I got the offset fine. When you click find textures, it separates the text fields into lines, then checks if each location is a file, and removes any that aren't, then removes duplicates, then checks that both of the resulting lists have content. If one of them is empty, it does nothing. I'd imagine that was the issue. I'll add a message saying that instead of doing nothing and update the download.

 

[DRGN]

I actually have buttons commented out in the source for switching between palette and no palette, but I have no idea what the difference would be, if any, on finding them. The error you got was the attempt to read the palette data, which it calculated to be either negative or 0, since it doesn't have a palette.

About Doc, that's odd, when I just now dumped Doc's black CSP in Dolphin and converted it with your converter, then put the TPL and an MnSlChr.usd in, I got the offset fine. When you click find textures, it separates the text fields into lines, then checks if each location is a file, and removes any that aren't, then removes duplicates, then checks that both of the resulting lists have content. If one of them is empty, it does nothing. I'd imagine that was the issue. I'll add a message saying that instead of doing nothing and update the download.

The Doc that I tried was from Steelia's MnSlChr pack. It was a tga, so I converted it to a png first, then to a tpl. Seems strange that that didn't work. I just now tried again, but with Doc dumped from Dolphin (as png) and converted to a tpl, and it worked. (So nice work!) As you probably know, Dolphin doesn't preserve the palette, so I don't know why a difference would've been created between the two. There was a valid path in both text fields when I tried it before.

And I still get the error doing the non-paletted texture too (I don't know if you're planning on making it work for those).

Btw, the download still says "Texture Finder 1.00". Also, it seems you're importing all of your libraries into the build, which is why the program as a whole is 78 MB+. You only need to import modules that you're specifically calling in your code (such as tkinter or PIL). This or this might help.

 

[CeLL]

The Doc that I tried was from Steelia's MnSlChr pack. It was a tga, so I converted it to a png first, then to a tpl. Seems strange that that didn't work. I just now tried again, but with Doc dumped from Dolphin (as png) and converted to a tpl, and it worked. (So nice work!) As you probably know, Dolphin doesn't preserve the palette, so I don't know why a difference would've been created between the two. There was a valid path in both text fields when I tried it before.

And I still get the error doing the non-paletted texture too (I don't know if you're planning on making it work for those).

Btw, the download still says "Texture Finder 1.00". Also, it seems you're importing all of your libraries into the build, which is why the program as a whole is 78 MB+. You only need to import modules that you're specifically calling in your code (such as tkinter or PIL). This or this might help.

Oh yeah I was lazy and just copied all the imports from a different project lol (it's Smash related but secret for now). Forgot to take some out. I'm pretty sure that like 3/4 of the download was the numpy module xD Fixed.

Smashboards was updating the text but keeping the same hyperlink lol, fixed.

Idk if it's any different for other types, and Idk how their TPLs are structured. Especially CMPR's, don't they have several palettes?

 

[Achilles1515]

Oh yeah I was lazy and just copied all the imports from a different project lol (it's Smash related but secret for now). Forgot to take some out. I'm pretty sure that like 3/4 of the download was the numpy module xD Fixed.

Smashboards was updating the text but keeping the same hyperlink lol, fixed.

Idk if it's any different for other types, and Idk how their TPLs are structured. Especially CMPR's, don't they have several palettes?

Cell, this is a fantastic tool. I'm jealous of your guys' ability to make standalone programs. I wanted to use your program to find the offset of this CMPR image:

(poison mushroom when you go to the Item Switch menu)

so I can change it to Steelia's purple poison mushroom, but then I saw your note about the program only working for palette images and then I got sad.

Keep up the good work!

And I know you've probably seen this, but here is what Steelia posted about searching for CMPR offsets:

"Likewise, when a _14 file is converted, it will not match up 100% with its DAT counterpart, but it will be much, much closer than a _8 or _9. What I do is I take small snippets of hex from the TPL (around 4~8 bits), and try to match it up to anything in the DAT.

Using the _14 file you supplied, here are the first 3 lines:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
00 04 40 02 00 00 55 aa 00 04 40 02 00 00 55 aa
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

And here are what the first 3 lines of the actual offset look like:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
60 01 00 04 55 55 aa ff 60 01 00 04 55 55 aa ff
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

Note how the 1st and 3rd lines match up with one another perfectly, but the 2nd lines differ very slightly, enough to where you wouldn't be able to find a match if you tried searching using that hex."

 

[CeLL]

Cell, this is a fantastic tool. I'm jealous of your guys' ability to make standalone programs. I wanted to use your program to find the offset of this CMPR image:

View attachment 37251

(poison mushroom when you go to the Item Switch menu)

so I can change it to Steelia's purple poison mushroom, but then I saw your note about the program only working for palette images and then I got sad.

Keep up the good work!

And I know you've probably seen this, but here is what Steelia posted about searching for CMPR offsets:

"Likewise, when a _14 file is converted, it will not match up 100% with its DAT counterpart, but it will be much, much closer than a _8 or _9. What I do is I take small snippets of hex from the TPL (around 4~8 bits), and try to match it up to anything in the DAT.

Using the _14 file you supplied, here are the first 3 lines:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
00 04 40 02 00 00 55 aa 00 04 40 02 00 00 55 aa
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

And here are what the first 3 lines of the actual offset look like:

00 02 00 00 55 55 55 aa 00 02 00 00 55 55 55 aa
60 01 00 04 55 55 aa ff 60 01 00 04 55 55 aa ff
00 04 00 00 55 f5 a5 ab 00 04 00 00 55 55 55 ab

Note how the 1st and 3rd lines match up with one another perfectly, but the 2nd lines differ very slightly, enough to where you wouldn't be able to find a match if you tried searching using that hex."

What file is that CMPR in?

Edit: nevermind, I tried it with some Fox textures and doing the same thing definitely doesn't find CMPR's.

 

[Achilles1515]

What file is that CMPR in?

Not sure! Possibly MnSlChr.

 

[CeLL]

I tried something with CMPRs and it didn't work, but I realized I might be reading the TPL wrong. I'm assuming from looking at them that the 4-byte value at 0x1C is the offset of the start of the image data.

Edit: Also in doing that I realized that it might not find some CI4's but I think I fixed that now. Also, it's telling me that stock icons are in MnSlChr.usd, as well as IfAll.usd. When I made Fox's stock icon transparent to test the offset in IfAll.usd, it appeared (or rather, didn't) as transparent in a match, but on the victory screen it was still like normal.

Also like I mentioned before this process cannot find the palette, and I think that is why it doesn't work for CMPRs. Since according to http://wiki.tockdom.com/wiki/TPL_(File_Format)#Image they have many palettes. Perhaps if I knew how to separate the palette from the image data in each "block" it would work.

 

[DRGN]

Oh yeah I was lazy and just copied all the imports from a different project lol (it's Smash related but secret for now). Forgot to take some out. I'm pretty sure that like 3/4 of the download was the numpy module xD Fixed.

Smashboards was updating the text but keeping the same hyperlink lol, fixed.

Idk if it's any different for other types, and Idk how their TPLs are structured. Especially CMPR's, don't they have several palettes?

lol yeah, it was mostly numpy.
And yeah, I forgot just how strange CMPR is. It has lots of miniature palettes; a palette for each pixel group. I don't actually know why Dolphin needs to regenerate palettes in the first place, but if it's going to do it for _9, it makes sense it would do it for the small ones in _14 too. But I don't know why the image data isn't different too, since, like in the case of _9 textures, the image data is just referencing the palette. So a different palette would mean the image data would have to point to different indices, meaning the image data would have different values. Unless... do the data portions of CMPRs always point to the same indices (and the colors there just change) for any texture? Anyway, if what Steelia posted is consisntent, then we would just need a function that matches the image data block section, then skips the palettes, then matches the following section, etc. I also just had an idea of a way to make the searches even more efficient, but I'll have to explain later as I'm about out of time atm.

I tried something with CMPRs and it didn't work, but I realized I might be reading the TPL wrong. I'm assuming from looking at them that the 4-byte value at 0x1C is the offset of the start of the image data.

Edit: Also in doing that I realized that it might not find some CI4's but I think I fixed that now. Also, it's telling me that stock icons are in MnSlChr.usd, as well as IfAll.usd. When I made Fox's stock icon transparent to test the offset in IfAll.usd, it appeared (or rather, didn't) as transparent in a match, but on the victory screen it was still like normal.

Also like I mentioned before this process cannot find the palette, and I think that is why it doesn't work for CMPRs. Since according to http://wiki.tockdom.com/wiki/TPL_(File_Format)#Image they have many palettes. Perhaps if I knew how to separate the palette from the image data in each "block" it would work.

Yeah, 1C should be the start of the image data. It can technically change if there are multiple images in the file, but I don't think Dolphin would dump a multi-image file. I haven't seen one before.

That kinda sucks about there being multiple stock icons. Since it means if we want custom ones to match our costumes we'd have to have two sets. Unless they're the same of course, but then why would there be two sets? Are they different in some way?

 

[CeLL]

I automated the manual copy - find process for finding textures without palettes. It's really fast, not like the other search.

 

[Achilles1515]

I automated the manual copy - find process for finding textures without palettes. It's really fast, not like the other search.

But is it really accurate?

 

[CeLL]

But is it really accurate?

It just searches the DAT for the exact image data in the TPL and returns the offset, like copying it and using find in a hex editor. It's a built in function that I bet is actually written in C. The other function basically makes a map of the pixels and then drops the actual pixels. So like it says that the 1st pixel is the same as the 3rd, 8th, 126th, etc.. Much harder on the processor than comparing two bytes several times. That's why it's so much faster. Obviously won't work for anything you can't just copy and search in a hex editor to find, but now you can do it with less effort/do it with multiple DATs/TPLs at the same time.