Guide How to Hack Any Texture

[SLUGS]

I'm attempting to edit a skin using DAT Texture Wizard for the first time - I tried to replace Crown Jiggs Half-Closed Eyes and Closed Eyes textures with appropriate ones by following the guide as best I could and using Steelia's offsets

These are the textures I used, dumped from Dolphin:

This was the result:View attachment 48687

What obvious mistake did I make?

Thanks for the help, I'm having a lot of fun with this stuff anyway

I have the same issue with Kirby's closed eyes haha

Edit: Now the same problem with Mewtwo.. used the DTW to try to replace... why does this never work

 

[SillyGoose]

Does anyone know where the offsets for Yellow (Daisy) Peach's textures are (specifically her 12 eye textures)? Steelia's Peach folder does not include Yellow Peach for some reason

 

[DRGN]

Sorry it took me so long to get to these.

Got it.. So do you know what it means when you have steelia's placement files and it has a (2) by the offset? 2 lines?

I have the same issue with Kirby's closed eyes haha

Edit: Now the same problem with Mewtwo.. used the DTW to try to replace... why does this never work

I'm not sure which file you're looking at to be sure, but he's probably referring to the number of lines available in the DAT for the palette. A lot of small textures, like characters' eyes, have small color palettes to save space. So instead of 256 colors, they might have like 32 or 8. One line in a hex editor typically shows 16 bytes. So 2 lines = 32 bytes. And one color (in this particular format) takes 2 bytes. So the number of colors you can use in the palette in the case you had = 32 color bytes / 2 bytes = 16 colors.

If you create a palette for your texture in your image editor with the right number of colors (or less), then it should work with DTW with no extra steps. However, there are some textures that don't follow the normal rules of where the palettes are placed in the file (i.e. they don't directly follow the image data, and are in a totally different place). Cases like these are harder to work with, and you'll need to know the offset for both the image data and palette. There are notes in the usage guide in DTW's download (and the OP, in section 5's "Unusual Palette Placement" spoiler) on how to give the palette offset for cases like this. Getting those offsets is the hard part though. You can look in the Advanced Texture Hacks section at the end of the guide and the resources there to help learn how to read the dat files if you want to try to find these yourself.

Typically, the eyes are at the ends of the files, after all of the other textures. If you're lucky the palette data for each image will follow after the image data for that texture (or they'll just be _14 type or something else and you won't have to worry about palettes). Otherwise, you'll have groups. One group will have all of the image data for the eye textures, back-to-back. And another group will have the palette textures, again back-to-back (maybe with a line or two of padding between them), but in the same order that the image data came in. So if 'eye 3' is third in the group of image data, its palette will be third in the group of palettes. This might be confusing, but hopefully it'll make more sense as you start seeing patterns and understanding what you're looking at.

Was wondering if anyone had any insight to the bar behind the tags the users enter? It doesn't seem to be a texture but an object that appears when users have a tag. I'm hoping to either extend it or remove it all together. The short bars become very noticeable when using the 8 letter mod

Can't figure out how to post a damn picture so here's a link to what I'm talking about
http://imgur.com/PqiKGxT

Yeah, I think a few people have looked into that. Afaik no one has tracked it down yet. @Starreaver1 was one looking into it. He might know more.

Does anyone know where the offsets for Yellow (Daisy) Peach's textures are (specifically her 12 eye textures)? Steelia's Peach folder does not include Yellow Peach for some reason

# (file order): | Eye state: | offset:
1 | Open (gleam right) | 0x32BC0
2 | Open (gleam left) | 0x3ABC0
3 | Half-closed (gleam right) | 0x68BC0
4 | Closed 1* | 0x70BC0
5 | Half-closed (hurt?) | 0x78BC0
6 | Looking left (gleam right) | 0x80BC0
7 | Looking right (gleam right) | 0x88BC0
8 | Half-closed (gleam left) | 0x90BC0
9 | Closed 2* | 0x98BC0
10 | Closed tight | 0xA0BC0
11 | Looking right (gleam left) | 0xA8BC0
12 | Looking left (gleam left) | 0xB0BC0

*Closed 1 & 2 are nearly identical, but the second one has a darkened spot in the center of the eyelid.

All of the textures are 256x256 (for some crazy reason), type _14 and therefore 0x8000 bytes long. The "gleam" variations are basically the same textures as each other, but with the gleam in the eye shifted a bit to the left or right.

 

[SillyGoose]

EDIT: Wrong thread

 

[SLUGS]

@ DRGN Okay let me just walk you through what I'm doing and maybe you can point out the problem haha cause I'm still messing it up I guess.

I am attempting to replace PlKbWh.dat with my custom textures. I want to replace Kirby's closed eye texture. Looking at Steelia's placements file. I get the following information. "16 - 06EyeClose - 000361e0 (28 lines)" So 28 X 16 = 448. And then dividing that by 2 means I should get a palette with 224 colors. So in GIMP I create a .png file called "txt_0103_9.png" which looks like this

I then index this image to 224 colors and overwrite the file. I then put this into the DTW.

then I replace PlKbWh.dat with the new .dat file and get this result..

Hope you can help! Not sure what I'm doing wrong.

 

[DRGN]

@ DRGN Okay let me just walk you through what I'm doing and maybe you can point out the problem haha cause I'm still messing it up I guess.

I am attempting to replace PlKbWh.dat with my custom textures. I want to replace Kirby's closed eye texture. Looking at Steelia's placements file. I get the following information. "16 - 06EyeClose - 000361e0 (28 lines)" So 28 X 16 = 448. And then dividing that by 2 means I should get a palette with 224 colors. So in GIMP I create a .png file called "txt_0103_9.png" which looks like this

I then index this image to 224 colors and overwrite the file. I then put this into the DTW.

then I replace PlKbWh.dat with the new .dat file and get this result..

Hope you can help! Not sure what I'm doing wrong.

The only remaining problem is that the palette does not come directly after the image data, which is unlike most textures, and one of the annoying things with some eye textures. Unfortunately the placements file doesn't mention that. But you can tell because the image data is 0x4000 long, so it ends at 0x000361e0 + 0x4000 = 0x3A1E0, which is exactly where the EyeHurt texture starts (that also means you've replaced part of that texture with a palette btw, so you'll need to fix that one or start with a new file). So where is the offset for the EyeClose palette? 0x3E400

At least I'm pretty sure. I found it by following the data structures, with a little intuition. Unfortunately the intuition part is still needed because the data structures still aren't fully understood. (Even revel8n's structures don't work in many cases.) That's why MeleeToolkit only works for characters, and even then doesn't pull some of the textures. Anyways, I went to the image header, then the texture object from there and found 8 offsets together; I figured the first 4 are a group of image headers and the second 4 are for palette headers. Since the image is 3rd in the group, I picked the 7th offset and followed that to the palette header to find the offset to the palette data. The number of colors for the palette corroborated the venture. As soon as all of this is figured out I'm going to automate it.

Now finally, since the image and palette data is in different places for this texture, you need to give both of these addresses to DTW. i.e. "--> 361e0:3E400" (doesn't matter if you include the "0x" part or not.) Hopefully that works. Good luck!

 

[SLUGS]

The only remaining problem is that the palette does not come directly after the image data, which is unlike most textures, and one of the annoying things with some eye textures. Unfortunately the placements file doesn't mention that. But you can tell because the image data is 0x4000 long, so it ends at 0x000361e0 + 0x4000 = 0x3A1E0, which is exactly where the EyeHurt texture starts (that also means you've replaced part of that texture with a palette btw, so you'll need to fix that one or start with a new file). So where is the offset for the EyeClose palette? 0x3E400

At least I'm pretty sure. I found it by following the data structures, with a little intuition. Unfortunately the intuition part is still needed because the data structures still aren't fully understood. (Even revel8n's structures don't work in many cases.) That's why MeleeToolkit only works for characters, and even then doesn't pull some of the textures. Anyways, I went to the image header, then the texture object from there and found 8 offsets together; I figured the first 4 are a group of image headers and the second 4 are for palette headers. Since the image is 3rd in the group, I picked the 7th offset and followed that to the palette header to find the offset to the palette data. The number of colors for the palette corroborated the venture. As soon as all of this is figured out I'm going to automate it.

Now finally, since the image and palette data is in different places for this texture, you need to give both of these addresses to DTW. i.e. "--> 361e0:3E400" (doesn't matter if you include the "0x" part or not.) Hopefully that works. Good luck!

Thanks that helped out a lot! I got the closed eye to work and Right hurt eye. All I need now is the half eye and left hurt eye... not sure why DTW is not picking up the palette for left hurt eye?

Edit: Kirby also now crashes dolphin when I do rock when the left side is facing lol

 

[SillyGoose]

I replaced every single jiggs eye texture in Steelia's file with a white, closed eye texture. Everything went well. However, while using the skin and dash dancing, there is 1 frame per turnaround where jigg's original eyes show up. Is it possible that Steelia simply missed a texture?

Edit: by dumping with Dolphin, I found that its the exact same texture as Jigg's normal eye texture (Texture 3). I looked for duplicates of Texture 3 in the hex code and found that Jiggs has 2 additional eye textures not documented by steelia, one for when she's dash dancing and one for when she turns around in her run animation. Weird stuff.

 

[Luddoj]

I'm really glad posts like this exist. Thanks for the hard work.

 

[Br0h]

Does anyone know what the .dat/.usd file is for Falco's phantasm? EfxData.dat doesn't seem to work :/

 

[Saxon116]

Is there a GCRebuilder equivalent for mac?

 

[SLUGS]

Is there a GCRebuilder equivalent for mac?

You can run it through wine

 

[Saxon116]

I tried it at first and that didn't work, but just tried it again and opens fine. Thanks!

 

[SLUGS]

I tried it at first and that didn't work, but just tried it again and opens fine. Thanks!

No problem! It is very sketchy lol

 

[SLUGS]

So @ DRGN I still need a little bit more clarification on this issue.. How do I know when I've stumbled upon palette data?

 

[DRGN]

So @ DRGN I still need a little bit more clarification on this issue.. How do I know when I've stumbled upon palette data?

Well, if all you have is the data, you can compare the length of the data with how many palette entries there should be. For all of the palette types, 1 color is 2 bytes. So if the data you're looking at is 64 bytes, it has 32 colors. But this can just tell you if it's NOT what you're looking for, since obviously it's not proof that it is. Also sometimes you might not be sure exactly where the data ends to count the bytes. So a better way to check is to find the palette header, which is done by searching for the palette data offset (+0x20) in the file. As shown here, the palette looks like this:

0x0 - uint32 - paletteOffset
0x4 - uint32 - paletteFormat
0x8 - uint32 - unknown (only seen as 0s)
0xC - uint16 - colorCount
0xE - uint16 - unknown (only seen as 0s)

(^ Offset relative to start of palette header - unsigned integer, + number of bits - description)

You can also keep going up the structure hierarchy to find the texture header, which should contain pointers to both the image header and palette header for the texture. But sometimes the texture header is actually a table. Also, keep in mind that sometimes when you look for a pointer, you might find it more than once in the file.

 

[Mobius_]

Sorry, but is there a simple 'download skin -> open .iso -> replace files' type thing somewhere?

I've read through this guide a few times and apparently I'm completely missing something.

 

[DRGN]

Yeah, if you already have a skin (the .dat file), all you need is step 6 in the guide. Open GCRebuilder (d/l link available in OP), right-click on the file to replace, click import to import your file, and you're done.

 

[Oskurito]

I used dolphin to dump textures and just to test I grabbed ps stage icon and edited it with paint, it works on a regular melee .iso but not on 20XX. Also, when I dumped the textures from both versions they had different texture IDs. Any ideas?

Maybe I should work with an unmodded melee iso to begin.

 

[Dillyne]

I'm fairly new to this and am experiencing some difficulties. Some textures, sounds and effects I can fit in but some it says the file is not the same size with an error, anyone know how to fix this?

 

[Oskurito]

I'm fairly new to this and am experiencing some difficulties. Some textures, sounds and effects I can fit in but some it says the file is not the same size with an error, anyone know how to fix this?

Are you sure you're not replacing old files with bigger ones? that totally might be a problem. There's a trick in which you can replace the how to play video tutorial file with a smaller file with the same name to save up a lot of space for you to include additional content. I think if you look around the sound tutorials or google around you might find how to do it, I just cant remember exactly where I found that right now.

On a side note, I figure out the melee .iso was modded all over the place that it wasn't really worth it to find what was the problem, it's way easier to just start with an empty melee .iso and start from there.

 

[Drysocks47]

So I made my first custom costume for green captain falcon following the guide, downloading the Steelia's files, editing them in gimp, turning them into a .dat, and importing it to the iso with gcrebuilder. When I open up dolphin to check out how it looks the game works fine until I try to start a game with green captain falcon. An error pops up and dolphin closes. Am I missing a step somewhere that is screwing things up? Also, what are the white versions of certain textures for? Ex. Chest FW I didn't edit any of them.

 

[TheLaw]

I don't know if there's a separate thread for reporting glitches, but I found an interesting one. I've downloaded two Peach costumes (Emo Peach and Miku Hatsune), and my friend and I were playing and he was pulling an unusual amount of special turnips, especially stitch face (i.e. at least 5 in one match, twice in one stock, and it happened several games in a row). When he went back to playing the normal Peach colors as well as the alternates that came with the 20xx pack, everything was normal. I will be posting this in two other threads.

 

[DRGN]

So I made my first custom costume for green captain falcon following the guide, downloading the Steelia's files, editing them in gimp, turning them into a .dat, and importing it to the iso with gcrebuilder. When I open up dolphin to check out how it looks the game works fine until I try to start a game with green captain falcon. An error pops up and dolphin closes. Am I missing a step somewhere that is screwing things up? Also, what are the white versions of certain textures for? Ex. Chest FW I didn't edit any of them.

Can't really say what went wrong without knowing exactly what you did. It's possible you input the wrong offset for something, which caused data to be written to the wrong place. If you changed a bunch of textures, then probably your best bet at this point is to start over since you don't know which one messed it up. Try doing just a few at a time if you still have trouble.

I don't know if there's a separate thread for reporting glitches, but I found an interesting one. I've downloaded two Peach costumes (Emo Peach and Miku Hatsune), and my friend and I were playing and he was pulling an unusual amount of special turnips, especially stitch face (i.e. at least 5 in one match, twice in one stock, and it happened several games in a row). When he went back to playing the normal Peach colors as well as the alternates that came with the 20xx pack, everything was normal. I will be posting this in two other threads.

Had to be coincidence, since texture hacks can't affect the game's mechanics.

 

[ZetaWolf]

Thanks for the tutorial. I never knew how it worked prior to this. I might get into Texture Hacks soon!

 

[Milun]

Uh... hi. Sorry to revive a dead thread, but I'm having the problem too (and I'm trying to use the old-fashioned method).

I'm trying to do Grey Shiek's eyes. I got it working on default (ignore the torso, that was me trying to brute force it):

But then when I attempt to change the other eye frames, I get the usual:

I'm doing it the copy-paste .tpl method, and I had always assumed the way it worked was:

29 - 00043a20 * - EyeL_Half
30 - 00045e20 * - EyeL-Close
31 - 00048220 * - EyeL_HURT
32 - 0004a620 * - EyeL_Left
33 - 0004ca20 * - EyeL_Right
^ And then directly after the last one, paste in the palette data (32 lines) which is used for all of the above.

No such luck. I prefer the old fashioned method for things like this, (I didn't have the best of luck with the Wizard). I recall a while back I did a Dr. Mario hack, and I'm pretty sure this is what I did and it worked? I'm sorry for asking a redundant question (I can model and stage hack, but _9 has tortured me from the very start), but I'd really appreciate it. It's for a birthday present.

 

[DRGN]

Uh... hi. Sorry to revive a dead thread, but I'm having the problem too (and I'm trying to use the old-fashioned method).

I'm trying to do Grey Shiek's eyes. I got it working on default (ignore the torso, that was me trying to brute force it):

But then when I attempt to change the other eye frames, I get the usual:

I'm doing it the copy-paste .tpl method, and I had always assumed the way it worked was:

29 - 00043a20 * - EyeL_Half
30 - 00045e20 * - EyeL-Close
31 - 00048220 * - EyeL_HURT
32 - 0004a620 * - EyeL_Left
33 - 0004ca20 * - EyeL_Right
^ And then directly after the last one, paste in the palette data (32 lines) which is used for all of the above.

No such luck. I prefer the old fashioned method for things like this, (I didn't have the best of luck with the Wizard). I recall a while back I did a Dr. Mario hack, and I'm pretty sure this is what I did and it worked? I'm sorry for asking a redundant question (I can model and stage hack, but _9 has tortured me from the very start), but I'd really appreciate it. It's for a birthday present.

np, that's what this thread is for!

For future reference, for anyone looking for eye palettes, there's discussion on how to find these earlier in this thread, starting around here.

First of all, the palette is not shared by all of the textures; they each have their own.

Judging from the colors, I think you mean her white costume, PlSkWh. Regardless, here are all of the offsets for her White, Blue, and Neutral costumes:

# (by file order): | Eye state: | Image Data offset: | Palette Data offset:
1 | Open (left eye) | 0x34920 | 0x38920
2 | Open (right eye) | 0x38b40 | 0x3cb40
3 | Half-open (left eye) | 0x43a20 | 0x4ee20
4 | Closed (left eye) | 0x45e20 | 0x4f040
5 | Hurt (left eye) | 0x48220 | 0x4f260
6 | Looking Left (left eye) | 0x4a620 | 0x4f480
7 | Looking Right (left eye) | 0x4ca20 | 0x4f6a0
8 | Half-open (right eye) | 0x4f8c0 | 0x5acc0
9 | Closed (right eye) | 0x51cc0 | 0x5aee0
10 | Hurt (right eye) | 0x540c0 | 0x5b100
11 | Looking Left (right eye) | 0x564c0 | 0x5b320
12 | Looking Right (right eye) | 0x588c0 | 0x5b540

For her Green costume, subtract 0x60 from each offset.
For her Red costume, subtract 0xA0 from each offset.

All of these may have up to 256 colors.

(Odd fact: two of her eyes are at 128x128 in size, while the rest are 96x96.)


You can read about the method I used to find these by following along the discussion that I linked to above, but some more examples might still do some good, so here are some notes I took while making the above table, with some explanation added.

First, I found a few image data headers. Subtract 0x20 from these and then search for them in the dat, and you'll find that there's a place where several of them are grouped together. These are basically a table of pointers, common for eye textures. This is the hex of that header-pointer table in the dat (@ 0x43240):

00 04 31 90 00 04 31 A8 00 04 31 C0 00 04 31 D8
00 04 31 F0 00 04 32 08 00 03 CD 20 00 05 AE A0
00 05 B0 C0 00 05 B2 E0 00 05 B5 00 00 05 B7 20
00 00 00 00 00 00 00 00 00 04 31 28 00 04 32 20
00 04 32 38 00 06 00 06

I don't recall these being documented anywhere, but they're basically structured like this:

object: | length in bytes: | type of data:
image header addresses | 0x4 x n | pointer
palette header addresses | 0x4 x n | pointer
padding? (all 00) | 0x8 |
start of this data structure? | 0x4 | pointer
addr of first image header | 0x4 | pointer
addr of first palette header | 0x4 | pointer
# of image headers | 0x2 | int
# of palette headers | 0x2 | int

( @ Tcll )

I don't know how much of what comes before or after this is actually part of the same structure, but I think the headers that come before it might be part of it. It's really weird, and doesn't follow the normal pattern you'd see for any other texture structures.

Anyway, when you lay out the pointers (shown below on the left) with the respective headers that they point to (shown below on the right), in order, you get a set of 6 for the image headers, followed by a set of 6 for the palette headers:

00 04 31 90 - 00 03 8B 20 00 80 00 80 00 00 00 09
00 04 31 A8 - 00 04 F8 A0 00 60 00 60 00 00 00 09
00 04 31 C0 - 00 05 1C A0 00 60 00 60 00 00 00 09
00 04 31 D8 - 00 05 40 A0 00 60 00 60 00 00 00 09
00 04 31 F0 - 00 05 64 A0 00 60 00 60 00 00 00 09
00 04 32 08 - 00 05 88 A0 00 60 00 60 00 00 00 09

00 03 CD 20 - 00 03 CB 20 00 00 00 01 00 00 00 00 01 00
00 05 AE A0 - 00 05 AC A0 00 00 00 01 00 00 00 00 01 00
00 05 B0 C0 - 00 05 AE C0 00 00 00 01 00 00 00 00 01 00
00 05 B2 E0 - 00 05 B0 E0 00 00 00 01 00 00 00 00 01 00
00 05 B5 00 - 00 05 B3 00 00 00 00 01 00 00 00 00 01 00
00 05 B7 20 - 00 05 B5 20 00 00 00 01 00 00 00 00 01 00

As whoever's reading this may or may not know, the first 4 bytes of each image header or palette header is a pointer which goes to the actual image data or palette data (remember to add 0x20 to account for the file header offset). So there you have the offsets of the palette data for 6 of Sheik's eye textures. These are all for the right eye. Then there's another pointer table for the left eye.

The first pointer of the image headers corresponds to the first pointer of the palette header, the second pointer of the image headers corresponds to the second pointer of the palette header, etc. You can compare the offsets you see for the image data with Steelia's placements files to check which texture is which (otherwise you'd have to manually build a tpl and convert it to see what it is).

Hopefully this helps to make things clearer. You'll still probably need to have read this or this first, and some of the discussion I linked to.

 

[zankyou]

@ DRGN
When I looked into it the eye textures traced back to the join matanim which is assumed as of now to be related to animations. Theyre formatted weird probably because another file deciphers them.

 

[CeLL]

Can we have some light shed on increasing the quality of a texture?

 

[DRGN]

Can we have some light shed on increasing the quality of a texture?

That's tricky, but I think definitely doable. First the texture would need to be recreated/saved in the new texture type (like _6 for 32 bit color + transparency), and then the trick will be in going through the relocation table and using that as a guide to increase all pointers in the file appearing after the changed texture, increasing them by the difference in size of the new & old texture. The file header would also need to be changed appropriately of course. An absurd task by hand, but programmatically simple. I'm planning to add this ability to DTW3.0. At least, theoretically it should work! ^_^

 

[Tcll]

I don't recall these being documented anywhere, but they're basically structured like this:

object: | length in bytes: | type of data:
image header addresses | 0x4 x n | pointer
palette header addresses | 0x4 x n | pointer
padding? (all 00) | 0x8 |
start of this data structure? | 0x4 | pointer
addr of first image header | 0x4 | pointer
addr of first palette header | 0x4 | pointer
# of image headers | 0x2 | int
# of palette headers | 0x2 | int

( @ Tcll )

which files are these structures from??
yea with the DAT format, it's so loose that anything's possible... heh

EDIT:
btw, increasing the quality of the textures is actually really easy.
UMC actually expects pixel/palette data in any of these HQ formats:
- [ Intensity ]
- [ Intensity, Alpha ]
- [ Red, Green, Blue ]
- [ Red, Green, Blue, Alpha ]

each value following the common 0-255 range
(float values are also accepted (expected from 0.0 to 1.0) )

all of these formats can be easily converted between each other (except going from RGB to I which needs B/W conversion)

it's a 2-pass standard, yes, but it can be brought down to a single pass

EDIT2:
btw I should also mention, anyone who wants to help document things about the format, please do so here:
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

 

[Milun]

np, that's what this thread is for!

For future reference, for anyone looking for eye palettes, there's discussion on how to find these earlier in this thread, starting around here.

Thank you so much!

(I'll write the slight wonkiness to me exporting the palettes improperly while brute forcing). Thank you!

EDIT:

"Hurt me more, Snake."

 

[Saxon116]

@ DRGN is the dark blue background in the SSS a color effect? How can I change it?

 

[zankyou]

That's tricky, but I think definitely doable. First the texture would need to be recreated/saved in the new texture type (like _6 for 32 bit color + transparency), and then the trick will be in going through the relocation table and using that as a guide to increase all pointers in the file appearing after the changed texture, increasing them by the difference in size of the new & old texture. The file header would also need to be changed appropriately of course. An absurd task by hand, but programmatically simple. I'm planning to add this ability to DTW3.0. At least, theoretically it should work! ^_^

Ive gotten into the habit of inserting images right before the pointer table. That way you wont need to change every pointer. Ive done it once by hand and its incredibly tedious and it didnt work although that could have been what I was testing for. If you replace the pointer for the old image that image wont be loaded into the ram.
Also I dont know if replacing would work. If you move certain structures around the game breaks. Like the node tree has to be in its exact position. Although images are normally after the node tree so it might not be a problem.

 

[DRGN]

@ DRGN is the dark blue background in the SSS a color effect? How can I change it?

I think I remember reading about that in the past, but I don't remember where. I think @ Cyjorg might know though.

Ive gotten into the habit of inserting images right before the pointer table. That way you wont need to change every pointer. Ive done it once by hand and its incredibly tedious and it didnt work although that could have been what I was testing for. If you replace the pointer for the old image that image wont be loaded into the ram.
Also I dont know if replacing would work. If you move certain structures around the game breaks. Like the node tree has to be in its exact position. Although images are normally after the node tree so it might not be a problem.

Well the recalculating method I'm suggesting would be nice because none of the structures, or the node tree, would be changed as far as the game is concerned I think (I assume that even if other functions had to peek into the structure, they would follow the hierarchy to do it, and not try to peek into arbitrary addresses). The only limiting factor I can think of would be how much data the game can read at once. Others have tried to load double sized CSS files before, for example, but it failed. I don't know their exact methods or why though.

 

[zankyou]

(I assume that even if other functions had to peek into the structure, they would follow the hierarchy to do it, and not try to peek into arbitrary addresses).

Now that I think more about it, I think I concluded that before I realized that certain structures had to terminate at other structures. So you cant just move 1, youd have to move a set. As long as you keep the general ordering the same itd probably be fine. At one point I remember trying to double the size of the CSS file and I think achilles did as well. I think achilles just added it after the string table but this was before I realized you could add pointers. As far as the limitation, this is stuff I was testing when I first got into hacking so I dont really remember but I think the dreamland background was on the upper end that I could add. If theres not a pointer to it and the game knows the end of the structure before it, its probably not going to be loaded into the ram. So the file size doesnt matter in that regard, only the size of the structures that have pointers to them do.

 

[Tcll]

@ DRGN :
ok, so I've read a little bit and done some research and tests
UMC imports shiek just fine, however, the structures you've mentioned aren't even touched other than pointer collection for my pathfinder:

0x000004322C: jumping to: 0x0000043240 from start of file
0x0000043240: read 0x00043190 as 274832 -- Pointer

so I'm doing some reverse-searching through the file to see if I can find the initial structure that points to these structures

I have a feeling these may have something to do with the currently untouched (by me) matanim root-node

EDIT:
also, look into how animations Pl**Aj.dat files reference bones.
there's really no other way I can think of other than exact-relative offset (relative to the allocated data section of that DAT)

however the relocations may also play a factor in this

EDIT2:
yep, the more I look at this, the more this seems to be the case...

the offset of the current struct in question is 0x43250+0x20 (which has 2 array structs pointed to by the offsets you mentioned earlier)
a quick search for that offset reveals a pointer in an array.
it doesn't take long to realize that the struct after the end of that array at 0x43750 is the initial root struct of the matanim node

knowing a little of how the DAT is structured, since these blocks are stacked on top of each other, common sense with logic tells that the 3 blocks are all part of the matanim node

lemme see if I can get Revel8n to come out of his hole, he knows more about this area than me

 

[Cyjorg]

@ DRGN is the dark blue background in the SSS a color effect? How can I change it?

I don't however I'm 99% sure @Myougi helped change it on the Falcon Dittom pack

 

[Tcll]

oh interesting, I think I may have just stumbled across a few BP registers while testing an idea:

offset 0x43100:
61 00 01 20 01 40 01 60 01 80 01 A0 05 A0 00 00 (array termination bytes)
61 00 01 20 01 40 01 60 01 80 01 A0 05 A0 00 00
(no the data is not pasted twice)

offset 0x43158:
61 00 01 20 01 40 01 60 01 80 01 A0 05 A0 00 00
61 00 01 20 01 40 01 60 01 80 01 A0 05 A0 00 00

seemse to be a standard >.>

anyone doing any MDL0-TEV hackwork might recognize these
anyone understand the 61 00 command off-hand??

I was looking into that array above the matanim root-structure to see if that was frame data when I stumbled across those.

 

[zankyou]

So I just wrote a script to insert an inverse bind matrix for every bone that didnt have one and it didnt break the game. So I can only assume that as long as structures stay organized in a certain way its fine to insert things.
EDIT: Maybe. I didnt take a good look at the model, just if the model ran. A lot of things are messed up but Im going to assume that some pointers are off from rebuilding it.