Question about moving library files around
I'd like to know if I can customize product's forward facing locations.. without breaking anything in Daz Studio.
By forward facing, these would be the icons/files that appear in your Smart Content or Content Library when browsing, and not the files located in /Runtime and /Data.
I understand that I would also need to edit the product's manifest so DIM knows where these files are located.
The reason why I'd want to do this is because some products, whether they be from the Daz3d shop or third party vendor (custom content), install to inconvenient locations and cause a lot of unnecessary and excess clutter in my library folders and excess searching if I forget where they installed to. Basically, they install to locations that are not "default," or have a typo in their install paths.. for example:
Creator intended to install to /Environments but instead installed to /nvironments
Outside of the manifest, would any other files need to be edited by hand to move said forward facing files without causing issues?
Most of the files I want to move are custom content that don't even have a manifest.
Thanks for info. :)
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Content Library tab displays the actual files on your drive. Moving the files is not a problem for Content Library, as long as they stay in your content directory. Well, for Poser-format content you have to keep them inside one of the main Poser folders, and for DS-format content don't put it under Runtime or Data, but those are basically the only limitations.
However moving the actual files and folders it will break the metadata links to them, so it will break your Smart Content. So you'll need to edit the product metadata so it knows where the files now are.
I guess I'm not being very clear... lol. I edit the metadata with applications designed for editing raw code, like Atom or Notepad++. I've fixed lots of packages this way. I'm just not certain if the only files Daz Studio needs to be edited are the manifest and the .dsx in /Runtime/Support or if there's another one somewhere.
I suppose I'll just trial by fire it since editing metadata straight in Daz Studio is super tedious (to me, anyway). I accomplish the same task in a fraction of the time by just going straight to the source of the metadata. Although I realize most people wouldn't be able to read those files, it's pretty straight forward to me. A lot of server applications are configured in a similar way which is something I did for a living for a while. A lot of linux applications are also configured out of text editors.
So the manifest file (for DIM), and the .dsx file in /Runtime/Support if I'd like to change any locations of Smart Content items? Is there any other file containing metadata that would need edits?
You can edit categories without issue, a safer method of editing locations is to use links rather than moving the actual files.
Hi Richard, thanks for the tip. I haven't had a chance yet to begin organizing my library, I've been super busy lately. I'll certainly take a look at links first before doing any manual edits to physically move things. That said, I've stumbled onto a particular package that has really stumped me in regards to what Daz Studio is looking for and what the metadata says. Rather than make a new topic in the Nuts and Bolts area, I figured I'd run the question through here first, although a moderator can feel free to remove the question if they would prefer I make a new topic over there. This is loosely related to this thread because it's another reason why I believe metadata is being stored or pulled from another location outside of just the .dsx in /runtime/support
I need to make a new character so I was looking through more of my content lately that I haven't even opened yet since purchasing, and found a really weird inconsistency in SASE Karma for Josephene 8.
I never would have noticed anything since the logfile is not showing any error, but a Missing Asset dialog box pops up in the lower right corner of Daz Studio. I haven't ever encountered a package for Daz that I haven't been able to fix missing files for, except this one (this is technically not true since I merely copied the file and put it where Daz Studio is searching for it, but that's simply a work-around in my opinion). When Daz says it can't find a file it's either because the file is in the incorrect location or it truly just doesn't exist. In either event you can stop Daz's fussing about it by correcting the metadata (and either removing the entry for the missing asset, if it's truly missing, or by correcting the broken path). The file in question for Karma is no different, Daz is searching for it in the wrong location.
Here's where I'm confused... and what's rather interesting...
Digging into the metadata's code, the file does exist where the metadata tells Daz to look for it. The rundown is that Daz wants to look for this file in:
D:\My Daz3d Library\textures\SASE\Karma\
The actual location of the file, where the manifest told DIM to install it to:
D:\My Daz3d Library\runtime\textures\SASE\Karma\
Normally I would just update the metadata's .dsx file in runtime\support to provide the correct location of the file and do database maintenence to fix this up. But according to the .dsx, Daz should be looking for the file exactly where it is, in the runtime environment. There's only one reference to the file in question, SASEKarmaEyesB_1007.jpg, and the support asset is coded as such:
(Snippet taken from \Runtime\Support\DAZ_3D_68489_SASE_Karma_for_Josephene_8.dsx)
This is the correct value, and should also be the value being passed onto Daz Studio by Postgres/CMS in regards to the file's location. If the CMS only generates the metadata from the provided .dsx file from the product, why is it searching for SASEKarmaEyesB_1007.jpg using anything but the path defined by the .dsx..? Which is how this is loosely connected to this thread, where I've asked if the .dsx and manifest are the only files which need editing in regards to moving things around in the library... :)
Actually the more I think about it, Daz probably generates the metadata and passes it to Postgres. Since I can't find much documentation about how they interact with one another, I'm sorta left speculating. But given Postgre's usual application as a CMS it's more than likely just responsible for maintaining the database, rather than generating anything at all. If anyone knows for certain I'd be curious to know, but it's not that big of deal. Never hurts to kn,ow though. :)
Metadata is not related to loading issues - those are down to issues in the .dsf or .duf files themselves. In this case, given the symptoms, I think the path in the .duf is probably //Runtime/Textures/SASE/Karma/SASEKarmaEyesB_1007.jpg and the double / at the beginning is causing the first name to be skipped - in fact this issue is known to affect the eye 7 materials from this vendor, as they used an existing file (with the issue) as a template for future sets rather than saving a fresh preset each time. DS used not to care, but changes to enable it to handle more characters in paths introduced this behaviour of treating two /s as an escape. You can manually edit the .duf files for eye 7 to remove the double characters, but I would check for updats first and report the issue to support if there is no update.
I thought one time I tried to open one of those and found it was compiled (or encrypted), so I hadn't tried to open another one since... hmm. Maybe that was a *.dsa extension. I don't remember now.
Anyway, you're the man, thank you.
As you said, just about every hit is a path with 23 lines out of the 133 contain double slashes. Tedious, but easy enough to fix. Much appreciated. :)
All the Eye Colour*.duf, and the Karma All Maps.duf
Curiously, while I was looking for the *1007.jpg, I found some other attributes I think are also probably incorrect.
Should the id attribute of asset_info in the .duf files always reference the absolute path of it's container? Example should "karma all maps.duf" be:
Because many of them are pointing to a file and folder that doesn't exist at:
Since I'm poking around in here I might as well fix it if it's supposed to be named after itself. Karma All Maps.duf is okay, but without even looking I spotted five or six in the character's root directory that point at the Rainy character.
The id of the file itsdelf is OK - it isn't a call, and again I think this is because (with systematic naming of files) it is simpler, and more reliable, to do a search and replace in an exisiting preset than to manually apply the settings and then save a new preset.
Alright, I'll leave them be. Thanks for the assist! I had to totally break her installation to fix her, but, I learned in the process, so it was worth it. I was just about to give up on it too... after I had replaced all the escape characters in every file in her character directory and reimported metadata there was initially no change, Daz kept wanting the file to be in /textures instead of /runtime. Sooooo I opted to trial by fire and removed every single // from every single file in her directory (over 56,000 references lmao). I fully expected that to break her install but it didn't, and Daz still wanted her texture to be in /textures even after all that. Soooo, I browsed the shop for a bit because I needed to think... low and behold, I ran a full search on her files, and realized I'd missed a single file that was outside of her character directory. It was only one level up, which made it really easy to miss when you're simply browsing paths and ensuring all the files line up to the same path. After nuking the remaining three or four escape characters in that file, Daz stopped asking for the texture. Woooo! But I broke her eyelashes in the meantime by removing some double slashes from one of her morphs. lol. At least I can address this issue if it ever crops up again. :)
Now... to sleep.. before I pass out on my keyboard. Thank you again, hope you have a great weekend!
I'd have doena global search and replace from
"//Runtime
to
"/Runtime
which should catch only the problems.
Generally a character will have a main preset in the Characters folder, then individual shaping and materials presets in a named folder within that - the main character preset for loading in Categories will usually point to the preset in the Characters folder, though the file itself may be duplicated in the sub-folder.
Sorry I didn't see this thread earlier, I could have saved you some grief. The "//Runtime" problem crept up with the release of Studio 4.20. It had stricter syntax checking, and previous versions had let the error slip through. Any products with the typo were suddenly throwing errors, and many were corrected, but, apparently, not all. As you have discovered, the easiest way to correct it is to just edit the preset (np++ "Find In FIles" is a blessing).
Also sorry I looked, because after checking, I found 100 more files in 40 products to repair...
And that's just Genesis 8 figures.
It seems that I don't have the products with such a wrong data in DUF files but how did that "//" come from ?
Saving a xxx Preset normally doesn't create such an error... or did the vendor manually edit the DUF file(s) ?
They were present, quite by accident, when some PA's probably mis-typed and copied, copied and copied the setup for other products (they tend to be from the same 2 or 3 vendors). Studio 4.20 exposed the problem, so anything released after that version would have been caught in production. Many were updated, but some older versions are still floating around. Of course, someone has to write a ticket to get it changed, if the PAs are not proactive about it.
Yeah it was the main file that I had missed. I didn't even see it when I was searching--but yeah, I did do a global replace..lol, that was how I ended up replacing 56,000 lines in such a short time. :)
I appreciate the thought, this thread actually didnt even start out about the missing file, I was just wondering if there were other files with pathing content and such like that which may need to be edited if I moved stuff around in my library... it wasn't until I brought up the missing file that I started to find the files I was actually looking for. Those being the .duf's. I just wanted to know where every file was that might contain a path in case I broke something if I manually moved some things around to alleviate some clutter in my library which has grown quite a bit and very quickly lol. But yeah, thanks. :D It's the thought that counts. :)
edit -> As it turned out I was right in my thinking that there had to be other files somewhere related to pathing and content. I just didn't realize it was the .dufs.... those are everywhere. I feel kinda silly that I must've never apparently tried to open one. I seem to remember trying to at one point but I think it must've been a .dsa because whatever it was was either compiled or encrypted and I think the dsa extension is not in a readable format. I'd have to double check though. It's not like I purposely go around looking for things to break haha :)
The .dufs could be plain text or compressed, which Studio can compress/decompress with the Batch Convert tab pane (not an obvious title).
The older legacy files are .dsa and .ds, which are actually script files (as opposed to .duf, which are purely data structures). The .dsa's can be converted into .dsb's ('a' for ASCII, 'b' for Binary) and back again, but are still editable in the Script IDE. It will even upgrade deprecated formats.
There is a .daz format which no one can read, but Studio can load them. Again.
Finally, the real encrypted format is the .dse, which is understandably uneditable. You need the source code to make a new version.
Thanks for this tidbit! I had recently found that in the window panes while I was trying to troubleshoot Face Transfer 2 vanishing (on both my systems). I assumed it was part of one of the converters I'd picked up on the shop. Anyway, that's nice to know since I had just gone to go take a peek at another .duf causing one of the last warnings I had yet to figure out, the "has no corresponding file," one, and it happens to be a compressed .duf :) It's only complaining about one file but I have a few other packages I've uninstalled that complain about lots more than just one, so hopefully I'll be able to shut them up and have a peaceful logfile. :)