Jump to content

Reset a llTargetOmega() spin


You are about to reply to a thread that has been inactive for 63 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello all,

I have a cylinder attached to my body center. It rotates by use of llTargetOmega(). That works all fine. I can increase/decrease the speed or stop the spinning.

After some spinning around i like to not only stop the spinning but also want to reset the rotation, that is that the cylinder goes back to the default avatar rotation.

When using llSetRot() i am not able to set the rotation back to the original point. 

Any help around? 🙂

Thanks in advance,

Trivis

Edited by trivis
Link to post
Share on other sites

Try re-issuing the llSetTargetOmega command, if that fails to make a change then first set targetomega to all zeros, then re-issue the command.

llSetRot won't have any effect because your object isn't actually rotating in terms of world positions or even local, it just appears to be rotating.

  • Like 1
Link to post
Share on other sites

Thank you for this idea. It was my first thought too. Tried it, but also without the effect that i am looking for, unfortunately. 

And thanks for the knowledge of that the spinning isnt rotating. So, perhaps there isnt a solution.

Anyhow, thanks for thinking with me. I really appreciate and value your contribution!

Trivis

Link to post
Share on other sites

See the following bug reports on this issue:

https://jira.secondlife.com/browse/SVC-4348

https://jira.secondlife.com/browse/SVC-4598

https://jira.secondlife.com/browse/SVC-6111

I think the consensus is that there is no non-hacky way to address this.

The most common workaround is after stopping targetomega, make a small rotation adjustment then set the original rotation.

From my own testing earlier, the amount of rotation depends on how close the object is to your camera, ie, a 0.001 degree change will trigger an update at close camera distance, but not far distances.

Examples:

llTargetOmega(ZERO_VECTOR,0.0,0.0);
llSleep(0.03); //allow a minimum of 1 server frame to elapse to attempt to separate effects into individual update packets, else llSetRot() effect 'might' not be seen
rotation r = llGetRot();
llSetRot(llEuler2Rot(<0.0,0.0,0.001> * DEG_TO_RAD) * r);
llSleep(0.03);
llSetRot(r);


llSetLinkPrimitiveParamsFast(link,[PRIM_OMEGA,ZERO_VECTOR,0.0,0.0]);
llSleep(0.03); //allow a minimum of 1 server frame to elapse to attempt to separate effects into individual update packets, else llSetRot() effect 'might' not be seen
rotation r = llList2Rot(llGetLinkPrimitiveParams(link,[PRIM_ROT_LOCAL]),0);
llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,0.001> * DEG_TO_RAD) * r]);
llSleep(0.03);
llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,r]);

 

Edited by Lucia Nightfire
  • Like 1
  • Thanks 1
Link to post
Share on other sites

Thank you very much for all this insights!!!! This is so very helpful.

I also tried the stopping in combination with llScaleByFactor(1.00); that seems to work as good workaround for now. I am sure anymore, but i think i did the stopping with llTargetOmega(ZERO_VECTOR,0.0,1.0);

The llScaleByFactor() was kinda accidentally part of my script, in a reset module.

Link to post
Share on other sites

This is one case of a general issue in Second Life - different forms of motion control are not interlocked. For example, keyframe motion (via llSetKeyframedMotion) and position setting (via llSetPos, etc.) interfere. You need to completely shut down one kind of motion and allow some time before starting another. The same is true of llTargetOmega, and of pathfinding. One control mode at a time. Come to a full stop and wait a second between changing control modes. Or, better, pick one control mode and stay with it.

  • Like 1
Link to post
Share on other sites

Any change that causes an object update seems to correct the client-side rotation caused by llTargetOmega.

This includes things like:

  • Changing hovertext. *
  • Changing object name/description. *
  • Changing "temporary" status. *
  • Changing color/texture on any face.
  • Changing fullbright on any face.

* Some updates are better than others. These will cause full object updates (causing more network traffic), others will only cause partial updates.

The sim is smart enough to not send updates that don't change anything. So you can't just set the color of a face to white (if it was already white, as most are) and expect it to update the object.

  • Like 3
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 63 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...