Ok, this is going to be a long post :shock:, but don't be scared, most of the content will be examples.

I was in the middle of my 200th hair categorizing session :P , when I took the time to inspect a package's 3IDR files.
In this particular case it had 7 resources of that type.
Here are the contents of the first resource (sorted by instance):

3IDR (AC506764-00000000-5F6C7FCE-00000001)


So I browsed the TXMT resource list and found the referenced resources:

FFDDC82A: ##0x5f6c7fce!pmhair_Casual1~hair_txmt
FFD815F8: ##0x5f6c7fce!pmhair_Casual1~hair_alpha_txmt



The second 3IDR file:

3IDR (AC506764-00000000-5F6C7FCE-00000002)


The referenced TXMT's:

FF4AA237: ##0x5f6c7fce!cmhair_Casual1~hair_txmt
FF775C5D: ##0x5f6c7fce!cmhair_Casual1~hair_alpha3_txmt
FFC126D3: ##0x5f6c7fce!cmhair_Casual1~hair_alpha5_txmt

However, the referenced PropertySet tells a different story:

GZPS (EBCF3E27-00000000-5F6C7FCE-00000001)



As you can see, the 3IDR file points to the child age textures and to the toddler age property set.

This discrepancy goes on to every 3IDR file (child property set + teen textures etc...), until we reach the last one:

3IDR (AC506764-00000000-5F6C7FCE-00000007)


And as you guessed :roll:, the referenced property set has data for amhairlongsimple_black_clone, and no associated textures.

The question is:
Is this normal data?
If so, can I expect the 3IDR resources to be correctly parsed just by
associating a PropertySet with the TXMT's referenced by the previous 3IDR file?

Can you explain this in more Detail, I am not sure what you mean.

It means that if I want to correlate the GZPS and the TXMT resources together, I'll have to fetch the TXMT's that were referenced by the previous 3IDR (as shown in the example where the MaterialDefinition for the toddler age was referenced by the 3DIR instance 0x01, and not 0x02 where the toddler PropertySet was found). :shock:

Ok, then I tried to manually edit the 3IDR files, to see if the game would accept data that in my perspective made sense, to no avail.

Therefore, the answer is yes, the data is correct although it may seem wrong.

PS: I can always take the easy path which is to determine the ages by the file names, so this issue might not be so critical after all.

Hi Theo, i'm just posting here what i already know about skin resources:



---posted today at MoreAwesomeThanYou forum--

the instance ID is the key that link property set to the specific 3IDR and BINX.

to be more detailed:

property set has information and limitation to ages, skins, genders,... but also has information about the mesh
and the groups that is been used in the mesh. Also, with those informations, is stored the position of the
line that the Material Definition will be found in the linked 3IDR (by Instance ID).

BINX looks like a resource that inform how to render and store the thumbnail in the catalog. i'm not 100% sure.
anyway, there will be stored the lines of the mesh resource found in the 3IDR. I don't know exactly the functions
of each property of BINX but i know some and how to make it work correctly if i add a group to a mesh. what i
can say is:
sortindex = is the position of the thumbnail in the catalog.
stringindex = is the line of the TEXT resource that will be show when you mouse over a thumbnail.
iconidx = i'm not sure but i think that is the number of lines that the mesh resource will be rendered in the thumbnail. (a mesh
with just one Material Definition has a value 3 in this field (line one CRES, line 2 SHP and line 3 TXMT).
stringsetidx = not sure, but is the next line of 3IDR after all mesh resources are setted in iconidx (UIDATA?)
binidx = not sure also, but is the next line of 3IDR after stringsetidx (TxtList?)
objectidx = not sure again, but is the next line of 3IDR after binidx (Collection?)

those are the only thing that i know about those resources."

anyway, the Hair Tone XML has important info about the Hair in this case and maybe is required to be stored in the 3IDR.
When i use a private Collection, i can remove that hair tone XML and link the right PSET to the proper 3IDR. Since when you create a hair in bodyshop it uses a Global Collection, without any properties, maybe this hairtone is required and then those consecutives PSETs are stored in the order but in the different 3IDRs.

anyway, i agree with you. is confusing how bodyshop create those things..
i have just toughts about it, but not really sure why is required a 7th 3IDR and BINX to the package..
just another place to store this information.

Thanks for the reply, it was an invaluable help to my initial purpose.

I had actually considered using the instance number to associate the resources, but then I got confused when inspecting the 3IDR contents, so I couldn't think straight anymore :roll:, but thankfully your post made things clear to me again. :D

So I can jokingly say that the lesson learned is: don't mess with 3IDR resources, and don't even attempt to look at them! :P

lol
i agree with you.

anyway, like i said before, i think that what makes the PSETs in wrong 3IDR resources is the gobal collections resource, since i can remove the hair tone xml from the package and create a private collection resource (using the same group ID that all resources are using in the package) and swap with that 0x0FFEFEFE collection. Removing the Hair Tone XML you can then store the proper PSET in those 3IDR resources.

when removing that Hair Tone XML, it will read the hairtone value stored at all PSETs and if is pointing to a maxis hairtone (binned) will automatic link to the exact proxy tone to the brows. Anyway, to hairs that are using unique values to the hairtone field in PSETs, i can't give you an answer of what will cause.

EDITED:
I was just thinking now about the BINX and maybe this makes more sense:
if the lines of 3IDR are been reading from 0 (the first line as 0) the UIDATA will make part of iconidx. This way the "stringsetidx" will point to the TXT resource, the "binidx" to the Collection and "objectidx" to the property sets or hair tone XML.
makes more sense looking in this way. And this is why is needed another 3IDR resource and a new BINX linked to it to store the last PSET out of the proper 3IDR resource...

that's interesting.