Redacted
cridgit
Posts: 1,757
Redacted
Post edited by cridgit on
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
DIM will import the metadata automatically, but it doesn't remove user-defined metadata (at least it hasn't for me, but my user-defined metadata is outside of default).
Redacted
You do realise that if you were to dump all of that garbage in the bucket and just use the Content Library, that you would have far fewer headaches and be able to get on with using your content in renders, instead of ****ing about all of the time.
when DAZ update meta-data, then show Update product in DIM,
I need to check the meta-data in zip ifrst.
Actually DIM do not overwrite usuall "user meta-data" not categorized as product,
but DIM install auto product meta-data,
then it make orphan files about files which I set my handmade product meta-data .
Before,, I usually keep the rule to set correct product name with token number, and author etc,,
But it cause duplicate product data, or sometimes overwrite my-product meta-data.
Now I need to set product name as original. and do not apply token number.
eg the real product meta-data name is
DAZ_3D_5661_Earane_Outfit.dsx (the token number auto adapted)
I need to set my product meta-data
as "MY_Earane_Outfit.dsx"
when I set product meta-data for daz product,
now I apply MY to the name. to check easy.
then if daz offer meta-data by dim is wrong,,,
I delete it from data-base,,
then re-install my product meta-data to correct it.
Use CMS manager often,,, then delete meta-data,, or re-improt meta-data,
and recreate meta-data or,, remove category of the product for the assets,,
these steps sometimes make strange name data eg,, "(2)aabb.duf "
there is only one file, and seems only one data in Content Library
and check my dsx in runtime >support ,there seems no data as named "(2)"
but actually, there is data in database record about some assets,, (
a few days ago , I experienced to find such cute "(2)aabbcc_foolish" .duf s
when I set meta-data and delete wrong daz offer meta-data.
I could not delete and correct the data name. I try to delete the product-meta data and re-import
my data,, I even delete my handmade dsx files from support folda,,,
but the strange name stuck to the files.
So I need to delete all data in database manually. then re-improt all meta-data,
, my handmade (set different name) product-meta-data, and user meta-data again.
I think,,DAZ need to offer us more good "database manager"
which can directly tweak or delete data in database.
though we can set dsx files in support directory. and re-import it,,
or delete (un-install) meta-data,, by content manager,,
Actually it can not remove all problems when problems happend.
Sometimes,, I want to directly tweak data in database.
This is only true for additional categories that keep being stored in the databases unless they are reset. Everything else will be overwritten.
- “User Data” is automatically overwritten by “DAZ Product Data”
- The “User Product Data” .dsa and .dsx files are overwritten by “DAZ Product Data”
Turning off the CMS when using the DIM
Official DAZ staff suggested in a DIM thread to turn off the CMS when installing with the DIM but only IF one wants to prevent anything to be written in the databases during installation.
What this does is prevent the DIM to directly write to the databases.
BUT:
It does not prevent the DIM of overwriting the “User Product Data” .dsa and .dsx files in /runtime/support with “DAZ Product Data”
Another negative side effect of stopping the CMS before installing with the DIM is that in the DIM you will not find any indication anymore if the installed product has smart content or not.
I deceided not to do it this way and keeping the CMS on because I want to know which product update has “DAZ Product Data”.
How do I manage metadata with the DIM?
Whenever I make any changes to “DAZ Product Data” I go to the “Product Library” open the “Content DB Editor” and export my own “User Product Data” to /runtime/support.
I make a backup of my “User Product Data” in a different location after each session.
Every time the DIM updates and installs products with “DAZ Product data” I check if I like the changes.
If I do not like the changes I immediately replace the “DAZ Product data” in /runtime/support with my own “User Product data” and reimport it.
- - -
Feature requests:
I made some suggestions in a VERY long thread that describes in detail all my issues and steps I had to take when making a complete reinstallation of all metadata with the DIM:
http://www.daz3d.com/forums/discussion/16216/#238578
A sample of the requests listed:
- There should be an on off switch on a product level basis if metadata will be installed by the DIM or not.
example: Separate checkmarks for metadata import in DIM for each product
- Prevent .dsx and .dsa files to be written to /runtime/support
- Prevent the .dsx files to be processed and directly written to the databases
- Update “Content DB Maintenance” “Import Metadata” window with a search field
- Update “Content DB Maintenance” “Import Metadata” so that metadata from other paths can be imported
- Add new feature to Content DB Maintenance “Export all product metadata”:
- - -
I considered the option to "Export All User Product Data" with just the click of one button as the most urgent one.
If that was there I could each evening make a backup of all product metadata. I assume it would about take 10 to 20 minutes to process the queue for 1000-2000 products. At the moment users have to export each product data manually.
https://bugs.daz3d.com/view.php?id=49185
- - -
Right after the release of the DIM it did not seem the right time to jump on requests for having metadata management included.
But I guess now sooner or later it would be appreciated if some efforts could be made to give back some functionality to the user what and when “DAZ Product Data” are placed in /runtime/support and when metadata is directly written to the databases by the DIM.
- - -
What do I mean with:
"User Data":
"User Data" is an official term used by DAZ. "User Data" collects all changes the user makes and saves them to the database. It is very important to understand that “User Data” is not a collection of all data in all products. Only those values the user changed will be saved.
Users can export their "User Data" from "Content DB Maintenance".
"DAZ Product Data"
"DAZ Product Data" is a term I use to describe the “Product” metadata that is created by DAZ staff and included in most products. “DAZ Product Data” is installed directly to /runtime/support.
“User Product Data”
Cridgit called this kind of metadata “homebrewn metadata” in his first tutorials.
“User Product Data” is a term I use to describe metadata that the users created themselves for a specific “Product”. To make sure that those changes are not overwritten the users export their “User Product Data” by going to the “Product Library” and open the “Content DB Editor” to export their customized product data to /runtime/support.
To make sure that the “User Product Data” is not overwritten automatically by “DAZ Product Data” it is recommended to make a backup in a different location.
Some people prefer to work that way; I used to rearrange my actual folders on disk, but in DS2.1 I converted all of those to Categories and find it's a much more flexible system for me.
Okay, I see what you mean -- if you create or modify metadata and save it using the DAZ product metadata filenames, it will get overwritten. I don't modify the product itself, I just create my own categories. If you modified the product metadata, you would definitely need to save those elsewhere or stop CMS when installing with DIM.
One correction -- even when there was a separate installer for metadata, the metadata was still included in the main installer.
I always asumed that the .dsa and the .dsx files were included in the separate metadata installers.
Actually I really believe that sometimes when I checked those installers by installing to a test directory I found .dsa and .dsx files.
But when I think about it I could come up with this theory:
Are you saying that in the "old" metadata installers there was only the .dsa file included?
- - -
For all those note familiar with .dsa and .dsx files in runtime support:
.dsx files include the metadata
.dsa files are just a script that triggers the .dsx files and the included metadata to be processed
When you have DS closed and click on a .dsa file in /runtime/support DS will open and you will see the corresponding .dsx file added to the queue.
- - -
So what the "old" metadata installers used to do was just placing the .dsa files in C:\Users\USERNAME\AppData\Roaming\DAZ 3D\Studio4\RunOnce
.dsa files located in that location are added to the queue to be processed at startup of DS and then read the .dsx files located in /runtime/support
Is that how it used to work?
Or could it be that there were actually 4 phases?
Phase 1a: separate installers with .dsx and .dsa files in a separate metadata installer
Phase 1b: separate installers with .dsa file in a separate metadata installer and the .dsx file in the content installer
- - -
The benefit of having really separated metadata installers would be to give the user complete control what is installed.
At least now with help of the DIM it would not ask additional efforts of DIM users to process this installers. And those who do not want metadata installed would have an easy way to just not install metadata.
Another benefit of having separated metadata installers would be that also in the DIM it would be easy to see if an update is just a metadata or a content update.
I can see how for everyone else that is not using the DIM it would be more effort again to run metadata installers manually.
Allthough I liked having control over separate metadata installers I was not happy with the extra time it took to manually install them.
Still the benefit was for product updates I could just ignore the metadata installers.
I ignore them because in most cases I allready fixed small issues myself.
Personally I do not believe though that DAZ will go back to providing separate metadata installers.
Especially for new users and the average user it seems easier if metadata is just there without having to worry about it.
Still, for advanced users that heavily customize metadata there should be more tools to work with the system as suggested.
Both the main installer and the separate metadata installer had the full metadata, i.e. .dsa, .dsx, and .jpg. The idea, as I understand it, was that if the metadata was updated you wouldn't need to run the full installer, but in practice you wouldn't have any way of knowing, so they dropped it.
It might be useful to have an option in DIM to not install the metadata -- I personally would like to install the product and categorize it myself, before importing the official metadata. But that wouldn't solve the problem of overwriting modified metadata files if it still installed the files.
A real life example why it is an issue that we have no control over which metadata is imported.
Sometime in summer 2012 the official metadata categories were updated:
http://docs.daz3d.com/doku.php/public/dson_spec/format_description/metadata/categories/start
Some Examples of changes:
“Footwear” instead of “Shoes”
“Materials/Wardrobe” instead of Presets/Materials/Productname
“Poses/Functionality/Sitting instead of Presets/Poses/Productname
At the moment I have 1005 "Products" installed with the DIM. For every (!) product I installed I took the time to adapt it myself to the newest guidelines when it was not allready done.
Yesterday when I started the DIM I found quite a list of "updated" products. After installing them I had to find out that they all still featured the old metadata system with the "/presets" structure.
- - -
When I first downloaded the products with the DIM this was acceptable. The DAZ team did not have time to make everything available for the DIM and update it.
But when now new product updates are released still featuring the old metadata categories it becomes very unconfortable that there is no way to prevent overwritting the files in /runtime/support and having the old metadata categories once again be written into the database.
- - -
This shows three issues that are all related to each other:
Issue I: The DIM is not asking for user-defined metadata ( the actual topic of this thread)
Users that allready put a lot of effort into updating the metadata themselves need easier ways to control what the DIM installs.
Having to clean up the metadata after every small update is becoming more and more time consuming.
Issue II: Updated Products are being released without updated metadata
At least at this point there should no more product updates be released in the DIM that are not updated to the official metadata categories posted here:
http://docs.daz3d.com/doku.php/public/dson_spec/format_description/metadata/categories/start
Issue III: On the product wiki pages there is not enough information to judge if a product has old or new metadata
At least on the product wiki there should be a note if the product features the old "/presets" or the new "Summer 2012 metadata categories".
It has become very important that all updates are described in detail on the product wiki page that opens when clicking the link in the DIM.
If for some reason updates are released with the old metadata categories there should at least be a warning message on the wiki pages.
- - -
Added 2 screenshots:
One shows the updates the DIM downloaded the other shows the state of the "Categories" after the installation.
There should not be a single file to be found under /Presets !
Update / Edit:
Added another screenshot that shows the workflow I now have to go through to undo the unwanted metadata installations the DIM dropped on me.
I first made a list with all product names that had "old" metadata.
I copy paste the product names then in the explorer search fields to speed the search for the .dsa and .dsx files up.
I copy the .dsa and .dsx files from my backup location to /runtime/support and then place the .dsa file in AppData\Roaming\DAZ 3D\Studio4\RunOnce
- - -
Its now 02:53am and I am still fixing things that I allready had fixed before. Guess that puts this real life example into perspective.
Redacted
Seconding what Bejaymac said. Devise a sensible multiple Runtime system, close stupid Smart Content. open Content Library, start creating art.
Yes, I was surprised by that one. It looks like even if there's no metadata, DIM creates a Product entry with all the files, so they no longer count as new.
the most worst point for me,, when DAZ release DIM,
change only product name about some items.
and offer wrong meta-data
then DAZ DIM install wrong meta-data in my runtime/support
and overwrite correct meta-data in data-base too.
eg,,
wilde-rhoads-for-genesis
this product was named as steam punk for genesis, I believe.
the read me had not finished yet.
http://docs.daz3d.com/doku.php/public/read_me/index/14146/start
this product meta-data is too strange.
because,, the dsx fies name in DIM,
DAZ_3D_14146_SteamPunk_Wilde
(but DIM show it as "Wild Rhoad fro genesis")
On the other hand
the dsx make new compatibility category as name "Wild Rhoad fro genesis"
eg Shorts,,
but ,,, there is no"Wilde Rhods for genesis” directory.
and the ZIP has only "SteamPunk Wilde" directory,
these assets are installed there.
as you know,, these funny meta-data mix up product name, and comaptibility base name,
and actuall directory name..
I am so frastrated to correct this producut to show by smart content.
when modify metta-data,, which product name is better ?
and of course,, this product meta-data set old category. not fit to new category.
and Read me has not finished,, so I need serch manually,, every files of this product.
when I install DIM, I send bug report. so how DAZ team check each report?
why they do not confirm and correct one by one, then version up installer and meta-data?
LOL! Dim is DIM and Smart is not so smart. I'm old school and will stay that way. +1 more for Bejaymac here.
If you have nothing to contribute to the conversation, please pipe down. If you don't care, don't say anything.
As a user who has worked for years to organize data by moving file structures, I find the CMS a wonderful boon. I ignored its various incarnations until Smart Content. Now, I want everything to have metadata. I see many valid points here, standardization is key. The wildly different categories, etc, and overwriting something I have already fixed are big issues. DAZ has attempted to set some standards, but they need to comply with their own standards! QC, people, QC.