What's the current state of llTargetOmega?

And is it worth trying to design something that's intended to last for a while, but uses this function? I'm interested in its behavior in child prims of attachments.

Right now I have it running in a test object (unattached), where 3 child prims have the rotation script, and the root has a 'tick' where it pings the children every minute and they call llTargetOmega again. I'll watch that over time and see if it keeps rotating.

I can see one issue already - it looks like one of the prims doesn't rotate unless my camera is close to it. Also, when I check the prim in the edit window, sometimes its rotation is changing, and sometimes it snaps back to 0. What's up with that? I thought targetOmega turned into real rotation only for physical objects. Mine isn't.

I guess the real question is, is it worth trying to find some kind of order/pattern here and try to work with it? Or is this behavior likely to be completely different in a couple of releases? I haven't paid much attention to the various ways in which this function has been broken over time, so I'd love to hear from someone who has a better idea than me.

Andrews office hour is tomorrow night. Simon & Sidewinder frequently show up, too. That'd be a good crowd to ask if changes are coming in that area..

I'm usually still at work during these things. If you happen to be there, I'd appreciate it if you ask

llTargetOmega makes a prim or object spin on the client side only! and different clients will probably see different things and there is no way to synchronize what they see. When nobody looks at it or is to far away to see, it is not spinning...or is it? I don't know

Andrew is one of the few that have friendly office hours..

"Tuesdays @ 11:00-12:00 and Thursdays @ 17:00-18:00"

I know somebody who's been going to the Thursday ones - I'll poke her to point him towards this thread.


I sorta thought that too but there were lots of problems getting llTargetOmega right when Havok4 rolled out. Not sure how it's related to physics but it definitely seems to be.

And unless I'm remembering it wrong, when you right-clicked the object and edited it, the rotating prims snapped back to their unrotated position. Today, I see it doing that sometimes, and sometimes it stops at a different rotation, both visually, as well as the numbers showing in the edit window. Is that new?

Ya... it's a good day if I've left work by 6pm

I have a few rotation scripts, now bear with me, I am not a scripting person at all, but my observation is that the 'simple' llTargetOmega script that doesn't use PI * 2 or whatever type of code always reverts back to the start position, the rotation code that does use PI * 2 etc in it sometimes reverts back to the starting position but not always.

Ok so I don't look like a complete idiot, I'll test this out in world and report back how much of the above is BS or not.

If you could post the simple vs. non-simple scripts, that would help too. I'm not sure exactly where the PI * 2 is applied to the function's parameters.

Sadly it's been that way for a while (months or maybe a year) based on my testing and reports of others. Same thing if you call llTargetOmega then subsequently stop it in the script, the object will sometimes snap back to its original position and sometimes not, and looking at the edit window seems to verify that the real rotation is actually different. But here's the weird part - if you have the object report its own rotation via llGetRot after the llTargetOmega effect stops, it will always report the original unrotated position, even if the numbers in the edit window say otherwise.

My comment at the time this cropped up was that LL has apparently stumbled upon a way to introduce quantum indeterminacy into SL, since the act of observing the results of llTargetOmega changes said results.


Oooh, that would be wonderful if there's indeed a way to predict when prims will snap back and when they won't. Do you mean using PI or some other constant as the rotation speed, rather than just typing in a number?

The "no rotation if it's far or moving slowly" effect is definitely a bug. RC11 has what's intended to be a fix for that, so you may want to see if your stuff behaves better seen through that one.

Ah, thanks, that's a good tip, I'll try it out. I'm 10 months into being a dad and still trying to find my feet, so I've really not kept up on what's going on with various aspects of SL development

My left eye has 4 rings in it that use llTargetOmega and just about everyone that looks notices it. And, I noticed with llTO, while an object if not physical the bounding sits still... But if it is, all the possible bounding, bouncing, and crawling is possible. I'm confused... If it really were client side, that shouldn't work... It seems to be working for me... What should it do when it's not working? (o.o)

One of my favorite sandbox mini-griefs is to rez a cube, set it temp + physical, dump my script with an insanely high llTO Y axis setting in it, and make about 20 shift copies. They scatter and fly like crazy and are really fun to sit on. (^_^)y

Have you ever seen the rings stop rotating? Or do they act fine every time you log on, through teleports, etc. etc.?

