• Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!

    You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!

Official DAT Texture Wizard (current version: 6.1.4)

Starreaver1

Smash Apprentice
Joined
Oct 12, 2013
Messages
132
Location
Minneapolis, MN/Princeton, NJ
Ahhh it was just me being an idiot. I'm not familiar enough with texture editing, I had copy pasted the ENTIRE tpl into the dat. I skipped the header (the first three lines?) and copied the rest and it worked perfectly. Thanks so much for the scripts and guides, DRGN!
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
First off, I want to say that an update to the TPL Overwriter is in the works. I actually finished some big improvements to it a few weeks ago (yet couldn't release it because it still needs some small stuff finished), but I learned some new things about Melee that made me really want to work on my main project for a bit. Hopefully in the next week or so I'll have the update released.

How to Replace the CSS Closed Port Texture

1) Modify this image:

View attachment 28309

*Anything in the transparent area will not show up correctly on the CSS and the image will be displayed as black and white (so make your image in grayscale).


2) Use the PNG to-from TPL tool to create a TPL of your modified image.
  • This image is a "_3" type.

3) Use the TPL Overwriter to insert the image into the MnSlChr.usd file.
  • Placement is 0x2F760.
  • Alternatively to using the program, open the TPL in a hex editor and copy from 0x40 onward and paste at the above address in MnSlChr.usd.
I noticed a while ago that your original texture ID for this is different than my original (yours = _624092e7, while mine = _72e9b203). I tried dumping the texture from v1.00, 1.01, and 1.02, and got the same ID every time. I was starting to think it was a change the Dolphin developers had made in the hash generation at some point (and that we probably had different versions of Dolphin). But I just had another thought; the graphics backend (API). I always use Direct3D11. I changed it to Direct3D9, and bam! There was your ID for that texture. So is that what you use, Direct3D9? And what version of Dolphin do you use?


My interest in this is with the concept of "placements" files. Obviously we want them to be universal, so if one person makes one, everyone after that for those textures can use it. We could have one for each .dat or .usd in the game. As the library of these becomes more complete, I don't see why it all couldn't just be included in with my programs. Then it wouldn't even be necessary to have to find out what offsets different textures use; the program would just know already, so as soon as you've selected the texture(s), it sets and shows you the offset(s) it suggests to use to overwrite them into the DAT or USD. I've even thought about a program that could first go through the DATs/USDs and locate textures, specifically to generate placements files. However I was worried about all of this when I saw textures with different hashes (the texture ID or "texID"). If the graphics API and the specific texture are the only two factors for the texture ID, then I don't think it would ultimately be too bad. It would only mean writing a placements line with a few more IDs in it, such as "_624092e7 - _72e9b203 - 2F760" for the closed port texture.

The only alternative I can think of for this is still the folder ID method that Steelia made. As described in the OP, those folder structures can also be used by the overwriter program (i.e. when using the 'Scan folder structure' method, it will scan the placements file for folder IDs rather than using a texID from the file name. And will attempt both ways if it can't find an offset using the first type of ID). But I think using texIDs is ideal, since the application is more "self-contained", if that makes sense. Meaning you don't need any special set-up; you only need the file. It also makes more sense for non-character work, where you don't need every associated texture and might not want to go online to find/download the whole texture pack. Also, having all of the textures not in individual folders makes it easy to drag-and-drop each of the specific textures you want to work with at once to one of the programs here. So far I've been trying to include support for either of these methods for identifying the textures. For example, another placements file line would be "_624092e7 - _72e9b203 - 2F760 - 46", where the 46 (an arbitrary number in this case) would be the first two characters of the folder that the closed port texture would be sitting in. (And remember, each of those items on the line can appear in any order. But standardizing would be nice.) Then the full folder name would be "46 Outer Closed Port Panels" or something like that, so it's also clear to people browsing through the folders of what is what.

Well that's the gist of it. I just thought I'd explain in case anyone might have any thoughts or better ideas on the matter (or just enjoys reading walls of text).
 

Starreaver1

Smash Apprentice
Joined
Oct 12, 2013
Messages
132
Location
Minneapolis, MN/Princeton, NJ
If it matters DRGN, I got the exact same thing as you (_624092e7) using OpenGL and Dolphin 4.0-720-dirty (compiled from source code run in debug mode). Idk why it's labeled that at the top lol. But basically Dolphin 4.0 I guess?
Also I love reading walls of text at 5 in the morning (I'm in NJ now not MN, should probably change that).
 

Koopa|o.O

Smash Cadet
Joined
Mar 25, 2013
Messages
53
as someone semi newer to texture hacking, im glad to see an easier way to do this type of thing. The older ways are a lot more confusing which is why i gave up trying out stage hacking..good stuff
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Yo, I have a question.
@Brandondorf9999
Thanks for pointing out the bug. I've fixed it and uploaded an updated version.
(Also added an error message in case it can't find an image type for a given file.)

I don't know what the offsets are for the textures in EfCaData.dat, but I can tell you how to find them:

1) dump the texture as PNG using Dolphin
2) convert unmodified PNGs to TPL using the PNG to-from TPL script. So you'll
essentially have the "original" TPL data.
3) open the TPL in a hex editor, such as HxD
4) starting at offset 0x40, copy the contents of the file (so you'll be copying all but the first few lines) to your clipboard
5) open up an unmodified version of the .dat file that the texture should be in (open it also in the hex editor)
6) run a search (ctrl + F) in the .dat, using the data you copied from the .tpl
(If you're using HxD, you'll need to change the datatype for the search to "Hex-values".)

