I've created a package for V4 that INJects some custom morphs via PMD and then enslaves those custom morphs along with several Morphs++/Aiko/Vittorio morphs to a few master parameters.  The result works perfectly for me, but my beta tester reports that the model explodes when the enslavement pose is loaded.  If any one of the master dials is set to 1, the morphed model appears as it should, but dialing it back to 0 re-explodes the figure.  Does anyone know what the heck is going on here?  I'll post the text of the pose if necessary for diagnosis.  Any help at all will be greatly appreciated, as I'm at my wits end!  It's a persistent problem that makes no apparent sense!

Make absolutely sure your testers are not using a modified V4, and they have updated to the current version.  It has happened to me that testers use a hacked up version of V4 that has issues with some item or other, or are using an old version of V4 that included buggy morph data (original releases of V4 actually would cause Poser to crash in certain circumstances, all by themselves).

Good advice, but in this case it's a copy of V4 that was downloaded and reinstalled on June 18, 2010 & is unmodified.  (V4 & M4 were both updated last week).  As I usually only use Poser for testing, I don't keep a copy of V4 with morphs preloaded.  There was similar behaviour with these files a few weeks ago, so I'm not inclined to think its caused by the recent V4 update.

A big part of the problem is the inconsistency.  One time, she'll blow up but the dials will restore her and make the expected mesh changes.  Another time, she won't blow up but the dials will have no effect whatsoever.  It's as if the computer is randomly choosing to do anything EXCEPT what it's s'posed to do!

An alternative is to do it the DAZ way with INJ/REM poses, and make use of one or more of the existing channels in the CR2.
enderosity.com/mod/freestuff/details.php?item_id=49770
shouldn't take you very long to write out a set of poses with that script, I use it.

I'm already using some of the existing channels for the master parameters.

and....

Nothing.  I just thought you thought that might be at least part of the solution.

Quote - I just thought you thought that might be at least part of the solution.

Or part of the problem.

I suspect the "blow up" is happening due to a phenomenon known as "double feeding" (which is possibly a side effect of the way Poser reads some poses).

The usual reason for ERC not working when INJected into DAZ figures is if it's been setup with an explicit figure number (as DAZ insist on doing) and the figure isn't the first loaded in a session.

So if a hand constructed figure works consistently but INJection doesn't, you're running into one or more of several Poser quirks, which you may be able to work around by suitably modifying the INJ poses.

Whilst unintended, I think an exploding V4 could be fun...

Quote - An alternative is to do it the DAZ way with INJ/REM poses, and make use of one or more of the existing channels in the CR2.
enderosity.com/mod/freestuff/details.php?item_id=49770
shouldn't take you very long to write out a set of poses with that script, I use it.

Would the result be legally distributable, though?  Remember: most of what the total morph does is simply enslave certain Morphs++, Aiko, and Vittorio dials to a certain proportion.  

If you already got past distributing a PMD legally, I wonder why you're asking this question.  You can modify your INJ/REM poses by hand to 1) load your deltas plus whatever DAZ deltas are required (or just instruct the user to load these first themselves in your documentation), and 2) set any dial values you want, in one pose.  Of course you don't want to include the DAZ deltas in your distribution, you couldn't do that with a PMD any more than with INJ/REM.

Yes, but then it's an all-or-nothing character morph that can't be easily blended with other custom characters, which is the whole point of the package.  The two dozen or so dependent third-party morphs need to be automatically dialed up or down as a function of just a few master dials controlled manually by the user.  The PMD is merely for transferring the few original morphs that are involved.  Unless I'm misreading your statement, what you're suggesting amounts to little more than the usual dial-spinning INJ/REM setup.

Yes, we are failing to communicate.  What is it that you are able to do with PMD injection that you cannot otherwise do?  You just said all you're using it for is to move in your own deltas - I don't understand what the issue is with using INJ/REM for this part of the task instead, and just don't change the other aspects of however you're setting the other dials.

I've tried transferring deltas without PMD (by embedding the deltas in the INJ PZ2), but the results were screwy (if I recall correctly, the dials were either invisible or ineffectual).  My own skills are advancing steadily but still limited.  If you know how to make it work, I'd be happy to listen!  In fact, I could use another beta tester at this point, if for nothing else than to rule out some quirky fault in my current testers workflow ('cause as I said, it mysteriously works perfectly for me).  You up for it?

While I'm not at all interested in testing your stuff, you're welcome to look at how I did the body INJ for the seraphim freebie outfit, or the other couple of morph-related things I've released for free. 

Quote - I've tried transferring deltas without PMD (by embedding the deltas in the INJ PZ2), but the results were screwy (if I recall correctly, the dials were either invisible or ineffectual).

A PMD injection can create a new channel in the figure, eg:

                targetGeom <span style="color:rgb(0,255,0);">LongNose</span>
                        {
                        name LongNose

A normal delta injection can't create a new channel in the figure. You have to inject into an existing channel, eg: targetGeom PBMCC_28 { name LongNose

Perhaps that is where you were running into difficulties.

nruddock,

What's this "double feeding" you mention, and can you provide any technical info or links? I'm well aware of the "explicit figure number" problem, it's causes and cures, but "double feeding" is a term I have not heard before.

Quote - What's this "double feeding" you mention, and can you provide any technical info or links?

First coined in relation to magnets -> http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=1679333
Wyrmmaster's magnet sets include poses to fix the problem when it occured.
Cage noted recently that it can happen when using poses to add ERC -> http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2802838

I believe this is a bug introduced in Poser 8 if I understood the discussions correctly. Each pose file contains two sections and it appeared Poser was reading both sections each time instead of only one.  

I may be wrong though :(  

I would change the pmd  so the morphs are applied zeroed, which should have no effect on the figure, and then have a pose file to apply the morphs in the correct order.

Turned out the problems with the exploding V4 were indeed caused by a Stupid Tester Pet Trick:  I had left Use External Binary Morph Targets checked (the default installation state).  Turning it off appears to have resolved the initial problem in P7.

TEN STROKES OF THE LASH!

Stop batting those eyes~!

Quote - Stop batting those eyes~!

Touché! 

Update: unchecking "Use External Binary Morphs" appeared to solve the problem for a while, but now it's returned with an improved but still annoying 50%% occurrence rate.  Half the time, it works swimmingly, while the other half the explosions and/or ineffectual dials return.

UPDATE: While tinkering around, I made a discovery that, while frustrating in its own right, might point us in the direction of the problem's root cause.  Apparently, the pose that creates most the desired morph dependencies arbitrarily remove a few default dependencies (mainly, the Eyeballs section of Morphs++).  In other words, after loading the custom-enslavement PZ2, the eyeball morphs on the Head have no effect whatsoever because their enslavement of the corresponding morphs on each Eye is canceled.  Earlier, I encountered the exact same problem with the ChestSize Morphform, but I thought at the time it was just an isolated, quirky result of me trying to enslave a scaling parameter rather than a normal morph target.  This latest discovery is disturbing for two reasons: 1)   according to the prefixes used in the internal names for the Eyeball morphs, they're not scaling parameters but true morph targets;   2)  the custom-enslavement pose leaves all of the Eyeball morphs completely alone!

Once again, the system appears to be doing something I never told it to.  Does anyone know an ERC code command that basically says "APPEND BUT DO NOT OVERWRITE"?