"Duplicate formula found" and unhelpful log file entry

IsaacNewtonIsaacNewton Posts: 1,300

This has been a recuring issue for years.

DS identifies that a .duf file being loaded contains duplicate formulas and stops doing anything else until you acknowledge that fact. So it must be serious, right? Well actually it doesn't seem to make any difference at all, as far as I have ever noticed. Apart from the fact that it annoyingly stops the loading process, of course.

In the error message, which you must acknowledge to continue, it says see log file for more details.

Ah good, the log file will tell me what this pesky duplicate formula is and the locations of the properties in the formula. That will make it easy for me to track down and fix. WRONG and WRONG!

The log file details consists of lines like:

2020-12-09 21:20:31.249 WARNING: ..\..\..\..\..\src\sdksource\fileinput\dzassetdaz.cpp(7032): Duplicate formula found linking LGlute Move UpDown&Side2Side 1 & CTRLMD_N_LGluteUpDownSide2Side1_n1 in E:/POSER/Projects/Genesis 8/Fredda/Fredda01.duf.

WTF? The two properies in the duplicate formula are mentioned, the duf file location is mentioned, but no indication of where the properties are located. Presumably this information is in the .duf file (how else could it be noticed), but have you ever tried opening a .duf file?

Since DS has identified a serious problem (it MUST be serious or DS would not stop the loading process, surely), why isn't more useful information put in the log file.

@ the DS devs: If you can spot the problem, why can't you give more information about what is causing it and ... forfend... maybe a hint as to how to solve it?

How about a helpful tutorial.. whoa... I just had an amazing inspirational thought... you could put a link to said helpful tutorial in the error message! Wouldn't that be useful!

We have had the "Duplicate Formulas" issue for years, isn't it about time some more thought was put in to a way to solve it? Or, if it really dosn't need solving, then remove the message which stops the loading process.

 

Post edited by IsaacNewton on

Comments

  • Duplicate formulas means that there are two ERC links between properties (so that one proeprty gets its valeu from, in part, another) where the links match in  property name as both controller and controlled (not necessarily the same properties, just the same names). Usually this means that two different products used the same names, so each would work in isolation but when both are present one blocks the other. The name of a morph is usually the same as the name of the .dsf file, so you can search for the files and identify the conflict (and then report it to the developers and either make your own fix by renemaing one of them or simply temporarily uninstall one of them). I'm not sure why the log doesn't give the details of both partners, when it's a conflict.

    Your case looks odd as it's a scene file, rather than a morph asset, that is cited - that may indicate that one of the problem links is embedded in the file - it could still be a conflict, or if you have set up any ERC Freezs yourself it could be that you ran two without an ERC Bake between them.

  • IsaacNewtonIsaacNewton Posts: 1,300
    edited December 2020

    Given that duplicate formulas is a recurrent problem (I just saw another post this evening on the subject), wouldn't it be a good idea for DAZ3d to release a tutorial on how to fix the problem quickly?

    Or if it is a problem that actually doesn't need to be fixed, then remove the annoying error message which stops the loading process.

    I'm all in favour of error traps, but they should be helpful. If an error is not serious, why not wait until loading is complete before giving the error message, such as is done for missing texture files? It's not like we are given an option to abort the load because the error has been detected. No, it's the worst kind of error message; namely "There is an error. OK?" Well no, it's not OK, but no other option is given. This sort of error message should not be present in professional software. I really think that DAZ3d devs should address this issue.

    Post edited by IsaacNewton on
  • BejaymacBejaymac Posts: 1,886

    Simple question, where did you get this "Fredda01.duf" file from, who ever created it is the source of your problem, I've dealt with more "Duplicate Formula" errors than I care to remember, yet not once have they been in a DUF file.

  • vwranglervwrangler Posts: 4,885

    IsaacNewton said:

    Given that duplicate formulas is a recurrent problem (I just saw another post this evening on the subject), wouldn't it be a good idea for DAZ3d to release a tutorial on how to fix the problem quickly?

    I can't speak to the rest of your post, but I can say, from the user end: dealing with this is not something that most users would be willing or able to do, and it's not quick. I had two (very patient) PAs walking through the process with me a while back -- a Zev0 product got corrected into a duplicate formulas error with a Male-M3dia product -- and it's very very tricky even to just find the error. Part of the issue is that -- before 4.14, anyway, which I haven't installed -- the error log only identified the second product involved in the process. It was a pure matter of luck that the process in this case involved a recent enough installation that both ends of the conflict could be found.

     

    Bejaymac said:

    Simple question, where did you get this "Fredda01.duf" file from, who ever created it is the source of your problem, I've dealt with more "Duplicate Formula" errors than I care to remember, yet not once have they been in a DUF file.

    Oddly enough, I just had an error like this. As far as I can tell, the issue seemed to involve some clothing that had been converted from a previous generation. It was very weird to see that error coming up in a DUF rather than a DSF file.

  • pjwhoopie@yandex.com[email protected] Posts: 793
    edited December 2020

    I think one way to fix it would be have an online asset database for folks that created Daz Assets (regardless, of whose roof they slept under.
    If you are creating a new G8F "Isabell", you can/could upload the file to and it would be scrubbed against the Daz, all seeing, all knowing database and spit out what was confilicting with what is already in the data base.

    So, in my example above, it might spit out, there is already a Isbabell.duf file, or there is already an eyeshalfopen...yadda yadda... so that PAs/Asset makers could fix problems before they made it into anybody's store.

    Just sayin'

    Post edited by [email protected] on
  • BejaymacBejaymac Posts: 1,886

    I doubt that would help any, when it comes to DUF files DS doesn't care what they are called, just as long as two identically named DUF's aren't in the same folder.

    The issue is that content makers don't think like computer programmers, as a result they don't know that every single asset and internal ID needs to have a unique name, and not just unique to you, so using simple naming systems just doesn't cut it.

    In the case of the character Rin, calling a corrective morph "eCTRLEyesClosedL" isn't unique as that's the ID for a pose control that comes with G8F, but that wont cause the duplicate formula error. That is caused by having another corrective morph, from another product, that is also using "eCTRLEyesClosedL", you can also get it from converting one or more characters from G3F to G8F.

    The annoying thing about Rin is that her creator went and changed the file name to "eCTRLRinEyesClosedL.dsf", if he'd named the morph that when he was setting it up in DS to begin with then none of this would have happened.

  • IsaacNewtonIsaacNewton Posts: 1,300
    edited December 2020

    Bejaymac wrote "Simple question, where did you get this "Fredda01.duf" file from..." This file was named so by me because it uses the Fredda head morph. The G8f figure is from an old duf file.

    I take your point about the complexity of finding and solving the original cause of the duplicate formulas. In which case, I ask again, is it worth tracking down? If it were not for the annoying error message that stops loading in the middle of the process without giving any option to do anything about the issue, I would say, I have not noticed any consequences to this error.

    So why do the DS devs have this kind of error message for this particular error? It seems pointless. Why can't they just give an error message after loading is complete?

    Post edited by IsaacNewton on
Sign In or Register to comment.