Recently I purchased a product, installed it, gave it a test ride, and noticed that none of the morphs worked. So I had to open up the cr2 file and figure out what was happening. It turned out that the cr2 referenced a pmd file that was assumed to be in a specific, hard coded directory like this: 

:Runtime:libraries:Character:<vendor_name>:<product_name>:whatever.pmd

To get it to work I had to move the pmd to a directory where I keep all my orphaned morph files, and edit the cr2 to reflect it's new location.

This is not an unusual problem. It makes the false assumption that everyone installs their content in the default libraries and in the same sub-directories as the vendor uses. I could be wrong about this, but I will guess that almost every Poser user quickly sets up their own approach to content management. Very few continue to use the default installation.

Anyway I went back to the product page and noticed that it was rated 5-stars. Even some of the reviewers that complained about the lack of working morphs gave it 5-stars. Maybe I'm being too harsh here, but I can't see how a product is worthy of 5 stars when it requires - I don't know - 90% of its users, 50%, even 30% to have to edit the cr2 file to get it to work. 

That's just one example. It's not at all unusual for me to have to edit some of the files for one reason or another.

Then, of course, some products are just better than others, but I don't think I've ever seen one rated less than 4 stars and even 4 is extremely rare.

It just seems to me that a rating system in which everything gets the highest grade is no rating system at all.

OK, OK... I'm just blowing off steam here. Thanks for allowing me to rant.

If I was happy with the rest of the product I guess I would rate it a 2 or a 3.

A product is supposed to be user friendly unless nothing else is stated.

The product apparently works correctly if installed at its proper location mentioned in the readme file. So the product is not "bad" because of that.

I would prefer creators would put PMD files in geometries, but others prefer them in the location where the CR2 lives. So the creator made a decision to put it in the cr2 folder (which is the default where Poser puts it if you create your own PMD files)

People who reorganize their runtimes are (or should be) aware of the path reference issues and be prepared to correct them or have the search option set the Deep.

I usually fix the issue by installing it to the default location and then move the CR2 files to my desired location. The advantage is that you do not need to edit the cr2's and the disadvantage is a cluttered root in the runtime:libraires:character folder.

wimvdb, technically you're correct. The product works as advertised. I just don't think that reflects reality very well. It's like burying some critical piece of information deep inside a software terms of service agreement and expecting regular users to actually notice it.

I've not actually polled the Poser community on this, but my impression is that very few users actually use the default library structure. That means that everyone who uses a non-default structure will have to do extra work to get the product to work when the vendor could have saved everybody that extra effort by putting the morphs in the Geometries directory, or anywhere outside of the Library directories. So instead of the vendor doing something one time, you've got, what... 100, 1000, 10,000 users doing it 100 or 1000 or 10,000 times.

I should mention that some of the product's reviewers who complained about the lack of morphs appeared to be unaware of the obvious fix and resorted to other workarounds.

I realize that Poser doesn't provide vendors with any kind of standard of guideline for this sort of thing, but it looks like most have settled on using Geometries or a Morphs directory within the library directory.

I suppose the best approach might be for Poser to be able to recognize relative paths like HTML, so that a reference to just a file name would assume that it is in the same path as the referring file, and something like :morphs:MyFile.pmd would assume a subdirectory under the referring file, etc

... also, you make a good point about the user created pmd files going in the same folder as the cr2.

Attached Link: Requirements

"All files should adhere to the proper file structure for the software it is intended to be used in. Poser products should follow the path :Runtime: ..., etc.."

Rendo's presumption seems to be that people use external runtimes to organize rather than changing the library structure.

Product creators are held to strict standards and their products fail if they don't do it the way rendo requires. Check out the "Requirements" link above. I'm pretty sure that is why it was put into the same file with the CR2, since that is where Poser puts it.

I've never had a problem using content from this store.  I just unzip and copy the RUNTIME folder over my own.  That way, the vendor subfolders etc are pointed to by the CR2s.

Or are you talking about a CR2 that had a path like E:DATA FILESPOSER_DEVGEOMS in it?  Those are very rare and are found more often at ShareCG.

Thanks for the link to the requirements. As I was reading through them I came upon this under "Morphs":

Custom morphs must follow the following path:

• Runtime:Libraries:Morphs:yourdirectoryname

