replacing the scripts does not seem to work for me either.

the exact same script works fine in a new prim - but items that have been rotating forever in my store - simply will not rotate.

i have lights from all the major club lighting creators and NONE of them are rotating :-O

.

Please fix this issue!

nothing seems to be able to get them rotating again

PLEASE MAKE SURE YOU VOTE FOR THIS ISSUE IN THE FAR LEFT BORDER

JUST POSTING A COMMENT MAY NOT BE ENOUGH TO GET THIS PRIORITIZED

(Currently 7 comments including the reporter and only 4 votes)
.

.

A SIm restart fixes the problem ))

.

A new prim is ok but if i edit it to move or rescale the rotation does'nt work again.

It's the same issue if the script is reset.

This append only in the sim France3d Guadeloupe

http://slurl.com/secondlife/FRANCE3D%20Guadeloupe/99/155/23

The scripts work fine in others sims.

ONE WEEK AND ALWAYS THE SAME ISSUE - MANY SOLDS LOST And we continue to pay fees !

If restarting the sim fixes the issue then I suggest that the Lindens do a rolling restart across the entire grid. I think the overall problem has to do with Havok4's structure somehow.

Given that llTargetOmega is a physics call when applied to objects that are physical (and a client-side only function in non-physical or phantom objects) my working conjecture is that this most recent behavior, which is distinct from behavior seen and reported in many, many Jira items of the past, has something to do with the update to Second Life Server 1.20.0.83892 during the week of 31 Mar 08. Unless the bug is spotted, I'd expect this to repeat again any time the physics engine is updated. It might also be that, as items rezzed under the old physics model, these items become irrevocably inactive until rezzed anew under the updated physics model. Thus far, none of the items that I have restarted by Shift-dragging new copies seem to have halted, and there was some suggestion in earlier efforts to address the random stoppages, in older Jira issues, that development believed they had spotted and fixed the issue in this recent update.

Reading comments here, though, it seems clear that the Shift-drag-copy workaround is not going to be available to all residents, where their permissions for an item might not include the Copy privilege. So I stress this is ONLY a workaround, not a resolution or solution, and only one that is relatively convenient to those with full copy permissions on objects that use llTargetOmega to create rotational and oscillating effects in client viewers.

Yup a restart is only a temporary fix.... Got a restart last week to get them going...Fine for a few days...Now once again rotation scripts not working...

UMMM...What does it take for an issue to be "assigned"? Apparently LL just doesn't understand that the fate of the entire Universe depends on properly functioning rotation scripts :-O

shakes head

Our place is a little dead atm, half the things I sell aren't working properly and this is unassigned. After all we saw last 2 weeks, for me it's time to reconsider future plans in SL. I love SL so much, but it is hurting.

This is a very big problem. Many many scripts use llTargetOmega, and many many of them are not working. PLEASE ASSIGN THIS ISSUE TO SOMEBDOY SO IT CAN GET FIXED ASAP!!

Hi:
I too suffer from this. All our rotating fish/sharks/ducks/sharks chasing ducks stopped working. I asked a Linden to restart the sim, and they've all gone back to working. According to someone on-line (Yes, slightly more reliable than reading tea leaves..) they will re-break in 16-20 hours.

I worry! The ducks need to keep their wits about themselves!
Thank you, Stimpy

Edit added:

Hmmmm, why is this just major?...should be a show-stopper !!!! And still un assigned!!!

IT IS INMOST OF THE THINGS I BUILD TO GIVE MOTION AND NOW — NOTHING ---- THIS IS SEVERE ENOUGH THAT I WOULD SAY STOP WHAT YOU ARE DOING AND ROLL BACK TO THE PREVIOUS SERVER UNTIL YOU GET THIS "LITTLE GLITCH" FIXED.... TAKING 500+ GLOBS OF PRIMS INTO MY INVENTORY AND THEN ATTEMPTING TO REZ THEM AT THE EXACT PLACE THE CAME FROM IS NOT ONLY FOOLISH IT IS A WASTE OF TIME. DELETING AND RECREATING THE SCRIPT DOESN'T WORK - WTF IS UP AND YOU HAVEN'T EVEN ASSIGNED THIS AS A PROBLEM??????????????????????????????????????? WHAT ARE YOU WORKING ON? CLOUD MOVEMENTS?

YOU NEED TO STOP LETTING YOUR DEVELOPERS DO THEIR OWN QA

AND YOU NEED TO STOP MAKING PEOPLE WHO ARE PAYING A LOT OF MONEY TO USE THIS BE YOUR GUINEA PIGS, OR AT LEAST I AM TIRED OF BEING YOUR GUINEA PIG.

I PAY A QA TEAM TO TEST MY RL PRODUCT BEFORE THE CUSTOMER SEE'S IT
SO THAT WHEN THE CUSTOMER DOES SEE IT THEY SAY WOW THAT IS GREAT,
NOT OH SH*t THEY F*CKED US AGAIN....

THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?
THIS IS A SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER SHOWSTOPPER THERE DID THAT GET YOUR ATTENTION?

I'm not with LL, but you might want to check other issues that are open and see if there are specific ones that involve those other functions you mentioned, besides llTargetOmega? Concerns about those other functions may get lost in the shuffle here; then again, this issue remains so vaguely defined in some ways, I would guess that most of these issues have been assigned under some other Jira item already.

