script disabled due to llRotLookAt

The following script on a default cube repros my problem.
After a short time the script changes state so it is no longer running ... it does not get a script error - though it will if I reenable it. The script error it get's on reenable is 'Math error'.

I know this is directly related to the last two values in llRotLookAt. Changing those values changes how long the script will run. Since I don't know how to determine acceptable values I don't know if I am delaying the problem or avoiding it.

The suggested values of '1/2 mass' & '1/10 str' don't provide any rotation. So while that may not crash, it is not useful. I have a more compilcated script that repros the same problem after working for a long time, so I know that verifying that it works the first n times does not mean it will work then n+1'st.

Here is the output up to turning off:
AA Repro: Test llRotLookAt
AA Repro: Rotate+move 0
AA Repro: Rotate+move 1

integer b;
integer i=0;
vector pos;
default
{
    state_entry()
    {
        i = 0;
        pos = llGetPos() +<0,0,0.3>;
        llSetStatus(STATUS_PHYSICS|STATUS_PHANTOM,TRUE);
        llMoveToTarget( pos,0.2);
        llSay(0,"Test llRotLookAt");
        llSetTimerEvent(1.0);
    }

   timer()
   {
        vector erot;
        vector target;
        if (b)
        {
            erot = <0,0,TWO_PI>;
            target = pos; 
        }
        else
        {
            erot = <0,0,PI>;      
            target = pos + <0,0,0.3>;
        }
        b = !b;
        rotation rot = llEuler2Rot(erot);
        llRotLookAt(rot,0.3,0.3);
        llMoveToTarget(target,0.2);
        llSay(0,"Rotate+move " +(string)i++);
    }
}

yeah, there is something seriously buggy with the rotations. i have a little helper who follows me around, and matches my orientation, it will go for random amounts of time before producing the same probelm you have run into, i.e. the not working, and if you try to recompile it gives a math error. I gave a copy to doug 'the ladies' man' linden about a month or so ago, not sure if he has made any sort of head way on it though...

I have had problems with physics-enabled objects with llLookAt crashing and wigging out physics for the whole sim. I gave the object to Andrew "supa fly" Linden and also filed a bug report. Haven't heard anything aboot it since.

Hmm, I guess all of these problems happened after 0.7 was pushed out? I guess we had fixed a few bugs related to llRotLookAt in the 0.7 release (I think), and I guess assumed that things were working OK, then.

I'll have a go with the script here, and see if there's anything obviously busted going on...

Nada and Wednesday, are you still having problems with your scripts on the current build?

- Doug

Totally guessing...

I'm wondering if your code is breaking at the euler conversion...have you put a whisper immediately following that line to see if that is in fact where it's breaking (so it's not getting to the rotlookat line)? I have a couple of thoughts regarding what might be happening here.

If the above test passes...have you tried setting the tau and strength to a computed value instead of the hardcoded float, a la the docs...

"½ the mass of the object and good damping values are less than 1/10th of the strength.".

One last thing...there was a post a while back about using timerevents to update positions. Under a value of about 2 seconds people said it was inconsistent; the reply was that the subsystems run async. Have you tried just opening up the timer to say, a value of 5, to make sure that your not seeing an error related to this behavior?

Also something I'm curious about...do physical + phantom objects suffer any oddities?

For sure post 0.7. Seeing as it was totally boning physics for the whole sim and people were getting mad at me, I was waiting for something to appear in the release notes before trying it again.

Possible hint: The rotation was totally in the X-Y plane (no Z component), and sometimes the object would take the long way 'round to get there (say, turning 350 degrees ccw instead of 10 degrees cw). So maybe there's something weird with the math there.

yup still dying, i busted it out to show hamlet the other night and it died maybe 30 seconds afterwards. i am using a sensor script, on 5 second intervals to detect my position, that uses a move to target to get to a position that is offset of mine, and once it is their, it then rotates to look at me. values for the tau and strength are both set to llGetMass()... i will drop working box, if i can find one, on you doug.

Mr WG, andrew is most definately 'supa fly'!

I have had repeated problems with some of the flying objects I've created that have llRotLookAt in them, I haven't been entirely sure if thats what caused the problem though. The scripts would just die and refuse to run after a period of time.

I'm curious though, has anyone tried to mod(as in A % B) the rotational values so that if your turning in a circle it doesn't continuosly increase (such as to 1000+ degrees) and are you always using the llEuler2Rot, has anyone recieved the same problem using just Quarterions(the standard rot) and not having to convert?

mine doesn't convert.

Can you post the line that determines your positition and rotates to it from the offset movetotarget position?

In response to Tcoz's conjecture:

I first experienced this on a follow-me object I was building, so the event was in a Sensor callback. In that script I guarded all events with exit/leave llSay's. The script was turned off between events.

That script did use computed values rather than hardcoded values. I also tried precomputing the values and sticking them in globals in case repeated llGetMass calls were causing the problem.

I also tried minimzing the calls to llRotLookAt, and llMoveToTarget. I can say that when the script was heavily delayed due to a larger number of llSay's in the sensor callback, it took much longer for the bug to repro, but it still did very consistently.

I haven't tried it with timings as long as 5 seconds - mainly because that would be of no use to me . However I can say it is actually turning off the script rather than the problem of the update not being rendered on the client.

I don't know if physical + phantom objects have oddities - it is really cool/creepy when it rises out of the floor at me though. And I like not running into it as it hovers over my head. Also - I believe this still repros without the phantom bit set.

Oh - other random information ... scripts in sub-objects continue to run correctly when this script gets turned off.

What there ever a resolution to this?
Did Doug ever find anything?

heh totally forgot about this thread. hey goodwil, here is the lines of code.

sensor(integer a)
{
     vector pos = llDetectedPos(0);
     rotation rot = llDetectedRot(0);
     vector offset =<-1,0,0>*rot;
     pos+=offset;
     llRotLookAt(rot,mass,mass);
     llMoveToTarget(pos,.3);  
}

since the object is always behind the owner, i can just detect the rotation of said owner and match it.