I have been working with ERC code for some time, but I am having problems with code in my latest product. I can not get the FBMs working correctly no matter what. I will be glad to share the L3 version of the product shown who wants to examine my .cr2s and tell me specifically what I am doing wrong. I have this code for example and I am testing it in Poser 5 and it isn't working targetGeom Muscular1 { name Muscular1 initValue 0 hidden 0 forceLimits 4 min -100000 max 100000 trackingScale 0.026389 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd Figure 1 BODY:1 Muscular1 deltaAddDelta 1.000000 Now if I replace it with this code it should not work right? I mean the index being 15 will mess it all up. targetGeom Muscular1 { name Muscular1 initValue 0 hidden 0 forceLimits 4 min -100000 max 100000 trackingScale 0.026389 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd Figure 15 BODY:15 Muscular1 deltaAddDelta 1.000000 But this works and the correct code isn't!!! I am pulling my hair out here. Like I said, I will be glad to share the Laura 3 version of this product to anyone who can really help. I know the basics of ERC code in relation to FBMs, but I am in need of specific knowledge Here is another question? Is this proper syntax? valueOpDeltaAdd Figure 1 BODY:1 Muscular1 deltaAddDelta 1.000000 Or is this proper syntax? This has the PBM prefix. valueOpDeltaAdd Figure 1 BODY:1 PBMMuscular1 deltaAddDelta 1.000000 I am wondering about the usage of the internal name and the name poser displays to the user. They are two different names. I would suspect that the ERC code would be using the internal name and the second example would be the proper one, but from what I have read, it is not. Why are there two names, an internal and a regular name and how does it apply to this particular usage of ERC? Also, another question, has anyone ever seen this syntax with usage of conformingTarget? valueOpDeltaAdd conformingTarget BODY:1 Muscular1 deltaAddDelta 1.000000 I wish to know more about this and what are the drawbacks and/or advantages. thank you marty

PBM stands for "Partial Body Morph". I think DAZ and others use this as a "dial name" to indicate that the morph is slaved to a FBM channel in the BODY actor. the channel name in your code should be the internal name of the master channel;

                   valueOpDeltaAdd
                                Figure #
                                BodyPartName:#
                                
                        deltaAddDelta 1.000000

The above would corispond to a master channel named "[valueParm] MasterChannelName", where "valueParm" is the channel type and "MasterChannelName" is the channel name. In short, you should not use PBM[ChannelName] unless the master channel is actually called "PBMChannelName", which it probably isn't. I am guessing that you have multiple figures in your document, and I suspect that your problem is one of crosstalk. To test this hypothesis, load the figure with the ERC on its own without any other figures in the document and see if the ERC works then. If this works, then we know that the problem is crosstalk. To find the best solution it would be necessary to have more details than you have provided so far. What exactly are you trying to achive here? Is the code native to the cr2, or is it being injected? Is you figure a conforming figure? If so what figure is it intended to conform to? Do you need to have more than one instance of the figure in a document? Is it necessary for any reason that the name of the master channel be "Muscular1", and if so is a channel named "Muscular1" likly to exist in any other figures in the same document? "Now if I replace it with this code it should not work right?" Figure 15 BODY:15 No, actually it is more likly to work, as the root of the problem (if my assumptions are correct) is Poser's failure to update the actor number in the slaving code correctly. In other words if the figure with the ERC that is not working is the second figure loaded, then the problem may be that this figure is using an actor number of ":2", but the slaving code is still using an actor number of ":1", and thus pointing to a master channel in the first figure loaded, rather than to its own master channel.