So Renderosity in fact does require that custom morphs be placed outside the cr2. The custom morphs that I have seem to be roughly divided between the Geometries folder, the Morphs folder and some random folder the vendor set up.

While Renderosity may have strict requirements, they don't appear to be very well policed. A quick look at my content and the requirements shows that my stuff has lots of violations of the requirements. Of course it's possible that some of my stuff is older than some of the requirements, but there are problems even with the new stuff.

I'd love it if vedors didn't put "!" or "!!!" in front of their file names.  Thanks DAZ3D!

Quote - I've never had a problem using content from this store.  I just unzip and copy the RUNTIME folder over my own.  That way, the vendor subfolders etc are pointed to by the CR2s.

You're using the default library structure, then. Since P7, I believe, users have been able to place their content within the Library folders as they saw fit. Many of us - maybe most of us - have taken advantage of that and have organized our content in a way that made sense to us. For example, I put all hair in the Hair folder whether it's a cr2 or an hr2 file. All my outfits go in the Materials folder. Why not? It works for me, and it sure makes more sense than putting hair, clothes and characters all mixed up in the Characters folder.

I sort by how Poser content functions.  But I could see creating my own folders and browsing through them instead of going through Poser's built-in "browser".

You're right, ElZagna. I didn't read that far down. Nice catch.

Quote - Thanks for the link to the requirements. As I was reading through them I came upon this under "Morphs":

Custom morphs must follow the following path:

• Runtime:Libraries:Morphs:yourdirectoryname

So Renderosity in fact does require that custom morphs be placed outside the cr2. The custom morphs that I have seem to be roughly divided between the Geometries folder, the Morphs folder and some random folder the vendor set up.

While Renderosity may have strict requirements, they don't appear to be very well policed. A quick look at my content and the requirements shows that my stuff has lots of violations of the requirements. Of course it's possible that some of my stuff is older than some of the requirements, but there are problems even with the new stuff.

I don't want to be a nitpick here, but custom morphs are morphs customized for a particular figure. The ones you were talking about are native morphs - belonging to the clothing/figure itself (the PMD files). Nothing is said about that. Every Poser figure (as in Non-DAZ) uses PMD files and all have the PMD files (with their native morphs) stored with the CR2.

I have lots of content (probably more than most) and it is something I always watch out for. Many items (not most, just many) have the PMD in the CR2 location. Not only at ShareCG, but also at Content Paradise and other places.

If Poser loads a figure with a PMD (no matter the actual path reference), it will always find it when loaded from the library  - if your search options are set to Shallow Or Deep. The seach algorythym searches the CR2 origin path as well. Things get tricky if you save it in a scene file. The actual PMD file is stored with the correct relative path. However.... If the PMD file did not go through the search algorythm (for whatever reason) it is stored with its original path (the wrong one if you moved it around) and will not be found if search is set the Narrow. And that is where the problem is. If it would store the relative path for every item it loads in the scene file, there would not be a problem. But it does not

Smith Micro should fix this, but apparently it is not as trivial as it seems.  If you would change texture references which have no relative or absolute path to a relative path, it could break existing content

But I am going to repeat myself here: I am all in favor of putting PMD files in a separate folder - being it in Morphs or geometries. It would make my life easier

I'm afraid I didn't follow the custom morph vs. native morph part, but that's OK for now. The thing that stood out was your point that Poser  (Smith Micro) content places the pmd and cr2 together.

I never used SM-Poser content other than the primitives, so I wasn't aware of that, but it came as a real surprise. That seems to defeat the whole idea of arranging your content in a meaningful way unless you are willing to set your search options to shallow or deep, which I don't want to do. Maybe I'm just being old school about this, but I've always felt that if a file was not where it was supposed to be, I wanted to know about it so I could fix it. I don't like the idea of having an app look all over the place for something that seemed to be what I wanted.

And that brings us back to relative paths. I've done a lot of programming in my time on many different platforms and with many different languages and I never had a problem with relative paths. Consider HTML:

1. links in the same directory as the current page have no path information listed: filename
2. sub-directories are listed without any preceding slashes: weekly/filename
3. links up one directory are listed as: ../filename

Easy enough. I can't imagine why that would be difficult to implement in Poser unless there is something very unusual somewhere in the core of the app, and there might be.