Yes, but there lies a subtler problem there as well (subtle enough that although I mentioned it in my post above it seems to have slipped notice.) To wit, if I use a human-readable name of reasonable length for files that show up in the library display (aka figures, props, poses), but a more complex name within the texture and geometries folders (to prevent Poser from grabbing the wrong files), when said user decides to re-organize their Runtime they will have a difficult time figuring out what goes with what. Fortunately, a folder structure can help here. Not so much to help Poser figure out which texture it should be going for, but to help the end-user figure out that "Princess_V4highheel6_redleather2BUMP.jpg" is one of the files that goes with the "Strappy_high_heel" in their Library folder. Presumably all the user would have to do is drag all the similarly-named top-level folders (aka folders with the merchant's name on them) to the new Runtime. Except, of course, when the IS no merchant-named top-level folder in the Library! Aka you've gone along with the user's wishes and your top-level folder in Figures is "Laura_Clothing" or "Large Houses." At that point you have to trust to readme, user's memory, and perhaps a distinctive thumbnail (why I have a company logo in all my thumbs as well as a distinctive style to each set I render) to allow them to figure out that to move shoe number 51 through 55 in their crowded clothing library they also need to locate some folders with a certain merchant's name else where in their Runtime. It's compromise, but I think the scheme above works. Much depends, however, on how many different items you have that belong together, and how much they belong to other things. I would want shoes, for instance, to be able to be placed in whatever part of the end-user's library they preferred. But for something like the set of trad climbing cams, nuts, and 'biners I'm thinking of making, they'd best be placed in a set of nested folders on their own.