Rotation script TargetOmega not working
under review
Reid Parkin
TargetOmega rotation script stops working randomly when linked to a scripted child prim. Use a prim with basic rotation script from inventory library and attach a scripted prim with an alternating texture face changing animation script as used for flapping bird wings. Check it for a day or two. I can send it to you, if necessary.
Log In
Certified Lunasea
I can confirm this issue as well. I experience the same issue with multiple scripted objects. Some of them I created and others which have been purchased from others. All of these objects were running fine for years and then suddenly stopped rotating intermittently.
Placing them into edit and then closing the edit floater seems to allow them to resume rotational motion but they stop again at random intervals.
I was not about to sit online watching these scripted objects for hours so I made a script to cause them to bob up 0.01m and down to their previous height every 2 seconds or so to force a positional update in an attempt to patch the issue. Unfortunately this isn't working so great since even with the extra script in place the objects sometimes get stuck for a bit (sometimes for as long as a minute or two) before they again resume their rotational motion. This really needs to be fixed.
Reid Parkin
I just found that if I log out and log back in it has stopped. I just tried this.
Maestro Linden
under review
Thanks for sharing the scripts. I've rezzed 2 prims and placed the scripts in them. As expected, the linkset is rotating slowly for now, while some of the child prim's faces flicker between transparent and opaque. I'll check back over the next few days and see if it stops rotating unexpectedly.
Maestro Linden
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.
Certified Lunasea
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.
Certified Lunasea
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);
}
}
}
Reid Parkin
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.
Maestro Linden
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.
default
{
state_entry()
{
llSay(0, "PRIM_OMEGA appears to be " + llList2CSV(llGetPrimitiveParams([PRIM_OMEGA])));
}
}
Certified Lunasea
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])));
Reid Parkin
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.
Certified Lunasea
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.
Maestro Linden
needs info
Hi Reid, could you please attach a minimal version of the script in question?
Reid Parkin
Maestro Linden From the Inventory Library.
default
{
state_entry()
{
llTargetOmega(<0,0,0.2>,PI,1.0);
}
}
Reid Parkin
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";
}
}
}