Okay, I hope I can answer all the questions in one go. First, it was probably unwise of me to speak of 'original' and 'new' files. Let's rather call them input and output files.

So there's an input cr2, which is not necessarily the original cr2 the character was shipped with, but what you currently use. It may have your favorite texture and pose preloaded, it may include custom morphs, etc. Most importantly, it could well be a result of previous applications of the script I am proposing to write. So this can be an iterative process. You buy or download a new morph pack and add channels and groups for it in your favorite cr2. Then you buy another new morph pack and you do it again. No need to start from the original cr2 each time, as long as the one you're currently using isn't for some reason badly corrupted.

Then there's the input pz2, which is 'new' in the sense that in contains morphs that the cr2 is not yet prepared for. Otherwise there'd be no point, would it? :laugh:

The program will obviously have to produce an output cr2, which will contain updated grouping and updated lists of morph channels. Now JoEtzold suggested to simply load all the morphs into the output cr2 so that there's no need to also rewrite the information from the input pz2 and produce an output pz2 from it. But that may not always be desirable. A cr2 can get pretty large when lots of morphs are loaded into it, which eventually will slow down the loading process and eat up precious main memory within Poser. So unless you always use all the morph packs you have at the same time, you might not want them all preloaded.

So if I just prepare the cr2 to take those morphs without necessarily preloading them all, since I don't expect morph makers to be totally disciplined and make sure their internal channel names never collide, I'd like to have a mechanism to avoid conflicts. Hence the provision for an additional output pz2 with modified channel names and with the grouping removed, so that they do nothing else than inject the morphs that my cr2 was prepared for.

I could use basically the same mechanism to support binary morphs if I found the pmd format documented somewhere or if someone like Dimension3D, who obviously understands that format, donated some code to extract the channel names from the pmd and, if necessary, change them to produce an output pmd file. Failing that, all I can do is look at the pz2 that injects the morphs from the pmd and use the information that's in there.

Finally, regarding Binary Morph Editor (brought up by nyguy): it's a fantastic program and I can't recommend it enough to anyone making or juggling with morphs. But honestly, I'd like something that I can distribute with Antonia for free and that's almost trivial to use.

So in the first iteration, the program would just take a single input cr2 and a single input pz2 and produce a new cr2 and, if necessary, a new pz2. Once this works and looks sufficiently robust, I'd add some code to work more smoothly with large or complex runtimes, and maybe the option to preload the morphs instead of just preparing blank channels for them.

All the fancy extra stuff like splitting or combining packages, adding or removing individual morphs or converting between binary and textual deltas can be done with other software for now and might be added later on when the basic system has proved itself.

Okay, hopefully I've covered everything that was unclear. Your turn again... :-D

-- I'm not mad at you, just Westphalian.