SRIV How are textures are cached and read as "unique" in-game?

[[V] Knobby]

Have you tried hex editing the files? I don't see why you can't change the names now. It gets harder if you change the length of the name, but I would imagine you can get around that by just changing some characters. Hopefully "soon" this will get easier.

 

[GPZ]

I'll try that, thanks.

 

[.Swami]

Your file sizes much larger in the high res area. I'm not sure if it is because of the size of the joprez texture you are using or what.
View attachment 5379

Edit: This image is actually with saints_linda_high, but the sizes are mostly the same for lindas as well.

Yes, some (2? 4?) of the textures are in fact a higher resolution, but only 2x, and saved with the same .DDS compression.
I've not had issues with a simple texture resize like that in the past.

Have you tried hex editing the files? I don't see why you can't change the names now. It gets harder if you change the length of the name, but I would imagine you can get around that by just changing some characters. Hopefully "soon" this will get easier.

Yeah, that method worked for textures (hell, it's the basis for the tutorial I made); I got the "joprez" files to load for that gang customization character with no problem (just that initial issue of the flickering of genericbusinesswoman02), but didn't try it with meshes, though I doubt it should be too different.

I can't do much of any work until I get SRIV to run mods/edits like it used to on my old 32-bit HDD, though. You're kinda on your own until then, @GPZ . : (

 

[GPZ]

[V] Knobby - I changed the texture names through hex editing from "zoey" to "zoes", and there's a one-letter difference like you suggested, in addition to that I renamed the textures in the cpeg and matlib files as well. However, the textures do not load in-game for whatever reason, and "Zoey" spawns like this:

I suppose this is a step in the right direction as the game recognizes that the textures should be different. I added this version below so you could examine it if you wish.

 

[[V] Knobby]

What you're actually seeing here is the misc_static texture. This is the texture used when we can't find the requested texture. What is happening here though is that the renderer is still asking for zoey and zoey isn't loaded any longer with this container. As a result, the diffuse texture is misc_static. I'm not sure what else could be referencing zoe, maybe Randall knows.

 

[GPZ]

That's what I thought - that the "new" textures cannot be found. However, when I attempted to port a head from SR3 ("Cypher" character's head) and it displayed correctly even though its textures shouldn't be in the game. Are textures referenced elsewhere than in the ccmesh or matlibs?

 

[Meatplowz]

Most all characters should be self-contained. There are of cases of other NPC's with direct texture sharing as we've seen earlier. Texture references for characters are only found in ccmesh and the "*_head"/ "*_high" matlibs outside of the associated pegs.

 

[GPZ]

I hex edited all of those files like Knobby suggested earlier and changed the names of the textures in the pegs as well, but for some reason the textures don't show up. It seems to acknowledge that the textures are different but it cannot find them. I don't think the texture names are wrong - I only changed one letter on the diffuse textures' filenames.

 

[Meatplowz]

Hrmm, oh another thing as far as the "_high" matlib goes. The high file is found and loaded based on the character's name. So the mesh reference for "Zoey" in the character.xtbl. "zoey.cmeshx", code will look for "zoey" + "_body_high.matlib_pc".

 

[GPZ]

It's working! No texture flickering, no sudden color-swapping, this is perfect.

I just reviewed all of Zoey's files and I finally realized what my problem was: There are two separate "entries" inside each ccmesh and matlib - as soon as both of those entries matched the new texture names (zoes instead of zoey) it worked. This is so cool, thank you guys so much, I really appreciate your help with this.