One issue that I have seen with most 3D Content software is the placement of downloaded 3D content. Typically most 3D Content software (CC, iClone and DAZ included) allow the content developer to dictate the location (or sub-location) that the content will be installed in. While it is possible to re-organize (i.e. move) downloaded content later, it does mean that using the default download location can lead to a inconsistent mess because the location will not be consistent between different content developers.

As an example, consider a CC Cloth Skirt that is part of a Cheerleader outfit. Most content developers will dictate that such content is downloaded to one of 4 locations:

1. No Sub Folder
This option means that the content developer has not specified any such folder and thus the content is placed in the software's default location for the content type. For the CC Cloth Cheerleader Skirt example, this would be in the Cloth/Skirt folder. A lot of content user like content to use this location because it means that when the user is look for, as an example, a skirt they only need to consult the one Cloth/Skirt folder and they will find all the skirt content that they own without having to recurse through sub-folders. This is especially true if the software (like most software does) shows a thumbnail of the content so selection is very easy.

2. Content/Pack
This option means that the content developer has specified that the content will be in a sub-folder from the content type folder which is named after the content or content pack. For the CC Cloth Cheerleader Skirt example, this would be in the Cloth/Skirt/Cheerleader folder. This type of a organization allows the content user to quickly find a specific content type by use of themes but it does not allow easy listing of all content of a particular type because the content user needs to move in and out of sub-folders to see all the content.

3. Author
This option means that the content developer has specified that the content will be in a sub-folder from the content type folder which is named after the content developer. For the CC Cloth Cheerleader Skirt example, this would be in the Cloth/Skirt/LordAshes folder (assuming that the content came from Lord Ashes).This allows a user to quickly find content from a particular content developer (vendor) when, for example, searching to content bases but, once again, it does not allow all of the content type to be listed easily because the content user needs to move in and out of sub-folders to list all the contents.

4. Content/Pack and Vendor
The last common content development option is to store the content based on a sub-folder from the content type based on the Content/Pack and Vendor. Basically a combination of 2 and 3 in either order. For the CC Cloth Cheerleader Skirt example, this would be either the Cloth/Skirt/Cheerleader/LordAshes folder or the Cloth/Skirt/LordAshes/Cheerleader folder.

The problem is that each content user will tend to favor one of these organization methods (or maybe even their own) but they will get the content stored the way the content developer organized it. Yes, they can move it later but why not address this during the download?

Possible Solution:

Instead of having the Content Developer specify the sub-folder to which the content should be installed to, have the Content Developer provide values for the following properties: Short Content Name or Short Pack Name and Vendor Name. In such a case, the content downloader could be modified to provide a selection of the 4 above default options (or 5 default options if you want to support both version of the 4th option: Content/Vendor and Vendor/Content) with the last selection remembered so that it would be the default selection if not changed and then the downloader could construct the destination folder based on the selection. Constructing the destination folder based on the selection and the two content properties (Short Content Name or Vendor Name) should be fairly simple but it would make it so much more friendly to the user.

I was even looking into trying to recognize a RL content download so that I could build a external application which would move the downloaded contents based on my preference but I have not found a trigger for this. While each download generate a "Installcontent.rlcontent" file which my external application can monitor for, I don't see any obvious way to get the downloaded content manifest (i.e. the list of files downloaded and where they were downloaded to) in order to figure out which content needs to be moved. The contents of the rlcontent file is a seemingly hex string which cannot be easily associated with downloaded content.





"We often compare ourselves to the U.S. and often they come out the best, but they only have the right to bear arms while we have the right to bare breasts"
Bowser and Blue, Busting The Breast

Thanks for your proposal! I think that there is a room to improve, and want to hear more opinions from developers and users.

I was even looking into trying to recognize a RL content download so that I could build a external application which would move the downloaded contents based on my preference but I have not found a trigger for this. While each download generate a "Installcontent.rlcontent" file which my external application can monitor for, I don't see any obvious way to get the downloaded content manifest (i.e. the list of files downloaded and where they were downloaded to) in order to figure out which content needs to be moved. The contents of the rlcontent file is a seemingly hex string which cannot be easily associated with downloaded content.

Marketplace allows users to purchase a group of content packs, and download them all from a single rld file. I think that might be the reason why we are unable to specify the content name on the rld file, so as your idea of changing the file location might not work in this case.