Props I make call multiple main .dsf files.
lukon100
Posts: 864
I make hard surface models with morphs in Blender for Daz. And I often revise the mesh and morph targets (in Blender) and save the revised prop over the old one, with same name and all. Everything works still fine, but these morphing props often accumulate multiple main .dsf files, all of which get called by the .duf when loading. The actual morph .dsf's are still just one version each, and work fine. Only the main .dsf file gets a new version along side it.
My updated meshes from Blender always have a different version identifier in the name, even when I keep the name of the prop exactly the same. I suppose this is why Daz makes an additional main .dsf file for each new version. What baffles me is why Daz makes the .duf file call the main .dsf files for obsolete versions of the main .dsf file, such that I must keep all the those obsolete main .dsf files just so the prop will load.
Doesn't this take up disk space needlessly?
And, isn't there a way to get rid of these calls to obsolete main .dsf files?
I could re-make the prop all over again from the known-good Blender-exported mesh files. But that will often require me to also re-make the morphs, and to re-make the often complicated IRC relationships between the morphs. Hours and hours of do-over work.
Would it be safe to open up the .duf prop file and edit it such that it no longer calls any obsolete main .dsf files, and replace all those calls with calls to only the most recent version of the main .dsf file?
Isn't there an even easier way?

Comments
I don't quite understand what you mean by "main .dsf'.... if you mean the DSF file of the Base geometry of the Prop, one DUF should only link to one DSF file of Base geometry... How can it link to multiple DSFs ?
Yes, by "main .dsf", I mean the DSF file of the Base geometry of the prop. I call it "main .dsf" becaue morph files also have the .dsf extension. And I want to distinguish them in my posts.
I do not know how my prop files can call multiple base geomatry .dsf files. Perhaps they actually do not call multiple .dsf geometry files. What I do know is that if I delete one any one of the multiple geometry .dsf files (or just change the name to flout any call to them), the prop fails to load. I get error messages saying Daz can't find the .dsf file I changed the name of. If I restore that .dsf file and then change the name of a different .dsf file, then Daz throws errors saying it can't find the different .dsf file I changed the name of. I take this to be evidence that the .duf prop file calls both of those .dsf files.
I investigated one of my prop .duf files and discovered that the prop .dsf file does indeed call only one gometry .dsf file.
Yes, then why does Daz thow the error message claiming it can't find the geometry .dsf file that isn't even called in the .duf prop file?
I have a suspicion: There exist several .duf SCENE files on my computer that use the old version of the prop. The old version of the prop, in turn, calls the older geometry .dsf file. Perhaps Daz loads my new prop from the CMS, but also tries to load an obsolete version of the prop it finds within a .duf scene file OUTSIDE the CMS.
-OR-
Maybe Daz is trying to load old .obj version exports from Blender, that happen to be in the CMS at the path:
E:\Luke\3D\My DAZ 3D Library\Other Import Formats (Raw)\Vehicles\Air And Space\Qyixor\Bulkhead With Door
Wherin live the Blender generated .obj exports for five versions of the prop, the fifth one being the final good one from which the .duf prop was made. These files are .obj's, but maybe Daz has a way of confusing at least one of them for a .dsf file. I don't know.
Can I just send you a copy of one of my props that has this problem? Particularly, this "Bulkhead With Door, V1.duf" that I've been investigating?
I don't think the issue has anything to do with cms because any explicite error of showing missing dsf files should just link to the physical file locations in your Daz Library rather than any metadata stored in cms database.
AFAIK, after importing OBJ files into DS scenes, OBJs turn into geometry data in RAM that can be saved as DSON format files, so it shouldn't have the link to the original paths / files of OBJ anymore~
Yea, you can send me the Prop's DUF file as well as the its DSF file in data folder. I can test it on my side ~~
A DSON asset has a DUF loader file, a Geometry DSF, and a whole bunch of sub DSF files, each of those sub DSF files has a "Parent" line which attaches that DSF to the geometry DSF in DS.
One or more of those sub DSF files in your prop is looking for another Geometry DSF than the one DS is trying to load it with. "AKA" a bad Parent error.
The main question is how did you save the prop to start with, "Figure/Prop assets" or scene/subset?
Thanks for your reply.
I saved it as a Figure/Prop asset.
5 props in my product have this problem, and all 5 have morphs. Based on what you're telling me, it sounds to me like one or more of the morph dsf's are calling one or more obsolete geometry dsf's. Or maybe the UV "default.dsf" is doing that.
Also, all 5 props with this prolem are used in one or more scene subsets. I don't know if this is relevant.
---------------------------------------------------------------------------------------------
Update:
Yes. One morph dsf file did call back to an obsolete geometry dsf. That morph file was itself obsolete as well.
Merely renaming this obsolete morph file (to simulate deleting it) did not fix the problem. Even renamed, it had to be moved to a temp directory outside of Daz CMS - an even better simulation of deleting it.
Anyway, once ridden of this obolete morph file, I could finally also get rid of the corresponding obsolete geometry dsf file it was calling, and the prop then loaded fine without it.
The obsolete morph dsf file differed in name by one letter; it had a pluralising "s" - "Open Doors" instead of "Open Door". The new, good morph is "Open Door". They are both ERC's that XTranslate a pair of sliding doors apart from one another.
So now I'm wondering whether the other 4 props with this problem also have this problem because of the presence of obsolete morphs. I'll be checking on this in the upcoming week, if I have time.