Maybe I'm just being dense. Target omega and llSetRot quandary

[Timothy McGregor]

integer turning;

stop()
{
    llTargetOmega(ZERO_VECTOR, 0, 0);
    turning = FALSE;
    llSetRot(<0,0,0,1.0>); // This doesn't work. Why?
}

start()
{
    llTargetOmega(llRot2Up(llGetLocalRot()),0.2, 0.1);
    turning = TRUE;
}

default
{
    state_entry()
    {
        stop();
    }
    
    touch_start(integer num)
    {
        if (llDetectedKey(0) == llGetOwner())
        {
            if (turning)
            {
                stop();
            }
             
            else
            {
                start();
            }
        }
                
    }
}

 

[Innula Zenovka]

Which viewer are you using?   There have been a host of update issues with llTargetOmega in the 3.4.x branch of the viewer and tpvs based on it.

[Timothy McGregor]

Firestorm 4.2.2 (29837) 

[Timothy McGregor]

I didn't think to check with the LL viewer. I'll do that.

[Timothy McGregor]

Interestingly, if I put any rotation other than ZERO_VECTOR in there, it does work. I can turn it any which way except on ZERO.

[Rolig Loon]

ZERO_VECTOR is not a rotation.   ZERO_ROTATION is, though.

ZERO_ROTATION sets the object with its Z-axis vertical and its +X axis aligned with global East.

If you are using ZERO_VECTOR in llTargetOmega, then you are turning the spinning off. It has the same effect as setting the gain to zero.

[Dora Gustafson]

---

Zaphod Kotobide wrote:

integer turning;stop(){    llTargetOmega(ZERO_VECTOR, 0, 0);    turning = FALSE;    llSetRot(<0,0,0,1.0>); // This doesn't work. Why?}

 

---

When your object is not physical llTargetOmega works entirely client side.

When you start and stop your spin the object hasn't moved at all on the server side,

the object has the same rotation before, during and after the spin.

If that rotation is <0,0,0,1.0> the ZERO_ROTATION, the server doesn't bother to change it even though you may see another rotation on your client.

To overcome it you may force a rotation different from ZERO and the back to ZERO.

:smileysurprised::smileyvery-happy:

 

[Timothy McGregor]

That's what I'm seeing. I realize the effect is client side in this case, but still it was throwing me off that even after the rotation stopped, editing the piece showed what it had rotated to at the point I stopped it. Even though in reality it was still on zero. 

The issue comes in when I stop this thing, and walk across it. There are things linked to it that I'm bumping into when it appears I'm walking through empty space, but in reality there's an object sitting there in its original position. Now that I understand completely what's happening here I'll have to try and figure out an elegant way to deal with that. It doesn't appear that there is much that can be hoped for though since the server has no idea where it is, and it's different on each client. Nudging it as you suggest sure works, but it's not particularly graceful from a visual standpoint. 

[Timothy McGregor]

---

Rolig Loon wrote:

ZERO_VECTOR is not a rotation.   ZERO_ROTATION is, though.

ZERO_ROTATION sets the object with its Z-axis vertical and its +X axis aligned with global East.

If you are using ZERO_VECTOR in

llTargetOmega

, then you are turning the spinning off. It has the same effect as setting the gain to zero.

---

All true. But targetomega wants a vector, and indeed all I am aiming to do in that call is stop the spinning.Subsequently, I'd like to figure a way to reconcile its actual rotation between the clients and the region. 

[Innula Zenovka]

As Rolig points out, llSetRot  needs ZERO_ROTATION, not  ZERO_VECTOR.

Having said that, after I changed it to 

integer turning;stop(){    llTargetOmega(ZERO_VECTOR, 0, 0);    turning = FALSE;    llSetRot(ZERO_ROTATION); // }

 it both compiles and works as expected (stops apparent rotation, returns apparent rotation to ZERO_ROTATION) in the latest official beta, Second Life 3.4.2 (266995) Nov 14 2012 03:52:03 and the beta version of Firestorm, Firestorm 4.3.0 (30936) Nov 13 2012 23:33:24 (Firestorm-beta).   

However, in Catznip R7 Oct 23 2012 19:54:00 (Catznip Release) it stops the rotation but doesn't return the apparent rotation to ZERO_ROTATION.   Is that what you're getting?

So my advice would be to use the latest Official Beta or Firestorm Beta and, if you're making this for a product, hold off releasing it for a few weeks till people have had the chance to update their viewers.

If you don't want to wait, the workround is to do something like this:

 

integer turning;start(){    llTargetOmega(llRot2Up(llGetLocalRot()),0.2, 0.1);    turning = TRUE;}rotation z10;stop(){    llTargetOmega(ZERO_VECTOR, 0, 0);    turning = FALSE;    llSetRot(z10*llGetRot());    llSetRot(ZERO_ROTATION); // }default{    state_entry()    {        z10=llEuler2Rot(<0.0,0.0,10.0>*DEG_TO_RAD);        stop();    }        touch_start(integer num)    {        if (llDetectedKey(0) == llGetOwner())        {            if (turning)            {                stop();            }                         else            {                start();            }        }                    }}

 

That certainly works in Catznip and, I think, in any other viewer.    What's confusing the sim, I think, is that the object never actually changes its rotation -- llTargetOmega is wholly client side.   So, as far as the sim is concerned, it's at ZERO_ROTATION and doesn't need changing.   But that's fixed, now, in the latest viewers.

[Timothy McGregor]

At no point was I giving ZERO_VECTOR to llSetRot(). As far as I know, that wouldn't even compile. What Rolig pointed out was all correct, but unrelated to my quandary.

However, in Catznip R7 Oct 23 2012 19:54:00 (Catznip Release) it stops the rotation but doesn't return the apparent rotation to ZERO_ROTATION. Is that what you're getting?

Yes. In the current release of Phoenix. Nudging slightly off zero and then back to zero produces the result I expected from just explicitly calling llSetRot with zero rotation. But it isn't very pretty to watch. In the end, this is really just a moderate aesthetic issue, not a show stopper. I'll play around and see what I can come up with.

[Timothy McGregor]

Looks like I might be able to avoid all of these little quirks by using llSetKeyFramedMotion(). Playing around with that now with promising results.