I also hate when admins/merchants IM me and say "Funny I don't have that problem". Sounds like my husband when I tell him my car is making a funny noise.

Heheh. In regards to missing textures, if a merchant says "Funny I dont have that problem", well of course not. They have the missing texture on their harddrive. Nevermind they forgot to include it in the zip!! :P

Quote - I also want to add a separate gripe. I wish merchants would NOT package files for more than one base character into the one product. e.g. V3/S3/A3 or M3/D3/H3. I have separate runtimes for each of these and consequently when I get one of these products, I know I've got some work on my hands splitting them up.

Worst offender by far is DAZ in this regard, but PoserAddicts have been known to put out packages like this too.

**Now see, this is a good example of how to not be able to make everyone happy.

Someone above in a post complained about having the some of the same textures in all the folders and here's a complaint about having the characters for different figures in one pack. The problem here is that those two characters may be sharing a texture for the teeth or some other part.

I do two character packs. I've done them for V3, for V3& M3, for Hiro and A3. And I try very hard to conserve space by using what I can for both characters, such as the teeth and gums. Plus, the whole idea is that you have two characters...male and female. According to the rules I have to follow, they have to be in the same zip because even though there are two characters, they are one product. And nope... I can't make it to where there are two zips simply because even if I divided everything into a him and her type zip, they still have to unzip all into the same folder. Rendo's rules. Can't win for losing on this one.**

ITA with the list. I also dislike having to text edit errors in MAT poses and INJ REM poses because names are: !INJ ohmygodIlovesuperlongINJnamesandPosessolong-itwillgiveMacUserssuchafitandIlovethat-givingMacUsersafit_heeheeh. :P bB

***Rule 1: You Are Not the Most Important Person In the World.

Naming the readme file "Readme" sort of assumes that it's the only file I'm going to have with that name, doesn't it?  Now, while I like your stuff (otherwise I wouldn't have bought it and downloaded it), that doesn't mean that you're the only person in the world whose product I'm going to buy, and as such, so that your Readme isn't overwritten by their Readme, wouldn't it make sense to give your Readme file, heck, your Readme folder, a name which logically connects it to the product you want me to read about?***

It is for this very reason that I stopped reading readme's entirely years ago! If it's called readme.txt or readme.doc or readme.html, it hit's the recycle bin.

Attached Link: The List dun.dun.dun.

you have of course opt out options?

"accreditation (you must/must not credit the creator)"

Sorry if I buy an item I don't have to credit anyone. Even with a freebie it's done as a courtesy.
Marque

Well I don't know if my way is agreeable or not. When I make products now, (in the past it was different) I make a readme folder and put my readmes in it. Each readme starts with BE4(productname)readme.txt, which I hope that isn't too long. It tells the buyer that readme is for that file and merchant. All pose files goes in to a folder called BE4Productname and the file itself is always BE4productname. Character, props or textures are done the same way so the buyer knows what goes with what. The BE4 is because it's hard not to use the same name for a character that some other merchant has used, even when you think it's unique. I started doing it this way when I read so many complaints about files and folders not matching. And after buying a few myself that had me searching all over for parts of the package. Also I try very hard to make sure all unzips into the correct folders without looking for drive such and such, and I do try to get rid of the dbs things. :) Another thing I do is use from three to six testers for each product. drifterlee, I'd sure like to add you to my list of testers. You sound like not much escapes you. :0)

Was about time for such a rant...

At some point I had to reorganize the Runtime because after installing many products there is no way to find what you have installed. The stuff ends up just everywhere.
Now the Runtime is ~50GB, ~300k files and Textures is ~ 22GB, ~40k files.
Imagine what a mess it would be if the files would all be where they would have extracted too.
As it is now it's still not always easy to find a certain item if it's in a folder with the vendors name because I don't remember the vendor but the product and to which category it belongs.

Havin a structure like:
ABC:Dress
ABCD:Dress
ABC1:Dress
ABCH:Dress
...
Does not make it easier to find the dress I was looking for.
Since I have every product registered in a DB it's easy to search.
But the DB wasn't part of the product and it's a pain in the ass having to refer to each and every texture, mesh, whatever file that comes with a product. Besides this, it's somewhat funny that external tools are required to keep track of files.

Someone said it already: Thumbs.db - I don't want to see any of these files installed to my Runtime. Sure, it's easy to keep the computer from doing so, but that doesn't mean that it is my job to watch over each file that is written to disk. And someone who can't program or script or use DB's will have to manually sort the extracted files til the end of all days. Or longer...

What I would love to see is:

1. Hashset, creation date, rev. nr. as part of the filenames. At least for textures.
2. Because it's very unlikely that filenames appear more than one time this way, it don't means that I wan't 10 same textures in 10 different named files.
3. Not like 10 different character morphs that are named all the same. (See point 1)
4. Some DB script file that makes it easier to register the files in the system DB. No matter what DB is choosen.
5. Some thoughtful naming of products. Some XYZ-Hair is cool, but XYZ often don't say much about the geometry - or basic style - of this hair. And "long hair" is a bit vague, isn't it?
   Often there is already some realworld name for some type of hair or clothing. Using it may ease the search procedere.

