llTargetOmega stopped working

my train set is suffering the problem at Accapulco (Second Life Server 1.19.0.79136) , when i click it the smoke starts but i then have to right click it and select touch for the rotation to start.

It is because the sim fails to send a correct prim/object update when the omega is changed, so the client just keeps spinning the object. As Andrew Linden said in the SVC-54 JIRA:

"This looks like a simulator "interest list" bug and I suspect I've already fixed it in one of our internal code branches."

He did fix it, but apparently someone came in behind him this last update, and "unfixed" it.

Yay SCM!

Naah, I used our internal job tracking stuff.

Anyway, see the blog

all lsl functions are processed by the server, so by default any lsl function failure is server related... even for client side effects (like no physics target omega) they are first handled by the server and the information is passed to the client. if it passes bad information the client side effect never starts.

The Rolling Restart yesterday helped, but DID NOT entirely fix the problems with llTargetOmega. for an example see the swing on my land at:

Qinglong 168, 73, 48

The version of this bug that I saw was with a rotating dance pole. It'd be going fine for a bit then stall. I'd give it a right click and it'd start spinning again for a minute then stall again. Not sure how that relates to the interest list. Maybe a change to the dance animation does a partial update and forgets some of the target omega stuff.

Anything that's viisble on a residents screen, IMO, could be a bug on either side - could be that the server-side is sending the wrong (or incomplete) info or it could be that the client-side isn't doing the right thing with it..

Either way, I don't see it any more and am happy.

Submitted JIRA
SVC-1461

Just out of curiousity, if you change the script to do something like this, does it still have problems?

float gDirection = 0.5;
default
{
	state_entry()
	{
		llTargetOmega (<0.0,1.0,0.0>, gDirection, 1.0);
		llSetTimerEvent (2.0);
	}

	timer()
	{
		gDirection *= -1.0;
		llTargetOmega (<0.0,1.0,0.0>, gDirection, 1.0);
	}
}

Meade - The changes you suggest make it FAIL even worse. It tends to keep rotating in the same direction with only momentary periodic swings the other direction. Thank you for the suggestion though.

Really? Hm.. How about this?

float gDirection = 0.5;
default
{
	state_entry()
	{
		llTargetOmega (<0.0,1.0,0.0>, gDirection, 1.0);
		llSetTimerEvent (2.0);
	}

	timer()
	{
		llSetTimerEvent (0.0);
		gDirection *= -1.0;
		llTargetOmega (<0.0,1.0,0.0>, gDirection, 1.0);
		llSetTimerEvent (2.0);
	}
}

Meade - The last one fails in a similar manner to the first one. I'm going to let the Lindens sort this out. It may take them a while, but it was working before last weeks server upgrades.

THANKS

I found a fix for my train by simply adding a zero seconds sleep , now works fine

      llTargetOmega(<0,0,-0.1>,PI,1.0);
      llSleep(0);
                
CODE

It's just another dupe of this same problem set, as described in SVC-54.

One fix I have used it to call llTargetOmega 2 times with different small values.

For example to stop a target omega do:
llTargetOmega(<0,0,0.1>,1,1);
llTargetOmega(<0,0,0.0>,1,1);
or call on: llTargetOmega(<0,0,0.0>,1,1); 2 times

But to start it again do something like:
llTargetOmega(<0,0,1.8>,1,1);
llTargetOmega(<0,0,2.0>,1,1);

You must incriment the starting again in steps or the viewer will not notice it and it will remain stopped unless you right click edit it. The right click edit is not practical by any means.

This will work as it still works in my products.

Its a little bit of a mickey mouse type of fix but it does work.
If you put a timer or a llSleep between the events it will also help fix this for you.

-Cherry Hotaling

This seems to be broken for me at the moment - in the same way people are describing. Did this issue ever get fixed?

Yes, but the fixes had another bug that broke it again.

This is known to LL and they are "working" on it. That probably just means that someone will stamp [RESOLVED](tm) on it and go for a latte.

HURRY LINDENS! I got tired of replacing the tons of rotation scripts on my land every day!


Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 282022.7, 258275.1, 50.6 in Koko located at sim2703.agni.lindenlab.com (216.82.18.200:12035)
Second Life Server 1.20.0.83892

The latest from Kelly Linden in the latest blog entry is that she thinks they've found the new problem. It's not that llTargetOmega is really broken, it's the other bug that things are sticking in that selected/sat upon state (and selected objects don't move). So at least now they know what to fix =)

Good, I thought it was me going crazy...
I've had to duplicate most things with rotating scripts but it's odd that not everything stopped working as some of the rotating scripts still worked. Yes, it's the exact same script in the same sim about 5 meters apart...odd.

Which blog entry did he say this in? So many lately..

It's in the comments for the rolling restart entry,

http://blog.secondlife.com/2008/04/14/rolling-restart-wedthu-april-1516-for-121-server-deploy/#comment-597249

I've tried adding a llSleep(0); line to my rotation scripts, but it doesn't work. Nor does resetting the scripts. I have to go in and click-drag copy every prim or prim linkset that contains a llTargetOmega function, then delete the copy, to get the rotation to restart.

This is very frustrating...

While llTargetOmega is rendered client side it actually is a prim setting much like the title. You can add a script that sets the roataion and then remove it and the prim will continue to rotate. When an object that is rotaing with llTargetOmega is slected it stops rotating while selected, I guess this is to make it easier to edit it, right now that selection does not go away once you no longer have it targeted so it does not restart the rotation. Also for some reason object seem to be being selected even if they are not selected at any time. I hope this helps explain a little about why even resetting the script does not help, the object remains selected so the script can not start the rotation.

Read the JIRA SVC-1910 , it explains this somewhat and the Lindens are very aware of the issue. They hope to have it fixed this week with an update.

http://jira.secondlife.com/browse/SVC-1910