There's a rant I want to make. And I know several of these things have been said before, but I'd like them in one place.

After I received Poser 7 when it came out, I started on a complete re-install of my downloaded content. Still haven't gotten through half the V3 stuff yet, but I've been doing it slowly to organize the folders in (to me) a rational manner) in different runtimes, checking the references in each zip and exe to make sure the pointers are correct, so on and so forth. And after you do a few hundred of them in a short period of time, you tend to notice the things that bother you. It was in this spirit that the following was inspired.

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?

Rule 2: I Am Not A Mindreader

In a similar note, if you want me to read your readme files, it might behoove you to place said files in a location where I would expect to find them. Buried in the library folders is not where I expect to find them. Placing them outside the Runtime folder, that's logical.

Rule 3: I Am Not Using Your Computer

Your Geometries folder might rest happily in C:Documents and SettingsuserMyPoserStuff. Mine doesn't.

Rule 4: I Am Still Not Using Your Computer

Which makes it rather difficult when the product I bought from you includes a reference to a reflection map or a texture that's not part of your product but is on your computer. And not mine.

Rule 5: I Will Decide What's Important on My Computer, Not You

Quick Quiz: Naming a file "! ! ! ImNumberOne.pz2" to get it to the top of the list in the library is
a) Dumb
b) Annoying
c) Unnecessary, since the folder it's in should have a unique name anyway, right?
d) Make me want to track down the merchant and beat them over the head with a keyboard
e) All of the above

Now that isn't to say that using the exclamation mark to get something to the top a file isn't justified. I like having the character inj and rem files right at the top. But having EVERY SINGLE FILE in that character's folder having multiple exclamation marks in front of it is stupid.

Rule 6: Remember That I Might Actually Buy Other Stuff From You

So when all your mat files or your pose files for all your products are named creatively, you know, like "01.pz2" and "02.pz2", and all your folders for different products also have the exact same name, one wonders if you only ever want any single person to only ever get a single one of your products so that they don't overwrite each other.

Rule 7: Just Because You Can Use Really Long Names Doesn't Mean You Have To

I mean, it's not that I don't get enjoyment out of looking at pose files and trying to figure out which one I want to use. Who wouldn't want to joy of seeing two thumbnails in the library with the exact same truncated name underneath them and guessing which one is the one you want to use?

Rule 8: My Textures Folder Is Possibly More Complicated Than Yours

":skinbody.jpg" might be a perfectly valid reference in a cr2 or a mat file for your apparently near-empty textures folder. However, given that I'm likely to have about 3,122 files with that name, your folder in the Texture directory doesn't have a name I can easily find, your readme file is located in the Hands folder and doesn't tell me what your folder holding the textures is anyway, do not be surprised if people get somewhat annoyed. See also Rules 3 and 4.

Can I get an Alleluia??

I personally dont think this topic can be repeated enough until those dang readmes are named something other than readme!

You forgot Folder nesting though. So.....

Rule #9:

We DO NOT want to have to click 10 times to get to your content! DO NOT put it in SeansStuff>stuffIsell>makesmebigbucks>atrenderosity>TEXTURES
kthx

I am: aka Velocity3d

I agree. I have purchased over 1000 items in the RMP alone and lately there are many mistakes in the code that I have to fix myself. I am still waiting on a hair fix for weeks. I fixed it myself in Crimson editor. The files pointed to the merchant's E:/ drive. It took me not even 10 minutes if that with search and replace to fix it. Why is it taking this merchant WEEKS to fix it? I should not have to fix items I PAID REAL MONEY FOR! Freebies are free and can have mistakes. Not purchased items I am sorry. Daz is even worse. Their readmes are messed up at least 30% of the time. renderosity is supposed to have testers for products. There is at least one tester who is missing these mistakes. Also poor English in the readmes.
I always rename my readmes to "Alice" or whatever it happens to be and keep them in a Poser readme folder on my desktop. it really helps.

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

*if thats a Rendo brokered product, don't blame the vendor. blame Rendo. Merchants here are required to use the same readme and in the same location or the product is failed.

Good topic and nicely done, I'd like to add one:
Putting a name in front of "runtime" in the zip file is really annoying because it doesn't go in the runtime, it goes someplace else so with these I have to unzip to a temp folder before copying them to my runtime.

Injustice will be avenged.
Cofiwch Dryweryn.

How about this. Let's start a list of "banned from now on" generic texture names. I'll get it started with:

wood.jpg
chrome.jpg
gold.jpg
silver.jpg
rock.jpg
stone.jpg
wall.jpg
floor.jpg
ceiling.jpg
house.jpg
oldwood.jpg
silverref.jpg
silverreflect.jpg
silverrefl.jpg
brass.jpg
translash.jpg
eyereflect.jpg
brick.jpg
fetchrome.jpg
chromemap.jpg

Anyone care to join in?

I'd rather stay in my lane than lay in my stain!

Quote - *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?

*if thats a Rendo brokered product, don't blame the vendor. blame Rendo. Merchants here are required to use the same readme and in the same location or the product is failed.

No, they need the same licence file. Which I don't care about (since they are all the same).

I just checked assorted Renderosity downloads and there doesn't seem to be a rigidly adhered to system for naming the product readmes or where they are located.

I agree with most, but not all, of the points raised above.