Maybe it works better if it's on an attachment... I guess I should try that as well.

Every time I've looked, they've been spinning. Add to that, they're set to spin a 4 different (and relatively low) speeds in two different axes... All contained in a 16-prim linkset. (^_^)

Oh... And if you visit my cookie jar in Ferguson, look at the ceiling... I have a decoration up there with nearly the exact same scripts as my eye... It's been spinning away ever since I placed it with no resets or pings. It will stop when selected, but will spin again once you let go. (^_^)y

Weird. The linkset I made today definitely stops on its own. I wonder if this is related to when the prim was created. That would be kinda freaky, but not entirely unbelievable.

I don't think it could be connected to creation date... My eyes and the spinner decoration were made well apart from each other. That would be totally surreal if it were true though. (o.o)

NEWay, I tossed ya' some stuff inworld just now. All the while watching my spinners spin... Feeling a bit woozy now. (@_@) ..... (^_^)y

Thanks. I'll take a look when I get home. Maybe it's your avatar's aura that keeps them spinning

According to the wiki, llto is client-side only for non-physical objects.

The llTargetOmega problem that came with the Havok 4 rollout was really a separate bug, the one where objects were staying selected even when they weren't really selected any more. Selected stuff doesn't move. Sadly, that was right around the first time all the server side parts of the function itself actually passed all the QA tests, so that little achievement sort of got buried.

I asked about this tonight at Andrew's office hour. One of the Lindens may (or may not - no promises) by stopping by to help or ask questions or provide details or tell us we're full of it. Not sure..

Although it wasn't really stated at tonights meeting, having an easy set of instructions to repro the problem or a simple object that demonstrates the problem is usually much appreciated. If you have such an object, and a Linden doesn't stop by this thread and you'd like me to raise this again at the next meeting, feel free to drop one on me, Ziggy, and I'd be happy to show it to them.

Also, BTW, thanks for ZHAO (I and II!!).


Yep. That was mentioned tonight. There _is_ some server side component to it, though I'm not going to pretend I understand how it works. Andrew (Simon?) did mention that there's some special-case code that pokes the interest list to make llTargetOmega work correctly. Maybe it messes with the bounding box, growing it to the point where it encloses all the rotations that the object will be going thru, so that it shows up on interest lists that wouldn't normally include the un-llTargetOmega'ed object. If that makes any sense..

Very interesting. I looked at Imnotgoing Sideways's spinner, and indeed, it spins quite happily. The difference appears to be in the spinrate. I changed mine to +/- 1, and now it's acting like his - visibly spins even if I'm far away. My original script had spinrates of +/- 0.1. If I change my spinrates back to 0.1, it goes back to the old behavior - the object _sometimes_ remembers to spin when I zoom my camera in. If I'm standing close to it, the 2 prims nearest me will spin but the furthest one won't.

So... this looks like target-omega LOD? I haven't tested to see if the behavior is also modulated by the size of the prims.

If someone else can test this and confirm, that would be helpful.

I just made a full-perms demo object, I'll drop it on some of you if you want. It's real simple though:

* Rez a cylinder, drop a script in that has this line in state_entry:

llTargetOmega(llRot2Up(llGetLocalRot()), 0.1, 1);

That makes it spin around its local Z axis.

* Make 2 more copies of this prim. If you want, change the spinrate to -0.1 in one of them.

* Rez a sphere. Link all 4 objects together so the sphere is the root prim.

* Move away a bit and watch what happens.

And thanks a lot for asking about this Are chat transcripts kept for these meetings?

Some are.. I don't see the one from his hours this week, though. Dunno if that means he didn't make logs or just hasn't gotten around to it yet.

http://wiki.secondlife.com/wiki/Andrew_Linden

OK, I built what Ziggy described. Under 1.19.1.4, movement is jerky even up close, and stops altogether after moving far away. It won't even reliably start back up moving again unless I relog.

Under 1.20.13, the movement seems to keep going smoothly even at a distance (threw on a striped texture to help see what's going on). So, it appears at least from here that the bug has been squashed.

ok ignore my post I was confusing two different scripts as having the same function.

however in the root prim, this script in RC 1.20.2+ does snap back to the original starting position on reset.

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

}