Rotation script - limiting range

[GloriaGlitter]

Hi all - I have a script that was originally used to give realistic movement to a pigeon.  I have a mesh receptionist avatar object (not animesh) that I've put this script into so that there is a little bit of movement for her rather than her just standing static.  So with this script she can rotate 360 degrees which means sometimes she has her back to visitors.  I have been trying to adjust this script so that she only turns in say a 90 degree arc (i.e 45 degrees either way of facing forward).  Is it worth trying to edit this script or start from scratch.  I am not too bad at scripting in general but find it hard getting my head around rotation functions.  Thanks

rotation temp;
integer delay = 72;
integer count = 0;
integer switch = TRUE;
float rnd = 1;
float z;

setLocalRot(rotation rot)
{
    rotation localRot = llGetLocalRot();
    rotation parentRot = llGetRot();
    
    localRot.s = -localRot.s;
    parentRot = localRot * parentRot; //Order of ops important here.

    parentRot.s = -parentRot.s;

    llSetRot(rot * parentRot);
}

default
{
    state_entry()
    {
        z = 0;
        llSetRot(llEuler2Rot(<0,0,z>*DEG_TO_RAD));
        //setLocalRot(llEuler2Rot(<0,0,0>*DEG_TO_RAD));
        llSetTimerEvent(0.0);
        llSetTimerEvent(0.7);
    }

    timer()
    {
       
        
        if(switch) {
            rnd += -rnd;
            switch = FALSE;
        } else {
            rnd = (llFrand(2) - 1);
            switch = TRUE;
        }
        
        float x = rnd;
        float y = rnd;
        
        z += (llFrand(20) - 10);
        
        if(z > 360) { z -= 360;}
        else if(z < 0) { z += 360;}
        
        setLocalRot(llEuler2Rot(<x,y,z>*DEG_TO_RAD));
       // float t = llFrand(5.0) + 3;
       // llSetTimerEvent(t);
    }
    
    on_rez(integer start_param)
    {
        llResetScript();
    }
    
     touch_start(integer total_number)
    {
        llResetScript();
    }
    
}

 

[Qie Niangao]

This is a very odd script, and probably much more complicated than you need for this. Maybe it's the pigeon ancestry, but I'm not sure why it's randomly tilting in x and y by tiny amounts, nor why it's using a user-defined "setLocalRot" function instead of llSetLocalRot... nor, for that matter, whether the object is actually linked to anything such that llSetRot wouldn't suffice. 

What if the timer did simply:

      llSetRot(llEuler2Rot(<0, 0, llFrand(PI)-PI_BY_TWO>));

?

ETA: Sorry, that was misremembering the request, so it moves +/- 90 degrees. For +/- 45 degrees, I think the calculation would be more like llFrand(PI_BY_TWO) - (PI_BY_TWO/2.0)

ETA 2, much later: Oh, hehehe, I bet this goes in her head, so it spins around a little on her neck and nods a tiny bit. In that case, yeah, I'd try llSetLocalRot and put in some tiny llFrand() values for the x and y coordinates, too. Trial and error here, but I'd see how it looks with those two dimensions varying independently -- separate llFrand calls -- instead of always by the same amount in the same direction as the "rnd" variable does now.

Edited August 8, 2020 by Qie Niangao

[GloriaGlitter]

Hi Qie - thanks for your replies.  Just working with your ETA1, it does rotate +/- 45 degrees but the incremental steps are too big at the moment and so the object moves too fast through the rotational changes.  I was looking for much smaller steps (like in the pigeon script above) as if the avatar object was just shuffling around.  Yes, re your ETA2 you're right about the tiny x and y values as I wanted the avatar object to slightly tilt back and forth as it rotated enhancing the shuffling impression.  At this stage I was going to apply it to the whole object but once I can get this working I might try to have a separate head and body as you suggested.

[GloriaGlitter]

As an experiment, I tried changing these lines in the original code:

  if(z > 360) { z -= 360;}
  else if(z < 0) { z += 360;}

to

  if(z > 45) { z -= 10;}
  else if(z <-45) { z += 10;}

So far it seems to work ok - is this a possible solution to my original question?

[Qie Niangao]

Seems promising, yeah, now that I understand better what's intended. (Personally, I think I'd still try llSetLocalRot instead of the homegrown function, but maybe I'm still missing something.)

In passing, I'm kinda intrigued by whether there's an intuitive explanation of how those z angles will be distributed, with the up to +/- 10 degree steps over a +/- 45 degree range. I don't think it's a uniform distribution, but short of running a simulation, I wouldn't know what to expect.

[GloriaGlitter]

Hi Qie - thanks for your input.  I think the +/- 10 degree steps only kick in when the rotation position goes past the end points i.e. more than 45 or less than -45 in order to bring the object position back into range.  It seems to work quite well - my low prim mesh receptionist almost looks like an animesh model.  It does look like the 'home grown' localrot is a bit of an overkill and I'll have a go at simplifying it as you suggest - on the other hand why fix it if it isnt broke

[Qie Niangao]

Yeah, that's how those ±10° degree steps work to get the range back to ±45°, together with the fact that the result of llFrand(20)-10 is also constrained to ±10° at most... and I'm glad it's working well.

What I was mumbling about was that the 45° range is different from the 360° before: that "correction" was just to restate the result back into the range 0 to 360, so for example 365° gets restated as 5° -- the very same angle. With the 45° range, though, the formula sorta "bounces off" the ends of the range. My hunch is that this results in a kind of bimodal distribution, with angles near -40° and +40° occuring more often than other angles, but personally I'd need to run a simulation to confirm that whereas somebody else might have an intuitive explanation for what distribution to expect.