@ harleywood guru 8 Apr

While I share your frustration over this issue, personally I'm not prepared to risk having my Jira mod privileges curtailed by bumping this up to a level that doesn't seen warranted to me personally. That said, anyone is more than welcome to edit the item and promote it to Showstopper status if you feel that's warranted. Don't be surprised if it gets demoted slightly, however, since Showstopper seems to be reserved for the stuff that prevents you from logging on at all, or crashing so hard that you decide to give up on SL entirely.

Since this issue was totally vague and contained no real repro info the devs could use until it was revised around 5 Apr or so, it shouldn't be a surprise that it hasn't been assigned to anyone yet. The all caps get tired real quick too. Hard to read for substance between the shouting. AND TO RESTATE, I FEEL YOUR PAIN and I'm off now to recheck whether my scripts have died yet again. Hearsay is fine to relay if you want no action, but the devs need solid first-hand observation of script behavior if they're to have any hope of squashing this. Btw, look at the related issue, please, the longstanding problems with llTargetOmega have been assigned, they just haven't been assigned under this particular issue. SVC-1461 reports a specific variant of this bug that deserves attention too. Unfortunately someone marked it resolved by claiming it was a dupe of this ball of vague confusion and complaint. I think I'll have to revert that now, since if I were a dev I'd probably stop reading this issue somewhere halfway down the comments.

You are forced to choose between the (for some) somewhat more stable and eye-candy-crap of the now standard "WindLight" viewer 1.19.1(4) with severe lag and malfunctioning physics, or use the older and buggier 1.19.0(5) with functioning physics. The latter is downloadable via the links in Pastrami Linden's blog entry http://blog.secondlife.com/2008/04/03/the-new-viewer-a-well-oiled-machine/ , which is the closest the Lindens will ever come to admitting that their baby the WindLight viewer is a total screw-up (by offering those emergency links to the older viewer).

Of course, content creators going back to 1.19.0(5) and seeing their things the way they should be, don't help those of their customers using 1.19.1(4) much, so the problem remains.

The re-pro is pretty simple, create this script & drop into an obj:
default
{
state_entry()

}

then wait for a day or two for it to stop moving. Unlike the old llTargetOmega bug we all know & love the new fail will not re-start on touch/edit/llSetText. The failure of the llMoveToTarget (for physical objects) appears to be related - fails at the same time and works perfectly fine after a sim re-boot. This may be a clue to what's causing the bug since I can't imagine why a client-side motion and a sim-side motion would fail together in this manner. It's almost as if the sim no longer updates the viewer with the objects status (that one should be displayed rotating and one should be moving to a given position). Physical objects don't seem to move at all, as if the sim has stopped attending to them completely.

I wish I could provide a clearer assesment of this problem but I have no knowlege of how the viewer & sim software is written. Someone from LL with a working knowledge of the latest sim release and access to a re-bootable sim needs to investigate this more fully.

This does NOT mean that we are unaware of it, and in fact know generally where the problem must be, but have had no luck so far in isolating the actual cause.

• • • Something that would help immensely ***
      A script or set of steps that would trigger llTargetOmega items to stop rotating, even semi-repeatably

Having that in hand would dramatically accelerate getting this one resolved. We are working on it, but are fishing in the dark until we can see how to make it happen...

Thanks,

Sidewinder

/Sidewinder

One more possible cause. Maybe some last minute changes in the Havoc code were made before it was pushed out? Clearly the scale on which it happens now is alot bigger than during the testing as you described.

1. I can offer an environment where the error reproduces itself consistently after 5-10 minutes instead of after 1-2 days (after "resetting" objects so rotation works temporarily), always in my viewer 1.19.1(4) but never in my viewer 1.19.0(5). The location is my sky planetarium at http://slurl.com/secondlife/Honawan/96/122/422 and the objects are the 0.5 m spheres used in celestial globes and 0.625 and 0.7 m sculpts in space dioramas. Please note that the prims in space dioramas (should) have own rotations independent of the rotation of the surrounding, larger spheres. Other prims have failed too in 1.19.1(4), but appear to need much longer time. Please note that this is in my viewers, since I suspect this problem may depend on the combination of viewer, server, cache and environment (after the response from cloud and Harleen). What may be special about my location is that it is extremely graphic heavy, with up to 300 heavy textures within 64 meters in the field of view simultaneously (yes, it lags in almost all viewers), probably messing severely with the viewer cache.

2. I don't know anything about how states are transmitted and cached in SL, but I know approximately how I would do it, so this is still pretty much a guess of what may go wrong: Server transmits the rotation state of an object to the client when client requests it (as part of the general loading or when refreshing), or when the server decides it's time to force a refresh. In the meantime it's cached in the client. If the cached state is lost from cache owing to some kind of timeout or the server not refreshing it upon client request, then I suspect the state is reset to a default involving no rotation.

3. Suppose the new server isn't as eager at pushing refreshs or answering refresh requests, or the new client isn't as eager at requesting refreshs or taking in pushed refreshes, and the cache isn't "rotated" as often as needed to force or accept refreshs before timeout, depending on the environment. Then the rotation state is lost. So, depending on the server, client (including settings like e.g. cache size, render distance), environment and avatar position/view/moving/rotating, the result may vary from user to user and time to time. Old server/old client worked (rather) well, old server/new client worked (rather) well during testing, new server/old client will work in some environments, new server/new client perhaps in fewer, and so on. At least I would start looking into these combinatory effects in communication server-client, rather than just server or client, if I had the tools, time and knowledge. That means probably both Sidewinder and Pastrami would be needed to solve this.