If you get a match, you should be able to see where the match starts, which is the offset you need.
If you don't get a match, your princess image might be in another castle file.
I've done this to change multiple stuff so far, but I've come across a problem. I'm currently editing the SSS (MnSlMap.usd/dat) and I can't find any reference to this:

(GALE01_2b2bd9fb_9.tpl)

I've got the same problem with several images on the SSS. They all end with _9.

To what I understand files ending in _9 have palette data, could this interfere with your method of finding their offset?
Btw, I've also tried searching in all menu related .dat/.usds without finding it so I must be doing something wrong.

Thanks in advance.
 
Last edited:

Achilles1515

Smash Master
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
Yo, I have a question.

I've done this to change multiple stuff so far, but I've come across a problem. I'm currently editing the SSS (MnSlChr.usd/dat) and I can't find any reference to this:
i.imgur.com/xQDfJ5i.png
(GALE01_2b2bd9fb_9.tpl)

I've got the same problem with several images on the SSS. They all end with _9.

To what I understand files ending in _9 have palette data, could this interfere with your method of finding their offset?
Btw, I've also tried searching in all menu related .dat/.usds without finding it so I must be doing something wrong.

Thanks in advance.
Steelia already has these offsets (in MnSlMap) mapped out.

Code:
{All palettes are 32 lines}

01 - 0000e2c0  ~Princess Peach's Castle
02 - 0000f2e0  ~Rainbow Cruise
03 - 00010300  ~Kongo Jungle
04 - 00011320  ~Jungle Japes
05 - 00012340  ~Termina Bay
06 - 00013360  ~Hyrule Temple
07 - 00014380  ~Brinstar
08 - 000153a0  ~Brinstar Depths
09 - 000163c0  ~Yoshi's Story
10 - 000173e0  ~Yoshi's Island
11 - 00018400  ~Fountain of Dreams
12 - 00019420  ~Green Greens
13 - 0001a440  ~Corneria
14 - 0001b460  ~Venom
15 - 0001c480  ~Pokemon Stadium
16 - 0001d4a0  ~Pokefloats
17 - 0001e4c0  ~Mute City
18 - 0001f4e0  ~Big Blue
19 - 00020500  ~Onett
20 - 00021520  ~Fourside
21 - 00022540  ~Mushroom Kingdom I
22 - 00023560  ~Mushroom Kingdom II (Subcon)
23 - 00024580  ~Icicle Mountain
24 - 000255a0  ~Flat Zone
25 - 000265c0  ~Battlefield
26 - 000275e0  ~Final Destination
27 - 00028600  ~Past Stages: Dream Land
28 - 00029120  ~Past Stages: Yoshi's Island
29 - 00029c40  ~Past Stages: Kongo Jungle
 

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Steelia already has these offsets (in MnSlMap) mapped out.

Code:
{All palettes are 32 lines}

01 - 0000e2c0  ~Princess Peach's Castle
02 - 0000f2e0  ~Rainbow Cruise
03 - 00010300  ~Kongo Jungle
04 - 00011320  ~Jungle Japes
05 - 00012340  ~Termina Bay
06 - 00013360  ~Hyrule Temple
07 - 00014380  ~Brinstar
08 - 000153a0  ~Brinstar Depths
09 - 000163c0  ~Yoshi's Story
10 - 000173e0  ~Yoshi's Island
11 - 00018400  ~Fountain of Dreams
12 - 00019420  ~Green Greens
13 - 0001a440  ~Corneria
14 - 0001b460  ~Venom
15 - 0001c480  ~Pokemon Stadium
16 - 0001d4a0  ~Pokefloats
17 - 0001e4c0  ~Mute City
18 - 0001f4e0  ~Big Blue
19 - 00020500  ~Onett
20 - 00021520  ~Fourside
21 - 00022540  ~Mushroom Kingdom I
22 - 00023560  ~Mushroom Kingdom II (Subcon)
23 - 00024580  ~Icicle Mountain
24 - 000255a0  ~Flat Zone
25 - 000265c0  ~Battlefield
26 - 000275e0  ~Final Destination
27 - 00028600  ~Past Stages: Dream Land
28 - 00029120  ~Past Stages: Yoshi's Island
29 - 00029c40  ~Past Stages: Kongo Jungle
Awesome, I'd still like to learn what I did wrong so I know in the future in case I come across something like this again.
 

