Let us avoid confusion. "Crosstalk" is any communication -- desired or undesired -- between figures in a Poser scene. The above discussion, however, was entirely on the behavior of ERC channels; a very specific set of code originally developed for full-body morphs. ReadScript and Python-aided methods had not been previously discussed in this thread (nor was the "built-in" slaving code that Poser uses for the "grasp" channel in hands). In original P4, one "good" crosstalk is that a conforming clothing item could "see" the master FBM dials in the figure, and thus take on the same morphs. Unfortunately, this same communication meant if you loaded two figures with FBM, both would take on the same morphs. I am told P5 does not replicate the latter behavior. I am told, however, that P5 does replicate the former behavior. This sounds very suspicious to me. Also, I have ERC-controlled rotations in one of my products, and gallery evidence that these rotations are not being used by at least one P5 user. I will have to commit to more tests but I am willing to believe that in the ordinary circumstance P5 slave channels NEVER point "out" of the figure they are contained in. Hence, the development of ERC injection poses by Jim Burton and others; these do not edit the "broken" ERC channels, but they add to the scene a new channel with a user-desired relationship. In reference to "breaking" a P4 ERC relationship, it is as simple as this. Load two figures containing a master dial -- say, FBM "Superhero." To the second figure, conform a clothing item containing ERC slave channels. It will follow the morph in that second figure. Save the pz3. Close. Re-load. When the scene is reloaded, the ERC in the clothing will still point at the second figure. Well and good. Delete the second figure. Save, close, reload again. Regardless of whether you conform or not, the clothing's slave dials will now point at the first figure (since there is no longer a "figure 2, BODY:2" Poser will hunt until it finds a matching "Superhero" dial in "figure 1, BODY:1" I admit, this particular scenario is not itself a problem. But it shows the basic problem -- load order is paramount. If your scene has been edited in any way, you can never quit Poser without causing unexpected behavior the next time you open the scene. By the by, to reach the above pronouncement took two weeks, loading somewhere close to a hundred scene. My method was to document every number and relationship in a scene, load it, document what behavior was in the scene, save, inspect the pz3 in a text editor to see what numbers had changed, restart Poser and load the scene again, rinse and repeat. As part of that experimentation I tried null figures, I tried conforming or not conforming, selecting before loading and not selecting before loading, inserting null or special characters in place of "figure N" or "BODY:N", even deleting some of these lines completely. You must take this kind of care; Poser is just random enough that it is entirely possible to "discover" that the file works perfectly if one only adds "I am a wombat" at the top of the pz3. It takes a great many tests to determine that your result was merely co-incidental, and Poser works just as well (or badly) without that phrase. I do not mean to dump on any discovery. As a clothes maker and prop rigger I would love to have control over the ERC relationships in a scene. I am all for any experimentation that leads to that result. I am just suspicious of easy results, having gone down this path far too many times before.