Here's the situation, I have a figure with multiple parts and I want the xrot of one part to drive the ztrans of another part in smooth stages with an initial delay in the slave channel.

In Poser using the valueOpKey this is working fine but the file does not respond in Daz Studio; using the valueOpDeltaAdd the operation works in both programs but there is no staging or delay just instant on of the slave with any movement of the master dial.

Presuming that  valueOpKey is not supported in DAZ Studio, can I code the .cr2 so that valueOpDeltaAdd in the slave channel begins the ztrans displacement after the movement of the master dial and continues progressively until the master reaches it's limit?

The part containing the master channel is the parent of the slave part. Though this places it immediately above the slave part in the hierarchy could the parenting be contributing to the difficulty? Would it be better if the slave part was not parented to the master part?

I created a morph of the ztrans , since the valueOpDeltaAdd works in both programs when applied to morph data, but was not satisfied with the linear movement compared to straight ztrans dialing of the part.

Thanks in advance for any assistance provided.

You're right that the new valueOpKey doesn't work in DS.

The order of parenting isn't the problem.  This was a problem, I think, in the
earliest P4 edition, but not any more.

The simplest way to get a delay in starting is to put the slave's initial
value (initValue) outside the range of its Max and Min, and set ForceLimits = 1.  

Then as the deltaAddDelta moves the initValue upward, the real thing won't
actually move until the calculated result gets inside the Max-Min range.

Note: this seems to work in some circumstances but not in others.  I haven't
parsed out exactly why!  You can see it working in these blinds:

http://www.renderosity.com/mod/forumpro/media/folder_9/file_431154.gif

No, I take it back.  I just remembered how the Venetian blinds really work,
and it's not that simple, but it still gives a method that you could use.
Each slat is parented to the bottom bar, and is slaved to the main Pull
dial in reverse.  The bottom bar is also slaved to the Pull dial, but forward.
So when you turn the Pull dial, the bottom bar moves up linearly and each
slat moves down with the same delta, until the slat hits its own Min
value.  After that, it simply moves along with the bottom bar.

In other words, you'd need an intermediate part that moves your real
slave's zTran upward by parenting; and then you'd have the slave responding to the
controller downward, so that its own zTran exactly counters the parented
movement until it bumps into its Min.  After that, the intermediate mover takes the
slave upward with it.  If you don't have a real intermediate that would serve
the purpose, you can introduce a "ghost part" without any geometry.

If this will help, here's some of the code.

The bottom bar's Y tran:

        translateY ytran
            {
            name ytran
            initValue 0
            hidden 1
            forceLimits 1
            min 0
            max 0.425
            trackingScale 0.002
            keys
                {
                static  0
                k  0  0
                }
            interpStyleLocked 0
            valueOpDeltaAdd
                Blinds
                BODY
                Pull
            deltaAddDelta 0.500000
            }

One slat's Y tran:

        translateY ytran
            {
            name Raise
            initValue 0
            hidden 0
            forceLimits 1
            min -0.154
            max 0
            trackingScale 0.001
            keys
                {
                static  0
                k  0  0
                }
            interpStyleLocked 0
            valueOpDeltaAdd
                Blinds
                BODY
                Pull
            deltaAddDelta -0.500000
            }

Try looking at this document

http://www.atlantis23.com/arc_download.html

it might give you some ideas

Thanks guys! I'll get back to you with my results after I give the suggestions a try.

@ ockham

Okay, well the coding example wouldn't work in this situation but the mention of a "ghost part " reminded me of lesbentley's code for the doors in another thread which with a little modification worked for what I'm doing. I will be exploring your example code for the blinds because it gives me an idea for something I want to try so not a wasted effort on your part.

Thanks again for your help, it's what pushed me over the hump I was stuck on.

@ markschum

Warn somebody before you post that link again! :lol: Full of good info but dang I felt like I was back in school already.

Seriously, thanks for the link the information is very helpful, it will just take me a little while to come to grips with it.

How does the Burns poem go?  Ghostie parts and gheestie parts and things that get over
the hump in the night.......... 

If you look about at that site theres a similar document on ERC.

I have just been invited out  to the pub, so this is going to be very a very short short post.

Attached is the text of an example. xRotating box_2 will start to affect box_1 after the xRot exceeds 45°. When rotating box_2 you probably won't see any movement of box_1 until you release teh dial. Everything relevant is in box_1. The zTran in box_1 is slaved to the xRot in box_2. It is also slaved to a valueParm channel "HoldBack" in box_1. You can adjust the angle at which box_2 will start to move box_1 by changing the value of the "HoldBack" dial.

I will try to say more later,but perhaps not tonight.

Thanks lesbentley, I'll look at what you attached even though your coding for the doors worked for my purposes admirably well.  I fiddled with the code a bit and got it to start when I wanted so the ztrans part bypasses the base part at the proper place.