Achilles1515

Smash Master
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
Awesome, I'd still like to learn what I did wrong so I know in the future in case I come across something like this again.
You can't use the PNG-to-TPL for palette images to give you the exact hex values used in the vanilla files. It has to deal with the way that DRGN's program dithers colors to create a palette with an exact amount of values. and maybe some other things. And palettes can be rearranged and pointed to in different ways from the image values and still produce the same end result.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
What happens is that when Dolphin dumps the texture, it doesn't preserve the original palette. It creates the image as full RGB, non-indexed.

So when you convert the texture using the script, a brand new palette needs to be created. And the image data is also different because it is entirely based on the makeup of the palette. So both the image data and palette data will be different than what the game has.

I'll update my old post to specify that that method only works with non-paletted images. Thanks for pointing that out though. At least that means you weren't doing anything wrong with those ones, and you figured out where the issue was coming from. :p
 
Last edited:

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
The Big Update!


Mostly for the overwriter program. Check out the change log:

Version 2.0:
- Changed the name of the program from TPL Overwriter to DAT Texture Wizard
- Added support for textures with palettes (all types now supported)
- Can select PNG images as well as TPLs for overwrites (includes automatic conversion)
- Automatically hexes magenta and lime green palette colors to transparent and 'shadow', respectively
- Line highlighting for successful/failed overwrites
- Ability to scan for offsets at any time, including AFTER all files have already been selected
- Remembers last used search directory (per session)
- Drag-and-drop file opening feature now sets the default search directory
- Ability to overwrite a texture into multiple locations (e.g. '..._3.png --> 123ab, 456df')
- Added true support for .usd files
- Now will only keep a backup of the dat/usd file if a change is actually made from the original
- Will accept filepaths in double quotes, and offsets may optionally include the preceding "0x"
- Can now also be installed to the Windows right-click context menu (super handy)
- Removed the 'Clear' button (since you can easily do the same thing with Ctrl + A, Delete anyway)
- Bunch of code optimization
- Added an improved user guide in the download, in the 'User Guide & Info.txt' file
- PNG to-from TPL.bat now included in the download (since it's only a 6 KB addition)

I've also added some minor changes to PNG to-from TPL. And I finally created a MediaFire account for a mirror (just for you, achilles ;)). Downloads for everything in the OP.

I'd also like to get around to making a new guide for texture hacking that uses these programs. Should make things a whole lot easier (and faster) for folks!

Happy hacking. ^_^
 

Achilles1515

Smash Master
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
- Added support for textures with palettes (all types now supported)
- Can select PNG images as well as TPLs for overwrites (includes automatic conversion)
- Automatically hexes magenta and lime green palette colors to transparent and 'shadow', respectively

These. Amazing, work. I had that exact thought for the magenta and lime green auto replacement just yesterday but did not get around to posting it. I'm glad you read my mind!

For clarification, those values are:
Magneta - 0xFF00FF
Green - 0x00FF00

Right? I haven't opened the program up or anything yet, but did you explicitly state these hex values in there so that people know exactly what to use? And is there a check box or something for enabling this auto replacement feature or does it always happen?

Do you have any placement offsets built into the program (aka no need for an external offset txt file or manually having to input the offset)?
What I'm picturing is a directory of filenames, and then you can click on a filename and it will show all the known image offsets for that file and ideally, a little preview of that default image that is clicked on. I guess it would also be cool if it housed the original file, so you could choose to extract that and edit it, without having to dump textures yourself (like ones not in Steelia's packs).
But yeah, then you could load your file into the program, load your edited image (with image preview), just click on the image in the directory that your edited one is replacing, and then click overwrite.

And I guess if you loaded a file, the image offset directory for that file would automatically pop-up. And a search function for the entire image offset directory? So anyone could load it up and think "hmmm..what about Falcon Punch?" *types Falcon Punch*, "Aha! Three textures for Falcon Punch, I see. Let me edit these real quick...."

I'm just thinking/typing out loud about this, and I figure I'd get my thoughts out. Program size may be an issue if you added in tons of default images, but I wouldn't care because it would be hella cool.

This program is amazingly useful already!

Last question - Can this program handle palette images whose image pixel info and palette info are separated in the dat (so not one right after the other)? I remember doing a, I believe, Dr. Mario conversion a few years back, and it was a weird format where a group of pixel info was stored consecutively for a few images (eyes and little **** I think), and then the palette info came consecutively in the same order right after. Just curious.