A readme that contains important information. Not 100 thank you's and a endless list of installed files. The list of installed files should be part of a seperate file and the DB script.
It's nice to see that the product consists of a few hundred files but I doubt I will ever check pesonally if every file was extracted/installed to the right location. That's a job for the system and not the reader of the ReadMe. In many cases the ReadMe could be reduced to the really important things: Product name - also already as part of the file name -, Vendor name and contact information, Product creation date and Product revision if applicable.

Product promo images - especially if scattered throughout the whole Poser directory - are not too useful AFTER I have bought and installed the respective product already.

Readme can be done in TXT format. In rather rare cases PDF or TEX is needed. I can't stand any DOC, WRI, ... files anymore if all that they contain can be done with TXT..

Maybe it would be a good idea to talk to e-frontier about directory structures and file names and the little room for filenames on the library palette.

A PZ3 shouldn't be extracted to the Runtime folder IMO. And even less it should be in some folder that gives no hint that there's a PZ3 file inside 20 more subfolders. - A little exaggerated.
Some people seem to think that it's cool to immortalize themselves in the Runtime by creating folders that simply don't belong there.
There is for sure some existing directory where such content can be installed because it's somehow similar to whatever is already in the specific directory.
P4 compatibility is nice. - If optional.

...

I wonder how long it would take till someone beats me if I start naming things like "chip: small, many pins" or "effect: 200kN, 5cm, 1450K, on model" in reports. Yeah right... That would be big fun.

This is the end...

actually, I need to credit some suppliers for actually doing some things 'right', as far as I'm concerned.

If you include everything you make under one folder, it's more likely I'll credit you. Some folks make 5 or 6 impossible things, all easily found in the same folder. It's a good idea.

If it's a subdirectory, that's cool. What I don't get is a sub-sub-sub directory. It's more typing for you, more searching for me. Why?

Another tiny gripe is just to put all the items with no general folder structure in a zip. I only found out you can put files in a text editor to trace the paths to the proper directory names, and I've been using Poser since about '02.

Quote - If you want to read the readme, keep the original installation file (pretty good practice, anyway, in case a Poser library just Bermuda-Triangles on you, as happened to one of mine recently).   You can open out the zip file without actually reinstalling everything and you can read the readme.    Of course, if you do things that way, it's actually rather useful for the readme to be called something instantly recognisable, such as "readme".

No, it can be named anything at all...because the readme (or other information files) should be the only txt files in the zip.  Easy to find.

Quote - A readme that contains important information. Not 100 thank you's and a endless list of installed files. The list of installed files should be part of a seperate file and the DB script.
It's nice to see that the product consists of a few hundred files but I doubt I will ever check pesonally if every file was extracted/installed to the right location. That's a job for the system and not the reader of the ReadMe. In many cases the ReadMe could be reduced to the really important things: Product name - also already as part of the file name -, Vendor name and contact information, Product creation date and Product revision if applicable.

This is the end...

**Not much can be done on this area. We vendors have rules to follow or our product fails testing. And the rules state that we MUST list the files in the readme.

May I kindly suggest that before all the complaints about product packaging are in, that you reads the rules for submission to each site? Renderosity in particular since this is where you have chosen to list the complaints. The rules are there for anyone to read. If you have something you want changed in the rules, all I can suggest is to contact store@renderosity.com and place the complaint/suggestion to them.

The other items mentioned in this thread that are not specific to the rules are valid ones and I agree vendors should be reading and taking notes.**

It's less a problem of  what some rules say than of fixing imperfect and incomplete rules for those who need detailed rules.

I didn't say it's all your fault, Unicornst.
However, the vendors are as well as the customers able to say what they want to have changed or why they do things in a certain way. Referring to some rules all the time doesn't work out well.
I know the "rules" and they don't say anything about unique file names, conventions, directory structures or databases.

Some ReRo people read this and can notify the responsible people of MP about the complaints.
They can change their rules or come with some reason why not to do it.
I write it here because in the end there will be different things that bother different people. A thread like this is a good place to write down all the wanted changes and all the complaints about what is going on.

"Someone who thinks logically provides a nice contrast to the real world." - someone said. :p*

There are vendors which do a good job with their products and files but some just mess things up. I won't give examples for good nor for bad vendors here.

*No, it can be named anything at all...because the readme (or other information files) should be the only txt files in the zip.  Easy to find.
*Who reads the file format before the file name?

You don't need to read anything to spot a text file

Far more insidious than the thumbs.db are the MAC bits and pieces that can sneak in, these drive me mad because I manually install everything so that it is in the right subcatgory of the specific Runtime.  XP will brainfart on moving these so you can't just go and copy from Geometries or Textures to your chosen destination, oh no you have to go right down to the final folder in that section and then rebuild the particular path in your Runtime so that you can put it where you want it.

I understand the gripes here which is why I manually install all files into my own folders so I put everything exactly where I want them. This way there is no problem finding anything. I may need to rename some sub folders but it's really no problem.

For me it is a common game whenever I have to find something that is in my P5 Runtime.

One of these Prop folders contains an interior set piece of a mansion.  Can you guess which one?  Go on, click on the pic, take a look and see if you can guess from the name alone.

It can't be that hard.  I mean, This is only a slice of my default P5 runtime.  I had to scroll a long way down to just get this little sample.

Why is a mansion interior set in a folder called "scenery"?

