PDA

View Full Version : Texture files not linked properly


Phaenoh
12th Jul 2013, 5:28 AM
I'm trying to finish off the mystery of non-default custom pet markings for TS2. I had a mostly working package, but the file was still not truly custom yet, it was still referencing *something* I've managed to break whatever it was referencing by giving the texture and matdef custom groups, but I don't know where the original thing that was doing the linking is in the first place to fix it.

I thought meshes called for their textures though the 3DIR, but I'd swear I have that correctly linked. (Loved to be proved wrong anywhere if it means I get a working package out of the deal ;) ) What else breaks when the texture's group number changes?

I'm trying to get this up as part of my Creator Anniversary on the 19th, so I'm motivated to find help quick! :call: Thank you rescuers!

Echo
13th Jul 2013, 2:36 AM
I'm pretty sure your highest numbered 3DIR is pointing to the wrong instance number for the TXMT. Your TXMT's instance ends with ..84A, but you're pointing to ..04B. Not sure if that's the actual problem though.

Phaenoh
13th Jul 2013, 3:54 AM
I think that's the TMXT for the actual body, when I tried fixing that, the entire body went black. With it the way it is now, it still shows the body, just not any of the markings. Maybe there is still another 3DIR that is missing, or something else that would reference the TMXT? Maybe I would need to include the SHPE? It links to TXMTs as well. Are there any other ways you could think to link the TMXT? I'm assuming the TXTR link is fine as that was working up until the group number change.

Echo
13th Jul 2013, 2:30 PM
Hmm... I'm pretty sure you still need your TXMT linked in through a 3DIR though. Maybe add a second line to that last 3DIR pointing to your TXMT as well? (Looking at Wes' dog collar, I can see that he has multiple TXMT references, including one from the global space)

I also noticed that you're adding the ##0x1C050000! prefix to all the references to the TXTR, but your TXTR isn't actually in the 0x1C050000 group. You probably need to fix that. :)

Phaenoh
13th Jul 2013, 11:38 PM
It looks like 2 of those are the one in his package, and the global one is for the buckle, so that's not relevant for me. I tried fixing the TXTR group, but that didn't solve the problem. I'm sure it will fix a future problem that I'm not even aware of yet, so I'm keeping that. I'll try putting TXMT refs in all my 3DIRs and see what that does... >.<

Phaenoh
14th Jul 2013, 12:51 AM
Ok, I must be looking at this from the wrong direction. You have two working packages back in that old thread. They don't overwrite each other. Why is that? I'm trying to create a finished version of your zebra stripes one, but each time I try something, it either breaks or the original overwrites it. What is it that keeps your two original ones from messing with each other?

Echo
14th Jul 2013, 3:23 AM
My original two are working because all the files are in their original, global groups, and everything is operating on that assumption. At the moment, your package has files in the global space, but they're referred to as though they're in the CC space (with the ##10c... prefix).

That said, the 3DIR where you said "I think that's the TMXT for the actual body", that TGI is pointing to my zebra stripes texture. I'm pretty much certain you need to point that to your TXMT.

Phaenoh
14th Jul 2013, 4:29 AM
Yeah, lots of learning since then. >.< I've got an entirely new package, made from scratched together bits of the locked Bandit Mask. It's still having the same problem as the last one though. I'm guessing the global/CC space mixup is likely present in my new one as well. How do I fix that? Is there anything else in this package that you can see that might prevent it from working correctly?

Echo
14th Jul 2013, 4:46 AM
Heh heh... Um... You know that thread I sent you to, where it starts with me asking "does anyone know how to fix the global/custom problem with these packages", and then no one actually figuring it out? Yeah... Bodyshop was never really my thing! ;)

I'd guess that there might be something wrong in the linkage between the TXMT and the TXTR pairs, because the Scenegrapher is showing them as orphans when I think ideally they would be connected... But I'm just not sure.

Phaenoh
14th Jul 2013, 5:14 AM
Oh, ... drat.

I've got much more experience with bodyshop modding so that's why I was able to put most of the rest of it together correctly, but I figured the bit I was missing was similar to object linkages. I've been looking at hair meshes and makeup and clothing and eyes to see how they are working it but so far no other breakthroughs. How did you originally diagnose that the global/custom stuff was the issue? What in the package tells you they exist in different spaces?

I'll look more into the TXMT and TXTR links, it has been bothering me as well that they are shown as orphans, but that's how makeup appears in the Scenegraph as well, so I originally disregarded it. I'll look at it again though.

Echo
14th Jul 2013, 7:28 AM
It's the group ID which places something in the global space. I can't remember specifically which one, but there was one type of resource for which all of that type shared the same global group. Moving things out of that group into 0xFFFFFFFF or 0x1C500000 would immediately cause the textures to stop loading correctly.

Phaenoh
14th Jul 2013, 3:24 PM
Ok, well then. What are the evils with leaving it global? It's not like we have to worry about any new EA items coming out to conflict with them, and as long as we kept a list of the new used numbers, shouldn't that be ok?

Echo
15th Jul 2013, 9:13 AM
At this point, not all that evil. About the same amount of evil as picking random GUIDs rather than using the GUID registry, which is pretty low given how many people are still actively modding. It was a bigger issue when Pets first came out and there were still many EPs coming, but at this point I'd say 'go for it'. :)

Phaenoh
15th Jul 2013, 2:06 PM
I managed a hybrid. The TXTRs and TXMTs have to stay global, but I've got two working non-conflicting packages, so I think I'm going to go with that and write up a tutorial on it so the info doesn't get lost. As long as the instance numbers don't conflict, this should be fine, right? I've generated them from the Hash Generator, so at least they are related to my packages and not just some made up number. I'm going to try to poke into coat colors and eye recolors as well before I quit this project.

Echo
16th Jul 2013, 11:51 AM
As long as the instance numbers don't conflict, this should be fine, right?

Yep. That and the "family" hash need to be unique. Everything else should be fine.

Phaenoh
18th Jul 2013, 5:09 AM
K, so I've got a couple different coat patterns working perfectly. That gave me the confidence to try eyes and fur accessories, but neither of them is working. I'm pretty sure I've done everything just as I did for the coats, but something isn't right. On top of that, they are both wrong differently. Maybe you can spot something I've overlooked?

Attached are the two broken packages, and a perfectly working coat for reference.