Folder structure: it may make SENSE to use a nested folder structure. For example, I've made a couple of free V4 clothes recently. Their geometries go in :runtime:geometries:svdl:v4clothing:
In my opinion, that's a logical folder structure. I start it with my screen name, since I'm the only one using that screen name (at least on 'rosity), I can be fairly sure that the subfolders I place within the "svdl" geometries folder will not be overwritten by someone else's stuff. Rather important, I'd say.
I plase readmes in :readme:svdl:productname. Why? Since some freebies contain more than one text file - a license file, special instuctions in sort of a manual, plus the standard readme... Again, I'd say that is logical.
The same goes for the libraries. Poses, props, characters, they go in ":svdl:product name", sometimes with a product category in between (useful for a V2+V3+V4 version of a product).
I don't think my name is that important. But it will allow the user to easily select the folder branch and move it to the desired location, without having to hunt down several folders in the character or pose libraries.
Same goes for textures.

So I do not agree with the call for "no subfolders". There are very good reasons to use a folder structure.

But I do agree that the folder structure should be set up with the comfort of the end user in mind. It's not meant for egotrippery.

The complaint about the paths pointing outside the runtime structure is something I, as a content provider, COMPLETELY agree with. While investing in a tool like Correct Reference may be a bit much (well, $30 isn't that bad) for a freebie provider, I'd suggest that commercial products should be run through CR or a similar tool before submitting to testing on the MP.

Everything I make is freestuff. But that's not a reason to release substandard stuff. A freebie provider should strive for the quality that is expected of commercial products, not only in the mesh/texture/pose/morph/whatever, but also in the setup.
That way, if the freebie provider ever considers entering the MP he/she a) already has a habit of correctly packaging the goods, making it easier to pass the MP testing procedures and b) already has a reputation of making good quality stuff with correct setup procedures, increasing customer trust - and sales.

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery My freestuff

Quote - How about this. Let's start a list of "banned from now on" generic texture names. I'll get it started with:

wood.jpg
chrome.jpg
gold.jpg
silver.jpg
rock.jpg
stone.jpg
wall.jpg
floor.jpg
ceiling.jpg
house.jpg
oldwood.jpg
silverref.jpg
silverreflect.jpg
silverrefl.jpg
brass.jpg
translash.jpg
eyereflect.jpg
brick.jpg
fetchrome.jpg
chromemap.jpg

Anyone care to join in?

There's nothing wrong with doing that. The problem comes with the references in the poser files.

If silverreflect.jpg is referenced like this
**:Runtime:textures:productfolder:gold.jpg
**There's no problem. If it's referenced like this:

**:gold.jpg
**Then it's utterly useless. Especially if it isn't a generic reflection file but a specific texture file.

Quote - I agree with most, but not all, of the points raised above.

