Jump to content

llTargetOmega broken?


Dekka Raymaker
 Share

You are about to reply to a thread that has been inactive for 4084 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :(

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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. (o.O)

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

 

 

Link to comment
Share on other sites


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.  

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4084 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...