I found this when I was looking for some trees and rocks (some "scenery") one day recently.  I forgot I had bought that damn thing!!  I haven't seen or used it in years!

Is it too much to ask for a folder that makes a bit of sense?

How about this problem?

I have outfits that I don't know who the hell can wear them!!  Is it for Aiko is it for V3, V4, Jessi, Jessi G2?  WTF!?

Is it too much to ask for the vendor to maybe put the initials in the thumbnail?  I think I have like two sets of clothes where someone nicely did this.  I look at those outfits and I know they are for V3 and V2 because the thumbnails have it clearly printed on them.

Hair vendors seem to get this for the most part.  Actually, almost every hair I've ever bought is quite clear on who it fits or int he pose flolder who it can fit.  HUGE KUDOS to the hair vendors!!

Oh, and the naming textures thing?  Yeah, I still remember installing something where a vendor named his texture "metal.jpg" and it installed in his folder (not so bad), but it over wrote another metal texture that was in a package I had bought a few months earlier from him!!  I wrote to him and never did hear back.  Not impossible to fix (backups of original zips and all that), but really annoying to find out months later when i decided to pull out the older product for some use.

Oh, and most importantly I will echo the readme thing.  I don't think I should have to dig around in my CD backups looking for a merchant's readme.  Sorry, not something I should need to do!  Make it clear and in it's own folder in a readme folder.

Oh, and one more complaint:  NAME YOUR FOLDERS AT LEAST SOMETHING SIMILAR!!

Man, trying to find the texture folder for something when the folder is named after the artist, but the pose folder was named after the product and the Geometry folder was named after the concept, is about enough to make one become very violent and stop buying products form anyone anywhere for months on end!!!

Quote - smallspace: you're correct. That's why the geometry of the V4 Warrior stuff is called V4WarriorCape.obj, V4WarriorPlates.obj etc.

I wouldn't consider that good filenames. Why? Because there's a good chance that they aren't unique because another merchant will probably make a product using the same names. And if you want to use both products in the same scene you'll end up with one working outfit and one that loaded the wrong obj-files... Filenames that are not unique are the biggest problem as Poser will only load one texture/object with the same name no matter how correct the path of the references is.

Got a point there, Dizzi. Problem is that there's a maximum to filename length. The idea of adding a hash or CRC to the filename would ensure its uniqueness, but chances are that the filename will be too long, especially for MacOS.

Maybe a hash code, limited to 8 characters, would do the job.

As it happens, I was finishing off a submission to 3dCommune as I read
this thread.   Looking at my filenames, I realized some of them weren't
specific enough, and corrected it.  (Added the name of the house to the
pose files like "view-leftwall".)

FWIW, the 3dCommune testers are *thorough. *  They won't let absolute
filepaths or unmatched names get by.  This is slightly annoying for the
creator, but a boon for the buyer.

The one complaint that I enthusiastically join is mysterious folder names.
If the character goes in the DreamVillage folder, all of its components
must have DreamVillage somewhere in their path.  Its geometries
shouldn't be in runtimegeometriesMyGreat3DDesigns.

Quote - It's less a problem of  what some rules say than of fixing imperfect and incomplete rules for those who need detailed rules.

I didn't say it's all your fault, Unicornst.
However, the vendors are as well as the customers able to say what they want to have changed or why they do things in a certain way. Referring to some rules all the time doesn't work out well.
I know the "rules" and they don't say anything about unique file names, conventions, directory structures or databases.

Some ReRo people read this and can notify the responsible people of MP about the complaints.
They can change their rules or come with some reason why not to do it.
I write it here because in the end there will be different things that bother different people. A thread like this is a good place to write down all the wanted changes and all the complaints about what is going on.

"Someone who thinks logically provides a nice contrast to the real world." - someone said. :p*

There are vendors which do a good job with their products and files but some just mess things up. I won't give examples for good nor for bad vendors here.