Folder structure: it may make SENSE to use a nested folder structure. For example, I've made a couple of free V4 clothes recently. Their geometries go in :runtime:geometries:svdl:v4clothing:
In my opinion, that's a logical folder structure. I start it with my screen name, since I'm the only one using that screen name (at least on 'rosity), I can be fairly sure that the subfolders I place within the "svdl" geometries folder will not be overwritten by someone else's stuff. Rather important, I'd say.

In fact, in my very non-humble opinion, this is EXACTLY what content providers should be doing. Your stuff (and I have a fair bit of it) is a relative joy to work with because it's logically organized and, if I want to move stuff around, easy to locate.

"If silverreflect.jpg is referenced like this
:Runtime:textures:productfolder:gold.jpg"
I think you meant, ":Runtime:textures:productfolder:silverreflect.jpg"

(See how easy it is to make a reference mistake)

It's still a problem. Just becuase you make a proper reference in your poser file, doesn't mean that some other bozo won't use the exact same file name and not have a correct reference. This means that Poser will go searching for his file and probably find your's instead. The only way to avoid that is to use unique file names. Hence, my call to stop using generic names. "Floor" is my #1 culprit

I'd rather stay in my lane than lay in my stain!

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

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery My freestuff

An example too is naming your character the same name as another current release at another major store or even here at RR. I bought Grace for V4 from Daz and Grace at 3dcommune by a friend I know from here. All the files got mixed up. I would hope merchants would be aware of current releases at all major Poser stores. I certainly would not name a character "Alice", but maybe "Alice Ann" to avoid file mixup with Aery Soul's Alice.

This is one of those subjects that gets rolled out every so often, everyone agrees but nothing ever gets done about it, the main problem is the providers themselves, they each have their own ideas on what THEY want to do.

What should happen is every store & site with freebie space should subscribe to a set standard & anything that doesn't comply should be sent back to be forced into shape.

That's in an ideal world of course, here in the real world it ain't gonna happen.

Windows 7 64Bit
Poser Pro 2010 SR1

I agree with all of the above.

However - please note that the mistakes that were pointed out such as absolute file paths - and generically named textures for that matter - should be found by testers and never seen by paying customers.

Vendors should first have their product looked at by at least 1 beta tester, then store staff. How both consistently miss these simple errors that they should be programmed to look for is beyond me.

Also, unless their policy has changed, those annoying !!!'s are banned over at 3D Commune - a product will fail if any library folder has special characters.

Gill

Quote - "If silverreflect.jpg is referenced like this
:Runtime:textures:productfolder:gold.jpg"
I think you meant, ":Runtime:textures:productfolder:silverreflect.jpg"

(See how easy it is to make a reference mistake)

It's still a problem. Just becuase you make a proper reference in your poser file, doesn't mean that some other bozo won't use the exact same file name and not have a correct reference. This means that Poser will go searching for his file and probably find your's instead. The only way to avoid that is to use unique file names. Hence, my call to stop using generic names. "Floor" is my #1 culprit

Actually, that screw-up was because I wanted to use a different example (and missed the previous line). If something is called silverreflect, you're probably safe using any silver reflection type map. "Gold" on the other hand may be a reflection may, it may be a gold coloured uniform, it might be a slightly tanned Caucasian skin.

Lululee, a merchant here, even suggested I become a tester because I find so many mistakes. Well, RR told me they didn't need anymore testers. If RR pays the testers, then they need to fire some of them. If the testers are volunteers, then I suppose we must forgive them.

How about this as well.

Please be so kind as to remove all "Thumbs.db" files from your zip before offering it to the public.

I'd rather stay in my lane than lay in my stain!

What I would like to see is continuity of naming the folders.

When I first started I did what everyone does, use the main Poser runtime and just install or unzip files to it. I was in tears when trying to find related content because within each folder in the library, the folders for that content were all named something different.

It doesn't help me one bit to have a folder inside the character folder called "red dynamic dress", while the MAT POSE files for that dress are in something called "JaneDoe MATS"! I know you want your name on a folder or two, but please, save that for the textures and geometries folders....and please, if you do that, then please package each of your product texture and geometry files into separate folders so that they don't overwrite files from another one of your products.

"It is good to see ourselves as others see us. Try as we may, we are never
able to know ourselves fully as we are, especially the evil side of us.
This we can do only if we are not angry with our critics but will take in good
heart whatever they might have to say." - Ghandi

it sounds like this is more a litany to the failures of the testing process. I reckon that only a few of the merchants will read this thread. I reckon that only a few of the beta testers will read it. they may only volunteer as testers to get free items, and not to do serious problem-fixing. if a marketplace is allowing defective products to be sold, it's the market's responsibility to make things right with the customer IMVHO. perhaps they should drop the independent beta-testers, and make certain all their testers are employees who are accountable - e.g. they can get demoted or fired if they play stupid.

The major problem is that there are two different mindsets colliding.

There's the "I'm an artist, and I want to do things my way!" mindset. Which is perfectly legitimate.

Then there's the "I'm a buyer/user, I want convenience" mindset. Also legit.

The problem is the people supplying content who think too much like the former and not enough like the latter.

I run into the same problem when I review amateur fiction. I see people going "well, okay, my spelling sux and i Use random Capitilization: and i dont follw any grammatical rules known to humankinded, but i'm writing a story and you should only look at that." My reply being then "Well, if you want other people to read your work but you don't care about following some basic rules to make it easier to read, I don't care enough to bother reading it at all."

In a perfect world (that is, one in which I was unquestioned ruler of all), products would be organized as follows:

ReadMe
    Merchant
        ProductName folder
            product readme files
Runtime
    Geometries
        Merchant
            ProductName
                product obj files
    Libraries
        Regular library folders
            Merchant
                ProductName
                    product files
                    AddOn folders*
    Textures
        Merchant
            ProductName
                product textures
                AddOn folders*

For the AddOn folders (marked by asterisks), what I mean are merchant addons to an existing product. For example, if I made mats and textures for the Daz Morphing Fantasy Dress and sold them, my texture directory layout might look something like this:

    Pose
        MATs
            DAZ
                MorphingFantasyDress
                    KeithsAmazingMFD

    Textures
        DAZ
            Clothing (if organized like this, otherwise move stuff up a level by removing this one)
                MorphingFantasyDress
                    KeithsAmazingMFD

Doing it this way means it's a lot easier to find things. I know all the MAT files from everyone making stuff for the MFD will be in the MFD directory structure. If I want to move the dress from, say, the V3 runtime to a dedicated DAZ clothing runtime, it's easy to find all the files and the add-on products that I've bought.

Quote - > Quote - *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?

*if thats a Rendo brokered product, don't blame the vendor. blame Rendo. Merchants here are required to use the same readme and in the same location or the product is failed.

No, they need the same licence file. Which I don't care about (since they are all the same).

I just checked assorted Renderosity downloads and there doesn't seem to be a rigidly adhered to system for naming the product readmes or where they are located.

then that has been changed since I was a merchant here. sorry for bothering you..

I think too much finger pointing would ensue were someone to come up with a list of venders who dont organize/name reasonably.

But I might just start a list naming those who DO organize correctly- efficiently. A better business bureau of sorts lol

Svdl would be on that list as I have had no issues with his system so far at all. That nesting described was perfectly acceptable. It's when folder names have absolutely nothing to do with thier content or to my knowledge creator.

I am: aka Velocity3d

Actually Keith .. I would hate your library structure. I want it by category, not merchant. For poses it is close to what I do but not exactly, etc. So even among systems you have people that would want it another way. I know some people don't want the merchant's name anywhere in the library (texture folder is possibly okay) so it is a toss up trying to please everyone and it is never going to happen.

Quote -

    Textures
        DAZ
            Clothing (if organized like this, otherwise move stuff up a level by removing this one)
                MorphingFantasyDress
                    KeithsAmazingMFD

Doing it this way means it's a lot easier to find things. I know all the MAT files from everyone making stuff for the MFD will be in the MFD directory structure. If I want to move the dress from, say, the V3 runtime to a dedicated DAZ clothing runtime, it's easy to find all the files and the add-on products that I've bought.

Unfortunately, even DAZ doesn't do this with all of its expansions :(

Great topic. I applaud you Keith.

One last little complaint...and this is specific to certain real merchants who shall remain nameless.

Certain merchants use the same textures over and over, yet don't have a single folder location for those common textures, but instead, choose to put all textures in separate folders just for each product. This means, that if I buy, say, 10 different products from one of those merchants, I wind up with 10 copies of the same textures in my runtime, eating up my hard drive space. Also, a beta tester testing a single one of those products is not going to find anything wrong with it.

I'd rather stay in my lane than lay in my stain!

Phew..! I am glad that none of the criticisms above apply to my products LOL

I too can't understand why the majority of vendors feel forced to name their readme's as plain old readme....

Rosity dosn't force that as stated in posts above...

I have always named my readmes as: Product Name.txt and they go into a RuntimeZME Readmes folder... so my Readmes are never overwritten and are easy to find.

Rosity don't seem to have a problem with that... my products have always passed testing first time round.

As to the texture name.. I use the likes of gold, wood, etc., but mine are named zme_gold, zme_wood, etc., so that Poser doesn't pick up someone elses texture files.

"You don't have to be mad to use Poser... but it helps"

Quote - Actually Keith .. I would hate your library structure. I want it by category, not merchant. For poses it is close to what I do but not exactly, etc. So even among systems you have people that would want it another way. I know some people don't want the merchant's name anywhere in the library (texture folder is possibly okay) so it is a toss up trying to please everyone and it is never going to happen.

Sure. I could understand if another system was used or desired. But the most important thing is consistancy so that if I want to rearrange things to suit my way, I could do it a lot easier than I can now.

The single biggest problem is the Textures folder. The library folders are easy enough to rearrange, to reorganize or whatever, but the textures are utterly impossible. Unless you go into the structure of the CR2s or PZ2 files to see where they are pointing, it's often impossible to find the folder holding the textures of what you want.

regarding the duplicate texture files, I heard a rumour that folks who buy alotta daz textures can end up buying the same one twice (or possibly more often). it was something about hi-res and lo-res versions. not sure how it happens, but the buyers tend to be indiscriminate.

Quote - I think too much finger pointing would ensue were someone to come up with a list of venders who dont organize/name reasonably.

But I might just start a list naming those who DO organize correctly- efficiently. A better business bureau of sorts lol

Svdl would be on that list as I have had no issues with his system so far at all. That nesting described was perfectly acceptable. It's when folder names have absolutely nothing to do with thier content or to my knowledge creator.

Hongyu is very good. He doesn't put his readme files in a dedicated directory, but they are named with the product name. As does aoaio.

Others? Hmm. Danie and marfano, although they use too many exclamation points. Royloo is usually pretty good. Xurge. That's just a quick look at the zips I have on this machine.

The main thing the ones I named have in common is that the textures are easy to find.

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

speaking of 'remaining nameless' - there's a name thing that occasionally trips me up.

I know I'm one of the minor players with only a 1-gig Runtime (and that's a whole 'nuther thread')..but maybe in the readme (whatever you want to call it) include

