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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
Not yet.
Are you serious here?
What precisely does this affect...ANY duf file? or just those accessed through poser content?
This is pretty scary.
Scene subset files...as far as I can tell.
Scene subset files...as far as I can tell.
Scene subsets containing imported items (Poser files, OBJ files) that hadn't been saved as an asset when the scene subset was saved.
Scene subsets containing imported items (Poser files, OBJ files) that hadn't been saved as an asset when the scene subset was saved.
Ok...so a subset of the subset... ;-P
Which goes to show that it is even more important to properly save assets as actual assets.
A relevant thought — will this mean that from now on content shouldn't be released any more as Poser-files-with-D|S-sidecars, but as proper already-converted-to-D|S-asset files?
A relevant thought — will this mean that from now on content shouldn't be released any more as Poser-files-with-D|S-sidecars, but as proper already-converted-to-D|S-asset files?
They can still be sidecars in the Poser libraries, but should be actual scenes/scene subsets rather than Poser figures/props with DS mats.
That's just it — from what was said upthread, the sidecars aren't just D|S MATs any more, that's why they must be hardcoded to point back to the location DIM wants to install the content files into.
I'd be interested in an official reply to this; what was the reason for the change to the sidecar file format? It's looking like this might be what's causing the problem.
That's just it — from what was said upthread, the sidecars aren't just D|S MATs any more, that's why they must be hardcoded to point back to the location DIM wants to install the content files into.
I'd be interested in an official reply to this; what was the reason for the change to the sidecar file format? It's looking like this might be what's causing the problem.
No the problem is not that they aren't just mats, the problem is that they are scene subsets without the associated Data files, so they require the Poser items to regenerate the Data files, and THAT part requires the relative paths to be unchanged. If they were actual scene subsets with Data files (which until now is the only thing I had seen) they wouldn't have this problem.
They can still be sidecars in the Poser libraries, but should be actual scenes/scene subsets rather than Poser figures/props with DS mats.
Just forget the sidecars and supply DS mats already. This is ridiculous. Never mess with a customer's content or change the 'rules' in the middle of the game. I don't care what your justification for doing this is, it's not good policy.
They can still be sidecars in the Poser libraries, but should be actual scenes/scene subsets rather than Poser figures/props with DS mats.
Just forget the sidecars and supply DS mats already. This is ridiculous. Never mess with a customer's content or change the 'rules' in the middle of the game. I don't care what your justification for doing this is, it's not good policy.
No thanks, things are a LOT better organized now than they were in the past. And they're moving away from sidecar files -- most of the time there are separate stand-alone installers now.
Just forget the sidecars and supply DS mats already. This is ridiculous. Never mess with a customer's content or change the 'rules' in the middle of the game. I don't care what your justification for doing this is, it's not good policy.
No thanks, things are a LOT better organized now than they were in the past. And they're moving away from sidecar files -- most of the time there are separate stand-alone installers now.
No sidecars and separate installers are fine with me.
However things being "a LOT better organized"? Better than what? Poser files by definition can never be with all the separate libraries. I will always and forever have to organize them myself. You should see my beautiful M4, K4, and 1 of 2 V4 libraries where I can drill down to what I want quickly with no fuss. And I'm in the process of organizing my separate Poser format scenes and props runtime.
We've been speaking of scene subsets, what about scenes? Do they create data files for imported content? Do scenes have relative pathing?
Well, I've heard back on my bug report. Support seems determined to inform me that "it sounds like an installation issue", "there's a setting issue on my computer", and would I please, please, pretty please try the DIM. No thanks.
I'll give my conversation with Support a couple more goes back and forth before I close it due to them not understanding we're talking about two different problems from three different directions.
This is not about relative vs. absolute paths -- all the paths are relative paths. The problem is that the Data files are not included, so they have to be recreated from the original Poser-format files, and those files are no longer at the same relative path.
Easily solved, before the item comes out of QA.
Sadly our save formats are just as user unfriendly with Poser content as the old .DAZ scene files were. By the sounds of things it's been a Poser prop loaded into DS and then saved as a scene/subset, if it doesn't have the asset files then DS wont load the Poser files, instead it reads the Poser data and recreates the asset files from it, it then loads those freshly created asset files, that's where pathways can really trip up the system.
TBH if your going to the trouble of creating DS materials for a prop then either save just the materials or use Figure/Prop Assets and convert it into a DS native DSON prop, that way the end user gets to choose which version to use.
As for the CMS, it works as a controller, that way content that hasn't been saved "correctly" will still work as intended, simple example is Genesis 1 clothing, viewed in a text editor you will find most of them have been saved as scene subsets. Saved like this means they don't have the conforming code required for it to "fit to" on loading, but CMS users are oblivious to this because it takes over and forces the item to "fit to".
This is not about relative vs. absolute paths -- all the paths are relative paths. The problem is that the Data files are not included, so they have to be recreated from the original Poser-format files, and those files are no longer at the same relative path.
Which is fine if you've done your organizing before you use any poser file. Neither DIM nor CMS has anything to do with it, right? I have plenty of Poser content installed ((1)non-DAZ and (2)DAZ installed prior to DIM and (3)DAZ installed with DIM prior to and during the switch from Valentina where I prevented the metadata from entering the db) and it works fine.
Confirmation, please. For Poser content all that is needed is to load the content and save each piece as a prop/asset before saving each piece as a scene subset then the current location will be set in stone?
Is there any way to edit a saved prop/asset if we run into trouble?
Edit: nevermind the last question. Saving a prop/asset creates the data files, pathing has nothing to do with it. I think.
Pathing is vital, as always, but it's all one-way and invisible to the user unless Something Nasty™ happens — the .duf file needs to know where the /data/ files are, but the /data/ files don't need to know where the .duf file is, unless the /data/ files are lost*. In this case the pointers in the .duf file will lead to wherever the Poser originals were when the .duf was created; this is how D|S recreates missing /data/ files.
* or were never copied into the installer in the first place...
About your edit anyway: if you don't save the .duf as a compressed file, then it's just plain text. But the format's changed a lot since D|S4.0 came out, even a simple materials preset is almost completely opaque to me now.
Pathing is vital, as always, but it's all one-way and invisible to the user unless Something Nasty™ happens — the .duf file needs to know where the /data/ files are, but the /data/ files don't need to know where the .duf file is, unless the /data/ files are lost*. In this case the pointers in the .duf file will lead to wherever the Poser originals were when the .duf was created; this is how D|S recreates missing /data/ files.
* or were never copied into the installer in the first place...
About your edit anyway: if you don't save the .duf as a compressed file, then it's just plain text. But the format's changed a lot since D|S4.0 came out, even a simple materials preset is almost completely opaque to me now.
Thanks--you explained very well.