llTargetOmega and llSetAlpha on link set/attachments

Has anyone else noticed that llTargetOmega and llSetAlpha doesn't seem to get along when used in conjuction with a child prim of an attached object?

I've filed a bug with LL about this, but I wondered if anyone else has encountered this.

I have a HUD which uses a client side animated prim for the reticle. To minimize screen clutter, I use llSetAlpha (0, ALL_SIDES) to clear off the prim when the agent isn't in mouselook mode. However, I have noticed that this intefers with the Target Omega rotation. The prim will animate fine until llSetAlpha is invoked -- Afterwards, it acts as if any further llTargetOmega calls don't do anything.

Anyone else noticed this? I've tried stacking the two commands various ways, such as adding a sleep command between the llTargetOmega and llSetAlpha but it seems like if llSetAlpha is called with any parameter after an llTargetOmega, the client rotating effect usually goes away. I haven't tried other prim-updating commands such as llSetColor and so on.

The odd thing is sometimes it works just fine, but more often it doesn't.

To repro, create two prims. Link them together. In the second prim, put this script:

integer toggle = TRUE ;

default
{
    state_entry()
    {
        llTargetOmega (<0, 0, 1>, 1.0, 1.0) ;
    }

    touch_start(integer total_number)
    {
        if (toggle)
            llSetAlpha (0.0, ALL_SIDES) ;
        else
            llSetAlpha (1.0, ALL_SIDES) ;
        toggle = !toggle ;
    }
}

Now, in the world if you click the second prim it will toggle invisibility without affecting its client side rotation. But if you then wear this test object, clicking on the second prim will cause it to sometimes stop rotating.

Odd.

Oh, playing with HUD objects really makes me wish that prims without explicit touch events would click-through.

I have had quite a few problems with llTargetOmega, although not in conjunction with alpha setting calls. All by its lonesome llTargetOmega on child prims on attachments works or not as the case may be, but more not than doing so for me. I have bug reported it a few times, but the more people reporting problems, the better!

The fun thing is to see it work right, look someplace else then look back and see it not working! oooooo!!

Hopefully this will be fixed at some point, but until then... back to static designs for me. Yes I could do a timer function call to make the code work... but I do *not* want to do that in something that may be around for sometime and that little workaround might cause server lag... better to have it cleanly function rather than workaround for my work...

Oops, I missed this reply...

Well, I heard back from the Lindens, but I am still not entirely sure if what I am seeing is a bug or intended behavior. "Shared Drawables" was mentioned, which can be toggled off under Debug / Rendering. By toggling it off, I get the expected behavior -- both for llSetAlpha calls, and llTargetOmega calls on child prims in an attachment set.

According to the Linden, Shared Drawables is batch rendering of attachment prims. I suppose it's a shortcut that SL uses to render all of an attachment in one pass instead of considering each prim seperately. Appearently, things like llTargetOmega for child prims isn't considered by batching, only the root prim. Whether or not this is something they intend to fix, or it's not worth fixing/invalidates the purpose of batching -- I am not entirely clear on.

This is definitely something that needs to be fixed. llTargetOmega on attachments in general has been quite broken ever since its introduction in SL 1.7, and it's been the bane of my existence. File those bug reports, people!

I've had demonstrated to me, though I haven't seen the script, a phusical object with llTargetOmega on it behaving differently to one without. I thought llTargetOmega was purely client side... is this not the case?

From the LSL Wiki entry on llTargetOmega:

Never actually tried this myself, so I'm not sure exactly what kind of behavior this exhibits. Sounds... interesting, to say the least.

I have found that -- at least in some cases -- calling llSetText() on a prim after calling llTargetOmega() can "nudge" it into behaving as expected...

see
/54/73/79278/1.html

So llTargetOmega on physical and non-physical objects are completely different operations.

Sounds like there's an opportunity for interesting experiments.

Hmmm. Setting lltargetOmega opposite to the rotational velocity...