Your name
Your site (if you have one)
the usual 'use/don't use commercially'
accreditation (you must/must not credit the creator)

I have something like 23 gig of Poser files (more like 15 gig of unique stuff, I keep getting the same stuff over and over..;), and 22,000+ downloads, I just can't keep straight who made what,
even with a database. Now I do get the file name, and I do load it, but once it's loaded, I get
say (not to pick on anyone) 'Warrioress armor'. Who made it? Can I use it in commercial stuff (like I'm that good..;), do they really want credit? And how do I backtrack (unless I put that in the database; i.e., loaded...what a fun bit that would be to do..;)

I honestly try to credit where I remember who made it, and on rare occasions get 'dinged' by the creator, if I don't. But sometimes I even forget I have loaded something into Poser (and wind up surfing through FIgures, trying to remember what I had...oh, I forgot I put that in..;)

Just remember, it's free advertising, draws some to your site if you have one, and can't hurt, especially if we don't get around to including it in Poser for 6 months or a year later..;)

I wish I'd said that.. The Staircase Wit

anahl nathrak uth vas betude doth yel dyenvey..;)

I just purchased a really nice product here for a good sale price. The readme is totally incorrect. If I were a beginner - and I remember those days well - I could not find a damn thing! I was told by Karen, an admin here, that the readmes and so on have to follow RR rules. Why isn't someone CHECKING THIS STUFF????????? (huffs angrily) PS Ziggy. If that is your freestuff with the cool circus and hospital stuff, thanks a lot! They're great!

Quote - 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.):

To be honest...so do I. I don't give merchants any credit internally (except when I buy enough of their stuff to justify a separate folder). I'm rather ruthless in renaming folders and files.

But the point isn't what I choose to do afterward: the point is the installation of a file. 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. The problem is that it takes time. And especially if I happen to unzip a few files (from different sources) at the same time. When I want to recorganize, then I can't find the right directory associated with the right pose files.

