Has anybody conclusively determined whether it's possible to do the master-slave ERC thing in a file that doesn't have a figure? I tried several variations in a simple PP2, and couldn't make it happen, but admittedly wasn't trying very hard. Searching through this forum and other websites (like Whisenant's discussions) leads to no really solid answer; the consensus seems to be "might work, probably won't, further research needed".

The second line in the ERC code is for the controlling figure. I am guessing that it has to BE a figure if you cannot get it to work on a prop. Poser 4 will change the figure on file open anyway and I was not able to get at it using a JNT pose - one of the few things that seems to be resistant to pose file adjustments. You need a controlling figure and a controlling group- A prop is a group, so there is a bit of ambiguity - computers tend not to like ambiguity.

Okay, thanks. It makes sense to think that each line after valueOpDeltaAdd must be filled by a specific thing. (If I had written the program, I would have done it that way!) Since there doesn't seem to be any way to indicate "Default Figure" or "No Figure" on that line, I'll just have to convert my props to CR2.

I bet your path is the required one. It does not matter what you put in the first line after valueOpDeltaAdd. If the file is the first one in, the master gets to be: Figure 1 no matter what the cr2 has it as. I am not sure what 'appens with subsequent files. The way the null is loaded - as a spacer before each figure, it seems to occupy the master that Poser inserts and lets the real figure control itself. This is possibly a Poser 4 issue only - the inability to set the controlling figure, I mean.

Ockham, I think it can be done. This is part of a channel I made for a clock valueOpDeltaAdd NO_FIG hour hand_1 vpHour deltaAddDelta -30.000000 The line '_NO_FIG' is what goes in if you have a prop, not a figure. This info was sent to me by VK, but in the end I made the clock a figure instead, so I didn't try it. But he assures me it works. If you need more info I can send you his entire e-mail on the subject. (I'm sure he won't mind) mac

I've done it and so have some other people. The key is the hierarchy. The controlling prop must be a parent (or ancestor at any rate) or the controlled prop. You can set that up in the hierarchy editor and it will be preserved when you save the prop as long as you save all of the props concerned to the same pp2. The syntax I use is: valueOpDeltaAdd hour hand_1 hour hand_1 vpHour deltaAddDelta -30.000000 (Adapting Mac's example) I don't know if the contents of the figure line really matter, but this syntax definitely works.

Ajax, I tried it your way, and it worked instantly and easily! And what's more, I didn't even add the corresponding lines into the "Master" actor. (Which leads to a bigger question: are they really necessary?) Specifics: I'm trying to control both front wheels from the steering column on a car model in PP2 form. I already had each wheel-tire combination rigged up so that the xRot parameter would make the proper steering movement for that axle. Following your example, I put into the xRot section for each Front Wheel the following lines: valueOpDeltaAdd SteeringColumn SteeringColumn MainSteer deltaAddDelta 1.0 This did the job perfectly! Added nothing to the SteeringColumn section in the PP2. (MainSteer is a substitute name for the yRot parm in the column, and the column is parent of the steering wheel in a conventional non-ERC way.)

Just for clarification, the steering column is NOT a parent of either front wheel; in fact, the column is one layer below the wheels, but only a rather indirect "cousin". So it's not necessary for the ERC master to be a parent or even above the slave in the hierarchy. It seems, then, that the only thing we really need is the five lines starting with valueOpDeltaAdd in each slave parameter!

Hmmm...that's odd. I can reliably make a body part or prop control another that's one level above itself if both are part of the same IK chain, but I can't get higher up than that and the IK has to be there. I use Poser 4. Are you by any chance using Pro Pack? The inability to control things at a higher level in the hierarchy seems to be a refresh problem of some sort. The effect of changing the master dial only seems to be noticed at certain times, like when you switch to a different camera or use undo. I almost never work with any type of master other than a valueParm though, so it could be that ERC works more reliably with rotation dials or something.

Yes, I am using ProPack. The model has no IK chains at all. So maybe I should revise the hierarchy to be sure it will work in non-PP Poser...?

Well, you can't put IK in props, only figures, so I figured you wouldn't have any IK. I'd say get somebody with plain old P4 to test it and see what happens before you put work into changing what you have now.

Yeah, I guess I can re-install original Poser on my spare computer and try it that way. Thanks again for the very distinct and clear explanations.

No worries :-)

Ockham, Glad you got it worked out. Though, I was just wondering if your pp2 wouldn't be more flexible as a figure anyway. That would solve any IK problems. Just switch Bend off for every part. My clock worked well as a figure, but the only moving parts were the 3 hands, hour, minute and second, all slaved to move in sync. On the other hand, with a figure, you might be plagued by crosstalk. Hmmm.....does crosstalk affect props? I never even thought about it before. I suppose it must do. Then again, with Poser, who knows? LOL mac

I tried the PP2 in a raw Poser 4.00 installation. As Ajax said, the ERC didn't work there. The figure built properly, but controlling the master didn't control anything else. I'll now try moving the slave parts down in the hierarchy.

