Duplicate Formulas on Genesis 8 Female

I can't load any G8F character, including the basic, without getting this error message. When I load the basic figure and look at the currently used morphs, I see that three eyelash morphs have been added as a default. Anyway, I am a vendor over at Renderosity and they won't pass any of my G8F products until this is resolved. Is there a fix coming?
Post edited by infinitetofu on
Comments
I get this, too, for all G8 females. And on so many other products too, that I just automatically hit the "Ok" button, to let them load. I guess I've given up on Tech Support fixing things (I have several unresolved tickets ...Well those are separate issues, I guess.)
This means that either two products use the same morph name, with a link to one or more morphs from each, or there was an error in setting up a morph (usually running ERC Freeze twice in succession trying to edit the link). Checking the log file (Help>Troubleshooting>View Log) should let you see which morph is triggering the error - then you need to work out whether it's a case of another morph with the same name or a problem with the morph itself.
I am getting this message as well, but when I check the log, there are a lot of "duplicate formulas" that show up. And it is happening with multiple characters.
In my experience this is pretty common. Also I give up with daz support since they are often unable to solve issues, even when you provide the solution to them yourself.
For example if you load the G3F, with the installed G3F package alone without any other package, you see in the log that there's an error because it requires a morph that's in the commercial head morph package. This was never fixed.
If you ask me, the DAZ quality control seems to be more worried about "nice pictures" than working assets.
Yes, it will - when you load the base figure, or any character for the base figure, it reads in all of the morph data and so hits the duplicate formulas (it doesn't keep the deltas, the actual shapes changes, in memory for shapes that are zeroed but it needs to read everything in and keep the relationships - the formulas - so it knows which sliders to show and when they will be triggered).
Is this a bug (as in causng problems) or just a notice that there's an unresolved link? The latter is perfectly harmless, it just means (in most cases) that there is a corrective morph (for a bend or another morph) which is to kick in only when some morph is set - if you don't have that morph then the link can't be established, triggering a warning in the log, but since you don't need the correction it doesn';t matter.
I've been getting the Duplicate formulas error since installing the new beta.
Removed as it wasn't about this issue
And not in the release build? Do the content directories, and their order in Content Diectory Manager, match? Order might matter if there are two versions of the problem file, one fixed and one not - DS will load the first it comes to.
It is harmless .. But warnings and unresolved links just slow down the loading time. And there is no reason to include a link to something that's in another package.
The comment about need doesn't really work in general - a correction for Shape X used with Shape Y, where X and Y are in separate packages, has to be included in one package or the other - and be loaded even if the other package isn't present.
I don't know .. Here pMCMEyesIrisSize_n has the only purpose to control PHMEyesIrisSize that's in the Head Morphs package. There's not X and Y as far as I can see, that is, there's only a control morph for a morph in another package. So pMCMEyesIrisSize_n should be in the Head Morphs package as well. I can't see any reason to keep them separated.
WARNING: fileinput\dzassetdaz.cpp(5795): Could not find target property for formula: .. PHMEyesIrisSize.dsf#PHMEyesIrisSize?value in file: .. pMCMEyesIrisSize_n.dsf
Me too
and in this case it may conceivably be unneeded, but in the geenral case you can expect to get these for good reason and they are harmless.
Only if the two have the same name - a duplicate formula error means that there are two instructions to link PropertyA to PropertyB, though they don't have to be the same properties - just use the same names.
More like when morphs have the same internal name. A good example is LY Domino and LY Briallen. Both LY Briallen and LY Domino's Thora FHM has the internal name LY_XXX, so when other morphs, like the ctrl shapng morphs, call the FHM (LY_XXX) it causes a duplicate formula error, since the internal name is being linked from two different formulas.
Both ends of the link would have to have the same name.
It seems clear that the way DS works, possible confusion can arise between different items (links, objects, morphs etc) with the same name. Normally this doesn't make much (or any) difference to how the scene works. However, the warning messages do interfere with the smooth running of DS. If DAZ3d cannot (or will not) change the software so these problems cannot occur then could they not change the way the warning messages are dealt with? For example, a message that pops up for a few seconds indicating that the user should check the log for "duplicate issues", but no user response is required and the message does not delay or stop further progress of the procedure.
That's why personally I only install the assets needed for the current project. Then when I change the project I simply switch the content library. Among other things, this also helps to avoid conflicts.
In my opinion the CMS idea of keeping a huge library of assets online all together with smart content tags is simply bad-designed. This is looking for troubles. Especially when you also have shops other than daz and the naming convention is left to the artist.
Actually Duplicate Formulas is an error, not a warning, and does indicate a problem - either the second property, if it's a name clash, won't work or, if it's a doubled up ERC, the property will work but the linked properties will not take their intended values.