As I mentioned the single biggest bugaboo I have is texture folder names.

@pakled: Thanks. There's some useful tips in there.
Commercial/non-commercial use is a good idea to incorporate in a freestuff readme. For a marketplace item it's not necessary, an item bought on the marketplace always can be used for commercial renders.

A file list, like in the readmes of MP items, should be in a freebie readme too.

Reminds me of a demo VBA script I wrote ten years ago - it dissected mail sent by a listserver and put the mail in an organized database. Something similar can be done with readmes, if they follow a certain format. Doesn't even have to be completely structured (the listserver script was clever enough to strip out the ads before storing the info in the database).

Hmm. Nice little side project. A database app that can import a readme, parse the info, and store as much info about the product as possible... Quite hard to make the readme parser sufficiently flexible, now there's a nice programming challenge....

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery My freestuff

I know merchants don't make much money unless they are rather popular, but jeez, can't they check their files?

The biggest offending folder of duplicate file names that artists and vendors need to note in my humble opinion (my read me's are coupled to a filemaker database I designed with the store image and all kinds of search terms, that someday hopefully will become a freebee it's self and the readme's are stored outside my runtime) is files named chrome.jpg, gold.jpg or silver.jpg in either the relfection maps folder or the materials folder. with no other sub folder. Yet they created sub folders for their textures. I hate to say it but I have a list of artists or vendors, whose products I try to stay away from, beacause of repetivie file path, folder and file naming issues that required correcting. People are human and make mistakes. But when 3 products by the same artist had be corrected,,, What drives me crazy is that two other resellers know of products in there stores that have major problems, missing textures, missing morphs, etc. Yet the products have not been removed or the info page changed to reflect the fact that claimed morphs are not in the cloth or fixed in many many months.

Gary

"Those who lose themselves in a passion lose less than those who lose their passion"

here are 2 things that really bother me and I apologize if they have been covered

geometry files - please put your geometry files in folders like Yourname/product name so if I ever need to delete I am not having to look all over the place for them

Also the same with your textures PLEASE!!! pit then in a folder with the product name and under your name. I have all thes eloose texture folders that should be in a folder under your name

In a world filled with causes for worry and anxiety...
we need the peace of God standing guard over our hearts and minds.

Jerry McCant

Quote - How about this. Let's start a list of "banned from now on" generic texture names. I'll get it started with:

wood.jpg
chrome.jpg
gold.jpg
silver.jpg
rock.jpg
stone.jpg
wall.jpg
floor.jpg
ceiling.jpg
house.jpg
oldwood.jpg
silverref.jpg
silverreflect.jpg
silverrefl.jpg
brass.jpg
translash.jpg
eyereflect.jpg
brick.jpg
fetchrome.jpg
chromemap.jpg

Anyone care to join in?

Goldref LOL

"I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge." Albert Einstein

Free the freebies!

Miss Nancy I'm sorry but I have to take exception to your comment:
they may only volunteer as testers to get free items, and not to do serious problem-fixing.

I work as a volunteer tester both for a Poser store and for several merchants on a private basis. I do this voluntarily and as a tester it is your duty to actually break the damn things whereever possible. I recently spent 5 hours on one outfit mesh test to cover every eventuality I could think of. At work I earn £8 an hour so that would be £40 just for the initial test alone and not taking anything else into account, like the fact it was a Sunday and I get paid double time if I have to do the office thing on a Sunday. You do not get free product for testing, you get minor compensation for your time by being allowed to keep the pack and in cases such as characters, clothing and scenery then it woudl be more cost effective to just buy the thing on release. You test for the love of it, and quite possibly because you are anal as hell I know you were talking about one specific mind set but I can't help myself, it is a knee jerk reaction whenever I hear or readanything like that.

As a merchant I always put all my textures in a nested structure starting with VLF and then in folders that relate to the product they are for and my texture pack name. Since the beginning of this year I now have an extra folder in there for the base figure they are for, G2, Miki 2 etc.. I do the same with my Read Mes as well. Basically I organise my products in the way I find works for me best as an end user and how I like to have the products I buy laid out.

Sorry, I can't remember who it was that requested merchants include their websote addresses in their Read Mes. Unless your site does not sell anything then you are not allowed to, if you look through the submission guidelines there are a lot of rules about what can and cannot be in your read me.

Non-specific file names are a pain in the front bottom, they really and truely are the bane of my life. blue, green, peach all drive me close to insanity - especially when it applies hair to your eyes and vice versa. My texture names are sually rather long but hey they are unique and yu can tell from looking at them who made them, what pack they go with and if it is a texture, bump, displacement, specularity or transparency map without ever having to open it. Then again, I am truely anal grin

**And I'll second Valerian70. She recently tested for a product of mine and gave me an itemized, detailed listing of every part of the product from the readme to folder structure to...well, everything! The most professional, complete and thorough testing I have ever had on a product of mine. And I'm proud to say that the product passed easily through the Rendo MP testers.

What did she get in return? 4 dress textures and a big hearty thank you! But that thank you comes from the bottom of my heart and I truly feel blessed to have had her test it for me.

BTW....Vendors are reading this. This one is, at least. And taking notes for the future.**

We seem to be following each other around the forums tonight Janet

I am all embarrassed now too but I'm glad you were pleased wth the testing - thats important to me!

You know....I was just thinking. If the MP testers were as thorough as you were, there wouldn't be any threads like this one.

I test for a few merchants here and get a free product. I often find things missed by the RR testers.

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". Since the readme will contain a list of the other zipped files, you will also know how many bits of punctuation preface the file for which you are looking.

It's too late to establish control over the naming conventions and the fault really lies with whoever it was that established the way in which certain types of character take precedence over others (in other words, it's completely out of the hands of 3D vendors, brokers, or software developers). It's not just the exclamation marks that affect the issue. Numbers do, too, as do internal hyphens and underscores and the case of letters. I have a V3 character which I use a lot, by a rightly respected vendor, whose Pose files reside in a folder with a mixed-case name. That actually means that it comes after all of the ones that begin with "MAT" and that its position in the list doesn't have a huge amount to do with strict alphabetical order. I use the set a lot because I like it, but it doesn't do any harm that it is easy to find. In a way, very possibly accidentally, that vendor did ensure that her character got used (at least by me - admittedly, not exactly a surefire way to billionaire status), but can one claim that using mixed case for a folder name is stealing an unfair advantage? Logically, the people who complain about the proliferation of exclamation marks ought also to object to mixed case, because it affects a folder's position just as decisively, if in not the same way.