I've also added some minor changes to PNG to-from TPL. And I finally created a MediaFire account for a mirror (just for you, achilles ;)).
Hehe, I appreciate it!

 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Hmm, I've got another issue, lol.

The messed up parts are supposed to be grayscaled versions of the vanilla with a red cross overlay. I'm guessing the palette data isn't stored within the .tpl files but in the actual .dat/usd?
How would I go about fixing this?

EDIT: Also, does anyone have the offsets for the two background images? I can't seem to find those.
GALE01_2b17b3eb_8
GALE01_015152cd_14
 
Last edited:

Starreaver1

Smash Apprentice
Joined
Oct 12, 2013
Messages
132
Location
Minneapolis, MN/Princeton, NJ
I've actually never used the overwriter because I couldn't figure out how to use it (very bad with these things ):< ) but I will definitely looking to figure it out and use this now that I've gotten more into texture hacking!
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
For clarification, those values are:
Magneta - 0xFF00FF
Green - 0x00FF00

Right? I haven't opened the program up or anything yet, but did you explicitly state these hex values in there so that people know exactly what to use? And is there a check box or something for enabling this auto replacement feature or does it always happen?
Yep. And yeah, it's stated in the guide. And yeah, it's automatic, but only for when those colors appear in palettes of course, and won't do anything to them in non-paletted images. I doubt those colors would occur in other places, but I could always add a toggle just in case.
Do you have any placement offsets built into the program (aka no need for an external offset txt file or manually having to input the offset)?
Nope. But it's easily doable. We just need to start creating these placements files. I think one per DAT/USD would be a good rate as we slowly go through the iso.
What I'm picturing is a directory of filenames, and then you can click on a filename and it will show all the known image offsets for that file and ideally, a little preview of that default image that is clicked on. I guess it would also be cool if it housed the original file, so you could choose to extract that and edit it, without having to dump textures yourself (like ones not in Steelia's packs).
But yeah, then you could load your file into the program, load your edited image (with image preview), just click on the image in the directory that your edited one is replacing, and then click overwrite.
I was planning on doing image previews. In fact there are already unused functions sitting in there for it. But before really getting into the imaging modules, I want to port the program from python 3.4 to 2.7, which has better support some things. I'd have to rewrite more if I do it the other way around. Definitely giving me some good ideas though.
And I guess if you loaded a file, the image offset directory for that file would automatically pop-up. And a search function for the entire image offset directory? So anyone could load it up and think "hmmm..what about Falcon Punch?" *types Falcon Punch*, "Aha! Three textures for Falcon Punch, I see. Let me edit these real quick...."

I'm just thinking/typing out loud about this, and I figure I'd get my thoughts out.
That would be cool. We'd have to manually create such a directory of offsets with tags though. I suppose it could be incorporated into the placements files.
Program size may be an issue if you added in tons of default images, but I wouldn't care because it would be hella cool.
The image library could be a separate optional download.
Last question - Can this program handle palette images whose image pixel info and palette info are separated in the dat (so not one right after the other)? I remember doing a, I believe, Dr. Mario conversion a few years back, and it was a weird format where a group of pixel info was stored consecutively for a few images (eyes and little **** I think), and then the palette info came consecutively in the same order right after. Just curious.
Yeah, it does, but you need to know the palette offset, just like the image data offset.
Hmm, I've got another issue, lol.
The messed up parts are supposed to be grayscaled versions of the vanilla with a red cross overlay. I'm guessing the palette data isn't stored within the .tpl files but in the actual .dat/usd?
How would I go about fixing this?

EDIT: Also, does anyone have the offsets for the two background images? I can't seem to find those.
GALE01_2b17b3eb_8
GALE01_015152cd_14
What was your process? Also, seeing one of your tpls would probably help.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
I dumped the images from Dolphin > Edited > your png-to-tpl.bat > DAT Texture Wizard'd into MnSlMap.usd (With Steelias offsets that Achilles pasted for me earlier).
http://www.mediafire.com/download/tt4x5oyiqckcfrm/GALE01_2b2bd9fb_9.tpl
(Edited Corneria icon)
Well that's weird. I just looked at the texture, and I couldn't find anything wrong with it. So finally I opened up DAT Texture Wizard, tried inserting it (at offset 0001a440), and it worked just fine.

So my theory is that you have something else, another texture most likely, in your MnSlMap.usd that is throwing the whole thing off. Some kind of misalignment that is causing all of the offsets to be off. Try taking a fresh MnSlMap.usd that you know is fully original, and try inserting only a few at a time (perhaps try Corneria first to establish at least one common thing that is known working).
 

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Well that's weird. I just looked at the texture, and I couldn't find anything wrong with it. So finally I opened up DAT Texture Wizard, tried inserting it (at offset 0001a440), and it worked just fine.

