Question about a rotation script

Well, I'm kind of new at scripting, and very unfamilar with some terms, so some of what I type below might not make very much sense;
How would I make a rotation script that stops rotation upon collision? (Example scripts are encouraged.)

You can spin an object around its axes by using the llTargetOmega() function. You make it stop by calling the function again (specifying zero spin.)

You can detect collision by using the collision_start() event handler. This handler is called at the beginning of the collision, at which time you can call llTargetOmega to stop the spin.

Simple example below. Put it in any prim, touch it to start spinning, then collide with it to stop the spin.

-peekay

ps. this assumes the object is non-physical.

default
{
    state_entry()
    {
        llSay(0, "Touch me to start.  Collide with me to stop.");
    }

    // Start spin when touched
    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        llTargetOmega(<0.0, 0.0, 1.0>, 1.0, 1.0);
    }
    
    // Stop spin on collision
    collision_start(integer num_detected) {
        llSay(0, llDetectedName(0) + " bumped me!");
        llTargetOmega(<0.0, 0.0, 1.0>, 0.0, 1.0);
    }    
}

The only problem with setting the rotation using llTargetOmega is that when you stop it it will reset to zero position which could result in a jerk in the image

That is not the only problem, unfortunately. For some reason, I have not been able to see *any* rotation that is caused by llTargetOmega for the last 4 or 5 updates at least. I know this must be rare, but is it as rare as a single case? Okay, ranting done

As previous posters suggested, using llTargetOmega with collision detection using collision_start will have good results. Additionally, while rotating, using llTargetOmega will result in smoother rotation than other potential methods.

Check your settings, something similar was reported a while ago and turned out to be a cleint side setting.

I think this was fixed as of 1.13... at least I no longer see this reset with my objects.

-peekay

I certainly hope this didn't get "fixed", I sure don't want to see my objects which have been given the appearance of spinning via llTargetOmega start coming to rest with different, actual rotation values than what they started out with.

Nevertheless, that appears to be the case.

-peekay

Personally I hated the 'jerk back' effect , it spoiled any illusion of reality.

I updated the wiki with the 1.13 patch explaining the new behaviour. while it will appear to stop at a new rotation, the server still sees it as being un-rotated. even your edit window rotation numbers will appear to have changed, but a simple test with a sensor and llDetectedRot(...) will show you that it is not actually rotated according to the server. you will note that collision boxes will not be rotated with llTargetOmega, so if the object in the initial inquiry is oddly shaped, or extremely long on one axis, collisions will fire/not fire when they should. Also, there are new problems with using llTargetOmega on childprims in addition to the root prim.

Thanks so much for taking the time to clear that up, and making the additions to the Wiki. I have a product I sell that combines both "fake" rotation via llTargetOmega and actual rotations via llSetRot and such. Fortunately the relevant script makes a call to llSetRot *after* stopping the llTargetOmega spin, and so forces a visual update most of the time. Still I question the wisdom of this change (if it was in fact a deliberate change) if only because it kind of blurs the separation between purely client-side visual effects and actual changes to in-world position and rotation.

It would be a whole lot more useful if there were a reliable way to predict where llTargetOmega is going to stop, and what the apparent resting angle were going to be.

You mean something similar to script posted a while ago by Lex Neva?

That was a very clever idea, but you're missing my point entirely; if this entirely client-side "special effect" is now going to have a persistent effect on the apparent in-world resting state of the affected object, then said resting state shouldn't be so utterly arbitrary with llTargetOmega continuing to just mindlessly spin away until such time as it's told to stop. I'm not looking for a way to seamlessly combine "real" rotation with llTargetOmega rotation, I'm bemoaning the fact that the lines between them are getting blurred at all, and the fact that objects operated on by llTargetOmega appear to now be stuck in some Twilight Zone where some observations and measurements give one result of their state, and other observations and measurements give an entirely different result. It's stupid and wrong and I'm expressing my frustration and suggesting a direction in which it could be improved, if it can't just go back to the way it was.

