Forum: Poser - OFFICIAL


Subject: The Rules for Content Providers (yes, I'm looking at you)

Keith opened this issue on May 11, 2007 ยท 124 posts


Zarat posted Fri, 11 May 2007 at 11:39 PM

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...