So my theory is that you have something else, another texture most likely, in your MnSlMap.usd that is throwing the whole thing off. Some kind of misalignment that is causing all of the offsets to be off. Try taking a fresh MnSlMap.usd that you know is fully original, and try inserting only a few at a time (perhaps try Corneria first to establish at least one common thing that is known working).
Okay, this is strange... I extracted a MnSlMap.usd from a vanilla 1.02 ISO and just inserted Corneria. (0001a440 - _2b2bd9fb) Still the same error...

Obviously I'm messing up somewhere, but I have no clue to where nor how.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
Well dang. That's really weird. Do you know how to hex it manually? You could try that. Copy from 160 to the end of the tpl file that you uploaded, and paste-overwrite (not regular paste, which would make the file larger) that data into the offset location at 1a440 in MnSlMap.usd, then go back to the tpl file, and copy from 20 to 12C (not including 12C). Now paste that into the offset in MnSlMap.usd directly after the data you just wrote in before (the cursor should already be at the right spot).

Or, someone else could try this exact same hack using the .tpl you posted above.

Has anyone else had success or failures with the program?
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Well dang. That's really weird. Do you know how to hex it manually? You could try that. Copy from 160 to the end of the tpl file that you uploaded, and paste-overwrite (not regular paste, which would make the file larger) that data into the offset location at 1a440 in MnSlMap.usd, then go back to the tpl file, and copy from 20 to 12C (not including 12C). Now paste that into the offset in MnSlMap.usd directly after the data you just wrote in before (the cursor should already be at the right spot).

Or, someone else could try this exact same hack using the .tpl you posted above.

Has anyone else had success or failures with the program?
Uhm, **** gets weirder... Did this, same result. I'm so confused right now. Why is it not working, lmao.


EDIT: Since we both had the same .tpl I guess it must be my MnSlMap.usd file?

Also, could you do a step-by-step tutorial for dummies regarding how to retexture the whole character port overlay? :p

EDIT2: Could you provide your MnSlMap.usd so I can test if mine was the issue?
 
Last edited:

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
Your attention, please.

I've uploaded a new version of DAT Texture Wizard with a fix for a bug that affected some CSPs, where in some rare situations magenta or lime green (the 'replacement' colors used to insert transparency and the character shadow) would not be replaced.

That is all. Please return to your daily activities.


Uhm, **** gets weirder... Did this, same result. I'm so confused right now. Why is it not working, lmao.


EDIT: Since we both had the same .tpl I guess it must be my MnSlMap.usd file?

Also, could you do a step-by-step tutorial for dummies regarding how to retexture the whole character port overlay? :p

EDIT2: Could you provide your MnSlMap.usd so I can test if mine was the issue?
Sure, here you go: MnSlMap (original).usd | MnSlMap (hacked).usd

You mean for CSPs? Yeah, I've been thinking I might do one, but I just have several other things I'm working on atm. I'd like to do one though. I have a few tricks I think would be helpful.
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Your attention, please.

I've uploaded a new version of DAT Texture Wizard with a fix for a bug that affected some CSPs, where in some rare situations magenta or lime green (the 'replacement' colors used to insert transparency and the character shadow) would not be replaced.

That is all. Please return to your daily activities.




Sure, here you go: MnSlMap (original).usd | MnSlMap (hacked).usd

You mean for CSPs? Yeah, I've been thinking I might do one, but I just have several other things I'm working on atm. I'd like to do one though. I have a few tricks I think would be helpful.
I actually meant the closed port before you select a character, but both would be helpful!

Also, I really appreciate your hard work on these things. :)

Daily activities resumed.


EDIT: To be extra clear, this is what I meant.
I don't think I've ever seen hacks done on the other panel. Have they not been done before? If not, I understand why now. haha

Anyway, I've done this:



I can explain this and the fix to CeLL's problem tomorrow. But right now it's past 5 AM where I am, so please excuse me while I go get some sleep. lol :p
 
Last edited:

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
I actually meant the closed port before you select a character, but both would be helpful!

Also, I really appreciate your hard work on these things. :)

Daily activities resumed.


EDIT: To be extra clear, this is what I meant.
Oh, I thought you might still be working on your other hack. :p

Did you see the short guide I posted a bit after that? It's hiding in a spoiler tag titled "Creating CSS panels in GIMP". If you looked at that, let me know which part isn't clear out you get stuck on.

