I'm pretty sure this problem hasn't been happening in the past.  In fact, I know it's new, because with my geometry-generating scripts I'd have run into the problem in the past if it had existed.

Here's the trouble.  I pose a figure.  Then I use a script to generate a geometry derived from the shape and position of the posed figure.  The geometry needs to be parented to the figure, so I do that.   Then it happens, the problem.  Wham-bango!  As soon as the prop is parented, it jumps to a new location, having been translated, scaled, and/or rotated, depending on how the parent figure has been posed.  The prop was zeroed upon parenting, being freshly created.  (The same happens when a new prop is generated using the Grouping tool and then parented to the posed figure.)

This seems to be new, as I said.  I've recently loaded SR3, so I am prepared to blame SR2 (which I skipped) or SR3, as I performed the same procedure I described above a week or so ago while setting up a scene using SR1.  Something seems to have changed while I was away from Poser, possibly as a tweak intended to enhance animatable origins and/or constraints.  But, as often seems to be the case when new things are added, there's no way to turn it off and restore the old handling and the new handling isn't explained anywhere.

Please, can anyone explain this and help me get back to properly parenting objects in Poser?  It used to be simple.  Now it is either complicated or broken.  I hesitate to file a bug report because they want the unmodified pz3, but I don't wanna send it to them.  :lol:

Yes, its happened to me, I made a post about it as well, now I try and parent everything first before making any posing, etc...

Its almost like the "inherit bends" just kicks in by itself, even if unchecked or something.

Well, that's no good.  :crying:  I can't see how I could use your workaround, since I need to have the figure posed before I can even create the prop to be parented.  Hmm.  It is a puzzler and a frustration.  Now I remember why Poser makes me throw things.  :lol:

I certainly hope this will be fixed in SR4.  You don't break something fundamental like parenting to a figure in a bugfix update, then force users to pay for the upgrade to get the fix for the new bug.  I mean, unless we're talking about Poser 8.  :lol:  :unsure:  Umm, yeah.  Worried about that.

Ah, Poser.  Always an adventure.  Being a Poser user means being a constant beta tester.  Sigh.

Hmm.  The behavior is avoided if actor.SetParent() is used in Poser Python... until the new parent actor is moved.  Then the reparented prop jumps.

I suspect this is related to the new "realign" feature.  Check out the options for SetParent:

Quote - SetParent
Explanation
Set the specified actor as the parent of the current actor. If inheritBends is 1, this actor will acquire the bend
parameters of the parent. If Realign is 1, this actor will be realigned to the local space of the parent.
Arguments
New Parent: The actor that will become the new parent of this actor.
• Inherit Bends: Defaults to 0. Enter 1 to specify that this actor should inherit the bends from the new parent.
• Realign: Defaults to 0. Enter 1 to specify that this actor should be realigned to conform to the new parent.
Syntax
SetParent( newParent, { inheritBends = 0, realign =
0})
Example
childActor.SetParent(ParentActor, 1, 0)

Realign is new to Poser Python, reflecting the feature offered in the update.  I parent with it off, using a script.  Poser turns it back on as soon as the new parent is transformed.  Someone goofed when programming the new bit, and apparently no one caught it before the release.  Oopsie!

Take it you downloaded SR3 quite recently Cage... so it would be SR3.1 you've installed?

I noticed these problems parenting after the initial SR3 release... then these looked like they might have been resolved in SR3.1...

...but maybe they haven't?

SR3.1 build 23027 should have this covered. But you might have to alter a pre-SR3.1 script for it.

Wait, there's an SR3.1?  Because that would be supremely awesome.  :woot:  (Please pardon; I seem to be experimenting with 80s retro superlatives recently for some undetermined reason.  Umm.  :unsure:)

My test script was flawed, anyway.  The problem was there the whole time, but not visible until the preview was refreshed.  Once the script was redrawing the scene, there it was.  But if the bug has already been fixed... wahoo!  Good one, Poser team!  I was going to suggest editing on the cr2 level to change parenting properly, but updating to a revised version is better.

Vilters, can you clarify at all?  What scripts would this update break?  Because I have to balance that hassle against the bugfix benefits, before deciding to update the thing.  I don't want to break my Python tools over this when I can just edit the cr2 in select situations as a workaround for the parenting thing.

Quote - (Please pardon; I seem to be experimenting with 80s retro superlatives recently for some undetermined reason.  Umm.  :unsure:)