I am also not quite sure how people propose to enforce unique names for files, while simultaneously enforcing strict rules for folder names, since one trend would demand a wider range, while the other would reduce it. I agree with the idea that vendors should try to create unique names for their files, but that is plainly impossible to enforce.

What I would like is for people to use teh default folders for things like animals...mostly aimed at CP with this one cause it is there software, but why say the blue jay, has his own folder the eagle, the cardinal etc...why not just place then in the animals folder???

♠Ω Poser eZine Ω♠
♠Ω Poser Free Stuff Ω♠
♠Ω My Homepage Ω♠

www.3rddimensiongraphics.net

Now I am really angry. I bought Orion's Azusa outfit for V4 and it is missing textures. I had to email Orion and customer support. WILL RR PLEASE TEST THEIR MERCHANT GOODS????

Why isn't there a template that the vendors have to adhere to in order to get their stuff in..I agree about the readmes. They have 900 letter names yet can't name the readme file to show what it belongs to. If there are vendors who continue to do this and have so many mistakes why do you continue to buy from them? Maybe a boycott would wake them up.
Marque

Quote : *"Now I am really angry. I bought Orion's Azusa outfit for V4 and it is missing textures. I had to email Orion and customer support. WILL RR PLEASE TEST THEIR MERCHANT GOODS????"

........

Yes I've struck this sort of thing on numerous occasions ...

However, I have been told that products take longer to hit the RR store (compared to other online shops) because the testing is more stringent .... yeah right !!

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.

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.

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.

My list is small thus far lol -subdomain will be nice too once I dont have 45 windows open on my computer I might set that up....

I am: aka Velocity3d

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)

Let me introduce you to my multiple personalities. :)
BluEcho...Faery_Light...Faery_Souls.

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:

Hashset, creation date, rev. nr. as part of the filenames. At least for textures.
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.
Not like 10 different character morphs that are named all the same. (See point 1)
Some DB script file that makes it easier to register the files in the system DB. No matter what DB is choosen.
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.

I wish I'd said that.. The Staircase Wit

anahl nathrak uth vas betude doth yel dyenvey..;)

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.

Here, let's play a game.

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.

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery My freestuff

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.

My python page
My ShareCG freebies

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.

I am: aka Velocity3d

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:

Use the path as specified (even if relative) - usually not guaranteed except for someone's own scene file.
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.
Search the Runtimes for the file.
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

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

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

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

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

My python page
My ShareCG freebies

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 (?).

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

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:

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

VanishingPoint... Advanced 3D Modeling Solutions

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.

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

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.

@ nomuse, "*religious objections to certain number sets*" - :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.

-D
---
It's all fun and games until someone loses an eye texture.

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:

Hi, my namez: "NO, Bad Kitteh, NO!" Whaz yurs?
BadKittehCo Store BadKittehCo Freebies and product support

How about !!!!!!!!! CONNIKAT FREEBIEZ

My Freebies

!!!!!!!!!!!!!!!!!!!!!!!!!!! DIET COKE SPEW !!!!!!!!!!!!!!!!!!!!!!!
:lol: Yeah, that onew would be just purrrfect :lol:

or LOL I could do zzzzz freebiez... that way people could just scroll all the way to the bottom.
To think, noone exploited that one yet!
[Kitty runs and hides]

Hi, my namez: "NO, Bad Kitteh, NO!" Whaz yurs?
BadKittehCo Store BadKittehCo Freebies and product support

My texture folder looks like a dictionnary, so much names! From a to z!

My Store

Dont forget that you can make a complex subdirectory structure with any modern filesystem.
You should create at least 48 subfolders named like "! ! !" or "+!+".
Further you should avoid short filenames the closer you come to root.
Never let a path be shorter than 240 characters.
Store only a single file per directory.

Going for redundancy is always a good thing...
What should reside somewhere inside the Poser installation can be spread throughout the whole system. ReadMe's included. This way the large capacity of nowadays harddrives will be used in an excellent manner while at the same time it prevents the user from doing what he's best at: conserving digital crap.