Also, note that the in-game design of the ports is slightly off. If you look at a vanilla Melee, you can see that the right panel is slightly up and to the right by 1px each (notice that the horizontal band through the middle shifts upward on the right side). What this means is that any designs that overlaps the two halves will appear slightly distorted at the point where the panels meet. It's really tough to get rid of by adjusting the texture alone. Just something to keep in mind if anyone is thinking of hacking both sides.
 

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
I think I kinda found out why it's messing up. I went to 0001a440 and there are different lines there between your MnSlMap (hacked).usd and when I implement it via the DAT Texture Wizard.

I copied the first line from there and searched for it in my Corneria icon .tpl file and I couldn't find it... You sure you didn't do anything to the .tpl that I sent you? o.o

I'm so confused.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
Yeah, that's pretty weird. I hacked it the same way you did to test. And no, I didn't change it.
I copied the first line from there and searched for it in my Corneria icon .tpl file and I couldn't find it...
From your MnSlMap, or mine?

Is your original file the same as mine? And do my files work if you import them into your iso?
 

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Yeah, that's pretty weird. I hacked it the same way you did to test. And no, I didn't change it.


From your MnSlMap, or mine?

Is your original file the same as mine? And do my files work if you import them into your iso?
I used your "original" and when I import it, it doesn't work. But the one you sent me the (hacked) version works. That's what I used to test. And at the same offset there are different values, so it doesn't make any sense. My .tpl doesn't have the values that your file had at 0001a440.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
I used your "original" and when I import it, it doesn't work. But the one you sent me the (hacked) version works. That's what I used to test. And at the same offset there are different values, so it doesn't make any sense. My .tpl doesn't have the values that your file had at 0001a440.
Ha! Holy crap I figured it out.

You weren't actually doing anything wrong, AND it wasn't a bug with either of the programs!

