residual effects of llTargetOmega()

[Chrisalexander Sixpence]

I need to remove the "residual effects" of calling llTargetOmega() on a child prim after it has rotated but then later stopped.  I need to put the child prim,  back where it was,  as if  llTargetOmega() were never called.

 

What follows is a detailed description:

I am using  llTargetOmega()  within a script that is located within a child prim of a larger linked object.  The child prim correctly rotates 360 degrees back to its original orientation, and stops. This stoppage is created by re-calling  llTargetOmega() within a timer() event.     Due to slight lags between script events, the previously rotated child prim is not precisely where it originally was oriented. Editing the object in "Edit Linked Parts"  does indeed show slight alterations to the Child's rotation parameters. (Usually off by tiny fractions of a rotation). 

HOWEVER,  all known existing scripting functions cannot detect these slight offsets in rotation. Nor can they correct them. I refer to  llGetRot,  llSetRot,   llGetLocalRot,  llSetLocalRot,   llGetLinkedPrimitiveParams(LINK_THIS,etc)  and  llSetLinkedPrimitiveParams(LINK_THIS, etc)    And both of those functions using PRIM_ROT and PRIM_LOC_ROT in the parameters.  

All I need is some tricky trick to erase these residual rotations in the child prim, as if llTargetOmega() were never called.   None of the above functions can do this.  They all think it is back where it began.  Although clearly the child prim is visually skewed, and editing the linked parts shows a residual skew in the parameters.

[Rolig Loon]

I've read your post several times and I'm still not quite sure I know what you're hoping for.  llTargetOmega does a false rotation, entirely client-side.  As far as SL's servers are concerned, your object isn't rotating at all.  So, when you stop llTargetOmega, you object should just snap back to the visual position that the servers knew it had all along.  In practice, sometimes it takes a little jog to make things snap back.  If you want your object to stop at the spot where llTargetOmaga leaves it visually, you have to do some tricky scripting with llSetRot (or SLPPF) to tell the servers to rotate your object incrementally as fast as your viewer is rotating it with llTargetOmega.  The Smooth Rotating Door script in the LSL wiki library is a good example of that technique.

[Dora Gustafson]

If you take the actual rotation before you make the 360 degrees rotation

rotation prior = llGetLocalRot();

 and set that rotation after you have done your stuff

llSetLocalRot( prior );

 Then you can't get any closer

There maybe something about how your view is updated (small changes may not show)
If that is the case, make a bigger change for a short while before you set the final rotation

:smileysurprised::smileyvery-happy:

[Chrisalexander Sixpence]

---

Rolig Loon wrote:

So, when you stop

llTargetOmega

, you object should just snap back to the visual position that the servers knew it had all along.

---

This is just not working for me.  Could you show me a quick line of code that officially stops llTargetOmega and causes this "snap back"? 

I am currently using

llTargetOmega(<0.0,0.0,1.0>, 0.0, 0.0);// Pause two seconds.llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, original_rot]);

 This does not correct the child prim's location. I see no snap back.

[Rolig Loon]

As I suggested above, and as Dora said in her reponse, if the actual (server-side) rotation of your object has been very small or non-existent, you may have to give the object a little kick to make it snap back.  Like this ....

integer gON;rotation gPrior;default{    touch_start(integer num)    {        gON = !gON;        if (gON)        {            gPrior = llGetLocalRot();            llTargetOmega(<0.0,0.0,1.0>,0.3,0.1);        }        else        {            llTargetOmega(<0.0,0.0,1.0>,0.0,0.0);            llSetLocalRot(llEuler2Rot(<0.0,0.0,2.0*DEG_TO_RAD>)*gPrior);  //A little kick            llSetLocalRot(gPrior);        }    }}

 

[Innula Zenovka]

Have you tried the old standby of setting and removing some invisible hovertext?   That forces the viewer to redraw the scene in circumstances where otherwise it wouldn't bother.

[Chrisalexander Sixpence]

Giving the door a little kick works like a charm. Everything is great now. Thanks for the help. :matte-motes-sunglasses-1: