llTargetOmega: Bug Report and Workaround!

Like several other posters here, I have encountered sporadic problems with llTargetOmega. In my case it was a rotating part linked to an object.

I have identified the bug and a workaround.

(Since llTargetOmega is client-side, I'll mention I'm running Mac OS, 10.3.9.)

The symptoms were that it would work great, but then a fresh copy of the object would not. All code arrived intact, debug llSay()'s would indicate everything operating as expected except: No visible prim rotation!

Also (as reported by others, too): sometimes a recompile of the same script would let it work again.

Here's some other threads reporting similar symptoms:

/54/36/73330/1.html
/54/d0/70993/1.html
/54/ec/69383/1.html


Here is a demonstration of the problem:

//
// llTargetOmega() Bug, on SL 1.8-whatever, on Mac OS client
//
// Instructions: Make a two prim object, and put this in the CHILD prim.
// Clicking on the child should cause it to start and stop moving.
//
// Note instead:
//  The first one you make works. Shift-drag the object, and the copy
//  (the one sitting in the original spot) does NOT work.
//  Uncomment the llSetText(), and then you can copy as many as you
//  like and they keep working.
//    -- Davan Camus, 2005.12.24
//

integer turning = 0;

default
{
    state_entry()
    {
        llSetText("",<0,0,0>,0);
    }
    touch_start(integer total_number)
    {
        string s;
        if(turning)
        {
            llTargetOmega(<0,0,0>,0,0);
            turning = 0;
            s = "stopped";
        }
        else
        {
            llTargetOmega(<0,0,1>,1,1);
            turning = 1;
            s = "turning";
        }
        // llSetText(s,<1,1,1>,1);   // uncomment this line to make it work right.
    }
}

And here is the related workaround I am using in production code ():

    link_message(integer sender_num, integer num, string message, key id)
    {
        if(num == CYLINDER_TURNING_START)
        {
            vector axis = <0,0,1>;
            axis *= llGetLocalRot();
            llTargetOmega(axis,1,1);
        }
        else if(num == CYLINDER_TURNING_STOP)
            llTargetOmega(ZERO_VECTOR,0,0);

        // This script worked fine in my linked object, but not
        // on copies, not until it was recompiled each time.
        // but!
        // HERE IS THE WORKAROUND:
        
        llSetText((string)llGetTime(),<0,0,0>,0);

        // The use of llGetTime() ensures that the text keeps changing,
        // and the zero-alpha makes sure that it's invisible.
        // I believe that this "nudges" the client to re-check various states
        // on the prim that, due to a server bug, are not being "nudged"
        // by llTargetOmega.
        //
        // In any case -- it fixed my object on my client, so there ya go.
        //
    }

*Flex*

I know this is somewhat of a fix for me.

Basically my script does this

If stopped = TRUE then llResetScript()

Got me?

Here on your script would basically be the following

else if(num == CYLINDER_TURNING_STOP)
llTargetOmega(ZERO_VECTOR,0,0);
llResetScript();

Thanks for the timely info, I just ran into the problem with llTargetOmega on my system (also Mac OS 10.3.9) and had basically given up on getting it to work correctly. I usually would recompile the script after rezzing (Resets didn't work), but this works nicely.

Variessa

okay, was this fix 'fixed' out of existance or what? it's not working for me today, in this build:

Second Life 1.13.3 (2) Jan 30 2007 15:34:24


neither are my other attempts to force a clientside object update, such as llSetStatus and llSetPrimitiveParams. and this isn't on an attachment, it's still on the ground!

::sigh::

in case anybody else is banging their head over this. here is something amazing i have discovered! (and have immediately bug-reoprted!!)


concerning starting and stopping a target omega-ing prim:

IF you write or drop your script in a prim that is a CHILD prim: it will fail to stop.

IF you write or drop your script into an UNLINKED prim: it will start and stop. AND it will continue to work after you have linked it as a child prim.


so... if you want to stop the target omega, make sure you make/put the script into a prim BEFORE linking it to anything.




how the heck it even KNOWS is beyond me. nevertheless, that's the results i got.

by the way, this appears to work even without 'forcing an update' with the llSetText or anything. go figure.