If needed, I can supply my viewer data and settings deemed relevant for both viewer releases I've tested.

Forgive me for asking a really basic question, but are the spheres in fact using llTargetOmega or do the rely on other functions?

I ask because llTargetOmega (in what's probably its most popular applications outside of vehicles) is strictly client-side when non-physical, while the other calls you mentioned before, in saying this is a viewer issue, are server-side issues to the best of my knowledge.

Not wishing to add confusing, but for the objects where I'm trying to observe this systematically – items that use ONLY llTargetOmega for rotation, I am seeing the same exact behavior in LL's 1.19.1 and 1.19.0 release viewers AND in the current OnRez viewer as well. This could suggest that the bug is somewhere in the interactions of my graphics card and the code driving the client-side expression of the function? But what I do know is that the items that were rezzed AFTER the 1.20 server code update at the end of March 2008, continue to work flawlessly, whereas items that I believe were rezzed before the server update continue ot function erratically at best. However, I can only confirm this is true in my Scamp parcel. I'm not convinced this holds for similar (but definitely not identical) items in Huineng. I chose to test in Scamp mainly because the items are all within easy range there, and there is a combination of ultra-simple llTargetOmega scripts (the ones that stopped after the server upgrade) and more complicated ones, where the scripts are fairly continuously active within their state_entry states, and their ongoing action confirms that they are still in that state when I observe them (without need to manipulate them or edit their scripts in some way)?

I guess part of what I'm asking here is, is it possible that some significant share of stopped rotations are happening due to the scripts functioning exactly as they are written? Would putting a timed reset in the problem scripts serve to refresh them and ensure that they deliver the desired funtions? Somehow I doubt it's that simple, and I expect if this is the answer to some of the problems there are yet more items where unanticipated state changes and non-existent error trapping are not the issues causing the failures.

I also note that there are items using llTargetOmega for their rotation in Scamp that I never noticed stopping, and I suspect the difference is that the ones that work are also cycling through other states on an ongoing basis, so that the script remains in the state where the llTargetOmega rotation was first called. One of my old conjectures about items stopping involved wondering whether they didn't stop after some visiting avatar touched, tried to sit on or otherwise took actions that might have changed the states. Since most of these rotations were located within a state_entry event, it seemed possible that some state change might override the existing TargetOmega client-side rotations, as state_entry does not seem to refresh in any way, unless other states conclude by explicitly refreshing. I'm tired so that is probably even more unclear than usual.

Anyhow:

Your description of the likely process sounds plausible (to an avocational, not professional programmer) – but given the documentation of llTargetOmega in the various LSLwiki's as a function that is almost entirely client-side (when used in non-physical objects, that is) this has always struck me as a somewhat "dangerous" function to use if you need to have some reproducible behavior in every single client who views the items. I've tended to use llSetRot and related calls when the project seems to call for something with entirely predictable and controllable behavior, even though that usually calls results in some "jerkiness" given the built in delays associated with those calls.

When I learned from some friends that their particular graphics cards did not seem to support the display of llTargetOmega rotations at all, this is when I made the decision to limit my use of the call severely. At least for purposes where i wanted to be sure that others were seeing something very similar to what I was seeing, once the scripts were debugged.

I guess my question is, in part, assuming these scripts DO rely entirely on llTargetOmega calls, do they:

1. Function as physical or non-physical items?

2. (for Sidewinder) Are there any particular approaches you think might lead to scripting that would serve this diagnostic aim? I'd like to help, but it would be useful to have some more specific ideas on where to probe for weaknesses that might be causing rotating prims to stop rotating. So far, I have yet to be present when I noticed any llTargetOmega script halt rotation while I was "in their presence" so to speak. (Another reason I suspect more viewer involvement than server involvement, except in the case of these most recent halts, whose behavior is very different from what I've observed for many months here.

http://slurl.com/secondlife/Scamp/9/14/141

The objects rezzed before the 1.20 server upgrade remain locked and unrotating, while post server upgrade copies continue to rotate. No changes seen for llTargetOmega items that did not break during 1.20 server upgrade.

System details:

Second Life 1.20.0 (84432) Apr 9 2008 03:59:09 (Second Life Release Candidate)

You are at 286317.1, 265694.7, 81.8 in Huineng located at sim5051.agni.lindenlab.com (8.2.32.52:13004)
Second Life Server 1.20.0.83892

CPU: Intel Pentium 4 Northwood (3049 MHz)
Memory: 1023 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: RADEON 9700 PRO
OpenGL Version: 2.1.7412 Release
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14308 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 108/35394 (0.3%)

}

*FIXED*

Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release)

You are at 260130.0, 248374.4, 30.7 in Hazzard County South located at sim4301.agni.lindenlab.com (63.210.157.205:13005)
Second Life Server 1.20.0.83892

