V4 Morph product - beta test results make no sense
deslea
Posts: 27
Hi
TL;DR Version: V4 Morph product reported by marketplace tester as behaving in a way that is inconsistent with design and structure. I'm confused.
Background
I sell a few products on an outside site (a little less family-oriented than here) that will remain nameless. I've got a fairly successful Genesis 2 morph product that I've been trying to adapt to V4 and make play nicely with Daz and Poser. I'm not a Poser user, but I taught myself enough to work with it. I'm also not a V4 user generally, so I've been on a crash course understanding the concept of PBMs and INJ and PMD files and other things that are outside my normal workflow. I've had many adventures trying different tools to make a product that is well-structured and compatible with both programs.
I thought I had it nailed, after a month of solid work, and it tested well on Daz 4.6 and Poser 2012. But what's come back from the site's beta tester makes no sense at all. To be honest, I really do think it might be user error or a really off-the-wall freak glitch (among other things, he says it overwrote his own morphs, but it has its own channels and groups and identifiers, so that doesn't make sense), but the site naturally won't accept it for another look until I've investigated.
Tester's Comments
He claims to have tested on Daz and "it didn't work" (no details).
He gives the following details about Poser. He's using 2014, not 2012, which I can't justify buying at this stage unless someone can verify that it handles morphs radically differently. I only claim to support 2012 on the blurb.
It is a fail. Not sure how to proceed here. I installed the pack...as directed, it doesn't work in Poser pro 2014 or Daz Studio. The morphs load to the individual body parts(in poser), but they do not create controls at the body(as stated in the readme and the inj pose thumb). I even tried different installations, those didn't work either. I also tried it with a clean V4 and one with my own morphs (not in community channels). The clean V4 didn't fare well. Some PBMs and frustration trying to use them. Using my V4 file, the morphs from the pack did an over-ride of my personal morphs. It didn't inject new deltas, just renamed my existing morphs.
Design element influencing file structure
One fact that makes this product a little more awkward to deal with is that it groups the morphs under their own group in Parameters (this is a user expectation because that's how the Genesis 2 version works - I can move from that if it's necessary to salvage the product though. I am also open to making separate Daz and Poser versions of the product). As I understand it, that means I have to have the channels declared and waiting at figure startup, for it to work on the Daz side of the fence. I haven't had any luck with declaring and then injecting later (although maybe I've done something wrong). This heavily influences the structure of the files.
Product Structure
The way the product is structured is as follows:
Basic structure
- Morphs and Powerloader manifest reside in Runtime\Libraries\!Daz\Victoria 4. The files set up the empty channels ready for the morph injection, either by Powerloader or INJ pose.
- Two pose files, INJ all and REM all, to inject the morphs into the channels if not already injected by Powerloader, in Runtime\Libraries\Pose\[Product name]. The INJ and REM files redirect via readscript to INJ-All and RM-All files under Runtime\Libraries\!Daz\Victoria 4\Deltas. They in turn read all the individual morph deltas in Deltas\[Product Name].
File structure:
Runtime\Libraries\!Daz\Victoria 4\[abdomen, hip, chest, lthigh, rthigh, body]
For abdomen, hip, chest, lthigh, and rthigh, each has the following three files:
[ActorID]-[Product Name]-Chnnls.pz2 - declares the empty channels and their parameters. All are set to hidden 1, named PBM_[morphname], and labelled EMPTY-[morphname].
[ActorID]-[Product Name]-Grps.pz2 - groups the PBMs under groupNode Morph, collapsed 1. (I didn't necessarily want the [Product Name] group for the PBMs, which the users aren't meant to be using directly anyway, although I can change this if it will help).
[ActorID]-[Product Name]-ERC.pz2 - establishes the ERC link from these channels to the user-oriented dial under Body.
Body has the Chnnls and Grps files but not the ERC. The channels are set to hidden 0, named PBM_[morph name], and labelled [morph name] (ie, drops the visible PBM_ for user-friendliness).
Runtime\Libraries\!Daz\Victoria 4\Deltas
InjDeltas.[ProductName]All.pz2 - calls the individual INJ files from Deltas\[Product Name]
RemDeltas.[ProductName]All.pz2 - calls the individual REM files from Deltas\[Product Name]
[Product Name].dsx - defines the Powerloader injections
[Product Name].png - icon for Powerloader
Runtime\Libraries\!Daz\Victoria 4\Deltas\[Product Name]
INJ and REM files corresponding to each channel declared in the other files. Each channel is set to hidden 0, and the ones previously labelled EMPTY-[morphname] become [morphname].
Runtime\Libraries\Pose\[Product Name]
Two pz2s, one to inject all and the other to remove all. They all INJ All and REM all in Deltas. The user is directed in the readme and the icons to go to [Product Name] in Body to control the morphs.
Can anyone see anything in the structure that could have caused the behaviour noted by the tester?
If someone is willing to take a look at the actual files, I'd welcome the help. The product is adult-oriented, so the Readme content may not be palatable to all sensibilities.
Many thanks!
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Did the tester run the DzCrateExPFiles-v4 file after installing the morph set? Does it work for you in DS if you create a new content folder setup and install only the V4 base and you morph set (use the Content Library Manager to copy your existing content folder setup to a new set, then create a new set with just a \Testing folder and make that the active set).
Hi Richard, thanks for the reply.
No, the beta tester wouldn't have run EXP. I deliberately didn't want to make it dependent on running the batch file because I know most people don't read the readme and won't run it themselves, and since it's not selling through Daz (not family friendly) I don't have the benefit of an installer to do it either. The tester needs to do this too - if it doesn't work straight off the bat installed the way the user is told to install it, the marketplace won't accept it.
So once I understood exactly what the EXP did, I manually copied the generated files (the Powerloader file and the ones in the body parts) into the zip. The only thing that isn't replicated directly from the EXP export to the zip is the explicit calls in the V4BODYChnnls/Grps.pz2 (because again, I don't want the user to do anything other than merge the runtime). I know in practice Daz reads through the BODY and other directories on loading and will automatically pick it up and add it to those files then. (Poser may not manually check the directories on load, but Poser isn't reliant on the calls in the first place - Poser seems to tolerate injecting the groups and channels later whereas Daz seems to need them upfront).
The only way it should have failed, unless I've missed something in my understanding of how all these pieces fit together, is if the tester tried to use it on an open instance of Daz and V4 from before the install (which a tester should probably have known better than to do, and he claims to have tried other versions and approaches so he would have restarted in between).
But even then, it should have just failed to work rather than overwriting the tester's other morphs in Poser. That's the part that's got me going "What the --??!!" and got me thinking there must be something radically wrong. Otherwise I'd just say "stuff it" and forget the special grouping, and just use the Injection channel, but this overwriting issue has got me going right back to the drawing board.
It works fine for me when merged clean into a new, empty content library with only a fresh install of V4 (not copied from my usual or dev Runtime, from the V4 installer, so it's not benefiting from any dev leftovers). It works perfectly then in both Daz 4.6 and Poser 2012. I just can't understand the behaviour the tester is reporting. If it was just not working, sure, there's all sorts of things that could lead to that on one version or another even if it works for me - but this is just weird.
All the little workarounds probably look clear as mud here, so I should probably summarise exactly what outcome I'm after here (and the way it actually does work for me in my testing). There may be a much simpler and less error-prone way of doing all this that eludes me.
- I want the user to be able to install with a simple file merge - no installers (unless I script and supply one, I suppose) and no manually running the EXP file themselves. (This one's not negotiable - I can't sell it through the marketplace if this isn't met, and nowhere else is likely to accept it due to the nature of the product). Hence the reliance on Daz scanning the directories to bridge the V4BODY*.pz2 gap.
- I want Daz users to be able to load with Powerloader, if they have it enabled. Hence keeping the morphs in Libraries\!Daz\V4. (I can live without this one in a pinch).
- I want the morphs to appear under their own grouping in both Daz and Poser. This seems to be the hardest thing to do consistently in both programs, and it's why I've needed to put channel and group files in with the V4 files rather than just having my own morphs directory. It was the only way I found that would make Daz do it. Poser, oddly, was more forgiving. I can probably let the grouping go too, in the name of getting the product on the market, but I'm really reluctant to do so. The ease-of-use thing is the point of difference and it adds a lot to the asking price. At this point I need it to recoup the month of work!
- I want Poser users to be able to click one button and load all morphs, ready and waiting as dials in Body. This was, I thought, the easy part, until the tester reported the overwriting issue.
- I want Daz users to be able to do this too if they didn't Powerload, or don't have the option to display the Powerloader enabled at all. Hence the reliance on V4 picking up the morph channels in the individual body part folders, to have the channels and group ready and waiting (since Daz won't load the morphs without the group and channels waiting, unless it's into the INJ channels).
Am I just being too clever for my own good here? Do I need to separate out the Poser and Daz versions into separate products? Is what I'm trying to do actually possible with Generation 4?
Thanks again!
The whole point of the ExP system is that it allows the list of morphs loaded to be adjusted - when the DzCreateExPFiles utility is run it scans through finding all of the installed morph sets and rebuilds the top-level pz2 files, which the CR2 is hard-coded to load, to call them. So if you include a copy of your top-level pz2 files they will fail with a missing file error for any morphs sets you had installed that the user doesn't have and will skip over any morphs that the user has that you don't. The batch file is a necessary pain for anything to happen (PowerLoader doing the same job as the batch file but with user interaction to allow selection of morph sets). What you might be able to do is make two versions - one for DS, relying on the User having PowerLoader active or using the batch file (which is what Carrara users would have to do), and one for Poser, using a .pmd file and a pose to load it. I can't think of a cross application way to handle this.
Thanks Richard, this is really helpful. That explains the behaviour the tester observed.
I have a couple of questions left to figure out how to re-engineer this. (This is spilling more into Daz behaviour now, sorry about that).
1. If I made a Daz version that relied on Powerloader, what files would I need to include (to get Powerloader-assisted EXP to finish the job) and which ones would I omit, if any? Am I understanding you correctly that manually including the Victoria 4\abdomen, etc files might/will break other morph sets for Daz users as well? Or is that a Poser-only behaviour?
2. Let's say I left Powerloader out of it, and did it as a basic injected morph. Am I correct in thinking Daz will only accept an injected morph to a channel loaded with the figure (ie, PBMCC_01-50) and you can't script it to add channels later? (I haven't had any success with adding channels). The problem I have is the set has 22 morphs. So in the test I did of this method tonight, I used PBMCC29-50. That will avoid conflicts with the majority of character morphs, but a few vendors use random channels, probably to avoid conflicts too. Mihrelle, for instance, seems to use PBMCC41 a lot. Similarly, can you script adding a group later? Also not something I've had any success with. I haven't tried an actual .ds script though, just the pz2s.
(Actually, you know what would be an awesome update for Victoria? To add a script that scans a directory - say, !Daz\Victoria 4\Vendors - and if it finds, say, an empty file called deslea_01_20.txt, it includes in startup the empty channels deslea_PBMCC_01-20. Then vendors wouldn't conflict with each other or across their own products, but the empty channels would only be included if an installed product needs it and the vendor has included the empty .txt file to trigger it. Just a thought).
I can't tell you how grateful I am that you've stuck with me on this - I know it's information-dense. Thanks so much.
As for your script which would add channels, that's basically what the EXP batch file does: it scans the !DAZ/V4 directory and computes a list of the corresponding channels, and then those will be created when you load a new V4.
Thanks Leana.
The problem I'm coming up against is, EXP doesn't seem to be predictable. This behaviour of it skipping or overwriting morphs depending on what's different about your config versus your customer's is a complete dealbreaker for making clean redistributable content. Frankly it's a miracle anyone ever developed anything for V4 at all when we're all limited to the same fifty generic channels and we can all overwrite each other regardless of whether we use PMBCCs or EXP. If we could trigger extra channels with unique names, with no modifications to the scripting within the core V4 files themselves, it would bypass all that and make a universally consistent behaviour.
I know I probably sound very naive in some ways, but as someone who's generally developed for Genesis/Genesis 2, I've found developing for V4 really awful and hacky and buggy. I'm sort of hell-bent on making it work now, but if I'd had any idea how error-prone the V4 technology was, I would never have started it.
On re-reading and after some testing, I'm actually not sure I understood this after all. Or rather, I think I understand, but it means I don't understand what happened to the tester after all.
The understanding I (thought I) had before this thread was -
!Daz\Victoria 4 contains core V4 pz2s that get rebuilt every time you load V4. Therefore, I did not include them in the folder structure provided to the tester.
!Daz\Victoria 4\[body parts] contain separate product-specific Chnnls/Grps/ERC files that should not affect anything else, but should trigger the rebuild. So I did include the ones of those related to my product in what the tester had.
!Daz\Victoria 4\Deltas contains metadata and INJ/REM All files for the product, which I did include.
!Daz\Victoria 4\Deltas\Product Name contains the actual deltas, injected by the INJs into the pre-prepared channels, which I did include.
After I read your explanation, I thought you meant the files in each [body part] were the problem, and if they were absent, Powerloader would (doing the job of EXP) rebuild them from the files that were left. That understanding didn't hold up in testing, and on re-reading I'm starting to think I was right in the first place. But in that case I'm back to square one on understanding how it messed up the tester's runtime. (Unless he'd hardcoded his custom morphs into the core V4 files, which were wiped in the rebuild?)
No, those files are rebuilt when you run DzCreateExPFiles-v4 (or when you sue PowerLoader with the option to create the files checked). When V4 is loaded, from the original library file, it reads those files and then those files read the individual product files that were present the last time the batch file was run. ExP works by having independent files, as you say, in the body part folders for each product; the batch file then tells the DzCreateExPFiles tool to scan those folders and to compile a list of their .pz2 files and to output it as a series of .pz2s in the root folder that use readscript to load in the product pz2s. PowerLoader is another tool that can make that list. Loading the CR2 is a purely read-only process, it doesn't change any files on the system and can't look for additional files.
Yes, a DS script or a Poser Python script could create channels in the figure into which the morphs could be injected - but then you have to maintain two scripts, and you are closing out users of other applications (Carrara, Cinema 4D via Interposer Pro, possibly Vue etc.). ExP usually works as long as people don't a) install to the application folder in Windows Vista or later and b) don't have two copies of the \!DAZ\Figure name folder., and it has the advantage of working in most applications that will read poser files and of having only a single set of files to maintain.
Thanks Richard, that explains pretty much everything in that case.
Where my logic had gone wrong was, I was sort of conflating the startup behaviour of the CR2 itself, Powerloader, the EXP and the batch file together. So for instance, if the user has Powerloader turned off, there's nothing to trigger the EXP and updated batch file, which would create the behaviour where the channels aren't created and nothing happens - but I hadn't connected that up because I was thinking of loading V4 as more or less a single event rather than a chain of events with interdependencies.
A marketplace tester is exactly the sort of person who will have two copies of the figure, unfortunately (and this tester actually does). That would explain why there were such buggy results. I don't think "usually works" will cut it for this even if I can explain it and convince the marketplace that it's because of the tester's non-standard install, so I think I'll just remove the Powerloader support altogether.
So my re-engineered approach at this point is -
- A Poser version with non-community channels and groups (won't work in Daz, but also won't conflict with INJ character morphs)
- A Daz version, with one of two approaches -
Either
(1) inject to channels 29-50, with an extra Troubleshooting folder with an alt version that injects to channels 7-28 (this significantly reduces, but does not completely eliminate the risk of clashing with character morphs),
or
(2) a script-based writing of the channels to avoid the conflict issue, noting that this will eliminate the possibility of use in Carrara etc - probably not really a problem for this product.
I've got the Poser and Daz INJ versions up and running, now I just need to figure out the script version. But if I need help with that, I'll start a new thread under Daz Discussion, since we're firmly in that territory now.
Thanks again for all your patience and expertise, it's very much appreciated.
You're welcome, I'm just sorry I couldn't offer a more general solution.