Moving child prims in attachments

I want simultaneously to move and rotate a child prim in an attachment. If the object wasn't attached, I'd use llSetPrimitiveParams([PRIM_POSITION, pos, PRIM_ROTATION, rot/llGetRootRotation]); (dividing by the root rotation because of the bug described at http://jira.secondlife.com/browse/SVC-93).

Am I correct in thinking, though, that, because of this bug, the only way to achieve this smooth and simultaneous movement when the item's attached is to have two scripts in the child prim, one calling llSetPos(pos); and the other calling llSetLocalRot(rot); and fire them simultaneously with a link message? That certainly works, but I'm wondering if there's a better way to do it.

you can still use prim params, but you'll need the root to report it's offsets (because they can't be gotten from another prim... then do the funky math dance.

Thanks, Void. I wonder if you could talk me through it a bit, if you don't mind, because I'm a bit confused about what I'm asking the root to tell me.

Do I call llGetLocalRot() in the root prim and then use the result ("rotation of attachment relative to the attach point" according to the wiki) as the divisor in the funky maths? The wiki tells me I need to "divide the local rotation by the root rotation" -- at least if I'm using llSetRot() rather than llSetLocalRot() in a child prim in an attachment -- but I'm not 100% sure what that means in this context.

Or do I need the global rotation of the avatar (llGetRot())? The wiki page on rotation seems to suggest I might, but I'm not sure if I'm reading it correctly. But if I do, what rotations do I need to set in the child? Those returned by llGetLocalRot() when it's attached or those returned by llGetRot()?

The more I think about it, the more I want to conclude that it's like using llSetPrimitiveParams in a child prim in any other circumstances, weird maths and all, except that I need to worry about the Avatar's rotation rather than that of the root prim of the attachment. Which would mean I need the results of llGetRot() from the root prim. But that sounds too simple.

I'm confussled.. please help.

Is the offset for PRIM_POSITION the same I'd be using in the stand-alone script, or do I need to tinker with that, too?

my ISP is being a POS so I can't get in and stay for more than a few seconds, but I believe it's the root local to the attach point ones that you need. I could be wrong though, in which case use the ones reported by the av.

I know that the official spec for PRIM_POSITION is supposed to match that of llSetPos (but obviously doesn't thank you SVC-93) and that states relative to the root when called in child prims, and relative to the attach offset in attached roots.

Thanks so much, Void. Seems that llSetPrimitiveParams in a child prim in an attachment needs the rotation to be divided by the results of llGetLocalRot() in the root prim, not llGetRot(). The PRIM_POSITION part just needs the local offset from the root prim, same as it did when I called llSetPos() on its own in the child prim.

I am feeling so pleased -- I never thought I would be able to learn how to move and rotate child prims in attachments using llSetPrimitiveParams, which always seemed to me the hight of complexity (almost as bad, in fact, as once I thought opening boxes must be!).

Thank you so much for all your help and patience, Void -- it's primarily because of your guidance I've been able to learn how to do this.

So, my successful script, which opens the lid of a zippo-style lighter when I'm holding it, is (you may recognise the script on which I based this)

  

 integer vgIntDoorSwing = -90;
 //-- use -# to reverse the direction of swing, eg. -90;
 
 vector open = < 0.00079, -0.14663, 0.12475 > ; // record of the offset reported by llGetLocalPos() when lid is open
 vector closed = < 0.00079, -0.12500, 0.15875 > ;// record of the offset reported by llGetLocalPos() when lid is closed
 vector pos;
 integer toggle;
 
 rotation vgRotDoorSwing;
 
 default{
   state_entry(){
     vgRotDoorSwing = llEuler2Rot(< .0,.0,(float)vgIntDoorSwing * DEG_TO_RAD> );
   }
 
    link_message(integer sender, integer num, string str, key id){
      //- small hack to reverse direction of swing on each
      //- touch & avoid lsl funkiness regarding rotation division
      toggle=!toggle;
      if(toggle){
          pos = open;
        }
        else{
            pos = closed;
        }
   
     vgRotDoorSwing.s *= -1;
     rotation root_rot = (rotation)str; //result of llGetLocalRot() call in the root prim
 
     llSetPrimitiveParams([PRIM_POSITION,pos, PRIM_ROTATION,( vgRotDoorSwing * llGetLocalRot() /root_rot)]);
 
    }
   
 }
 

nope, can't say I recognize it

(I wonder if I'll think memory jokes are still funny in 10-20 years? eh I probably won't remember.


and I should probably add a note about that on my user page (so the next person doesn't have to rely on my fuzzy memory) I think I'll give you credit since you re-worked it out =)