Hello, Backstory: For those who don't know. The sensitivity of a dial is determined by Tracking scale. However with morphs, changes in Poser last only for that session. Everytime you load a cr2, it will randomize the sensitivity(TrackingScale) for all TargetGeom dials. That sucks and it still exists in P6 with one exception..... the binary morph thing seems to have custom code that sets sensitivity consistantly to .02 Now you would think they would have fixed it. :( I tried a readScript to reset the trackingScale but it won't work. Anything short of Python, has anyone had any luck? Anton PS: Any P6 beta people, pleae try to get them to fix Poser so it doesn't randomize sensitivity on load.

Thanks for pointing it out. That has been a problem for me for far too long. If anyone reading this has the resources, please let the developers know about this one.

Yes it is very annoying, but I don't think it is random, as a particular morph always seems to get the same trackingScale. Perhaps it is some calculation based on the maximum displacement of a vertex, but I am just guessing.

I don't know what you mean by a "binary morph", but have noticed that targetGeom channels without any deltas get assigned a trackingScale of 0.02.

There are a couple of workrounds I can think of, but they are a lot of work if applied to all morphs, and not very elegant. One is just to slave the targetGeom channel to a valuParm channel, then hide the targetGeom channel. The morph will be set from the valueParm, and that can have any trackingScale you want. Of course this method can lead to crosstalk in P4.

Perhaps a better method is to use 'linkParms' to link the targetGeon to the valueParm, this method avoids crosstalk. The linkParms statement goes in the 'figure' section of the cr2, (traditionally under the 'displayOn' line, though I dont't think the position matters). As an example assume the channels 'targetGeom RoundFace' and 'valueParm RoundFaceX' exist in the 'head:2' actor, then the folloing code would be placed in the 'figure' section:

   linkParms    head:2<br></br>                  RoundFace<br></br>                   head:2<br></br>                      RoundFaceX

One might have hoped P6 would fix things like this, perhaps P7 ;)

I was afreaid taht there wasno solution without erc or python. I really don't want to do any erc at all. I am hoping they will fix it soon. Thanks so much for your thoughts on the matter.

Incidently, since "valueParm" channels can be renamed as "targetGeom" (so they will save with a pose), is the reverse also true? In either case it's a nasty choice; either dials that change to wild numbers with each session, or dials that don't save with a pose.

Nomuse, you can rename a targetGeom as valueParm, but then any deltas (morph data) in the channel wont work. Most types of channel can be used as a master channel in an ERC relationship. Normally valueParm channels live in the BODY actor (though they can go anywhere), and Poser just will not save pose data for the BODY actor, wether its a valueParm, targetgeom, or anything else (unless you rename the BODY actor).

Ok, perhaps some examples will help. See the attached files. You can copy the text and paste it into a text editor, then save it to a character folder with a cr2 file extension to test the file. First using linkParms to set a trackingScale. The trackingScale can be set to (almost) any value, incluting things like 0.00015, which is too fine to show on the dial but will still work. In this example the trackingScale has been set to 0.007. As mentioned in post #3, this file will NOT suffer from crosstalk! The actual morph channel 'targetGeom WideTop', has been hidden, but note that if the figure is resaved to a pallet it will show again in the saved version. To keep things simple I have knocked together a simple box figure with one morph 'WideTop'. Both the morph and the valueParm are in the square:1 actor. They are linked by a linkParms statement in the 'figure' section. The figure does not use ERC, at least not conventional ERC, though perhaps linkParms can be conciddered to be a type of ERC.

You can save a pose for the morph in post #7 if you use 'Include morph channels in pose data', because even though the targetGeom channel is being controled by a valueParm channel (Poser don't save pose data for valueParm), the targetGeom channel will have the same value as the valueParm. But what if the valueParm channel is in the BODY actor? Poser does not save pose data for the BODY actor! You can have your custom trackingScale and save a pose for a valueParm in the BODY actor, but this does involve the use of ERC. In the file attached to this post I have placed a valueParm (FBM) in the BODY, it controles the 'targetGeom WideTop' morph in the 'square:1' actor. I created a dummy actor and placed a translateY channel in it. I linked this channel to the valueParm in the body. Poser will save the value of the translateY channel to a pose, and the valueParm will take on the value of the translateY when the pose is applied (because of the linkParms statement). So here you have it, custom trackingScale and saving a pose for a valueParm in the BODY. Of course the pose is actually saving the state of the translateY channel, but the effect is the same. The trackingScale has been set to 0.001, it is not necessary to use 'Include morph channels...' when the pose is saved, as data is being saved for a translation channel.

Funny you mentioned it. Coincidently, I have used that to do other things I wanted to accomplish. I have found it useful, but decided not to use it create new dials just to fix tracking scale. You should know that that method has a calculation limitation that can result in crash if you use it to slave, a slave using the same method.