Happy New Year Everyone! I am poser expierenced but new to Michael. I just bought mike the other day , WOW thank you DAZ ! My question is when i put 2 "mikes" in a poze scene why does the 2nd mike clones what ever i do to figure 1 in the "body global" dial settings? like if i adjust the heavy setting for fig 1 /body, my fig 2 will duplicate the settings. and if i try to modify the body settings for fig 2 nothing happens at all.what causes this ? is it a glitch ?can i have 2 Mike models in a scene and be totaly independant in all ther settings ? Thank you for any help.

gosh I don't know, I am going to try it and see what happens. Sharen

It's called 'cross-talk' and it can be remedied by getting the 'millenium nul' character from freestuff and follow the directions.

That didn't happen to me, I made sure that I picked Figure 1, the first Mike and then picked figure 2 the second Mike clone and it was find. I picked Figure 1, body then started individual body parts. Sharen

Funny I just had the same problem the other day (see "Please Help: Can't use Vicky 2 and Michael 2 together" thread from yesterday) using Vicky 2 and Michael 2 together. The problem is that these figures share the same names for the full body morphs and Poser apparently can't keep track which figure you're modifying. The answer is to use the EMC Fixer null figure from Nerd (see the thread mentioned above for the link).

Why would it work for me Poser? Sharen Could it be the operating system we use - I am using XP and I have noticed I can do things in XP that I couldn't in ME

Pilothigh nailed it. The problem is known as crosstalk and is common with V2 and now M2 it would appear. Generally it occurs with the full body morph settings. The fix it to use the millinuem null character. Sharen, I am not familiar with the method you are suggesting. Will this work if you select the body of figure 1 and change the body morph dials - such as the heavy, thin, etc., that are designed to manipulate cross part morph settings? I've tried to do this the way you explained (I think), but I still ran into the cross talk problem. Maybe I am missing something?

http://www.rbtwhiz.com/rbtwhiz_EMCPrintable.html#update null loader: http://www.rbtwhiz.com/downloadables/MillenniumNull.zip http://daz3d.com/pages/faq/answers/victoria/crosstalk.html hope this helps. Mazak

I am going to try it with different dials set like you said. Sharen

Many Many thanks everyone ! May all your renders be grand.

Sharen, For example: Load Vicky first then Michael, select Vicky's "body" and set "Young" to 1. Now select any bodypart of Michael, and he is "Young" also. Mazak

Hi Sharen. I may be wrong, and if so I hope to learn something but I have to ask. Are you selecting a body part and tweaking the dials? Or are you selecting the body and tweaking one of the (full) body dials. Cross-talk occurs between figures that share the same name full body morphs. For example if you load a M2 figure and a V2 figure, both having a full body morph named "Heavy" for example. Any changes made to the first figure loaded in the scene (full body-morph-wise) will happen to the second figure as well. Er, atleast that has been the way it has worked up unto this point - maybe there is something about XP? Try loading two V2 figures and then change one of the full body morph dials (ie: figure 1:body:Heavy) Once you have applied the full body morph to the first figure, select the second figure(2) and try changing any dial on it (body or body part) Under ME and Win2k and W98 you will get cross-talk and the second figure will adopt the body morph applied to the first. If this does not happen under Xp than that will be good to know. :o)

Okay, let me try, I was selecting individual parts. Be back in a second. Sharen

Now I will try the same dials for both figures set them at different percents. Be back Sharen

I really think now it looks like it is an XP thing. What do you all think. Sharen

:o) Looks like an XP thing to me. Maybe there is hope for the OS afterall. How are you liking it Sharen (XP -that is)? I heard there were some issues with it. Like being a resourse hog for one. How well does Poser run in XP?

It is a large file XP, but that is because of all the HELP videos, once they are gone it is about the size of 98, I love it, and if it wasn't for LaurieA, and her brave soul to test some software, I don't know, but I am glad I switched, like I said more stuff works for me correctly in Poser in XP then any other OS. I LOVE IT, if anyone runs into problems, XP seems to correct all of it. And I am using Poser 4.03, that is it, I have Pro, but don't seem to need it now. Sharen

Thanks :o)

Hi Sharen, have nearly the same experience as you.No probs with 2 viccy 2 in the same scene. Im on xp too.