Offer formats that are of no use to most of the target group. Offer textures in resolutions that can not be handled by the target app or that are much to low to yield good results.
Provide the ReadMe in at least 20 different variants. Including backward compatible ones.

Create an installer to reproduce your files on every drive and of course into the "system32", "drivercache" and "System Volume Information" directories.
Use the OS-tools to remove user and admin ownership of these redundant file and any possible other rights. For NTFS the effort to screw the FS shadowcopy will surely pay off.

If you create an compressed archive that contains rel. filepaths you should at least try to overwrite as many important files of the target Poser installation as possible. But not the obvious ones like Poser.exe...
Oh, and one thing: never name a file in a way that could let the user know what it contains.

Optional: Offer technical help regarding the installation process and make the user pay for this service.

LOL! A real nightmare you describe here! ;p

My Store

@Zarat... LOLOLOL :lol:
GAH, you reminded me of the program I use for work... and we paid 6 grand for it too! Looking at it on the good side, if it worked properly I wouldn't have time to come here and chat with rendo people! ;P

Hi, my namez: "NO, Bad Kitteh, NO!" Whaz yurs?
BadKittehCo Store BadKittehCo Freebies and product support

Does that imply that here the subforums with very low traffic represent the worst software? ^.^
Seeing it this way, 3DS Max should work twice as well as Maya and Poser should work about 8 times as well as any other CG application.

Quote - Does that imply that here the subforums with very low traffic represent the worst software? ^.^
Seeing it this way, 3DS Max should work twice as well as Maya and Poser should work about 8 times as well as any other CG application.

perhaps just the opposite? :lol: Well, when my work related cad application (by the same maker as Max) quit working, I had plenty of time to go to it's relative forums and complain.... After a while I gave up that futile effort...

Hi, my namez: "NO, Bad Kitteh, NO!" Whaz yurs?
BadKittehCo Store BadKittehCo Freebies and product support

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

*Firstly, it's just too late, as I have said before. Secondly, how would you compel a vendor selling from his/her own site to adhere to any rules. Thirdly, even if you somehow eradicate the exclamation marks and the rest of the little tricks, there will still be an order. You'll get lots of sets called "Aardvark for V4" and "Aaaaardvaaaark for V4", which don't break the rules.

The whole problem, in reality, arises from the fact that the existing styles of product names DO follow an industry convention.

Yes, standardize the readmes! I always port mine to a folder under Runtime called: Readme

I've seen a lot of variations on that, maybe we could pick one?

Name them Productname_Readme or in the case of common product names Username_Productname_Readme

I also wish that the Poser creators would make up their minds about capitalizing, wouldn't mind if that was standardized too.

I like having the folder start ! ! so I can find it easily and then move it where I like.

"Your work is to keep cranking the flywheel that turns the gears that spin the belt in the engine of belief that keeps you and your desk in midair."

Annie Dillard

I'd heard -- and thought I experienced -- problems in Poser with leading capitals, so I got out of habit of ever using them. Oddly enough, it seems to me the library in P6 capitalizes all stand-alone words, regardless of the case of the original file...

I agree with kuroyume0160 that Poser's habit of grabbing the first texture or obj file of the same name it finds is a serious fault of the program. I've emailed ef about it and suggested that they develop a patch to prevent this from happening. I don't know if this still happens in Poser 7 but Poser 5 will grab the first texture file it needs and Poser 6 adds to that grabbing the first obj file it needs with the same name. What's the point of having fully qualified references in the library files if Poser is free to disregard them when trying to locate the files? This can really cause some weird issues and as a vendor with a lot of products I'm sometimes hard pressed to come up with all kinds of unique names for everyday items :)

I've always listened to customer's suggestions on what they wanted in the product folder structure and have tried to suit. One thing I do that someone complained about though was to use the same texture file in several products. I don't know how to get around this one. It may be true that you have several other products of mine that use this exact same texture but how can any one product know this in advance on install? Each product has to supply all the textures it uses or it will not work.

I think that consistency is what most everyone (including myself) is looking for in this. I customize my library folders a lot but leave the geometry and texture folders alone. So as a vendor I structure my own folders just the way I'd prefer to see all texture and geometry folders structured: vendornameproductname. Easy to find everything by each vendor :)

Rick

Quote - You'll get lots of sets called "Aardvark for V4" and "Aaaaardvaaaark for V4", which don't break the rules.

Actually, considering my gender and biomass, I think that Aardvark for Apollo Max would be more appropriate for me.

I'm in a big quanadry on this one...
From a user point of view, I frequently find myself going back and forth in how i want to sort the content, sometimes it's by vendor, sometimes it's by theme, sometimes by figure...

What would be really cool is if poser redid it's interface, and allowed sorting based on keywords. That way where the files are would only matter internally as long as internal and relative paths are correct.
That way, perhaps may execute content searches based on, I dunno V3 by outoftouch, or V4 Sci-Fi, or Uzilite (main and addons).
And it could be up to the vendor to provide a little xml file with keywords for it's product.
Sort of a database driven content search . Shouldn't be that hard to do.

Of course, that doesn't solve a thing at present!

Hi, my namez: "NO, Bad Kitteh, NO!" Whaz yurs?
BadKittehCo Store BadKittehCo Freebies and product support