If not, try the '_NO_FIG' placeholder. valueOpDeltaAdd _NO_FIG SteeringColumn_1 vpMainSteer deltaAddDelta 1.000 That should work (assuming Mainsteer is the slave channel) mac

I am glad I was wrong. I had not seen _NO_FIG before. What does Poser do to _NO_FIG when you save the file? What does it do if you open two copies of the file and save the second one? cross-talk happens when the three middle lines on a second copy match those on the first, the second line being the problem element.

I can't answer, Jaager, because I didn't use the '_NO_FIG' line. I ended up making a cr2 figure instead, so I don't know if crosstalk affects props or not. but VK, who mailed me back and forth when I was doing this, said that props were no problem, although he didn't mention crosstalk. I was making a posable clock with a face, hour hand and minute hand. This was the code for the clock prop. : - valueParm channels below, to be inserted nto 'channels' of the 2 hands: - valueParm vpHour { name hours initValue 0 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.01 keys { static 0 k 0 0 } interpStyleLocked 0 } valueParm vpMinutes { name minutes initValue 0 hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 0.01 keys { static 0 k 0 0 } interpStyleLocked 0 } : - Then in the zrot dial of the 2 hands : - valueOpDeltaAdd NO_FIG hour hand_1 vpHour deltaAddDelta -30.000000 valueOpDeltaAdd NO_FIG minute hand_1 vpMinutes deltaAddDelta -6.000000 These 5 lines of code go into 'hour hand' and 'minute hand' after 'interpStyleLocked 0' and before the closing '}' As I said 'NO_FIG' is the placeholder when you're making a prop, not a figure. I have so little time, I never get to try any of this stuff. If anyone does it, I'd be glad to hear about it. mac

ERC code works very well with props (pp2 libraries). In the valueOpDeltaAdd command, there is a _NO_FIG_ flag instead of 'Figure 1'. Because of this, the ERC code in a pp2 is 'Cross-Talk' free. When you save a prop library with ERC code, Poser will include the _NO_FIG_ flag, and overwrite your own parameter. Since there's no hierarchy in a prop, all channels can be ERC slaves of any other channel, as long as slave and master are channels of the same prop. When you parent a prop with ERC code to a figure, then the prop's ERC channels can 'cross-talk'. ERC code in props is particularly useful to create a well defined series of several MTs. Some of my models use this technique for instance to increase the resolution of morphs. Unfortunately, the models are not available right now (because of the database thingie at 3dC free stuff). But I'm writing a tutorial on ERC, and part 7 ('Segmented Morph Targets for Props') explains how to use ERC code for props, like the poseable mug prop. The tutorial will be available soon, I hope.

Thanks for contributing... Do you know if Poser 4.0 is "broken" in this respect? I've tried a number of variations, including the NO_FIG flag, placing the master first in the PP2 file, insuring that the slaves are below the master in the hierarchy. Every variation works just fine in Poser 4.03 with ProPack, but nothing works at all in plain 4.00 before all updates. Any ideas?

VK Thanks for stepping in. Since what I was saying was what you taught me, I'm sure you explain it a lot better. Glad to hear the tutorial is almost ready. I was wondering how it was going. mac

ockham,

I don't know if this is a problem of Poser 4.0. As far as I remember, I've used ERC in props running Poser 4.0 and Poser 4.0.3 (for Mac OS). Are you on a PC?

BTW, the hierarchy (sort order) of master and slave channels shouldn't matter in pp2 libraries. And the NO_FIG keyword isn't required. When I first tried ERC code in a prop, I've chosen the prop name. When I saved the library, Poser replaced the prop name by NO_FIG. That's how I found the keyword.

Mac,

I'm finishing chapter 10 of the tutorial ('Variable Slave Deformer Range'). I think this is the last chapter. Do you like to beta test the tutorial?

OK, thanks. If it looks like there should be a way to make the method work universally, I'll keep trying. The internals of the two .EXE versions look pretty much identical; the format statements for reading lines in PP2 seem to include the same stuff (deltaAddDelta and so forth) in the same order in both versions.

ERC doesn't work properly in Poser 4.0 (not in the PC version anyway). That was one of the things they fixed with the 4.03 patch. I always put Poser 4.03 as a requirement for any ERC using Poser items.

Hi VK, If you mean beta-test it for English, sure. But on the technical side, I doubt if I could do it. I'd love to see it. mac

ERC doesn't work properly in Poser 4.0 (not in the PC version anyway). That was one of the things they fixed with the 4.03 patch. I always put Poser 4.03 as a requirement for any ERC using Poser items. << Well, that settles it completely, and verifies my suspicions. I'll just put on the same requirement when I release anything using ERC! Now that P5 is out, the earlier versions should begin to fade anyway.

No problem, ockham. And thanks to VK for some stuff I didn't know about. I'll have to check out that NO_FIG thing more closely some time.