I have XP Pro, 512MB RAM, P4, the latest Poser patch and I had the crosstalk problem (see my earlier thread "Please Help: Can't use Vicky 2 & Mike 2 together..." However, as I mentioned, it seemed to me the problem kicked in sometime after I had started working on a scene containing the 2 figures, although I simply may not have noticed the effect at first. Anyway, the null figure workaround worked.

Nonsense people! It is cross-talk. The morph dials in Body in the controlling figure (the one Poser "thinks" is Figure 1 (Mike in this case) is controlling both figures - IF the second figure (V2) HAS ERC morphs with the same name. V2 and Mike both have Young. V2 does not have Muscular2.

If a morph/channel is remotely controlled (to make a morph/channel remotely controlled) it will have the following five lines after interpStyleLocked 0:

valueOpDeltaAdd
Figure 1
BODY:1
waist-low
deltaAddDelta 1.000000

and before: indexes 39

valueOpDeltaAdd says that this is ERC

Figure 1 This is the controlling figure - a variable

BODY:1 This is the actor in the above figure where the controlling dial is - a variable

waist-low This is the name of the controlling dial - if it is not precise, it will not work.

deltaAddDelta 1.000000 This is the rate - in this case one unit of the master changes the slave by one unit - a variable

For those who are too literal, the script eas cut from a clothing morph "waist-low" is just what that morph was called. indexes 39 - the 39 is specific to that morph, this number is specific to every morph 39 is pretty small, 9,000 is a big one (probably a Millineium head morph). But it cannot be larger than numbDeltas ### Which is the size of the group (fixed for any one group).

Jaager has right! The fullbody morphs: Young, Tone, Emaciated, Heavy are crosstalking. The OS is not important. Mazak

I tried this as well. (XP, PPP, 768Mb) Loaded Vicki2, translated on X Loaded Mike2, translated negative X Selected V2 body, set heavy to 1 Everything looked OK .... but, clicked on M2 and that body part became heavy. So yup crosstalk is still an issue under XP, and null loaders still needed. - Mark

Ok I just got windows XP for Xmas, and tried this, I loaded Mike 2 first, then Vicky 2, I set Mikes body to Heavy, and nothing happened to Vicky, until I moved Mike back then her body cloned Mikes and they were both heavy! So they looked okay until I moved them :(

It looks to me like Poser is only redrawing the one character that you're changing, but as soon as you select or do something with the other character, it suddenly realises that it has changed and needs to be redrawn as well. Confusing! - Mark

What happens if you change the full body morph names. And re-save the figures to the library? Will that prevent cross-talking? ScottA

Ok I went to Nerds site and got the EMC fixer, and its easy to use and fixes the cross talk :)

Scott, that will work and for V2 - M2 cross-talk stop it. But it does not help with V2-V2 or M2-M2 cross-talk. Even my method of TE of the controlling figure in the ERC script, requires that each one be a separate CR2 coming out of the Library. An if it is saved as a PZ3, this file must be edited before reopening. Poser bungs up the figure slots when it saves a PZ3, just as it does when it saves a CR2. Now, if only Poser 5 will let us lock these names.....

OK...Thanks Jaager, I don't own any of the Millenium figures. So I kinda feel left out when it comes to having trouble with them. ScottA

Okay, I tried this again, only this time, I first created Mike2, he is figure 1 and moved him over and back, then I created Vicky2, moved her to Mike2 left side, did the morphs and worked on it alot, for about an hour, tried to use only body morphing on each, first all the same dials, then different dials, nothing happened, so I don't know why and still have not seen this cross talking, I do not say it isn't there, it is just I can't see it. Sharen

Cross-talk is a factor when identically internally named channels exist for identically named groups. Poser reads as case sensitive. If you are a single character [text character] off, they are not the same to poser and it reads it as such; the channels/groups will in turn have no direct relation to one another... Which is why some morphs on Victoria will still work when loaded after Michael without a null, and vice versa.

As I've stated in a number of previous posts, the EMC Fixer that Charles built was not intended for the Millennium figures. It will not completely rectify cross-talk in Mike or Victoria (or any other figure that uses an equal naming convention) because it does not include the buttock groups in the list of actors. As such, there is no place holder for the initial instance of said groups and as a result Poser doesn't reassign control to the intended figure... which is one of the reasons I built the null (reference #10).

-Rob
rbtwhiz.com

I've used your NULL LOADER before (and thank you SO MUCH for providing it), but I can't remember if Poser boogers it up or not anyway once the PZ3 is saved. Does it? If so, it's a bloody crime as it renders the NL useless IMHO. Here's to hoping I'm wrong! -Tim

Tim,

Saved scenes [pz3] revert control back to the initial instance of a group/channel. This is something that is inherent in Poser, not ERC per say. The scenes must be manually edited to load as one would have hoped by saving. See, the scope that has evolved into what is now encompassed by ERC was not the intention of the powers that be, when they built version 4. They were just as surprised as the community was with EMC, the precursor to ERC (if not more, because they understood the theory behind it before anyone else knew what the heck we [Charles and I] were babbling about). They had no way of preventing something they didn't know would happen... users aren't supposed to disect the code and make the product better :). But take that last comment with a grain of salt, because full body morphs (FBM) and conforming figures were implemented, and this "problem" existed there, well before EMC or ERC.
ERC, being the re-utilization of code for FBM's, falls victim to the very same problems, because it [ERC] is a product of it [FBM]. The null, based on Mr. Taylor's findings, was built as a way to make something work... that should have already, but wasn't intended to. We can only work with what Poser will allow us to... Fingers crossed, this will be fixed in version 5 [I'm in no way insinuating that it will be, I'm just saying I hope it is].
As for it being rendered useless... I wouldn't say, that. You can still load multiple figures, independent of each other, and save poses to your library to rebuild a scene. And though it isn't the "be all / end all" solution, it's a step closer in the right direction...

-Rob
rbtwhiz.com

Question. What about loading the Null first into an empty scene then importing the pz3 instead of opening it as a new scene?

Shadow: Way to think outside the box! However, I don't think that will work. Just based on my understanding of how the NL works. Rob? Rob: Thanks for the brief (but dense) lesson. It seems to me they (CL) are well aware of the headache this is causing many a user, and will surely fix it in Poser 5. You're right, using NL, exporting poses, etc. IS a step in the right direction, but dang-nabbit if it isn't frustrating. It just seems so silly, especially to those just looking at the problem on the surface. Thanks again! _Tim

From tests I've run up to this point, no.

To duplicate the test, save a scene with 1 Michael[2] and 1 Victoria[2]... one with the null included, one without. Start a new session (to clear memory of instances within Poser). Import the saved scene that included the null... set values on Figure 1/Body/Tone, Heavy, Emaciated (channels that are named identically in both figures). You'll notice the second figure mimics the first and independent control is lost for identically named channels in the second figure. Now, start another new session (you must clear the instance count). Load the null from your library. Using the same steps you would in order to normally use the null (select Body, "No Actor" will be displayed), import the saved scene that the null was deleted from prior to saving. Do the same check as above with the like named channels. You'll notice the same affect.

The difference from the "normal" use of the null, is that in the mentioned scenarios the null is not being selected prior to the loading of each figure. Further tests also change my previous assessment of the extent that manual editing of a saved pz3 would rectify the situation (at least without the use of fixed names, which BTW dates as far back as the first day or so of the initial announcement of EMC [June 2000]). Inspecting the pz3 code for the conflicting ERC channels in the above scenarios would show that the proper links (figure exclusive) are established within. Additionally, inspecting the same code in saved scenes that didn't use the null, showed the ERC channels in any other figure than the initial to point at the initial (Figure 2/instancs of :2 point at Figure 1/instances of :1).

One would hope it does get fixed in 5... being that much of the testing, with a number of different scenarios, to pinpoint the problem has already been done. Admittedly, it is quite frustrating. Even more so... trying to find the solution with what we are currently limited to. ;)

-Rob
rbtwhiz.com

Thanks Rob (and Tim). Yes, I hope there is a fix for this in Poser 5. Though, it wouldn't surprise me any if you came up with it first. (Being that you and Nerd more or less inflicted this upon us. LOL!) Where would we be now without EMC/ERC - so no complaints here. Besides, all invention is not without its growing pains. Keep up the good work!