CPU: Dual i386 (Unknown) (2000 MHz)
Memory: 1024 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
Graphics Card Vendor: Intel Inc.
Graphics Card: Intel GMA 950 OpenGL Engine
OpenGL Version: 1.2 APPLE-1.4.56
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14319 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 54/38675 (0.1%)
Viewer Digest: 92099704-0ebc-4c6f-0916-223f535ad48f

However, I also created a number of cubes, with sizes from 0.1x0.1x0.1 to 1.5x1.5x1.5, after the server update, using the same script but written as new, to test any size dependency, and they all keep rotating. So the problem may have to do with something being stuck with older creations, even if they're re-rezzed, reset or rescripted. The cubes rotate around their vertical axis though, which I have seen earlier seems to be more robust than rotation axis not aligned with a major world axis.

I re-open this issue since it is obviously not solved.

Are All Rotating:
------------------------------------
Second Life 1.20.0 (84432) Apr 8 2008 21:02:50 (Second Life Release Candidate)

You are at 193144.7, 314300.8, 26.2 in metropole extrem north located at sim2214.agni.lindenlab.com (216.82.16.219:13015)
Second Life Server 1.20.0.83892 CPU: Dual i386 (Unknown) (2000 MHz) Memory: 1024 MB OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 Graphics Card Vendor: Intel Inc. Graphics Card: Intel GMA 950 OpenGL EngineOpenGL Version: 1.2 APPLE-1.4.56 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14321 (Mozilla GRE version1.8.1.13_0000000000) Packets Lost: 0/1329 (0.0%)

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) You are at 193142.7, 314289.8, 21.5 in metropole extrem north located at sim2214.agni.lindenlab.com (216.82.16.219:13015) Second Life Server 1.20.0.83892 CPU: Intel Core Series Processor (1662 MHz) Memory: 1015 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: Intel Graphics Card: Intel 945GM OpenGL Version: 1.4.0 - Build 4.14.10.4436 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15020 (Mozilla GRE version 1.8.1.13_0000000000) Packets Lost: 507/33588 (1.5%) Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release)You are at 193144.7, 314300.8, 26.2 in metropole extrem north located at sim2214.agni.lindenlab.com (216.82.16.219:13015)Second Life Server 1.20.0.83892 CPU: Dual i386 (Unknown) (2000 MHz) Memory: 1024 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 Graphics Card Vendor: Intel Inc. Graphics Card: Intel GMA 950 OpenGL Engine OpenGL Version: 1.2 APPLE-1.4.56
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14321 (Mozilla GRE version 1.8.1.13_0000000000) Packets Lost: 385/158435 (0.2%) Viewer Digest: 92099704-0ebc-4c6f-0916-223f535ad48f

Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release) You are at 260127.4, 248379.9, 30.8 in Hazzard County South located at sim4301.agni.lindenlab.com (63.210.157.205:13005) Second Life Server 1.20.0.83892 CPU: AMD K7 (Unknown model) (1342 MHz) Memory: 1024 MB OS Version: Microsoft Windows XP Service Pack 1 (Build 2600) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: RADEON 9800 PRO x86/MMX/3DNow!/SSE OpenGL Version: 2.0.6747 WinXP Release LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14297 (Mozilla GRE version 1.8.1.13_0000000000) Packets Lost: 0/2577 (0.0%) Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

Didn't Rotate:
--------------------
Second Life 1.20.0 (84432) Apr 9 2008 03:59:09 (Second Life Release Candidate) You are at 193148.4, 314297.2, 26.2 in metropole extrem north located at sim2214.agni.lindenlab.com (216.82.16.219:13015) Second Life Server 1.20.0.83892 CPU: AMD (Unknown model) (2000 MHz) Memory: 2047 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600 GT/PCI/SSE2/3DNOW! OpenGL Version: 2.1.1 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14321 (Mozilla GRE version 1.8.1.13_0000000000) Packets Lost: 237/81659 (0.3%)

Soo in conclusion its an "Second Life 1.20.0 (84432) Apr 9 2008 03:59:09 (Second Life Release Candidate)" Bug for WIndows XP users.

I have some wind turbines which have been affected by this issue: http://slurl.com/secondlife/Native%20Lands/38/14/23

At the moment they are all rotating fine, but this is because we rezzed some new ones. The others we tried to reset and to use the script above and were unsuccessful. Since the Havok4 rollout we have had several people contact us that they've stopped working, and since we sell them no-mod no-copy, they don't have a way to fix them.

Considering that, and considering that non-phys llTargetOmega is client-side, I'd be tempted to say that it's a client-system interaction problem. That would also (as some have stated) explain why some of us are seeing this, and others are not. It would also explain why resetting/recompiling/new scripting the object would not work.

edit to add...

when i try to edit the piece (which is just a lot of linked prims - each prim has a texture animation script and a rotation script in it) I get the following script errors.. i get 2 ,one from one of the scripts and one from the 'object (-0.00,0.05)'

PERMISSION_TRIGGER_ANIMATION permission not set
Object: Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set
Object: Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set

PERMISSION_TRIGGER_ANIMATION permission not set
Object: Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set
Object: Script trying to trigger animations but PERMISSION_TRIGGER_ANIMATION permission not set

interestingly only the originally rezzed one does this, I did a shift drag and the new one doesn't generate the errors.. but still doesn't work

For me rotation does'nt work in one sim and works fine in 2 others

I put here the about sl txt

The region where it is not working :

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