Don't even consider posting here tonight over making a pub crawl, one must keep priorities in order.:biggrin:

Quote - If you look about at that site theres a similar document on ERC.

I downloaded that one too, I'm a glutton for punishment.:rolleyes:

You have probably worked out what is happening by now, but just for the record... Let's take a very simple example, two cubes side by side, cubeA and cubeB. We slave zTran in cubeA to zTran in cubeB, so that zTranslating cubeB also zTranslates cubeA. Here is the slaving code in the zTran channel of cubeA: translateZ ztran { name ztran initValue 0 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.001 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd
Figure 1
CubeB:1
ztran
deltaAddDelta 1.000000 }

Now, say that we don't want cubeA to start moving until cubeB has travelled forwards by 0.1 Poser Units. We need to hold cubeA back until cubeB has travelled the required distance. What we can do is to create a valueParm channel and set its "k" line value to -0.1, the distance we want to hold cubeA back (this could be any value). Next we slave zTran in cubeA to this valueParm channel, let's call the valueParm "HoldBack". Here is the code we put in cubeA: translateZ ztran { name ztran initValue 0 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.001 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd
Figure
CubeB
ztran
deltaAddDelta 1.000000 valueOpDeltaAdd
Figure 1
CubeA:1
HoldBack
deltaAddDelta 1.000000 } valueParm HoldBack { name HoldBack initValue 0 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.004 keys { static 0 k 0 -0.1 } interpStyleLocked 0 }

Now cubeA still moves in step with cubeB, but 0.1 Poser Units behind it. When cubeB has travelled 0.1 Poser Units, cubeA will have reached the desired start position. The next step is to limit the backwards travel of cubeA to zero, so that it can't go behind the start position. We edit the code in the zTran channel of cubeA like this: forceLimits 1 min 0 max 100000

This is essentially job done, but there are a couple of little tidying up bits left to do. When we use one of the Poser "Restore" functions, we want the valueParm channel to maintain its value, so we need to set the 'initValue' to the same number as the "k" line value. We probably don't want to see a dial for the valueParm channel so we set its 'hidden' attribute to a value of 1. Here is the finished code: translateZ ztran { name ztran initValue 0 hidden 0 forceLimits 1 min 0 max 100000 trackingScale 0.001 keys { static 0 k 0 0 } interpStyleLocked 0 valueOpDeltaAdd
Figure
CubeB
ztran
deltaAddDelta 1.000000 valueOpDeltaAdd
Figure
CubeA
HoldBack
deltaAddDelta 1.000000 } valueParm HoldBack { name HoldBack initValue -0.1 hidden 1 forceLimits 0 min -100000 max 100000 trackingScale 0.004 keys { static 0 k 0 -0.1 } interpStyleLocked 0 }

When, instead of slaving a translate channel to another translate channel, we slave it to a rotate channel, the principles are exactly the same, but because we are dealing in two different units, degrees rotation and distance, the 'deltaAddDelta' ratio in the slaving code of the zTran channel will need to be different. The exact difference will depend on how much you want cubeA to move in response to rotations of cubeB. As a rule of thumb when slaving a translate channel to a rotate channel you will need a much lower deltaAddDelta value, as a starting point try a deltaAddDelta of between 0.01 and 0.001. Conversely when slaving a rotate channel to a translate channel you are likely to need a much higher deltaAddDelta value, with a value of 1.0 it may seem like the slaving is not working. As a starting point try 10.0 or higher. The valueParm "HoldBack" does not need to go in the cubeA actor, for P6 or above, it can go in any actor. In P4, and I think P5, if the master channel is more than one step below (or sideways from) the slave channel in the hierarchy, the slave can experience refresh problems, where the slaving action will not update until some other action, such as selecting the actor or moving the camera, takes place.

Thanks lesbentley, This type of thing can be used for a myriad of different things too. Morphs and JCM's and auto dialed body handles, come to mind.  odf is doing something like that now for cascading JCM's.

If I ever get any of my figures done I'm putting you in the credits permenantly, I've picked up so many things from your threads, i am most gratefull oh venerable one.  

Yup, Ockham and Les are most helpful. This works like a dream too, I had a thread very simular about 2 months ago and the delay action works perfectly.

Quote -
You have probably worked out what is happening by now,...

Yes, I had worked it out prior to your post using your code from the thread darkedge mentioned but the extra info is still very useful and much appreciated.

I've just started messing about with the ERC function so have quite a bit to absorb making any examples valuable to me and I am sure to others that are interested in exploring the enhanced rigging options.

Thanks again to everyone that helped me on this problem.

Examples are good.
For a number of years I lived way out in the boonies, no power, no phone and no internet. I ran my comp off a generator. So I basically spent alot of time slogging around with poser on my own, very frustrating. But since I have had the internet the last couple of years, I have learned so much more. Thanks to a whole list of generous souls. Very good to see threads like this where people share their knowledge.