It's because those stage icons use a different kind of encoding for their palettes than other _9 textures. I already knew that these different kinds existed, but I hadn't seen them or tried to hack them before, so I didn't recognize that these were that kind. I didn't even think about it at first. But I did plan for them when I wrote both PNG to-from TPL and DAT Texture Wizard. But there's a big difference in how these two programs deal with the difference. First let me explain that the difference between the two types of _9 palettes (there's technically 3 possible kinds, but afaik only 2 are used in Melee) is whether or not they use transparency. For example, CSPs are _9 and obviously use transparency. However these stage icons have no need for it. So, back to my story.... Batch (what PNG to-from TPL is written in), is not a great language to say the least, and it doesn't have a [reasonable] way to read files (besides like text files). Meaning the script can't check the image to see whether or not it has transparency (DAT Texture Wizard can, because it's written in Python). So instead I made that an option within the script, a toggle. If you open PNG to-from TPL in a standard text editor, you'll see some instructions and a few options you can change. One of them is called "sourceHasTransparency". The default option is "yes", because those are more common, especially considering CSP hacking popularity. If you change that to no, then, you guessed it, your TPLs will have the correct encoding and will work. But you also have an easier way to do your hack.

Since as I mentioned, DAT Texture Wizard is written in Python, it can read file binary and can check for transparency in png images (I have a function that can find the usage of transparency even if the image doesn't have an alpha channel). Meaning it doesn't need a toggle option for the user and will just work. If you give it your edited PNGs and MnSlChr.usd, it works. No need to convert with PNG to-from TPL unless you actually just want your TPL files (just don't forget the option). The only reason it didn't work with your TPLs is because by that point they were already converted with the wrong encoding. I thought I gave DTW your TPL, but I must have converted it to a PNG first (so I could open it in gimp to look at some things) and gave it that instead, and that's why it worked for me. *facepalm* And the sourceHasTransparency option is only needed for going from PNG to TPL, not from TPL to PNG, so again, wasn't an issue for me. Haha. Ridiculous. I'm just glad this was solved. I was just as confused as you were, lol.
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
Ha! Holy crap I figured it out.

You weren't actually doing anything wrong, AND it wasn't a bug with either of the programs!

It's because those stage icons use a different kind of encoding for their palettes than other _9 textures. I already knew that these different kinds existed, but I hadn't seen them or tried to hack them before, so I didn't recognize that these were that kind. I didn't even think about it at first. But I did plan for them when I wrote both PNG to-from TPL and DAT Texture Wizard. But there's a big difference in how these two programs deal with the difference. First let me explain that the difference between the two types of _9 palettes (there's technically 3 possible kinds, but afaik only 2 are used in Melee) is whether or not they use transparency. For example, CSPs are _9 and obviously use transparency. However these stage icons have no need for it. So, back to my story.... Batch (what PNG to-from TPL is written in), is not a great language to say the least, and it doesn't have a [reasonable] way to read files (besides like text files). Meaning the script can't check the image to see whether or not it has transparency (DAT Texture Wizard can, because it's written in Python). So instead I made that an option within the script, a toggle. If you open PNG to-from TPL in a standard text editor, you'll see some instructions and a few options you can change. One of them is called "sourceHasTransparency". The default option is "yes", because those are more common, especially considering CSP hacking popularity. If you change that to no, then, you guessed it, your TPLs will have the correct encoding and will work. But you also have an easier way to do your hack.

Since as I mentioned, DAT Texture Wizard is written in Python, it can read file binary and can check for transparency in png images (I have a function that can find the usage of transparency even if the image doesn't have an alpha channel). Meaning it doesn't need a toggle option for the user and will just work. If you give it your edited PNGs and MnSlChr.usd, it works. No need to convert with PNG to-from TPL unless you actually just want your TPL files (just don't forget the option). The only reason it didn't work with your TPLs is because by that point they were already converted with the wrong encoding. I thought I gave DTW your TPL, but I must have converted it to a PNG first (so I could open it in gimp to look at some things) and gave it that instead, and that's why it worked for me. *facepalm* And the sourceHasTransparency option is only needed for going from PNG to TPL, not from TPL to PNG, so again, wasn't an issue for me. Haha. Ridiculous. I'm just glad this was solved. I was just as confused as you were, lol.
Oh my god, you're my hero, LOL.
Now I can finally get on with the build!


I'm sorry, but I've got more questions to throw at you, hehe.

I'm looking for two images in the SSS, one's the weird background thingy with a lot of jibberish.
http://www.mediafire.com/view/b2zl9yqhqo0l6j9/GALE01_2b17b3eb_8.png#
Since this is a file with a palette (_8), how would I go about finding the offset for this?

The second one is the real background.
http://www.mediafire.com/view/sn9bnt8r418i64c/GALE01_015152cd_14.png#
This ends with _14 so I should be able to find it using 0x40 and on from its .tpl file and then find it within MnSlMap.usd/dat, right?
Apparently, no. I've searched through all of the Mn files, yet I cannot find it in any of them...
Any idea of what I need to do in order to find the offset?
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
I think I've seen those textures around here somewhere before, but I'm actually not at all sure where. Though I have a hunch @Jorgasms might know.

And how do you find images with palettes yourself?
Good question. So far I've only worked with ones with known locations. There are a few paletted textures I'd like to find too, but I've been so busy with other stuff I haven't even tried to look into it yet. But @ Achilles1515 Achilles1515 or @ Steelia Steelia might know some good methods to start.
 
Last edited:

Koopa|o.O

Smash Cadet
Joined
Mar 25, 2013
Messages
53
hey guys quick question.
im working on adding boo into yoshis instead of derm. I got the hand to be transparent, but i need help finding the texture that is pointed out in the picture (the pole) im using the pre organized and numbered grst folder (the one with placements.txt and etc) and dat texture wizard.
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
hey guys quick question.
im working on adding boo into yoshis instead of derm. I got the hand to be transparent, but i need help finding the texture that is pointed out in the picture (the pole) im using the pre organized and numbered grst folder (the one with placements.txt and etc) and dat texture wizard.
Open up Dolphin, go to Options > Graphic Options > Advanced > Dump textures. (May be incorrect names, my Dolphin is in swedish for w/e reason. :p)
Load up Yoshi's Story after you've checked this box.
Then navigate in your explorer to your documents where you'll find the "Dolphin Emulator" folder, here you'll find your dumped textures.
Use DRGNs PNG to-from TPL.bat to convert the poles texture into a .tpl.
Now you need a program called HxD (or another hex editor) and you copy everything after offset 0x40 (the field to the left shows a bunch of zeros (0x) and then the numbers (40).
Now open up Yoshi Storys .dat file in HxD as well and search (Ctrl + F) for what you copied. (You also have to change it from "text values" to "hex values" in the search box)
You'll now see the offset to the left of the window right next to the beginning of your now selected text.
Copy this to your placement.txt and also add the tpl files name except for "GALE01" in the beginning as well as "_X" in the end of the file.
(It should look something like this (Offset) - (tpl/png files name)).

I should note that this will not work on all textures (mainly files ending in _8, _9 etc, files with PALETTES). You should be able to find examples on what doesn't work by looking through the posts in this topic.

I hope this helps you!
 
Last edited:

Steelia

Smash Champion
Joined
Sep 23, 2007
Messages
2,523
Location
Home.
Oh my god, you're my hero, LOL.
Now I can finally get on with the build!


I'm sorry, but I've got more questions to throw at you, hehe.

I'm looking for two images in the SSS, one's the weird background thingy with a lot of jibberish.
http://www.mediafire.com/view/b2zl9yqhqo0l6j9/GALE01_2b17b3eb_8.png#
Since this is a file with a palette (_8), how would I go about finding the offset for this?

The second one is the real background.
http://www.mediafire.com/view/sn9bnt8r418i64c/GALE01_015152cd_14.png#
This ends with _14 so I should be able to find it using 0x40 and on from its .tpl file and then find it within MnSlMap.usd/dat, right?
Apparently, no. I've searched through all of the Mn files, yet I cannot find it in any of them...
Any idea of what I need to do in order to find the offset?
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).
 

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
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).
Holy... That looks like a living hell to find. I mean, these files seem to have thousands of thousands of values, it would take a LONG time to find these.

Anyway, thanks a ton for the offsets, much appreciated.
 

Koopa|o.O

Smash Cadet
Joined
Mar 25, 2013
Messages
53
Open up Dolphin, go to Options > Graphic Options > Advanced > Dump textures. (May be incorrect names, my Dolphin is in swedish for w/e reason. :p)
Load up Yoshi's Story after you've checked this box.
Then navigate in your explorer to your documents where you'll find the "Dolphin Emulator" folder, here you'll find your dumped textures.
Use DRGNs PNG to-from TPL.bat to convert the poles texture into a .tpl.
Now you need a program called HxD (or another hex editor) and you copy everything after offset 0x40 (the field to the left shows a bunch of zeros (0x) and then the numbers (40).
Now open up Yoshi Storys .dat file in HxD as well and search (Ctrl + F) for what you copied. (You also have to change it from "text values" to "hex values" in the search box)
You'll now see the offset to the left of the window right next to the beginning of your now selected text.
Copy this to your placement.txt and also add the tpl files name except for "GALE01" in the beginning as well as "_X" in the end of the file.
(It should look something like this (Offset) - (tpl/png files name)).

I should note that this will not work on all textures (mainly files ending in _8, _9 etc, files with PALETTES). You should be able to find examples on what doesn't work by looking through the posts in this topic.

I hope this helps you!
Thanks man, ill try this out, more questions are probably incoming because im pretty new to this

edit: I think it's a _8 or _9 file, the only texture I found that is close to it is this, and it doesn't really look like it, the offsets weren't found in the yoshis file, i guess ill have to deal with boo holding the pole:
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
@ DRGN DRGN (or another user capable of using GIMP) PLEASE, do this one favor for me. Add the proper alpha channel to this for me. I can't use GIMP, my body simply won't bare it. If I give it another go I might just die.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
@ DRGN DRGN (or another user capable of using GIMP) PLEASE, do this one favor for me. Add the proper alpha channel to this for me. I can't use GIMP, my body simply won't bare it. If I give it another go I might just die.
lol, sure. First of all, I like the design. Nice job.

There are already some bits missing from that image though (creating that line through it). Do you have the full layer without that that I could add alpha to instead?
 
Last edited:

Anutim

Smash Apprentice
Joined
Oct 22, 2013
Messages
185
lol, sure. First of all, I like the design. Nice job.

There are already some bits missing from that image though (creating that line through it). Do you have the full layer without that that I could add alpha to instead?
*****, I'm not sure how that got there, but I assume this ****ty ass **** software GIMP had something to do with it. >_>

Here. I also changed a few other things that I wanted slightly altered.

EDIT: So many stars! Beautiful!

Also, thanks! Really appreciate all the help you've given me. :)
 
Last edited:

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
Hehe, no problem. ^_^ I won't be able to do it until I get home later today though.
 

DRGN

Technowizard
Moderator
Premium
Joined
Aug 20, 2005
Messages
2,175
Location
Sacramento, CA
Here you go!:

Closed-Char-Port--Done_72e9b203_3.png


Unfortunately, the image isn't going to be able to line up perfectly, which is a graphical bug in vanilla Melee. The top-right half is actually misaligned up 1px and to the right 1px (you can see this in the original texture in Melee if you look closely). Compensating for this by graphical editing alone is really difficult (much harder than it seems because the portion in-between the panels is semi-transparent, and appears on both halves. meaning that if you edit the image to compensate by adjusting a few pixels, then you're actually changing those pixels in two places, resulting in a desired fix as well as likely an undesirable byproduct).

One trick is that any lines/edges parallel to the misalignment (diagonal) aren't noticeable; for example the bottom right of the shield.

I don't know how easy this would be to fix or if anyone would know how to at this point. I think we'd have to be able to actually re-position the texture. (We'll probably have to ask @ Achilles1515 Achilles1515 if the ability to do this is known.)

Another effect of the misalignment is a tiny gap that appears between the two panels. You can see this best if you look at the bottom-right of the vanilla texture in-game on the CSS. This is fixable though, as you'll notice it's not there on your new closed port above when you look at it in-game.
 

Attachments

Last edited:

f_un

Smash Rookie
Joined
Dec 16, 2014
Messages
5
Location
New Jersey
@ 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.
 
Top Bottom