I checked back today (43 hours after rez, and 3 hours after the region restarted due to rolling restarts) and my test object still appears as it did initially.

Maestro Linden I have to wonder if there is perhaps a difference with the region you tested the object on vs the ones we are using.

I have to ask since with two full regions that I have been helping to run for several years this particular issue is definitely something we have noticed since July of last year and effects new and old items alike regardless of creator. It should be noted that I have observed that this also effects items in which only the root prim has been scripted (no other prims are scripted in the linkset).

I'd be more than happy to show you several effected objects on the regions I help run if you would like, though I do not have open access to all of these as some were purchased from stores like Jian and Schadenfreude. Some of the effected items are ones I created myself several years ago and indeed do have open access. The common thread with all of the effected objects appears to be the use of llTargetOmega and the fact that they used to work without any issue or alteration whatsoever. As I stated previously I had to add an extra script to these items to keep them running, which I did in July of last year as a work-around.

It might be a good idea to check if it might be possible that the script and prim loads on the region are having some sort of adverse effect on llTargetOmega, though I attempt to keep my script loads fairly light on the two regions I help with. Both regions I am assisting with are full 30k regions currently running Second Life Server version 2025-03-14.13862207703 with multiple copies of the effected items rezzed across the region. Not sure if any of that is potentially effecting it but figured it was worth noting.

Since I do happen to have multiple copies of some of the effected objects rezzed out I wonder if that might be part of what is causing the issue since not all copies are necessarily effected at the same time.

Please feel free to reach out if you would like to see some of the items I have rezzed out that have exhibited this issue. I am also more than happy to post the code in the script I have used to work around this to some degree. In the mean time I will place a few of these items that are not fixed with my workaround to examine as well, perhaps a recent change has fixed the issue given restarts were just done yesterday. I hope so because having to add a script to work around this is not ideal in the least.

llTargetOmegaFix Written by Certified Lunasea

This script causes the object to bounce 0.01m up and down several times every other second to fix issues with llTargetOmega first noticed in July 2024.

default

{

on_rez(integer start_params)

{

llResetScript();

}

state_entry()

{

llSetMemoryLimit(4096);

integer i;

for(i = 0; i < 360; ++i)

{

vector my_pos = llGetPos();

if(llGetUnixTime()%2 == 0)

{

llSetRegionPos(<my_pos.x, my_pos.y, my_pos.z+0.01>);

}

if(i > 358)

{

i = 0;

}

llSetRegionPos(my_pos);

}

}

}

Maestro Linden please also ask others to look at it since it is a local thing and not everyone sees the same thing at the same time. Some will see it spinning and someone else won't, and vice versa. Also different operating systems and different viewers all see the same problem because I have had friends look at it Some customers are reporting the problem and I'm giving refunds and unlisting items. I don't want 1 star ratings because of it.

Items I bought in 2008 that use the script are now suddenly not working - a flying seagull.

I am on a homestead, if that helps. Many of my items use the script like fish swimming in a circle.

Please don't give up on it unless we have an alternative rotation script.

Certified Lunasea: If you have a live object that you can modify, could you try adding a script like this to it to see if the object is spinning as far as the server is concerned? The output _should_ match the parameters that were set in the most recent llTargetOmega() call.

I'm asking because it's possible that this is a viewer bug, since llTargetOmega() is a purely viewer-side effect on non-physical objects. Another thing to note is that llTargetOmega() is a property of the object (much like color) rather than a property of the script; objects should continue to appear to spin after the script is gone.

Rezzed out some copies of the effected objects without my workaround script applied to them and I was again able to observe this issue. All 3 items I rezzed stopped all circular motion, but all other animation functions in use continued to work.

This continued to be the case until I relogged at which point all 3 items appear to be moving in a circular motion again. Due to this the issue may not be with the call itself but with the rendering code in the viewer I am using, so further testing might be necessary to see if it is just one viewer or if others are effected. Unfortunately that testing is difficult given the random nature of the issue observed.

I will give your script a test and see what it does if I can get it to replicate again since if it is a viewer issue then the viewer developers need to know about it and fix it. That said I will need to make modifications to it as the behavior will revert to normal if the object is put into edit and then released, which is another indicator that it may well be an issue in the rendering pipeline on the viewer in use. For this reason I have put in a 1-3 minute (60-180 second) timer and have the report message run within the timer event, and I also changed the report message llSay call to the following:

