llTargetOmega broken?

[Dekka Raymaker]

I use llTargetOmega in quite a few of my art / objects, but very recently once started they do not stop whatever I do, just continously spins in my viewer.

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

    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
    }
}


I use viewer 1.23.5 because I do not have an intel version mac, is this my problem or is it a problem on all viewers?

[Qie Niangao]

I'm confused.  Did something ever work differently?  The "omega" of llTargetOmega is a rate of rotation, so what it means to set a target is to make it start spinning at a rate that it will maintain until the target is changed or nulled with another call to that function.

[Dekka Raymaker]

If I select 'Set scripts to not running in Selection', then 'Reset Scripts in Selection' previous to the past week, the object would stop spinning in my viewer, that doesn't work now.

I got my partner to try "Phoenix Viewer 1.5.2 (1102) May 14 2011 18:19:22 (Phoenix Viewer Release)" and she is experiencing the same problems.

I will try resetting the sim and see if that may help.

 

A sim reset did not solve the problem

[Qie Niangao]

Yeah, I don't think it's viewer-side, but I'm frankly surprised that it should ever have worked as you describe.  That's not to say it never worked that way; I'm often surprised by which prim parameters respond which ways to events such as having the script removed, or then being shift-drag copied.

(As it stands now, the effect of llTargetOmega() is not propagated through shift-drag -- which is how I remember it always working -- but persists after the script is removed -- which I thought I remembered working differently at one point.)

If something has indeed changed, perhaps it's related to the recent introduction of PRIM_OMEGA, although as far as I know, that was (is?) deployed only to the BlueSteel RC channel, in late June.  No idea if that's been promoted to the main release channel now or not.

I'm sorry this isn't very helpful.  Can only hope somebody else has some actual information.

[Rolig Loon]

PRIM_OMEGA has been working on my sim for a while now, and it's not Blue Steel.  I think is has been propogated across the whole main grid, but I could be wrong.

ETA:   And both llTargetOmega and PRIM_OMEGA persist after shift-drag and after removal of the script. (But not after shift-drag of a rotating prim from which the script has been removed.  That is, if you shift-drag and the script is in the prim, the copy works fine.  If the script is removed, the original still works, but the copy doesn't.  As I recall, that's the way it has always worked for me.)

[Imnotgoing Sideways]

I actually just ran in to this.  Techinically, llTargetOmega sets a prim state which in my opinion should persist.  The fact that it died on script-halt was something I always percieved as a bug. (>_<)

Though, in making a spinny-thing project this past week, I noticed that a script reset didn't yield sitting still.  My reflex was to add a 'scrubber' line in state_entry() as llTargetOmega(<0.0,0.0,0.0>, 0.0, 0.0); ... Which in my point of view should have been necessary all along. ()

Dunno.  While I do see it breaking certain content, I welcome it with open arms. ()

 

 

[Qie Niangao]

---

And both llTargetOmega and PRIM_OMEGA persist after shift-drag and after removal of the script. (But not after shift-drag of a rotating prim from which the script has been removed.  That is, if you shift-drag and the script is in the prim, the copy works fine.  If the script is removed, the original still works, but the copy doesn't.  As I recall, that's the way it has always worked for me.)

---

Well, but AFAIK the only way the still-scripted shift-dragged copy works is if the script executes llTargetOmega() again in the copy, as would be the case if it's called in state_entry().

I'm quite willing to accept that it always worked the way it does now, but Dekka is reporting that there's been some change.  

[Rolig Loon]

---

Qie Niangao wrote:

---

Well, but AFAIK the only way the still-scripted shift-dragged copy works is if the script executes llTargetOmega() again in the copy, as would be the case if it's called in state_entry().

---

Yes, exactly.  I should have said that.  llTargetOmega does have to be in state_entry.

[Dekka Raymaker]

for me if I remove the script it does stop rotating. this is a pain for me, I probably have hundreds of builds with this script in, but I will have to work around it now.

[Dekka Raymaker]

Well yes Qie, there is a definate change, I have been using this script since mid 2007, my work rotating work needs amending occassionaly, I guess I just have to remove the script now, amend the build and add the script back in. Thanks for everyones comments.

[Void Singer]

there has been weirdness with omega for a while.... it doesn't persists without a script but when stopped by script it has shown some weird behavior.... some clients won't see the stop if they are minimized, or on a different desktop (linux) when the stop or removal happens, but all clients should see it stopped if the enter the region after it's stopped.