Gnarly, Dude!!  :lol:

Quote - > Quote - (Please pardon; I seem to be experimenting with 80s retro superlatives recently for some undetermined reason.  Umm.  :unsure:)

Gnarly, Dude!!  :lol:

A superlatively excellent idea ;-)

Hello Cage,

I know that all reported parenting problems where fixed in SR3.1  builds 23027. => Check your build number to see that you effectively have SR3.1.

I personally do not use Python scripts for that purpose you say.
If I need some geometry, I take the object into Hex, cut out what I need, and rework it if required.

Take the reworked partial object into Poser and parent it.

Or Smart Parent it with inherit bends ON, if it spans multiple groups, and if I want it to bend following the underlying groups.

With SR3.1 all parenting problems reported by beta testers and end users got fixed.

PS. You know that for Smart parenting with inherit bends ON, the new object does NOT have to be grouped........
It has to stay single group. => But it will bend following the underlying groups....

Build a Hi-boot. => That will cover the toes, foot, and shin.

Build the boot as ONE group. Do NOT cut the boot up into groups (toe, foot, shin)

Maintian the boot as ONE single object without groups.
Now load the boot, position it over the toe-foot-shin, and Smart prop it to the FOOT, with inherit bends ON.

The boot will follow all movements of the toes, foot and shin. (The parent group, one group up and one group down.)

Most errors come from objects that have been cut up into groups to do that.

You have to cut up into groups for conforming clothing items, but NOT for SMart Props with inherit bends ON.

Best regards,
and Happy Posering.
Tony

Edit, the new object does not have to be grouped, but it HAS to be welded to work properly.

Thanks, vilters.  More information is helpful for me and anyone else who may read the thread.  :thumbupboth:

I did, indeed, have the older SR loaded.  I updated today and now things are much better.  I do note that the same problem persists if I try to do the parenting in a frame greater than 1, if the figure has been posed in earlier frames.  Possibly the parenting simply always has to be performed in frame 1, regardless of any posing in later frames.  I haven't tested that.  But the desired result can be had now if one works in that first frame.  Excellent!

I thought I had another bug, but it turned out to be user error.  :lol:  Note to self: Try to avoid switching off irradiance caching accidentally when trying to switch off indirect light for a faster test render.  Switching off IC slows everything terribly!  :lol:  I was panicked and irritated, thinking I'd broken something.  I defragged my drive and deleted my render cache and began removing items from my scene, trying to fix the problem.  And I'd toggled IC instead of IDL.  D'Oh!

The IC Checkbox is a brand new checkbox... :-) It was not there before :-)
It gives far better render results IF you have problems with artifacts in 90° corners. But at the cost of HUGE render time increase...... For 99% leave it ON.
It's in the SR3.1 read me.

There is a parenting bug even in Poser 7, which sounds similar to this. If I make something with the Mr. Looper script and attempt to parent it, it flies off to destinations unknown. I haven't investigated further since there are work-arounds on the few occasions that I need to parent something. I seem to recall that I've seen this sometimes with other props too, i.e. ones not made by a script.

You seem to have your answer, but let me know if you want me to look at this further.  

Actually that very thing happened to me just this morning.  It's happened before too, but I just didn't say anything.

No reflection meant on SM but usually, I find a workaround or just ignore the problem before anyone there can sort things out. It's just not worth the effort in most cases for me to report a problem.

EnglishBob and EClark, were you trying to parent the prop in a frame other than frame 1, or one which wasn't the first frame in which the figure was posed?  I never had any trouble with loop script prop parenting in P8 or PP2012 (pre-SR3).  I don't recall whether I tested parenting a loop script prop in P7, but I'm pretty sure I never had trouble with prop parenting in earlier versions.

Working with the SM customer service desk is no fun, frankly.  They want a ton of work on your part to prove you even have a problem, then I've seen no evidence that the reports ever go beyond the gatekeeper who handles the direct customer interaction.  I reported a bug directly to Cooper once, and he wanted the full, unmodified pz3 in which I'd had the error - which pz3 was one of those things no one else was ever meant to see.  :lol:  I shudder to imagine poor programmers made to study such a bizarre scene.  Ahem.  At any rate, I now tend to avoid reporting bugs to SM, which is unfortunate.  :sad:

Quote - ...were you trying to parent the prop in a frame other than frame 1 [...] ?

Very likely, since dynamic cloth was probably involved in all cases.