Les, I would be happy to give you a link to the clothing package. This is the first in a series of products that I will be putting out with a team of three members. We are making this outfit fit five characters in seperate packages. The first package to be completed is for Laura 3. So Laura 3 is the character I am conforming to with my clothing. The FBMs are being injected just as DAZ has set her up. The clothing I have built for her have only Muscular1, Tone, and HipNarrow morphs installed into her clothing. There are four pieces of clothing, a top, skirt, panty, and boots. Muscular1, Tone, and HipNarrow are three standard FBMs that are purchased in a morph package by DAZ, then installed. The morphs are injected exactly the same way we do V3. Each artical of clothing has morphs that share the same name as the figure. I tried to set up the code so it would follow the value of the valueParm in the Laura 3 figure (which is loaded first). Yes, I have tested this all here now and I have tested this in P5 and got it working, but I am still getting feedback from testers that this or that clothing is not doing what its suposed to. I am loading Laura3 first and conforming clothing to her, then loading the clothing one at a time and it automatically conforms and reshapes just like it should here at home. Then I am getting reports that the morphs in two of the clothing figures are working and two are not. I then examine the code again and see no difference. I am trying to make my clothing conform automatically to the first figure loaded up. by the way, here is the code that I am using now recomended by Grimjerk, who is on my team. This is the only code that seems to be working so far. I never heard of the usage of conformingTarget, but this is working at home. I think the main reason that its working is because the :2 instead of the :1. targetGeom Muscular1 { name Muscular1 initValue 0 hidden 0 forceLimits 4 min -100000 max 100000 trackingScale 0.0052736 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd conformingTarget BODY:2 Muscular1 deltaAddDelta 1.000000 indexes 2009 numbDeltas 2009 deltas

oh, yes, the FBM morphs work perfect when tested here in P5 at home, when the figures are loaded alone. They work off the valueParm in the figure its self, like it is suposed to. What is crosstalk, I mean I have heard it talked about sinse I started modeling poser stuff. But not being a big time user, I have been lucky to stay pretty much clear of its effects, so excuse me for being dumb. What is crosstalk?

""Now if I replace it with this code it should not work right?"

Figure 15
BODY:15

No, actually it is more likly to work, as the root of the problem (if my assumptions are correct) is Poser's failure to update the actor number in the slaving code correctly. In other words if the figure with the ERC that is not working is the second figure loaded, then the problem may be that this figure is using an actor number of ":2", but the slaving code is still using an actor number of ":1", and thus pointing to a master channel in the first figure loaded, rather than to its own master channel. "

---

I thought this is exactly what I should be trying to do. I was trying to make the first figure the master at all times.

It sounds like the main figure is not selected before creating the clothing item (with the Figure 1 and Body:1 version). This will cause the clothing item to follow the morphs in whatever figure was selected when you created the clothes... instead of Figure 1.

For clothing items to work properly in Daz Studio you need the PBM in front of the dials that correspond with the figure morphs.

targetGeom PBMMuscular1
{
.
.
.
valueOpDeltaAdd
Figure 1
BODY:1
PBMMuscular1

Mada

DAZ have a couple of morph name variations in common use across their products. Typically, the channel name (what comes after valueParm in the BODY or targetGeom in the other actors will commence with PBM. In this example PBMMuscular1 for Laura 3. This is the name which must be referred to in the ERC on the slave channels. actor BODY:1 <- ERC Master actor & Figure number ( ... channels { ... valueParm PBMMuscular1 <- channel name (Master) { name Muscular1 <- dial name (Master) ... } } } ... actor rCollar:2 <- ERC slave actor (different figure) { ... conformingTarget rCollar:1 <- slaves rotation channels to specified actor without need for explicit ERC ... channels { ... targetGeom PBMMuscular1 <- ERC slave channel (can have any name) { name Muscular1 <- ERC slave dial name (what you see) ... valueOpDeltaAdd Figure 1 <- number should match ERC Master Figure BODY:1 <- ERC Master actor (must have correct figure number after colon) PBMMuscular1 <- ERC Master channel name (not dial name) deltaAddDelta 1.000000 ... DAZ value parameter and morph dial names (as opposed to channel names which pretty much invariable begin with PBM) seem to have the following standards. Value Parameters on the BODY actor will just be the morph name. On other actors, if the morph target has not been injected and the dial is still visible, the dial name will have a PBM prefix identical to the channel name e.g. PBMMuscular1. Morph targets which have been injected (vertex deltas are present) and are secondary ERC master channels, such as the breast morphs on the chest actor, will have a dial name identical to the BODY value parameter dial name, i.e. no prefix e.g. Muscular1. Morph targets which are ERC slave channels usually have a lower case p prefix dial name e.g. pMuscular1, indicating that there is a secondary master channel on some other body part actor. I should note that conformingTarget is NOT a normal part of the valueOpDeltaAdd ... deltaAddDelta ERC code. It normally appears before the channel { } section of an actor. It is used to slave the rotation channels of an actor the those of the corresponding actor the slave actor's figure is conformed to without the need for explicit ERC in the rotation channels. Character figure CR2 files would normally specify the figure number of all actors as 1, so ERC is obviously bound to the figure being added to the scene. Poser has a reasonably easy job to do renumbering the figure and ERC code, though earlier versions sometimes failed in this regard, causing the crosstalk problem where multiple figures of the same type ended up slaved to the first one added. This feature was usefully exploited by clothing creators to allow "super conforming" clothing which not only has its rotations slaved to the figure it was conformed to, but also its morph channels. Later versions of Poser have altered the exploited ERC renumbering failure to limit crosstalk problems. Super-conforming is still possible, but instead of the clothing figures ERC links being self-referential and relying on poser to cross-talk them, they need to already refer to a different figure number in ERC links. Typical scenarios would be to use Figure 2 (or higher for multi-figure clothing sets with each a unique number) for the clothing and have the ERC links point to Figure 1, on the assumption that the conformingTarget figure will have been loaded first. As stated above, the latest Poser versions will renumber new figure ERC links to point to whichever figure is currently selected. If you need multiple, identically clothed figures, it can be useful to create the first clothed figure and then save the group back to the library. Subsequent loading of the grouped and conformed character and clothing figures will maintain the ERC links they were saved with, but avoid crosstalk with the previously loaded group.

By "latest Poser versions" do you mean Poser6? I was under the strong impression that Poser5 would not "point out" of the figure no matter what the loading order (forcing the invention of ERC Injection Scripts). If a conforming clothing item only points to itself, then JCM won't work; the dials of a conforming figure continue to read "zero" as the master figure is posed, and thus are incapable of feeding joint information to the morphs. So does Poser5 actually allow this beneficial crosstalk if a strict loading order and selection proceedure is followed? Does Poser6?