I understand Keith's folder structure - and it is somewhat how I do things.  Except for DAZ, I organize specifically on figure and then addons (Character folder ex.):

Miki
..Clothes
....Swimsuit

DAZ
..Aiko3
....Clothes
....Hair (figure hair, of course)
..Michael3
....Clothes
..Victoria3
....Clothes

If I organized solely on merchant, my Miki clothes might be strewn all over the Character folder.  This is just to illustrate that no one system will work for everybody.

Lest we forget, despite their ancient status, Poser 4/PP are still being supported by vendors.  And there in lies a quandry.  You can't have subfolders beyond the one in the library folder in these versions.  This is why such practices as "Merchant_Product_for_thisFigure_v1" exist (or worse when the names got too acronymatic and truncated to fit in the Library view).  And you can't have external Runtimes with these either.  It is just as simple to make two folder structures to support both the older and newer versions - but how?  Two separate products?  Two zips inside the product zip?  Mix them up and let the user sort it out?

Except for the "!!!!!!" crap and unique filenames, this topic arises so often because there are a myriad 'logical' ways to organize data - any database users to bear that one out (last name, first name, address, city, state, date, time, birthdate, and on and on, for example - which one is 'right' for they are all logical under the correct circumstances)?  Your way is logical, my way is logical.  There are situations where the merchant organization isn't good, but for the rest of the merchants which standard organization should be enforced?

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone