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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I have 5GB and an old and slow 'puter and don't see any lag or unusually long load times. I also don't have any morph sets or characters from Renderosity or ShareCG or any other site besides DAZ3D.
I had this hit me yesterday. There were entries in the log file showing where it was coming from, and once I deleted the problematic entry in the data directory, everything went back to normal.
Had the duplicate formulas issue loading G8F in DS4.12 as well. It wasnt hitting load time extremely much, but was still a nusiance. Log file was only showing alot of unsupported Iray optix warning lines. I orginally thought it was a GPU issue as I had another instance of G8F Manequin loaded in Blender at the time.
After I saw this thread. I went to the DATA/DAZ 3D/GEN 8/FEMALE/MORPHS, (not having Sad Sue) I file sorted by modified date, and started with non DAZ Store products.
I luckily found it on the first one (a freebie morph from Deviant Art). Or this was a morph load bug in 4.12.
I deleted that artist's Data File and didnt get a duplicate formula message.
I reinstalled the Artists Data file and restarted DS to see if it would bug it, to report the bug to him, and oddly still got no Duplicate Formula Error.
A few DS restarts and still no issue.
So IDK.
I went hunting for the actual morph dial in Shapes Tab and Parameters Tab and did notice the morph was a simple dial morph under G8F Morphs (not under actor, body, bodyparts, shapes) as if was fresh off Morph Loader.
Maybe this helps find the bug or others locate their morph. Going through all the morphs could have been like a needle in a haystack.
Just tested with 2nd instance open and no error.
Fingers crossed DF Error doesnt return after computer restart. If it does ill post an addendum here.
I too have duplicate formula's and load times of characters are horrible. Maybe i should investigate as well, see if i can get these load times down.
Got some experimenting to do. Thanks
I've been having this problem for over two years on G3F and G8F, G8F being far worse. Going through my log file would require a week of time. I don't have that type of time on my hands. I believe there is a very simple answer to this: for Daz studio to ignore Duplicate Formula errors and move on.
That, or Daz / vendor creates a script that goes through all duplicate formula files and fixes the issue automatically. I'd be willing to pay $100 for this type of guaranteed fix because of the amount of time it wastes for me.
I also agree that Daz should have a computer that has ALL the products loaded and QA's the morphs as people create them, so that the vendors are required to upload quality morphs- as stated prior, DAZ is free, it's the content library that they make money on- and if content is broken, they can't make money. So they are literally losing money with this error.
and that would help how? Logging the error take almost no time, it's finding it in the first place that slows the process and that would have to be done before it could be ignored.
How would a script fix the ssue? Most of the time it's a conflict between two products that happen to use the same name, so what would the fix be - scan through all the product files to change the name of the conflicting proeprties, being sure to change any presets that call it and hoping that no other products call it? It might be possible, I've done the equivalent manually, but it would inbtroduce a lot of potential for breakage too.
I have not converted anything. And I have no rendo or freebies installed other than Travelor's plants. The only non Daz content that I have installed is Hivewire plants and animals. I get the duplicate files error constantly-so I'm pretty sure that it IS from Daz content.
With which figure(s)? Have you checked the log file to see which proeprties are involved? As I said above, this is usually a clash between two (content) products, niot a bug in one, so difficult for testing to catch.
The only time i've seen this error, is I was using a product that converted G3 characters to G8. I could do this manually just fine. But I purchased a product to do the conversion for me. Then I converted one of the Daz characters (maybe it was the HD version) and never stopped getting the error after loaded G8 again. I reinstalled and started from scractch. It was time anyway.
There's something wonky going on with this. As a content creator I get this all the time when just working on a character and going back and forth through GOZ, pretty soon I will get a duplicate formula error with no understandable reason since every morph has different data. I might have 20 little morphs and they're all saved in the scene file only at that point. Some morphs will be rigged. Log is then filled with this stuff:
2020-06-24 22:01:34.390 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(6871): owner: Genesis8Female
2020-06-24 22:01:34.390 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(6872): output: neck_2:/data/DAZ%203D/Genesis%208/Female/Genesis8Female.dsf#neck_2?center_point/y
2020-06-24 22:01:34.390 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(6873): input: Genesis8Female:/Scenes/blah/blah_016.duf#ZBrush%20Morph?value
2020-06-24 22:01:34.483 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(6870): Duplicate formula found linking zOrigin & ZBrush Morph
If you are correcting JCMs or MCMs make sure that you use ERC Bake on the links (right-click on them in the Proeprty Hierarchy pane) before doing a fresh ERC Freeze - doing two ERC Freezes on the same property without a bake between is very likely to trigger this issue.
In my experience, the more Daz logs, the longer it takes. I've removed morphs before and it took hours. added them back in and took less than 1 hour. So the proclaimed 'morphs' isn't all that's bogging down Daz studio. But for the logging error- a database could be created on the user's computer and once daz does an initial scan, any problem files would be cross referenced and ignored, allowing the system to move forward. if more content is found, it would add those to the database. I'm sure there are other points to be had, but this would help significantly- especially if an author doesn't update said problem files.
If it's a conflict, find a conflict between Anain&Akasha and another product. That's what 60% of my several hundred, if not thousands of 'duplicate formulas' in my log file are. If it is a conflict, then a more strict adherence to file structures and names could be implemented to keep this from happening. At my place of employment, we have several thousands of files, if not millions. Each file gets a unique name, so unique that not two files have the same name. I've seen other scripts here for fixing duplicate IDs and such- opening a file up and changing a piece of information in said file and resaving it or renaming it, isn't difficult.
If the protocols that guide content creation were more strictly enforced, it's more than likely the problem would diminish. There are multiple other companies that disect xml files and scan the code, looking for things that aren't up to par and reject the entire file if an error is found, telling the content creator to fix it before it's allowed and published.
Not necessarily. A cross referencing system would all but guarantee no duplicate file names. It would take time for the system to process all the files and cross reference them, but it can be done.
I'm honestly just glad more and more people are having a problem with this- maybe it'll shed light on underlying issues we're all experiencing.
The writing of the log file doesn't take long (and is deferred until DS isn't busy) - a lot of errors/warnings in the log is associated with slow loading because of the errors, not the logging. Which file would be ignored for a clash? How would updates be handled? I'm not saying this is impossible, I do think it would have its own impact on speed (checking each file to see if it should be skipped - especially for a long list), it would be another "moving part" with its own potential to go wrong, and it would potentially remove useful debugging information.
That is a very large number of problem files. I have a lot of content and there is only one unresolved Duplicate Formula (which I have, pending a fix, manually cleared) - even allowing that a single product pair might throw multiple messages if there is a name clash it does sound as if there is more than just the way the content is initially set up going on. I do agree that a strict naming convention should help - and indeed a lot of PAs add an abbreviation of their name to the morph name for this reason.
Again, this is not usually an error in the file/product - it's a conflict between two products. Not something that could be fixed by scanning a single file. Checking for conflicts would take time related exponentially to the number of files.
Yeah I'm not doing anything like that. Also I'm using Morph Rigger Plus do rig stuff these days anyway.
I would think that DAZ would have a repository of assets, and ANY PA, regardless of their Vendor affiliation, could submit their upcoming creation to DAZ to be checked against their database to see if there were any confilcts, or for that matter, have a web portal to upload a file and have it automatically checked. Results spit out to say, "hay, we already have a file that says "Ann_Eybrow_Menacing,duf" etc etc...
At the end of the day, it helps DAZ overall. I know there is a lot of "you stay in your sandbox", or "its a XYZ product so its out of our hands". The reality though is a if RO, RE or whaterver is doing well, that kind of means DAZ overall is doing well."
Just my two cents.
The speed determent would be far less- as Daz could create a list of offending files. Once daz checks the name of the file against the list, it moves on, not scanning the inners of each individual file, which it seems to do.
And this 'moving part' would be optional- ie, a toggle switch like a radio button. I made this suggestion before and it was completely ignored.
Yes, it is. I have 4 TB of content- purchased and free. From renderosity and here. Suprisingly, I have more issues from here than I do renderosity. do you know how infuriating it is to buy a package, only for Daz to throw an error saying it wasn't done correctly? Then me having to hunt down that file and fix it?
If it's not the file/product, then what is the issue with "Duplicate Formulas found"? What is the EXACT cause of the issue? If a file is released with absolutely no error in the coding within, but still causes Daz studio to throw an error in the file- what's the culprit? I bought Daphne for Olympia 8 and i get the error. Is there another product that uses her file naming convention? Or Daz scanning within the file itself?
According to the log, it says it found a duplicate formula linking FHM and CTRL in ctrldaphne.dsf. This tells me it's within the file.
I don't know about anyone else, but if the error is within the file as the daz file suggests
Not understanding the basic issue does call into question the usefulness of suggestions for a fix or workaround.
What is happening is that you have two characters named "Daphne" installed, and both use ctrldaphne for (I guess) the full morph and (again guessing since you don't specify) FHMdaphne for the head morph (and possibly other names in common too). As a result when Daz loads both it is asked to create, and then to llink, two ctrldaphne sliders with two FHMdaphne sliders and doesn't know what to do. Installing either without the other will not generate an error, it's only when both are installed that there is a name conflict and an error is reported. If one or both of the PAs had in some way complicated the names (adding their initials to the morph name, or adding something like "forO8" at the end of the Olympia one) then there would be no clash. Now, I don't see another Genesis 8 Daphne in store so I suspect the other party to the clash is from another store or is a freebie - it is a pity the log doesn't list both files contributing to the clash - but that shouldn't stop you from opening a support ticket to ask Daz/the PA to do something to make the names on the sliders more unique.
As far as my conversion scripts contributing to this problem (for which I apologize), this issue should have been addressed in the latest update (for all of them). You would need to delete the morphs and do the conversion again though.
I solved the problem by starting a load and then going and having lunch or relieving other bodily function.
I found the culplrit and got rid of the problem. Now my issue is to cut down on G8F load times wich range between 54 seconds and a minute 27 secs.
Easy to fix. Remove the morph or edit the DUF file by replacing the ID.
Were you replying ot me?
I was calling into question what the exact issue was, because i was confused as to why Daz studio was looking inside the file when it was simply a naming issue of the file itself.
I can see others have the same thoughts.
but i have a new one for you. I don't understand this:
2020-06-25 16:58:57.854 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(5995): Duplicate formula found linking xOrigin & MCM_RS_Kala8_Navel_HDLv4 in /data/DAZ 3D/Genesis 3/Female/Morphs/DAZ 3D/Genesis 8/MCM_RS_Kala8_Navel_HDLv4.dsf.
is this referencing a Genesis 3 female morph or genesis 8 morph?
I've never had a Duplicate formula error. But I don't convert anything or use such utilities. Most of my content comes from DAZ.
The issue is not with the name of the file, but name of the morph - Which is defined inside the code found inside the file
This one would need to read the codei inside "MCM_RS_Kala8_Navel_HDLv4.dsf", it may have become corrupted - Reinstall the file, and correct the /Genesis 3/ in the path
Not according to Richard up there... unless of course, he didn't explain it well enough.
But the daphne issue was; it got installed in two different locations- one of which was completely false.
I'll look at the original install- I don't like changing file paths with morphs. I only do that for the content library b/c some author pathways make no sense.
It's the property name, which seems to be what I said. "As a result when Daz loads both it is asked to create, and then to llink, two ctrldaphne sliders with two FHMdaphne sliders and doesn't know what to do. "
Again, I'm talking about the paths specified inside the code, inside the morph files.
Since the filename specifies "Kala8", the code inside the file should not make any references to Genesis 3 paths, the wrong path may even be inside an other Kala8 related file.
Usually these are due to the PA making manual editing of the code and/or copying code from an other morph that was meant for different generation (G3)
Or you can write a ticket and wait if the PA fixes the code
Nope- that doesn't specify the name...
Moving on...
No, don't mis-quote me. They are two entirely different files in two entirely different folders. I don't reorder items in the content/data folder unless absolutely necessary. It's the files in the content library within daz studio- content/people/genesis X/character/ that i re-organize because some vendors have obscure file structures that don't make any sense.
But of course, I'll be the one blamed for all this, because what do I know- I'm only the end user.
Yes, if two different characters each create a ctrldaphne slider then having either one installed and not the other will not produce a coflict, having both installed will. In fact, of course, the .dsf file usually does have the same ane as the property - but it's the property names that matter.