Need help with this script Please

I got a rocking chair script from the forum...I made a rocking chair...added an extra prim over the seat...put the script in it...it is the last prim i connected to...problem is the rocking is way to fast...and there is no stop or start...please someone help me...this is the script I got...

rotation Inverse(rotation r)
{
r.x = -r.x;
r.y = -r.y;
r.z = -r.z;
return r;
}
rotation GetParentRot()
{
return Inverse(llGetLocalRot())*llGetRot();
}
SetLocalRot(rotation x)
{
llSetRot(x*Inverse(GetParentRot()));
}


vector normal = <1.5, 0.0, -1.75>;

default
{
state_entry()
{
@a;
SetLocalRot(llEuler2Rot(<normal.x, normal.y, normal.z + 1>);
SetLocalRot(llEuler2Rot(normal));
SetLocalRot(llEuler2Rot(<normal.x, normal.y, normal.z - 1>);
SetLocalRot(llEuler2Rot(normal));
jump a;
}

}

I'm actually having problems with something similar, you need to use the llTargetOmega function instead I think, which sets your object rotating in a given direction at a certain rate (so you can choose the speed). The problem is with changing direction which I can't seem to get quite right, I'll let you know if I find a solution, unless someone else posts first.

But play around with the llTargetOmega function, see if you can get it to work for you!

Too fast in which way, the rotations themselves (moving too fast from point A to point B), too fast between rotations (hit the "peak" then immediately reversing) or both? Probably both. Some thoughts.

Easiest way to slow it down would be to add some llSleep commands between the rotations. Also, you may need to split up the rotation into more than three segments (right now it's forward, middle and back only). Maybe add some intermediate steps. Of course, everytime you call SetRot, the script will automatically sleep for something like 0.1 seconds, so with enough intermediate steps you might not need to add any llSleep's at all.

To have it start and stop, say when touched, add a touch event and just cut and paste the stuff that's in state_entry into the touch event. State_entry would be empty.

SetRot can be a little jerky motion-wise (unless you use multiple scripts, beyond the scope of this response), haven't used TargetOmega so no idea if the motion is smoother that way.

I should be online tonight if you have any questions.

ETA: Ack! Well, don't just copy the rotation piece into a touch event. It would start fine, but would never bloody stop. Need to add a control structure of some sort to turn it back off. Mind is elsewhere at the moment, have a few ideas, but nothing solid to post right now.

Hmm, TargetOmega is MUCH smoother and more controlable in terms of speed, as it is done client-side, however it appears to be completely unsuitable for rotating an object in one direction then reversing the direction.

In my example I am trying to create a simple tail script to have my av's tail swish from side to side while idle (possibly faster when moving but that's beside the point if I can't get it working in the first place!).
To do this I had a TargetOmega around the z-axis, and wanted it to move at a rate of 0.01 radians per second, simple enough, worked fine. But I have a timer in it for when it should reverse (else it would go through my avatar and right around then back again!), so I figured "Oh, I'll just put in a negative rate!" that would work great except that changing the rate to negative flips the thing over and sends it in the wrong direction.
ie - if the tail was sticking to my right and moving toward my front, it would suddenly be on the left moving toward my front, rather than still being on my right and moving backwards as desired.

I hope that's clear enough, unless there's a way to use it that I don't see then I'll withdraw my first comment about TargetOmega being a solution

I ended up putting the steps (more of them) into a timer event, so each 'tick' moves you on one space - i.e. to the next position. This lets touch_start() events be called to turn it on and off easily.

I found for a smallish swing range 12 steps worked quite well. I also found that since you're moving in an arc of a circle with offsets to either side of the vertical putting in something with sin(2*PI/step_number)*max_offset rather than the fixed z values worked nicely. It also meant that I could detect for the "straight down" positions easily enough that I could always get the swing to stop pointing straight down whichever way I approached it (0, 6, 12, 18... are the numbers when it's straight down if you use sine).

Someone went away and tinkered and decided a 36-step swing was better, so scripting it with a function like sine is a smart way to go to get your swinging adjustable.

Can't get in world right now, but if you'd like a working version IM me, I do sell it, but with full perms.

thanks for trying to help...but i'm not a scriptor nor know anything about it...I don't understand what was even said here in response to my question...but thanks all for trying to help me...
Awalys, Sweetheart