Actually I didnt miss your point, I was merely asking if your script was like that posted my Lex.

I see. I misread your previous question to mean "would something like Lex's script provide the solution you're looking for?".

Was not my intention to hijack the thread to this extent, so briefly: I make a scripted toy, a puzzle box. It has incidental touch-activated llTargetOmega effects, and very specific rotations and translations of groups of prims under certain circumstances; it also serves as the sit target for some animations, so it needs to be resting flat at certain times and preferably at the orientation it was rezzed at, *not* wherever llTargetOmega feels like leaving it. Sure these are trivial things to take care of, but it bugs me that I need to consider them at all now.

How would it be scripted if I wanted it to be a physical object, rather than non-physical?

Instead of using llTargerOmega couldnt you use llEulen2Rot()

float X;
float Y;
float Z;
float min = 1;
float max = 360;

default
{
    state_entry()
    {
        llSay(0, "Touch me to start.  Collide with me to stop.");
    }

    // Start spin when touched
    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        X = llFrand(min - max) + min;
        Y = llFrand(min - max) + min;
        Z = llFrand(min - max) + min;
        vector ourVec = <X,Y,Z>
        ourVec = *= DEG_TO_RAD;
        rotation quarterian = llEuler2Rot(ourVec);
        llSetRot(quarterian);
    }
    
    // Stop spin on collision
    collision_start(integer num_detected) {
        llSay(0, llDetectedName(0) + " bumped me!");
        llSetRot(quarterian);
    }    
}

Im sure im wrong on more than one point here in my usage of llSetRot and Euler vectors. I've used them successfully to rotate objects in world but to a set roation not an arbitrary one. I haven't played with the llTargetOmega, but could you use llSetRot and Euler to solve the problem? I know in many languages there is more than one way in that language to solve the same task. Surely SL has to have something in the lsl that would do it.

The physical analog of llTargetOmega is llSetTorque.

However, if you apply upwards force to cancel the effects of gravity, and place the object in mid-air to avoid friction, then you can spin a physical object by using llApplyRotationalImpulse.

Small example script below. Start with a prim at ground level. Put in the script and make the prim physical. Right-click "edit", and move the prim mid-air (it should stay there.) Optionally rotate the prim. Then "touch" to rotate the prim. Touch again to stop.

Gently bump the object with your avatar to see what happens. To "catch" the prim, just right-click on it (or left-click again to stop the rotation.)

Physical objects can quickly "get away" from you when rotated, so try in an enclosed area.

-peekay

integer rotate = FALSE;

default
{
    state_entry()
    {
        // Zero out existing torque and apply upward force to 
        // counter gravity. 
        llSetTorque(ZERO_VECTOR, FALSE);        
        llSetForce(<0.0, 0.0, 9.8 * llGetMass()>, FALSE);
        llOwnerSay("Touch me to start.  Touch again to stop.");
    }

    // Start/stop spin when touched
    touch_start(integer total_number)
    {
        rotate = ! rotate;
        if (rotate)
        {        
            llOwnerSay("rotating");
            llApplyRotationalImpulse(<0, 0, 0.1>, FALSE);
            
        }
        else
        {
            llOwnerSay("stopping");
            llSetTorque(ZERO_VECTOR, FALSE);
        }            
    }     
}

actually, llTargetOmega works with physical objects as well, and it does update their position real-time to the server. I had made an experimental vehicle using llTargetOmega to drive it just for fun.

I had assumed llTargetOmega on physical objects is just llSetTorque with its axis limited to local. However, I've had some bizzare results using llTargetOmega on physical prims, including one object that became totally screwed up with script run-time errors.

Maybe 1.13 improved this behavior.

I have had a problem with llTargetOmega I have a flat disc with a texture of Propeller on it this spins on a post linked to stand (flattish square) and the two prims are linked with post as primary everything works fine until I attempt to add a tube around the prop, the spinning disc starts to rotate end-over-end the only way I can stop this is to insure the prop and post are always primary, which is annoying as this is just an effect in background I want to do more with finshed article script wise, anybody else had problems like this?