You are at 265313.3, 305821.6, 22.7 in FRANCE3D Guadeloupe located at sim3589.agni.lindenlab.com (216.82.22.70:13005)
Second Life Server 1.20.0.83892

CPU: AMD (Unknown model) (2209 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14326 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 154/422417 (0.0%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

The 2 regions where it works :

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

You are at 265684.1, 305490.0, 23.1 in FRANCE3D Saint Barth located at sim2572.agni.lindenlab.com (216.82.18.69:12035)
Second Life Server 1.20.0.83892

CPU: AMD (Unknown model) (2209 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14326 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 154/430401 (0.0%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

and

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

You are at 264675.4, 306716.2, 22.0 in FRANCE3D Courchevel located at sim4229.agni.lindenlab.com (63.210.157.133:13006)
Second Life Server 1.20.0.83892

CPU: AMD (Unknown model) (2209 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows Vista Service Pack 1 (Build 6001)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14335 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 49/164042 (0.0%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

It's the same results with the 1.19.0 (5) wiewer and windows XP SP2

I also note that in the sim who has problems there are many hudges prims around.

NON - ||TargetOmega SCRIPTED OBJECTS STOPPED ROTATING. !!!!!!!!!!!!!!!!!!!!!!!!!!

OMG :-O

This bug is SOOOOOOOOO RANDOM !!!

On my main SIM I have many objects with rotation scripts..... These objects were made by three (3) different creators.... This morning, approximately 50% of each type of object from each of those creators has stopped rotating [O/O]...... The other half is fine........

Two days ago ALL the rotating objects there that had the ||TargetOmega scripting stopped working but worked fine again after a restart..

AND!!!!! Today, One type of the objects that stopped rotating DOES NOT USE THE ||TargetOmega scripting !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

The objects that don't have the ||TargetOmega scripting that stopped working today are the very latest club lights... During the week I spoke with the creator about the bug. I noted that as of that time none of his lights that I own had stopped rotating while all the others had. He informed me that when he designed them he decided NOT to use ||TargetOmega because he felt there were too many issues with it.

sO wHAT nOW ??? [o/0].

[

1.) I'm seeing the exact same thing on Windows Vista and on Mac, so this doesn't appear to be platform specific.

2.) The physical objects I have that stop moving still have active scripts. Specifically, when I touch the object I still get the pop-up menu the script generates. I can put the object in 'sleep' mode and the lsl command llSetPrimitiveParams does move the object to it's sleep configuration.

It still appears that the server is not sending llTargetOmega status and is not updating physics movements. Why does this work fine after a reboot (usually for days) and then fail seemingly all at once?? Neighbors Sim looked fine, but come to find out she had just re-booted as well.

• • • My Windows Vista Config:
      Second Life 1.19.0 (5) Feb 28 2008 17:18:12 (Second Life Release)

You are at 273940.2, 256534.3, 24.6 in Second Wildlife located at sim3261.agni.lindenlab.com (216.82.20.250:13004)
Second Life Server 1.20.0.83892

CPU: AMD (Unknown model) (2294 MHz) <<<--- **Acer w/AMD Athlon x2
Memory: 1791 MB
OS Version: Microsoft Windows Vista (Build 6000)
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI Radeon X1250
OpenGL Version: 2.0.6845 Release
LLMozLib Version: 1.1.0 (Mozilla GRE:1.8.0.12_0000000000)
Packets Lost: 710/64321 (1.1%)

We have confirmed that this bug is server-side so we won't be needing any more client-side setup info.

This bug is currently being worked on.

have just logged back in and around 80% of the previously non working rotating prims are now rotating. I can edit them as a linked object or by editing a linked part and they still keep rotating.. and the error message from last night has vanished.

now if only the other 20% would work..

hmmm just went back for a looksee and about 80% aren't working now... but my alt (who just happens to be standing beside me) can see the original 80% still working..

i'll be around for a bit if anyone is interested in a look.

object is non-physic in this case.

tx Oh

seriously anyone have any info about this problem

thanks

apart from LL still working 9 - 5 monday to friday while all their infrastructure crumbles around them?? it's not a problem for them. I can't wait to see April's metrics.

There is sanity code already in the SL simulator that tries to scan for lost selections but if this really is a selection bit leak then it would appear to not be working correctly, or else is not aggressive enough and waits too long.

BTW, I think that when shift-drag-copying... the object that is moved and remains selected is the original, and the one that remains in place is the copy. You should be able to verify that by adding a script that does certain things on_rez().

Effectively, i looked at the objects count on 3 parcels in my sim and i saw :

Total prims = 7000
Owner/group = 690
Selected/Sat upon = 6310

If I do a "Shift-drag-copy", the selected count increase and the object don't rotate.

RE: "The best way to verify this is probably to pay attention to the "selected objects coun in the parcel object tallies. "

YUP

At the moment rotation scripts are not working for me on 2 sims.

In one sim I have 198 rotating objects (198 rotation scripts). I am currently showing 1402 selected or sat upon with no one in the sim.

In my other sim I have only 14 rotating objects. Only 3 of those are currently not working BUT I am showing 2014 sat upons or selected with no one in the sim....Curiously ,if I drag select all of the 12,000 prims i have in that sim, I show only 6,000 as being selected or sat upon .

.

.

I'm not sure what this tells me, but it seems like the viewer just isn't getting the updates, so it's likely the simulator isn't sending them. Some optimisation gone wrong perhaps, to avoid sending updates repeatedly?

it's also interesting that on the ground the rotations work but 100m up and they don't..

Still broken.

What is iinteresting is that one object cntinues to work correctly, even though it is based on the same scripts as otehrs that break over and over again.

If a Linden wants to come and look, I can show both the broken and unbroken versions.

Also thank you who ever borked the in worl dbrowser to not display or accept muse clicks without resizing it....

It still works under 1.18.5.3 open source.

Nothing on my land will rotate or move for more than a couple hours, same as everyone is experiencing with the llTargetOmega issue. It would appear to be selection bit leak as suggested.

Unfortunately I have the opposite. I sell a rotating dance base and the one in my 700m high skybox shop has been rotating happily for months yet all the ones in my other shops at ground level have to be kicked into action every day. This is getting a pain and causing unhappiness with customers.

• I seem to get about 3 days of normal server operation
• When things stop moving they seem to all stop nearly at once (very odd)
• Objects do appear to be selected, however selecting them and unselecting them does not clear the state

I have yet to see just a few objects on my sim affected by this - it's either all or none so far. I'm inclined to believe that the server is changing this 'selected' bit rather than people selecting/sitting on objectsand the selection not getting cleared. Perhaps something is causing the scan to erronuously change the state of objects? The sim next door is also needing a reset every 3 days, both sims freeze up with this bug within hours of each other since we reset at almost the same time each time we see objects stop.

Keep up the good work Kelly, we're all anxious to see this fixed soon, and thanks to Andrew & Sidewinder, etc. for escalating this. Cheers!

http://slurl.com/secondlife/Butzbach/67/173/28

All of the following stop working at the same time

scripted physical
scripted non physical
NON scripted physical

and in the NW corner (i think) There is a 7Seas fishing spot ... the fish cease ALL animations.

I repeat. ALL of these things quit working at the same time

A sim restart is the only cure available in this situation.

Random issue requires constent monitoring ... Irritating way to add 20 min to my morning routine

Sim-info:

Second Life 1.19.1 (4) Apr 9 2008 11:57:21 (Cool SL Viewer)

You are at 286321.4, 278153.6, 140.2 in Stinkhorn located at sim4211.agni.lindenlab.com (63.210.157.115:13006)
Second Life Server 1.20.0.83892

and here:

Second Life 1.19.1 (4) Apr 9 2008 11:57:21 (Cool SL Viewer)

You are at 262426.9, 230158.7, 70.5 in Yamma Yamma located at sim2957.agni.lindenlab.com (216.82.19.200:13004)
Second Life Server 1.20.0.83892

on ground and in +500meter height

In all three places it only happens on non- physic prims, not linked to any other prims. In 2 prims are the same scripts: one text hovering script, the rotation script and (since 1 day) a texture changing script. But the texture changing script isnt in conflict with the other two scripts, the bug happens before aswell. It seems one item (my tip jar in my shop; linked and scripted with several scripts) is imune to the disappearing hovering text bug but susceptible to the ||TargetOmega-feature..erm bug of course. It happens several times that the tip jar stops rotating but the text is still up but at the other two prims both happends... stop rotation and hovering text disappeared... that could be a help... maybe

We have done some work to clean up and tighten up the selection logic in the simulators. This should fix most cases of this issue. The fix will not be in the planned patch for this week, but should be in the next simulator update after that.

Isn't it remarkable that the llSetText bug happens exactly to the same time with the ||TargetOmega (suddenly not rotating and no text) in the same prim??? For me (of course im not a professional) it seems both bugs have the same problem with something in the HAVOK4 architecture. But i will open a new jira... smiles

Update:

ok... have seen the thing about the fix.

The more distant are the objects linked, ie the moving object far awy from the rotation center, and the less they have mass, the more likely they are to rez unlinked

Someone pointed it out in the first comments, but it looks like forgotten - may it partly explain the relationship between this phenomenon & havoc?

We all had to use some tricks to create non-simplictic moves - like making prims switching physical / non-physical, using llTargetOmega & llMoveToTarget to get the move, and so on. One of the issues is you cant sit on a child prim rotating, if linked to a main rotating too- it stops the rotations immediately. So when I see the objects described as "selected-sat upon" in the region, it may explain why they stop. Could maybe explain the broken link too, as "sit" is adding a "task " (ty Kelly) in the link.

Hope it helps... I would not like to be condemned to live in a world of static objects...

my problems with rotations started about 3 weeks before this release - around the same time i went through a period of this warning popping up whenever i went to delilah. It started with one rotation script not working and an inablility to set tp co-ordinates and have them work properly - they'd send me off in all kinds of directions except where i wanted to go. At first i thought it was just that bug about the object needing to be at 0,0,0 for the tp to work , so i fixed that, then i found that a texture was set to 90 degress to i set that back to zero.. after each of those the tp behaved fine for about a day then began to play up again.

it didn't start to behave itself until that warning message on landing went away.

Then there was the release and of course it's all gone haywire.

this may not have anything to do with it as i've also tp'd to another site where my rotations aren't working and it's on a different sim to delilah but the same sim version as koss..

so this may have muddied the waters or it may not. I just know that for a critical bug this has been outstanding for waaaaay too long without resolution.. particularly since it's not gone in this weeks fix and there's been no indication here when the next one goes in after that.

The nature of the bug means that a server restart will fix it temporarily.

Seriously, if we could fix this, it would rock! ^_

but if i set the spine rate to 0.01
that's not move....

Is the a probleme of variable precision somewhere ?
a decimal lost in any calculation... rounding the value to 0 ?

I have found in some sims, (including my own,) TargetOmega will not work at all, except for a brief period following a region restart as Kelly has pointed out.

In other sims what Zeja said about 1 or 0.1, but never 0.01, is true.

And in most sims I visit now TargetOmega seems to be working just fine, yet in all 3 of these cases the Server versions are now all the same. That is the part that is getting me...

If server 1.21 has been deployed and the sims I visit regularly are now all running on that version, why would 3 completely different results be occurring?

Kelly, any updates on the situation?

as of 29-Apr-08, llTargetOmega() continues to malfunction.
worst of all - its behavior is inconsistent.

for the purposes of this posting, "objects" refers to any/all objects that utilize llTargetOmega()

FEW objects behave the "old way" – single-prim: start/stop OK; multi-prim: start but can't stop
FEW objects work better! – single- AND multi-prim: start/stop OK
FEW objects refuse to rotate at all. NOTHING will coax them into rotating
SOME objects will not start rotating until sat upon!
MOST objects will rotate for a bit, then jitter for a short period, then stop; then can sometimes be restarted but the restart never sticks

i will say this: i see this new nastiness most often where the prim using llTargetOmega is a child.
and you want a live, repeatable example? come to http://slurl.com/secondlife/Mephilo%20Tor/29/165/701 and look at the "Galleries" banner.

all the objects i've been working with were created before Havok4 deployment

oh – i should add this: the bad behavior of llTargetOmega seems unaffected by the 'physics' status of the object

i'll post my tech details but DO NOT let that fool you. i continue to see the outlined issues on every Mac and PC system i have.

Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release)

You are at 283171.7, 267426.4, 701.5 in Mephilo Tor located at sim2978.agni.lindenlab.com (216.82.19.221:13000)
Second Life Server 1.21.0.85745

CPU: Dual i386 (Unknown) (2400 MHz)
Memory: 2048 MB
OS Version: Darwin 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce 8600M GT OpenGL Engine
OpenGL Version: 2.0 NVIDIA-1.5.24
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14774 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 49/335914 (0.0%)

If the number is off base then the issue I believed to be fixed is not fixed.

However, the behavior seen seems different enough that this is probably a different issue. (various states of non-spinning, child prims more than non, spin some then stop etc vs the old "they just don't spin") If this is the case I will probably resolve this issue and create another issue titled something like "llTargetOmega still not working right" and move some of these latest comments over there.

So ... how does that selected / sat upon count look?

• Kelly

I will point people at: VWR-5895 which does appear to be a separate issue pre-dating this one.

Additionally I have noticed that any rotation change where the magnitude of the resulting vector is less than 0.1 will not cause an update (and thus you won't see the change). I'm going to adjust this down to 0.01. I hesitate to move this any lower because we send this information at various quantization levels (32bit, 16bit, 8bit) and anything much lower will cause spurious updates - besides the movement being almost imperceptible anyway. This should fix the bug where llTargetOmega(<1,0,0>,X,1.0); would not update when X was less than 0.1 (but still only if X is greater than 0.01). There is already another bug for that ...... I just need to find it but thought I would update those watching this issue.

• Kelly

Thanks Kelly for fixing this, I can't tell you how great it feels to have things running normally again!

http://slurl.com/secondlife/Wallaby/232/226/54

The selected/sat upon numbers are correct.

I have a vendor with 16 prims that should rotate, and a large prim that rotates just fine. The 16 prims are linked, the large prim is separate. If I go into edit mode, select the 16 prims then close the edit window, they start rotating. For a minute or two, then they stop. If I shift/drag the vendor, the copy left behind starts rotating, again for just a minute or two.

This has been going on for over a month now. It's driving me crazy!

Have created single prim with script included, aslo second single prim with script including llSetText as mentioned elsewhere, and I still have the same problem of no rotation in viewers RC5 or RC6.

Current sim is latest sim code 1.21.1.86182. But also have this same problem on other sims across SL, all supposedly running latest sim code.

This non-rotation also applies to all purchased rotating items as well as own creations, so it discounts an error in the script I am using.

And yes Kelly ... Slected/sat on count is correct.

Sorry for additional edit. system info:
Second Life 1.19.1 (4) Apr 2 2008 11:59:37 (Second Life Release)

You are at 262619.1, 256951.9, 27.9 in Iaconelli located at sim2820.agni.lindenlab.com (216.82.19.63:13001)
Second Life Server 1.21.1.86182

CPU: Intel Pentium 4 (Unknown model) (3000 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8500 GT/PCI/SSE2
OpenGL Version: 2.1.2
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.15038 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 0/22516 (0.0%)
Viewer Digest: bb2966f6-cf81-a0de-1e21-dcd21f05428a

SL Hubby not having the same problem with rotation even though using same release candidate !!! Strange ????

There was a server update just a short time ago, yes? When the server code was patched to remove the ability to create larger than 10x10x10 prims? Perhaps the problem snuck back into the server at that time?

Again, this is the same problem I experienced before with this issue, which seemed to be fixed when this issue was originally fixed. It is not simply objects no longer rotating, rather that is just the most immediately noticeable effect. And there it is not simply child prims no longer rotating. It is entire objects. Also, prims scripted to move when clicked, such as doors, no longer work. These are single prim doors.

The problem can be, however temporarily, fixed by selecting the object, and shift+dragging a new copy. The same temporary fixed which worked for this issue.

Ah, perhaps I spoke too soon. Those broken items I had not fixed seem to have fixed themselves in the time I took to write this Jira comment. I would say it is still an issue, though it would seem the problem only lasts some minutes before self correcting?

Again, others noticed the objects functioning again at more or less the same time.

The problem seemed to last maybe 5 to 10 minutes or so.

All right I know what this is and it is related but not quite the same bug. Or it might be more accurate to say that part of the fix that was done made the case you saw only last ~5-10 minutes instead of until the region restarted.

It isn't perfect and Andrew has some ideas for improving it, but I'm not sure when that will happen.

Essentially our selection logic relies on a correctly working viewer - which all of ours are - that lets the simulator know when things have been deselected. Some 3rd party apps or viewers however don't always bother with that step which leaves the objects acting as if someone was selecting them. We currently clear all their selections when they log off or leave the region .... however if they don't leave the region cleanly (and hey, they already weren't cleaning up their selections) then it can take the region a few minutes to realize they are gone and clean up.

:-/ Not really great. Unfortunately I don't know when or how we will be able to address this particular case.

• Kelly

http://wiki.secondlife.com/wiki/LlTargetOmega_test

However, the test results are unsatisfactory with jerky and spasmodic rotation and sometimes non-rotation in both tests. This occurs only after a few minutes. Sometimes if I relog it is ok for a while.

I have also searched the forums and the solutions there are confusing and some redundant since server upgrades seemed to have affected rotation scripts and needs to be clarified.

The end result I am really after is like "Test 2".

-Meta

However, the end result of this is that really the selected stat only seems relevant if:

• A physical object is selected.
• The person selecting the object is allowed to edit the object (there is no advantage in having regular residents able to stop other people's elevators etc.)

For this reason wouldn't it be better to have the selection behave more like:

• User selects object.
• Viewer checks if object is physical, if so it informs the simulator.
• The simulator checks if the user is allowed to halt that object (are they a member of the group or the owner?).
• If the person is allowed then the simulator halts the object.
• The simulator then gives the viewer a polling time (P).
• The viewer must now send selection updates every P seconds, or send a deselected message.
• If the simulator receives the deselected message, or has not received an update after 2P seconds then it deselects the object automatically.

I can think of ways to accomplish the primary goal (only halt objects if the selector can edit them) that are much simpler than your description of the behavior. I mean, it is surely possible to do it without changing how the viewer and the simulator talk to each other.

I just received a report from a customer that a rotating object wasn't working although it was working fine a few days ago. I checked up on it and it was working for myself and a third Avi standing nearby but not for the customer. He was using 1.20, I haven't heard of anyone else having issues with the new viewer so far, but figured I'd post a heads up since I was able to confirm llTargetOmega was working for my configuration. The 3rd person was also reportedly using 1.20, so this could be hardware related (is this possible?) I've posted our operating data below...

------------------------------------------------My Config:
Second Life 1.19.1 (4) Apr 2 2008 12:03:24 (Second Life Release)

You are at 156797.6, 282494.7, 77.4 in Wet located at sim3097.agni.lindenlab.com (216.82.20.86:13002)
Second Life Server 1.23.4.93100

CPU: Dual i386 (Unknown) (2330 MHz)
Memory: 2048 MB
OS Version: Darwin 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386
Graphics Card Vendor: ATI Technologies Inc.
Graphics Card: ATI Radeon X1600 OpenGL Engine
OpenGL Version: 2.0 ATI-1.4.58
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17381 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 165/7150 (2.3%)
Viewer Digest: 92099704-0ebc-4c6f-0916-223f535ad48f

------------------------------------------------Customer's Config:
1.20.15 (92456) Jul 18 2008 10:58:42 (Second Life Release)

You are at 156687.5, 282468.1, 22.7 in Wet located at sim3097.agni.lindenlab.com (216.82.20.86:13002)
Second Life Server 1.23.4.93100

CPU: Intel Core 2 Series Processor (2194 MHz)
Memory: 2040 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: Intel
Graphics Card: Intel 945G
OpenGL Version: 1.4.0 - Build 7.14.10.4704
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.17382 (Mozilla GRE version 1.8.1.13_0000000000)
Packets Lost: 1/67451 (0.0%)

DRD

I'm surprised this issue still occurs. It's been fixed for me for about 6 months at least.

This happens very quickly and every single time.
When the boat is not moving the fishes seem to be doing fine.

Before doing so, however, please look at the about land, Objects tab and see how many items are 'Selected / sat upon''. The current expected behavior is that items that are selected stop moving, including their llTargetOmega rotation. Items can get "stuck" in this state due either to a bug, someone actually selecting them, or a poorly behaved bot that is still in the region and selecting a lot of things. The base behavior here (that items stop moving when selected by anyone) is already under review to be changed, but I do not know when that will happen.