Rotation scripts gone insane

Objects attached to rotations balls using this script, which previously rotated at a sedate pace, now are spinning like crazy. Is this a bug from the new update that was installed this morning?

default
{
    state_entry()
    {
       llTargetOmega(<0,0,.05>,PI,1.0);
    }

}

It's possible the algorithm was changed. Try:

llTargetOmega(<0,0,1>,PI,0.05);

instead? It used to be that this would have the same effect as the other one.

Definitly something to do with the update. My water lilies now look like they're in a whirlpool.
Unfortunatly for me, the script is no mod so I can't try and fix them. Hopefully they'll put whatever they changed back to the way it was.

I noticed it was noted in the blog.

http://blog.secondlife.com/2006/09/13/second-life-1121-release-notes/

I tried setting up three objects with rotation scripts in them, with different parameters in each, to see if it was the vector screwing with things.

I'm going by memory, since my internet connection went FUBAR while logins were restricted to lindens (so I can't log back in now), but if I remember right, this is what they were:
llTargetOmega(<0.0, 0.0, 1.0>, 1.0);
llTargetOmega(<0.0, 0.0, 1.0>, 0.1);
llTargetOmega(<0.0, 0.0, 10.0>, 0.1);

Each object had a different one of those lines, of course, but here's the kicker: All three were rotating at the exact same speed. O_o

I actually went and redid the prims what had spin scripts in them, can't fix them at all..

Though if anyone finds a fix at all please post, I really prefered my slow rotating signs hehe

Looks like the Lindens are aware of the problem and will address it. So I dont intend to try and fix any of my products that use it until the Lindens have decided what they are doing about it. Otherwise you may have to fix it again later. If the fast spin is really annoying you and critical for you then I found that the changes in the script below changed the speed the object rotated at.

Reading about TargetOmega on the wiki

It says <<

The rotation speed is based on the axis vector multiplied by spinrate

llTargetOmega(vector axis, float spinrate, float gain)
llTargetOmega (<x,y,z>, "spinrate", "gain"
spinrate in radians per second
gain must be none-zero for non-physical objects >>

default
{
    state_entry()
    {
       //llTargetOmega(<0,0,.05>,PI,1.0); //after upgrade ran really fast
       //llTargetOmega(<0,0,1>,0.5, 1);//reasonably slow
       //llTargetOmega(<0,0,0.1>,0.5, 1);// slower
       //llTargetOmega(<0,0,0.1>,0.3, 1);// slow
       llTargetOmega(<0,0,1>,0.1, 1);//very slow
    }

}

Rich, Since <<The rotation speed is based on the axis vector multiplied by spinrate>>

the variations you tried are all mathmatically equal, however it appears you left out the "float gain" number.

Yeah, couldn't get into SL to see the scripts. They aren't all equal though: Notice the last two. One has 1.0 and 0.1, and the other has 10.0 and 0.1.

Not sure, but I think, from a bit of observation, that if you've used non 0/1 values in the vector they're being treated oddly.

There's an object I built that seems to be rotating at the same speed as before, with <1.0, 0.0, 0.0> as its vector. A neighbour has something spinning insanely, so it's not something funny about the sim, although I'm not sure about the values in their script.

Eloise, you are right about the vector, that will teach me to play around with the numbers without looking up what they are supposed to be. This script was given to me and I tweaked the values to try and slow it down with out really understanding what I was doing.

I am wondering about the use of PI for the spinrate also, now that I have read the wiki explanation, I dont see the reason for that.

Rich, my mistake sorry, they are not mathematically the same, somehow I saw an extra 0 in there. It may be that the vectors values do not recognize 10, just 0 or 1.

The latest update seems to have fixed this but you have to reset the scripts before they start rotating at the correct rate.

What about objects that are not allowed to be reset?

Here's my guess... since the Lindens consider the problem 'fixed'....

Release Notes for Second Life 1.12.1(9) September 14, 2006
=====================================
Bug fixes:
* Fixed incorrect llTargetOmega() spin rates
* Fixed IM window resizing on close/open
* IM window saves size across sessions
* Inventory can once again be dropped on any part of a resident's profile
* Pay dialog scales for larger buttons
* Fixed Top Scripts/Top Colliders highlighting incorrect object
* Fixed mute for scripted give inventory (particularly for group-owned objects)
* Further improvements when editing long notecards or scripts


and the 'fix' worked for most people on most objects, don't hold your breath

So part of the problem lies with not putting a normalized vectors in for the spin axis?

Have been trying to find editable examples of out of control spinning scripts to see if this is the case. Many of my Items use llTargetOmega, swing, rocking chairs, doors, gears, bridges and such have not suffered this problem. Of course these update the spin rate at some point in time and are not a constant spinning item.

I think, but I'm not 100% sure, that most scripts reset on rez. So try re-rezing the object to see if that fixes it.

No, scripts don't reset on rez unless the scripter put on_rez(integer param) { llResetScript(); } in the script (some people do that).

Rerezzing the objects did not reset the script. I discoverd also that the script I used for the rotations is the one the Lindens provide in eveyones Inventory Library. It uses PI in the call. After reading the Wiki I still can't see any good reason for using PI there.

I have found that the scripts in no mod objects cannot be reset so they are ruined forever now.

Rerezzing the objects did not reset the script.

I also discoverd that the script I used for the rotations is the one the Lindens provide in eveyones Inventory Library. It uses PI in the call. After reading the Wiki I still can't see any good reason for using PI there.