If everything were miraculously fixed, and merchants adhered strictly to a uniform naming system (couldnt make that a law though) some "genius" would in a year (who's new to merchanting) would realize using "!" would put them on the top, and the ratrace would begin again. lol. I have noticed a trend with the !, *, and +++ at the begining of item names to get it higher on the list, it comes and goes, like the wind.

I'm simple, maybe a dullard, I dont know, but I know how i like things. I like items (free or purchased) to come with a distinct useable directory to automatically unzip to in their right prospective spots! The correct folder names, and the correct directories, but I'd LOVE to see these dissapear:

MYDOCUMENTS/poser4 (or 5, 6, 7)/Runtime..... so on so fourth
OR a completely BLANK file structure, with minimal to NO explanation (in easy english) where to put the stuff!

I can't tell you how many items I have, free or purchased, where i get regularly "obj not found", and I cant use the item! Now I'm sure I could get a laundry list how to fix this, move the item to where it belongs or WORSE........ how to edit the CR2..... but, pardon me, why should I have to know any of that? Why can't it be where it belongs in the first place!!!!

Just asking :)

And to Connikat...... here's my suggestion for naming something. In the past "Joes freebies" doesnt help me six months from now. I'll know on the day i download it its a toilet bowl, for instance, but when i'm looking for a toilet bowl in a month, six months, a year....... I'll have no clue its in there!

So if I were giving away a free (or purchased) toilet bowl I'd name the folder in figures or props....

Kirins Toilet ..... alternately you could make a subdirectory, "kirin's freebies/kirins toilet". Though the first makes it easier lol. Just a suggestion.

It's not just Daz3d, its in Poser too, with Poser 7 -shudders- CRProII found thousands of reference errors and dozens of duplicated files. I ended up unstalling Ps7 and staying with 6, much to my son's disgust at how I removed yet another present. And slowly adding things that I use a lot to it and taking the dorks that I rarely ever use and putting them on another drive.

-DR

Lot's of good suggestions in this thread, but I didn't see my particular pet peeve mentioned...

Thumbnails. In theory they are supposed to visually represent the item, you know, so I don't have to load it to tell what the item is... I have gotten packages- purchased, where the vendor decided to create an icon that visualized their "company" name, and used the same thumbnail for every component in the package. That tells me nothing, except that you took a short cut that's not workable for me. In one case, the package consisted of magical effects, each with a catchy "magical" name that told me exactly zip about what it looked like... useless.

Another was a product brokered through DAZ, a clothing set that featured the figure in silhouette, where the shirt thumbnail, for instance had the other clothing items blacked out and the shirt highlighted by being in color. Okay, good, I know it's a shirt. Good, I know what package it came from and the name of the vendor. Bad, I may want to use the shirt with somethng else, but aside from knowing it's a shirt, I have no idea what the shirt looks like.

Mainly, I'd just like it if content providers packaged content as if they actually use Poser. And before someone counters with D|S, these issues predate D|S and further if you are a merchant, you are getting my Poser dollars by claiming your product is compatible with Poser.

kalonart.com

I'll give you a recent pet peeve of mine...mat pose files for characters or hair that include x, y or z trans for various parts of the body, etc. Say I create a scene and get all the details worked out and the poses perfect or near perfect. I then wonder how that character would look as a blonde instead of a brunette or instead of using Suzie, lets try Violet. You click on the mat pose file to change something and the main character in the scene jumps out of postiion and screws everything all up. Granted you can undo things. But that means you have to open the Mat Pose files for that product and search and remove those references that never should have been there in the first place in my opinion. If they are there for a purpose then include that info in the readme, don't leave us guessing why you did certain things if they are there for a purpose. Tell us!

Gary

"Those who lose themselves in a passion lose less than those who lose their passion"

might i also add templates to the pile of detritus that accumulates in the runtime? when products do see fit to include them, i see some that are logically placed, other times they are scattered to the winds of the runtime. some appear dumped in with readmes with no clue as to what zip they came from. i'm sure others will speak about the template boondoggle as well...

regards,

waningmoon

Quote - I'll give you a recent pet peeve of mine...mat pose files for characters or hair that include x, y or z trans for various parts of the body, etc.

I'll give you another one. Pose files that move the body for no good reason. It's one thing if it's one pose in a set meant for characters (say a dancing couple). It's another if it's a pose for a single character. I have a large scene, I move the figure where I want it, carefully making sure the feet touch the floor and so on, look at it, decide a slightly different pose would be better, click on it and the figure is back at the origin.

Quote - Lot's of good suggestions in this thread, but I didn't see my particular pet peeve mentioned...

Thumbnails. I

I'll second that one! And even worse is when you get a pack of textures and you get NO THUMBNAILS! There's nothing worse than having to make PNGs for all the eye colors, etc in a texture pack you bought.

The other thing that irks me is that we are now on Poser 7 and people are still making stuff that is designed for Poser 4. I understand designing for the lowest common denominator, but I would hope that most Poser users are at least on 5 by now so can we please do away with the .bum file references! It is very unreasonable to expect vendors to keep making files that are compatible with software from four versions ago. How many software companies nowadays are designing for Windows 98? At least offer the Poser 4 version of your file AND a poser 5/6/7 version.

Forum: Poser - OFFICIAL

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