New Character Alice and her Outfit conflict with Dark Elf Alice Character
helgi66
Posts: 19
https://www.daz3d.com/alice-and-her-outfit-for-genesis-8-female
https://www.daz3d.com/de-alice-for-genesis-8-female
Alice by Belladonna morphs activate Alice by Dark Elf morphs.
Alice by Belladonna skin textures appear to load.
This is the second new character in a row I've purchased from Daz that
conflicts with another Daz product. I could understand a conflict with
an outside vendor, but with Daz hosted content? PA's need to start
adding unique identifiers for their characters, and the QC process
needs to check for potential conflicts. Hire some more elves or give
them more cookies or something...
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
If QA tried to test on a system with all products installed performance would suffer, and while they would catch name conflicts they might miss cases where there was an unintended dependency on another product. Please report this issue so that it can be addressed.
They don't need to test it on a system with all products installed. They'd just need to check the product for conflicts with other products of the same name. The best way to miss something is not to look in the obvious places.
I have to agree. Conflicts like this are a serious concern for me. With more and more products being produced, the need for custom naming of products, especially characters to avoid conflicts is needed more than ever
Actually, I would have expected DAZ to have a naming convention on non-DO characters, just to avoid any current or future incidents. I am obviously wrong...
Assign each PA a unique two/three-chararacter prefix, and require them to use it for all their character file names. Done. But I doubt that will ever happen. The nonsensical excuses that are made for these problems seem like gaslighting.
I had the same problem with two other Daz Originals: Erik HD for Lee 8 and Erik HD for Genesis 8 Male. AFAIK it's still not fixed. I had to find workarounds because I wanted to keep both characters, but I return dodgy products instantaneously nowadays.
this just happened with cinnabar's new g8f character 'evelyn', too. she loads with maelwenn's 'evelyn and lynn' (now retired from the store, alas) morphs applied. the only way to get the character to load correctly is to uninstall maelwenn's characters.
xyer0's solution seems like a really good idea. if PA's as a matter of practice keep their genesis 8/female/morphs/data files in their own personal directories, this won't happen. but as things stand, it can and does and will.
as richard points out, it's impossible for QA to catch this kind of conflict without having every character in the genesis group installed. they can implement this as a policy, though, and that'd be one recurring runtime problem that they don't have to worry about.
j
They could easily have two different content libraries on a PC, one with everything and one with nothing and test a product with both.
This seems to be an issue coming up with increasing frequency. Maybe just adding the product SKU to the end of the product name? Or at least running new products through a giant Excel sheet to ensure that names haven't been duplicated. Also, I've bought some products that have a product name that is one thing, but file names are something else. (Sorry, I don't have an example as I don't recall which products.) This has been tricky sometimes when doing a smart content or content library search because the name on the product page and the installed product name are inconsistent.
A quick web search for Daz3d Alice turns up a useful list of potential conflicts.
There aren't that many characters for Genesis 8 females with the same name.
Load potentially conflicting characters as part of the validation process and
see what happens. It's immediately apparent when the wrong mesh loads, or
the wrong image pops up when you hover over the character in question. You
don't need to try every option for the character to be able to tell a PA there product
needs a little fine tuning.
Instead of just (!) send a ticket, which might ages to get solved, I probably would also ask for a refund because such products aren't useable... and such refund requests probably would get QA working at enhanced speed...
They partially fixed the Erik problem -- they renamed the Content Library directories so that the files didn't overwrite each other any more by renaming the Erik for Lee 8 directory from just "Erik" to "VX Erik". An update for that was in DIM a month or so ago. They didn't fix the issue of the main controller for each character combining when "Consolidate Properties" is checked, however.
They don't even have that rule for their own characters. Both Eriks are Daz Originals.
I'm a bit confused. How can they possibly catch an unintended dependency on another product if they test each individual product on a clean system with nothing but the starter essentials installed? It seems like the only possible way to catch an untintended dependency would be to test on a system with everything installed.
It would probably take a monster system with a huge amount of RAM and disk space -- so far more powerful than what most users would have -- but a system with at least all the characters installed would allow them not only to catch any name conflicts, but also those duplicate formula errors that are so difficult to track down.
It does seem as if testing on a clean system and also checking on a system with all the characters might be advisable, its not difficult you just have seperate runtimes.
Isn't that the point? They don't...
As for asking for refunds instead of technical support...I've made a ticket asking for a refund acouple of months back. Every month I'm adding another comment asking if anybody is home, but apparently not...
I think Richard meant cases where a PA may have reused a file from one of their other products by mistake. If that other product is installed you won't see an error as the required file will be there.
Seems a bit odd if he did as the thread isn't referring to that at all.
Could DIM be updated to detect conflicts like this during product install?
+1
Seriously, seach for 'Alice'... "Oh look people that names already exists."
Time to vote with your wallet.
Stop buying,
Request refund on everything bought in the last 30 days... Explain why, making it very plain.
Let PAs know what you did on the forums, after all, they deserve to know.
It would only take a machine capable of running a spreadsheet to catch name conflicts.
My point was that a fully-loaded runtime, while slow in operation, would catch name clashes but would miss dependencies; a system with the base content and any listed dependencies would catch unlisted dependencies but not name clashes.
"My point was that a fully-loaded runtime, while slow in operation, would catch name clashes but would miss dependencies; a system with the base content and any listed dependencies would catch unlisted dependencies but not name clashes."
Well, it's sounds like the QC person just needs a second system so they have the tools they need to do the best quality work.
PC's are pretty cheap; it doesn't need a 3090 or anything. It can even be written off as a business expense ;)
This problem isn't going away by itself, and using customers to beta test released products, then leaving them without
a working product for an indeterminate amount of time is abusing their good natures and reflects badly on Daz.
Testing on a clean system will uncover missing files. Testing with a *complete* library would expose duplicate formulas. However, neither case will detect situations where a file is overwritten by a new addition, unless you try to use the former. In the case of the poor Alices, the later installation (either one) would work perfectly, since her files would prevail, at the expense of the other. Since the character filenames are identical, you would have to know one was there beforehand, because it would be replaced by the new one without any warning.
I appreciate your advice, but that's what I basically did years ago. I still use G1, make my own morphs or use GenX, I make body hair with Garibaldi and I use 3DL, so I don't have much interest in new products, but occasionally I need something that I don't already have. In this particular case it was a nice hair model for G3M, the product page said it ships with 3DL mats so I wanted to support the vendor. Turned out the RSL presets were infact the same IRay Uber presets copied over into a "3DL" folder and renamed RSL. So on behalf of all the 3DL users I contacted help center and asked if this is a mistake. I was told that these IRay Uber presets infact are RSL shaders because they (kind of) work in 3DL. I asked them if they are serious and yes they were, so I told them that I request a refund and that I won't accept store credit this time around, I want the money returned to my bank account. After that-nothing
.
You don't need a separate system just different runtimes.
"Testing on a clean system will uncover missing files. Testing with a *complete* library would expose duplicate formulas. However, neither case will detect situations where a file is overwritten by a new addition, unless you try to use the former. In the case of the poor Alices, the later installation (either one) would work perfectly, since her files would prevail, at the expense of the other. Since the character filenames are identical, you would have to know one was there beforehand, because it would be replaced by the new one without any warning."
That's not actually how it works in either of the conflicts I encountered. Both times it applied the correct textures to the new characters, but applied the morphs from the earlier characters.
It apllied morphs from both Alice's to old Alice.
Both characters get screwed up. I uninstalled the new Alice and reinstalled the old one just to be safe. I've contacted Daz and was issued a service ticket.
Right. So all you then need to do is have a system (doesn't need Daz Studio installed) that maintains a database of all the files used in each product. All of which are in the DIM, or listed in the .dsx file that's in the DIM. Compare a candidate DIM to the list of existing files, and you could get a list of conflicts. Once a product is conflict free and released, add it to the database.
The same could be done with "duplicate expression detection."
Dependencies on files not included in the DIM could be handled without having to install it - software could walk the various .duf, etc., files inside the DIM and compare what it finds to what's in the DIM, or what's in the "minimum Daz Studio install." (e.g. base GxM/GxF resources)
These are basic QA-type tools that should be part of a professional organization's process. "Let the computers do the work."
Just my idea. DAZ has the all the sources to DAZ Studio. DAZ has a database with all the products they sell, plus all the downloads required. Why not use part of the sources to create a kind of QA/QC tool? Run any new submission with that tool, and send the result back to the PA, "Please fix this"?
Why let people do the QA/QC, if it can be done via a program? The later is cheaper and more reliable, as it sticks to what has been programmed, and does not have to rely on the daily performance of an individual. QA/QC should be a regular, standarized process, and that's exactly what computers are for.
Did new Alice ever get fixed? I wanted her for her empty eye socket gore.
BTW, Mousso adds "MSO" to each stage of her file-naming; thus, her characters won't clash. I already owned Mousso's Medea, and I purchased Sangriart's Medea w/o thinking about it. That's when I discovered that Mousso had solved the problem before I had one. I sent Sangriart a note asking to consider instituting a unique ID in file names.
No, no update yet.