llRegionSayTo(llGetOwner(), 0, "PRIM_OMEGA appears to be " + llList2CSV(llGetPrimitiveParams([PRIM_OMEGA])));

Certified Lunasea I'm using the latest Firestorm Viewer and a friend is using the pre PBR Firestorm Viewer and we both see the same problem but not at the same time, if that helps. I'm pretty sure I tested it with the Official SL Viewer and also experienced it.

Reid Parkin I am using Firestorm 7.1.11.76496 myself, which is the release for PBR features and mirrors and such if I remember properly.

That said there have been instances where both I and my wife saw the same objects stop rotating at the same time while those I saw unaffected appeared the same to her as well. Given I am using a self-built desktop with a wired connection and she is using an off-the-shelf laptop via wi-fi and both of us have different settings even when using the same viewer software it doesn't feel exactly right to call it strictly a viewer or client-side issue just yet as I think more testing is definitely better in this case. Having more data points to compare is awesome in cases like these after all.

In any case I will continue to test the objects I have set out, they haven't stopped again for me so I am still waiting for the outcome of the test with the modified version of the script that Maestro provided as I am quite interested in what the results might be.

After several days I still have not seen the objects freeze again. I am not sure what is causing it to occur but have tried leaving the region and teleporting to several others before returning, logging out and back in, rapidly moving between locations within the region, and teleporting between different regions or moving to the adjacent region.

I have used both high and low draw distances and then repeated these tests with no effect in the last few days.

It should be noted that while it does appear to be a viewer issue when it is only being reported by a individual users, and especially since llTargetOmega is a client-side effect, it also has some characteristics of having some server-side component when it is triggered as multiple avatars can see the same effects on the same objects while other copies of those same objects may be completely unaffected and are also able to be viewed as such by multiple avatars. Add to this the fact that even with the script I made to work around the issue it can still exhibit itself for several minutes even with the user being able to see the bobbing effect that workaround creates. This is why I am reticent to simply label it as a client-side/viewer issue entirely.

I can report that the region has continued to see the object with the modified test script in it as rotating the entire time it has been running, and given the lack of results over several days I am not sure it will do any good to keep running these tests.

As it stands your average user that purchase an item that should rotate and sees it stop doing so randomly will think that these items are broken and may request refunds and/or leave bad reviews on said items.

With that said It may be a good idea for LL to look into the viewer code to attempt to determine what is causing these failures in the first place, and what causes them to stick in place. Especially since effected objects can have this effect persist even when an object is removed from view and well outside draw distance, or after teleports to one or more far separated regions, which shouldn't happen given these objects should need to be re-drawn by the rendering engine at that point. My question at this point is if it would be possible to have the viewer check the prim properties of items in view and cache those properties as well so that in cases of failure they can be properly restored without user intervention?

Certified Lunasea Thanks for the info and testing. I just logged in and found the one with your patch script is still working, and the one without your patch script was not. So I touched it to get it working again, then I logged out and logged in and it had stopped working again.

If you are interested in seeing my test items here's the URL

I have 3 out to test.

Logged off and back in and only the one with your script is still working, the yellow. Maybe I'm not using Maestros script properly. I'm not a scripter.

Maestro Linden From the Inventory Library.

default

{

state_entry()

{

llTargetOmega(<0,0,0.2>,PI,1.0);

}

}

Maestro Linden

The rotation script works fine when there is nothing linked to it (or maybe also with no scripted object linked to it).

The child prim has the following script to give flapping bird wings

integer total_sides;

integer link_counter = 3;

string face_direction = "forward";

default

{

on_rez(integer start_param)

{

llResetScript();

}

state_entry()

{

llSetTimerEvent(0.10);

llSetAlpha(0.0, ALL_SIDES);

llSetAlpha(1.0, 0);

llSetAlpha(1.0, 3);

}

timer()

{

if (face_direction == "forward")

{

llSetAlpha(0.0, link_counter);

link_counter++;

llSetAlpha(1.0, link_counter);

}

if (face_direction == "backward")

{

llSetAlpha(0.0, link_counter);

link_counter--;

llSetAlpha(1.0, link_counter);

}

if(link_counter == 1)

{

face_direction = "forward";

}

if(link_counter == 7)

{

face_direction = "backward";

}

}

}