**Oh, I knew you weren't saying it was my fault. I was just trying to point out that not everything is under the vendor's control. And I, personally, try very hard to not make things confusing in my products simply by using some of the most unique names I can find (I tend to use Celtic name websites for that) and by being sure that every texture that belongs to the product (as well as the readme) has the name of the product in it either whole (if it's short enough) or by initials. Then I actually count how many characters I am using in a title to be sure it doe not go over a certain amount. If it does, then I resort to a shortened version but one that still lets you know what it belongs to. Last of all, I place all my textures inside a folder bearing my vendor name so that you can look for my name and find the matching product folder. And all of these files are listed in the readme simply because Rendo says we have to list them.

Yes, vendors have been in many discussions with the ones who run the MP as to the contents of the readme. Unfortunately, we cannot discuss those talks in public. So I really can't say any more on the matter. All I can say is that most....and I only mean most, not all.... vendors try very hard to please not only the rule makers, but the customers as well. And it's a very fine line we walk a lot of the times in giving you, the customer, what you ask for and following the rules so that your product does make it past the testing here.

As for missing textures...cr2s that don't load right... I really don't have a suggestion. I can only say what I do  and that's if something is shown to be wrong in one of my products, then I'll either replace it with a fixed version or offer you a refund. We are all human and we do make mistakes. Sometimes, those mistakes are even passed through a tester because they are only human as well. My only advice is to deal directly with the vendor and if all else fails, ask for the refund. If you can't get in contact with the vendor within 3 days, then I would contact either Deb or Clint about it.

Think I might have to change my sig line? wink smiles**

Hello Everyone

How are you all doing?  Great I hope.  I've been lurking on this thread while we've been working on several projects.  I think some valid points have been presented.  I have a few questions though.  See,  when I work I lump everything together in one folder.  Usually,  in the libraries character folder.  

I guess my first question is,  do people want the folder named by artist or by item.  Second question is,  if the items are set up in typical poser fashion,  do they want a consistent name on the folders. 

As for the files,  would an addition of small case letters to the name be acceptable.

My final question is,  how would everyone like the files to be structured on the original figures that we are working on.

Side note:   We've had both outstanding and p*** poor experiences with beta testers.  I could go into a rant about the poor experiences,  but it's not within in my nature to do so.

Anyway,  everyone,  thanks for your time and have a great day!

Peace,
Patorak

For me it's basically if you HAVE to have your name on it (and apparently many consumers enjoy that as well) then please list item also.  
So to appease both parties it would be like Patorak-overcoat i think.  

For me I would prefer creator names in the readme only, however that appears to not be viable for the majority of consumers.

I don't sort my runtimes by vendor but by catagory anyway - ie svdls textures for clothing are now residing in the same folder as evileets.

Quote - I wouldn't consider that good filenames. Why? Because there's a good chance that they aren't unique because another merchant will probably make a product using the same names. And if you want to use both products in the same scene you'll end up with one working outfit and one that loaded the wrong obj-files... Filenames that are not unique are the biggest problem as Poser will only load one texture/object with the same name no matter how correct the path of the references is.

I'd blame this more on Poser's poor referencing than anything else.  Poser should do what my code does when referencing geometry and textures:

1. Use the path as specified (even if relative) - usually not guaranteed except for someone's own scene file.
2. Append Runtimes to the relative or 'relativized' (cutting back to 'Runtime' or below) path.  This should resolve almost all references and get the correct one in the process.  This is where Poser seems to go about it stupidly and go for the next step directly.
3. Search the Runtimes for the file.
4. Ask the user when all of these fail.

This way, as long as V4WarriorPlate.obj is in Runtime:Geometries:[ProductName] or [Merchant] or [Merchant][ProductName].  File paths are still limited - not as much as before, but if you start specifying 200 character names:

C:Program Filese-frontierPoser 7RuntimeGeometriesJoeBob3DV4 Warrior PrincessJoeBob3D_V4WarriorPrincess_Plate01_FrontPlate_Chest.obj

it's gonna get frustrating all around - and it's insane...  Aren't the Poser files large enough already to make this type of unnecessarily extended naming unfortunate?  Just use a good folder structure:

JoeBob3DV4WarriorPrincessPlate.obj
JoeBob3DV4WarriorPrincessPlate.obj

Qualified on Poser's ability to reference Plate.obj.  Otherwise, use JBV4WP_Plate.obj for some foresaken brevity and uniqueness.  You cannot fault vendors for Poser's shortcomings in these regards.  tyvm

Quote - > Quote - As it happens, personally, I install to an empty directory, sort, rename, then move it to the actual runtime when I'm happy with it.

 
After many problems with files, I do the same thing.

Merchants are free to name their folders after themselves, if they want, it would be even more of a boon if they did it consistantly, so that all fo their items fell into subfolders off their main folder.  I can learn.  The more value in a single folder, the more valuable that folder becomes to me, the more that I remember, "oh yeah, that cool dress was by Aery Soul" or some such thing.

But, PLEASE, PLEASE, if you have a vendor name that sounds like an object I might wnat to use, rethink your folder structure.  If you your name is "Scenery", "Enviroment", "FastCar", "BigGun", or anything liek this, then please don't use your name as your folder names.

Man, I hate finding gun props in a folder where I expect to find teddy bears and teddy bears in a folder where I expect to find guns.

One has to be half insane to have this freakin' hobby!!!!

I see that my forward slashes disappeared.

Let's try this:

JoeBob3D:V4WarriorPrincess:Plate.obj
JoeBob3D:V4:WarriorPrincess:Plate.obj

@Kuroyume:  There's still a genuine problem with using simple
generic basenames for OBJ or JPG files.  If Poser can't find something
in the original path (eg because you've renamed some folder), it will 
look elsewhere, in the order given in libraryPrefs.xml.  The resulting
OBJ or JPG will be wrong, but will often be deceptively similar
to the original.  So you can have a strange result like missing parts
or peculiar textures, with no immediately obvious reason.

This won't happen as often with unique base-names.
Poser is much less likely to locate a "similar but wrong" file named
1860LogCabinWithFireplace.obj in some random folder.  Instead,
it will give a nice meaningful "file not found" error, and you'll have
to look for the exact file manually.

That's the thing.  If the geometry or texture file is in the Geometries or Textures folder, the reference is correct, and the folder name hasn't changed - then Poser should find that exact file every time.  Otherwise, stop renaming the darned subfolders there or the reference path is incorrect - both stupidity (user or merchant).

But it is my understanding that Poser always takes the first match encounter no matter the fact that the actual file resides where it should - which is poor, poor coding if that is the case.  In other words, I don't care if you have 10,000,000 'gold.jpg' files in your runtime - if the relative path to each is unique then it should ALWAYS resolve to the correct one.  If this isn't how Poser works, maybe we should pressure the developers to work for their income...

This would need to be verified, but it sounds that if the file path is correct Poser will still take the first filename match.  Otherwise, there would never be contention as long as users don't meddle in the Geometries/Textures folders and the merchants use proper relative paths: ":Runtime:Textures:Hithere:HereItIs:Gold.jpg" should work every time to reference that particular file as long as it is a valid path.

This is why I challenge the veracity of Poser rather than merchants.  I have yet to encounter a merchant texture reference like: textureMap "gold.jpg".  This may happen on occasion, but the overall feeling reading this thread seems to be that even - textureMap ":Runtime:Hithere:HereItIs:gold.jpg" - incurs the same situation.  Otherwise the point would be moot.

Note that I'm not arguing one way or another here - just trying to discover why "gold.jpg" as a file name has such visceral reactions when, in the proper folder hierarchical context, it shouldn't even be noticed.

ETA: I understand that Poser will do a search and take the first opportunistic filename match when it cannot find it otherwise.  But that is just the practice.  I do the same (see other post).  It doesn't mean that it will find the correct match just that the search will try to resolve a missing reference.  I did the same because it is better to seek and to find than to pester the user first. :)  This is not a user, merchant, Poser matter specifically.  If the product is proper and the user puts things as they should be then Poser should find the referenced file.  I can sympathize with those who have found products that are incorrect (bad reference paths, missing files).  These things should be rooted out by testers (ehhem).  In other words, such occurences aren't one single responsibility (though most of it lies on the merchant's shoulders).  Poser does 'the best that it can to resolve a reference when all other avenues fail.  Maybe a better approach would be that when Poser finds a match through search, to ask the user to use that or select another (?).

Lot of contradictions in this thread. Which rather underlines the problem a conscientious merchant faces. We'd like to do right. But what is right (beyond, of course, better quality control) is not always obvious. For that matter, we'd like to pass Rendo testing. Historically the Rendorosity testing procedure has been random and undocumented enough that many merchants -- perhaps the majority of merchants -- have been unwilling to experiment. They'd rather use what passed last time, then take a chance and throw away all their hard work by trying something new. I know people who have had products fail testing due to not using "readme.txt" as their readme, or placing it inside the Runtime folder but not inside a folder named "readme." I've been failed for placing anything outside of Runtime, readme or not (and yet, on different occasions this has passed -- go figure.) So on the one side, merchants tend to be extremely conservative. Rendo has not been good towards support of alternate file structures, naming schemes, or use of non-standard options (like mtl files instead of MAT poses). On the other side, many questions have no clear "best choice." Take the contradiction implicit in the first post in this thread: "unique file names" versus "no long file names." Excuse me, but if I have a high-heeled shoe that fits Victoria 4, with say a red texture, AND it isn't the first high-heeled red shoe I have made, then a suitably unique name is going to be pushing the character limits for thumbnail display. Making this human-readable instead of machine readable (aka "My_V4_HighHeelShoe_Strappy2_RedLeather_BUMP.jpg" versus "V4s4c00404bm.jpg" only compounds the problem. And are folders an option? Again, within this thread, arguments against nested folders, arguments for them, and strong disagreement as to whether items should organize by merchant, figure, type, item, or character. Plus of course the folder scheme that works for textures might not work for the figures directory, and if the poor end-user has to delete or move the thing they'd really prefer a consistent scheme. For instance: I'm reworking a couple of old products to fit both the original PT girl and the new(er) Laura. Should I folder them by my own store ID, by the figure name, or by the items -- with then stuff for both figures stuck in the same folder hierarchy? If I do split up by figure, how can I possibly guess what the end-user has used to separate those figures, and how can I make it simplest for them to move my folder tree into theirs? I can't offer alternate or multiple zips, installs, or runtimes (not by current Rendo rules, I can't.) I could make two products, but I don't want to make people pay twice. Could I offer the L3 fit as a separate download available as an email link? Lots of problems inherent in that as well. This post is not meant as an excuse for poor organization, by me or anyone else. Nor do I want to stop at identifying the problem. Please, let's discuss, and maybe somewhere out there there IS a most-logical solution. I for one will gladly adopt it. Just to share, this is my current organization: Runtime .......geometries .................Princess ...........................Music_set ..................................lg_condenser.obj et al. I have also been attempting to strike a balance between length of file name, sufficient identifiers, and readability. On my current set a typical file is something like; Runtime ......library ...........props .................Music_set ......................Smart_props ..............................L3_vocal_NC.pz2 but I'm afraid the name length would compound ridiculously if I had to include merchant, set, and purpose within the individual item name.

A few more thoughts:

1. Be sure to name your obj files wuth unique names as well. Like using textures with the same name, Poser can easily use the wrong file.
   I know of at least one case where Poser used the wrong obj file when loading a prop even though the pp2 file pointed to the right one. For whatever reason, Poser decided to use the other obj with the same name.
    
2. People should feel free to use their own names as folders, but please be consistent. Don't change the names of your own folders and wind up with a mess like this:
   Johns_Folder (with an underscore)
   JohnsFolder (no separation)
   Johns Folder (with a space)
   Johns-Folder (with a dash
    
   I don't know about you, but as a customer, I certainly wouldn't want to see piles of these similarly-worded folders building up in my Runtime folder.

Daz is the worst for installing props in the "scenery" folder where I can't find them.

That is exactly an instance of which I speak.  The reference was correct but Poser chose the incorrect one.  That is for the developers to resolve - not merchants (in the final analysis).

I agree that it is rather easy to create at least seemingly unique filenames for geometry and texture files.  But remember 8.3.  When the number of files is in the billions and certain extensions are reused so often so as to be ridiculous (that is another topic for OS related gufaws) this seemingly good format failed.  Who'd ever need filenames with more than 11 characters?

Yeah, you get something like comb(11, 48) (48 = 26 alpha + 10 numeric + 12 other).  It's a very large number.  But not when the number of files reaches billions or trillions and there is no strict regulation on naming conventions.  The current filename length is 256 generally (iirc).  That allows for much larger combinations - and yet it is plain to see that filenames are continuously reused - even when long in attempts to be unique.  Let's face it - with autogeneration of files for various reasons, we can speculate on quadrillions or many factors more of files out there.  The number is just staggeringly impossible to imagine.
So that doesn't preclude the possible incidents of repetition.  Two merchants may use the same prefix (MyPoserStuff and MichaelsPoserShaders = MPS).  It has already been noted that 'unique' here can only be guaranteed by retaining a database of all files out there (in whatever context, this will be impossible) that people can use to identify uniqueness.

The internet uses a rather interesting system - fixed static IPs which are doled out to particular individuals while maintaining a layer of reusable 'local' IPs for internal networks (195. and so on) and dynamic IPs from a block of acquired static IPs.  That is the extent to which the internet avoids repetitive IP addresses (N.N.N.N where N >=0 <= 255).

Cinema 4D plugins have an ID system.  There is a block of LONG values for internal testing and use.  And there is a system to get unique IDs.  You request 'the next' ID from the pool for a new one.  You can always reuse one if not out there for a current product of your own.

You want truly unique filenames, you need a regulatory body to track and maintain that uniqueness.  There are no guarantees that obfuscated naming procedures (KDZ001FNK001A.obj) will never be reused otherwise.

Yep. There are shortcomings on Poser's side. They should make it a open source project for Poser 8. :tt2:

Back to filenames or product naming. I don't know why someone want his name in the filepath or visible in the application (i.e. Poser) if the ReadMe contains it already.
At first, when I had very few products, I used to keep the files in the order they came from marketplaces.
E.g.: ":Poser nRuntimeLibrariesCharacter"

That was not a big problem because there were 1) few products and 2) few vendors at all. Now there are products of hundreds of vendors and this system is confusing. A good solution would have both, the new Poser user and the long time Poser user, in mind.

Example of the structure of some of the products I have installed:
"..ReadMe's"
"..RuntimeGeometries"
"..RuntimeLibrariesV3Body"
"..RuntimeLibrariesCharacter"
"..RuntimeLibrariesPose"
"..RuntimeTexturesCharacter"
"..RuntimeTexturesCloths"
"..RuntimeTexturesClothsTemplates"

If there are let's say 20+ products of one single vendor then it makes sense to place them in one folder with the vendor name.
But that is rarely the case. Reality is that there are many many folders with vendor names and very few peoducts in them.
Often it's only 1 product.

"..RuntimeLibrariesV3Body"
That makes not much sense for example. There are only some .pz2 files in that folder.
The reason for the "!" and the reason for the location of this folder I can not see.

"..RuntimeLibrariesPose"
Sure, I expect poses in "..Pose" and not in "..Geometry" or "..Python". Needless to name the folder and needless to place that ! there. The word "Poses" I won't even see in Poser's library palette because the product name is so long already.

"..RuntimeTexturesCloths"
"..RuntimeTexturesClothsTemplates"
This is good. In the texture folder it makes sense to gather all textures per vendor.
The templates however can be located in one templates folder.
"..RuntimeTexturesTemplatesCloths" looks better and makes finding templates easier because if one looks for templates, he will look for some folder called "Templates" and for the vendor maybe after this.

"..RuntimeLibrariesCharacter"
This one is good too. If one installs a single product it's quickly to reorganize this structure.

In the case of "..RuntimeLibrariesCharacter" one quartal later the user won't know anymore what the single vendor-named folders contain.

For giving credit it can be helpful if there's a dummy file with the vendor name along with the pose files. Hair colors for example or any other stuff. It's more useful than placing the vendor name in the file path because it is visible if the library palette is opened to load the mat pose or the mesh.

For the hierarchy is to add: Below "Geometry" comes the geometry. - Similar to the case of "Template".
A geometry could be clothes, hair, props. These are broken down logically.
Clothes can be
"..GeometryClothesMenShoes"
"..GeometryClothesWomenShoes"

And so on.
Fantasy clothing also belongs to some real world category. Plate, leather, chain, scale armors belong to Armor etc...
Some magic wand belong to primitives --> cylindrical --> staves --> wands. - Or whatever. Have a look at what gaming industry does.

Real world industry gives some good example patterns for clothes and other stuff like houses, furniture, vehicles.
Hair can be sorted by it's default style, props can be sorted by their function.
A house would be somewhere around "..GeometryPropsdwellings"

From elementary particles up to stars and galaxy clusters everything can be classified and sorted.
If one creates a whole new universe the real world may fail to serve with some sorting pattern. In this special case it's ok to place the universe in whatever folder you want. As long as it sticks to Poser's file system.

Quote - Take the contradiction implicit in the first post in this thread: "unique file names" versus "no long file names." Excuse me, but if I have a high-heeled shoe that fits Victoria 4, with say a red texture, AND it isn't the first high-heeled red shoe I have made, then a suitably unique name is going to be pushing the character limits for thumbnail display.

So, if your MAT file is for a different shoe, why is it in the same pose folder?  Because if it isn't in the same pose folder, there's no problem.  If your folder has a reasonable name, the names of the files inside can be short without losing any functionality or causing confusion.

Here's an example from my own runtime.  One set of pose files for V4 is named "Pose 1", "Pose 2" and so on.  There are at least three other sets in my Pose directory that use the exact same naming convention.  But there's no mixup and they don't overwrite each other because they are in different folders.  In this case they are actually files for posing, so they don't need any more elaboration in their names.

If your MAT files for one set of shoes are in the "HiHeel1" folder, and the other MAT files in the "HiHeel2" folder, there's no problem if there's a MAT file named "RedLeather" or whatever in each because they won't get mixed up.  There's no need to use something like "MAT HiHeel01 Red Leather BUMP" and "MAT HiHeel01 Red Leather TEX" (and I've seen things like that) when "RedLeatherBUMP" and "RedLeatherTeX", located in the HiHeel1 folder, do the same thing.

What I see happening here is that people are confusing two different issue.  Things like Geometry files and texture files can have long unique names because people don't see them in the Poser interface.  Short names are needed for the things people do see and which can cause confusion and problems.

For the limited space on the library palette the naming could consist of a easy to memorize part that is visible and some alphanumeric part that is not visible in Poser and that makes the file unique.

Something like "Some Shirt_2f3ee91635d7897a71209f02d01280e5.".
This should give plenty room for combinations until there's a better filesystem coming.
The maximum path lenght should be 256 characters for NTFS. With more then 244 it can cause errors however. Maybe the full hash with 32 characters is to long.
With an 8 character hash, like svdl suggested, there would still be ~281.5+e12 combinations for the hash alone, if restricting to 0-9 and a-f. Long before this number of files is reached the OS will have trouble and there is no such harddisk capacity available today anyways.

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.

Heh. There are many examples in the outside world of shorter-length hashes that are sorted by various agreements. I think of MIDI sysex headers, for instance, which after specifying that the first hex group would be the manufacturer's ID, the MIDI consortium (of manufacturers of musical instruments) got together and decided that Roland would be 01, Yamaha 0b, and so forth. Unfortunately this formatting restricts any one manufacturer to having less than 256 different keyboards, drum machines, or sound modules that can have a unique ID (as they were given the next hex group for this). In any case. I can easily image a system by which, say, the first two digits uniquely identified the coordinating group or market used by a merchant, the next four digits were their unique ID within that group, and so forth. What I can't imagine is such a system being imposed, or remaining practical after merchants had changed names, stores, partnerships, made mistakes and corrected them, had religious objections to certain number sets, etc.

I agree with Keith on this.

The interface is one thing and the internal naming is another.  I rarely have Poser searching for objs or texture files.  I have never had a problem with Poser loading the wrong file fromt he wrong folder.  That is just weird and I think a rare thing.

I am willing to admit that maybe I am one of the few people who might want to modify a texture, so for me I want the file folder structure to make some sense too.  Ont he other hand, I've become quite accustomed to using my Search function, so maybe it isn't as important.

First things first, though.  A naming structure int he interface that resolves a few issues woudl be nice.

I love when a vendor stays consistant with their folder names.

I hate folder names that make me think of different objects.

I love when there is some differentiation in a thumbnail or file name to identify who the item is for.

I hate that the top of my runtime is cluttered with !!!!! things that really don't seem that important int he grand scheme of things.

I love vendors who put their readmes in a separate folder and maybe even throw the product name or the vendor's name into the name of the readme.

I hate getting a million readmes dumped into the same place.

Oh, and I'm glad to hear the some MPs are not allowing anything to be outside the runtime folder.  My Poser 5 Folder has 96 folders and I don't know how many loose files!!!

I was actually very surprised when i bought Poser 7 and found the base folder so empty.  My gut response was that I didn't get a complete download! LOL.

Too funny!

Anyway, I just have to post this, because I need to know, I am the only one who's base folder looks like this? (I will point out that it actually goes down with the loose stuff for another page or so, but this is the tip of the iceberg!)

I mean, my P6 and P7 don't (yet), but I have been much more diligent in creating my own runtimes to categorize things.  But I really think the average person out there who delves into Poser as a hobby must end up with some similiar mess.  It wasn't until years went by before I started cleaning things up, or even became aware that I could clean things up.  I remember how intimidating all the file extensions were at first and how I paniced at the idea of moving anything out from where it had been installed. 

Anyway, maybe someone else will find this good for a laugh.

:lol::lol::lol::lol::lol:

After a reinstalling Poser and all kind of add on content I had a Poser folder that looked similar to your screenshot. After this accident I started to add Poser and related files to the sys DB and sort them the way I want them. Right now I have 8 folders in Poser. I'm not done with changing relative paths in some files so that I can clean up the Runtime folder. There is a total of 10000+ folders under the Poser directory...

I still never know whether to organize my own runtime by item kind (aka "men's clothing, vehicles..." by figure supported, or by style (aka "fantasy, noir...") Sorta organize by projects now; assemble a runtime for everything I'll be using for a couple of vaguely related renders...

Yep, mine looked about like that I guess. I never really looked at the folders in the Poser runtime folder, just saw them through the library in Poser. But I certainly can relate to not being able to find anything when I was a newbie to Poser.

I got Poser in the Spring of 2004 I think. I was so intimidated by the fact that I had these really, really long menus in Poser and I coudln't find anything. Also, to me a "texture" should have been applied in the material room and not from a Pose folder in the pose room. That really messed me up.

It took me literally 7 or 8 months to figure out poser and actually make a render of a figure. A few months after that I learned that you could make subfolders in the library folders and organized my content that way. But I still had a hard time finding stuff. It was then I learned about external runtimes and started with 2 or 3 of those, but kept going back to the 1 runtime and subfolders. One day after a reformat I created external runtimes again and forced myself to get used to them. I was so tempted to dump them back into the main Poser runtime. Eventually I got used to it and each reformat saw me splitting up my runtimes into more and more.

But then you run into those stupid DAZ installers. Fortunately you can subvert them (with a little effort) and manually install the stuff into a directory or runtime of your choice. I guess us Mac users have a jaundiced view of the whole install thing anyhow. If I were to "open a zip onto my existing runtime" all it would do is DELETE the original and replace it with the new. Manual install becomes a way of life.

Quote - I guess us Mac users have a jaundiced view of the whole install thing anyhow. If I were to "open a zip onto my existing runtime" all it would do is DELETE the original and replace it with the new. Manual install becomes a way of life.

Ditto. Oh, ditto. I have things arranged 'how I can best find them when I need them', which is absolutely different than anyone else ever planned to set anything up, I'm sure. Since I have to do manual installs anyway, it seemed like it wasn't hurting anything to go all the way with it in terms of the items that actually appear in the library palette. Geometries and textures I just leave alone and where they were intended to be, but everything else goes where it's easiest for me to find it. Other people would probably be driven completely bonkers by my setup, but the reverse is also true. In terms of 'the files I access in-scene', everyone is going to have a different preference and setup. I have a runtime per character I use (and one for creatures, one for scenery elements, and so on). A lot of people don't do this, and therefore their setup needs are going to be a little different than mine since "it goes with this character" is assumed in the runtime selection. A lot of other things can easily influence this, too. For example, I broke up my pose folder into things like 'hair:style:texture sets', 'clothing:item:texture sets', 'character sets:product', 'poses:product' and so on and I never have any trouble finding anything now, but it takes a lot of work and upkeep. I'm not going to assume anyone at all has done anything even remotely similar no matter how much sense this makes to me, so I'm not going to structure an item in that way for distribution. I stick to the runtime:textures:surreality:product:file.jpg thing myself for textures, but that's just... intuitive to me. It's easiest for me to find what I need. Same general setup for the pose folder, with the knowledge that people can move the contents of that folder around, subdivide them, re-folder them, rename the folder, and so on, to best fit their file structure.

Poser is the only program that allows for naming folders. I think it should done away with. I've given up that. I no longer bother. The texture folder is such a screwed up mess. I quit trying to fix every folder. I still prefer how DAZ does it. They name it DAZ. and then subfolders. Less confusing and less !!!!! in front of a folder name. My runtimes are so full I can't  install anymore because my Poser texture folder is crammed with long winded silly names that takes up room and wastes space on my drive. I will not buy from any vendor that does the funny character name bit, !!!! or give their products a strange name and then name their geometriy & texture folders two different things. Nope. Unprofessional in my opinion.

Dunno. There's something about Poser that screams "hobbyist" way to loud.

Maybe a highly professional order that's done with only productivity in mind is not the right solution.
Whole Poser itself isn't designed for high productivity.
It's more like some tuned gameeditor that lacks a real script interface. HoMM V Editor, UnrealEd, NWN Toolkit, SpellForce Editor, Earth 2150 MapEditor are all designed for productivity in some way.
Poser is closer to these applications than to pro 3D apps. That's actually a good thing.

I have to say that I'm happy about the fact that some people enjoy it to provide content for the community, freebie creators or vendors, it doesn't matter.

Poser should stay with this trait of an fun-application but something needs to be done to manage the huge amount of 3rd party content.
The ability to create and rename, copy and cut folders and files using the Poser GUI and a decent script interface with syntax highlighting is something that e-frontier has to take care of.

Regarding the 3rd party items it would be useful already if they find some conventions and stick to them. That alone would already help to limit the organisation work/time for the user/buyer to acceptable amounts.
Only thing required is that everybody sticks to such a convention what shouldn't be asked to much sice industry can do it too and for many decades already.

...Reading the thread and scratching my head... 
Now i can't decide how to structure the folders for the freebie I'm about to submit... 
:blink: :blink: :blink: