Rotation Woes

[AirmanPA32]

Hello All,

I have a script where I am rotating an object using llTargetOmega being called from a control panel, this all works fine. 

I am trying to give the operator a means to set a "home" position and when the comand "center" is called, I want the object to return to the "home" position. 

My attempts are not working ... the object does not rotate at all.  I inserted a "whisper" to see if "home" (rStored) is being set and it always comes back with (<0.00000, 0.00000, 0.00000, 1.00000>).  Here is Part of the script with the pertinent elements.

Thank you all in advance.

Ray

 

rotation rStored;
Home()
{
    rStored = llList2Rot(llGetPrimitiveParams([ PRIM_ROTATION ]),0);
    llWhisper(0,"Home Rotation Set");
    llWhisper(0,(string)rStored);
}
Left()
{
    llTargetOmega(<0.0,0.0,1.0>, 0.3, 1.0);
}
Right()
{
    llTargetOmega(<0.0,0.0,-1.0>, 0.3, 1.0);
}
Up()
{
    llTargetOmega(<0.0,-1.0,0.0>, 0.3, 1.0);
}
Down()
{
    llTargetOmega(<0.0,1.0,0.0>, 0.3, 1.0);
}
Center()
{
    llSetPrimitiveParams([PRIM_ROTATION, rStored]);
}
Stop()
{
    llTargetOmega(<0.0,0.0,0.0>, 0, 1);
}

[Ron Khondji]

llTargetOmega() is totaly viewer side if the object is not physical.

So you can either make the object physical or use some other method to rotate it..
(I'm hoping someone else knows some other methods.)

[Qie Niangao]

Right. For non-physical objects, llTargetOmega has nothing to do with the object's rotation, only with how it's rendered (as if spinning) on client viewers.

So you're kind of stuck with some ugly choices. One might be to estimate what the object's apparent rotation would be on a viewer's screen when "homed", then move it accordingly when "centered." This is only viable for very short intervals, and intervals during which time you know the viewer will have the object constantly in its field of view. That's probably not your situation.

Laggier than llTargetOmega is llSetKeyframedMotion which actually does update the object's rotation. That's probably your best bet if you're doing what I think you're doing.

A last resort might be a timer loop of scripted llSetRot() or similar. Relying on script execution for every update, this tends to be jerkier and laggier than KFM but both approaches send a constant stream of object updates over the network. 

[AirmanPA32]

hmmm ...  thank you both ...  back to the drawing board.

[Rolig Loon]

Well, all hope is not lost.  You can use llTargetOmega and then, at the same time, run a moderately fast timer with llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, insert your updated local rot here]);

Every time the timer fires, get the prim's current local rotation with llGetLinklPrimitiveParams and then multiply with llEuler2Rot(,0.0,0.0,small_number*PI>) to calculate theupdated local rot.  You'll have to match small_number to the amount of rotation that llTargetOmega is providing in that same time interval.  If you watch just thge rotation that the timer is providing, it will be jerky.  When the llTargetOmega is running at the same time, you won't see the jerkiness any more, but the servers will.  That way, they can keep track of your object's "real" rotation.

[AirmanPA32]

I thnk I understand ... I will try.

Thank you

[Rolig Loon]

If you're still working at it, try this as a starting point.  Notice that the rotation speeds in llTargetOmega and the SLPPF command are matched.  The timer updates rotation as far as the server is concerned.  llTargetOmega controls what you see in your viewer.

 

integer gON;default{    touch_start(integer total_number)    {        llTargetOmega(<0.0,-1.0,0.0>, -0.1*(gON = !gON),0.1);        llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, llEuler2Rot(<0.0,0.0,-0.1>)*llGetLocalRot()]);        llSetTimerEvent(1.0*gON);    }        timer()    {        llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_ROT_LOCAL, llEuler2Rot(<0.0,0.0,-0.1>)*llGetLocalRot()]);    }}

 

[AirmanPA32]

Thanks Rolig ... yes I was working on it ...