Jump to content

Misbehaving weathervane


Rolig Loon
 Share

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

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

Recommended Posts

Here's an annoying one.  I made a simple sculpty weathervane for my roof about a month ago.  It works just fine, but for some odd reason  it has flipped upside down (+Z for -Z) four or five times since I installed it.  I've never seen it happen, so I don't know what conditions make it do that.  Any ideas?

default
{
    state_entry()
    {
        llSetTimerEvent(4.0);
    }
    timer()
    {
        vector WindDir = llWind(ZERO_VECTOR);
        if((llFabs(WindDir.x) > 0.1) || (llFabs(WindDir.y) > 0.1))
        {
            llSetRot(llGetLocalRot()*llRotBetween( <1.0,0.0,0.0> *llGetLocalRot(), llVecNorm(<WindDir.x,WindDir.y,0.0>) ));
        }
    }
}

 

Link to comment
Share on other sites

Second, I'd remove llGetLocalRot() from your formula.

But first, I wouldn't use llRotBetween() which doesn't work well in every situation.

 

default{    state_entry()    {        llSetTimerEvent(1.0);    }    timer()    {        vector wind = llWind(ZERO_VECTOR);        llSetRot(llEuler2Rot(<0.0, 0.0, llAtan2(wind.y, wind.x) + PI>));    }}

 My formula over here point the X axis of the prim toward the wind and I'm sure the prim will never turn upside down.

 

  • Like 1
Link to comment
Share on other sites

Aha... Good thought, Void. I hadn't considered that case.

Kaluura, I'll give your version a try. Thanks. I never would have thought of doing it that way. What do you mean by "llRotBetween() ... doesn't work well in every situation"?  Other than the fact that it always measures the angle that is less that 180 degrees between the two vectors -- thus making it hard to use if you want to get a compass heading, for example -- I wasn't aware of any situations when the function fails to work as advertized. 

Link to comment
Share on other sites

I wasn't necessarily avoiding it. I just wrote it the way that seemed most logical at the time.  Now I'm intrigued. Given the three options so far (llRotBetween, llRotLookAt, and Kaluura's method using llAtan), I can't see a good reason to favor one over the others.  What should I know that I am missing here?

Link to comment
Share on other sites

Now that I actually look at the code, my weathervane script looks a lot like Kaluura's suggestion, with the relevant line being:

llRotLookAt(llEuler2Rot(<0,0,llAtan2(wind.y, wind.x)>), 1.0, 1.0);

It's not obvious to me why llRotBetween() is unstable, so Void's explanation sounds as good as any I'd dream up.

Link to comment
Share on other sites

I tried to retrieve why I didn't like llRotBetween() and now I know. It introduce some parasite rotation on one axis which leads to object to go upside down when the vectors used in the formula are opposite like <1.0, 0.0, 1.0> and <-1.0, 0.0, 1.0>... but not <1.0, 0.0, 0.0> and <-1.0, 0.0, 0.0>. In other words, it's quite unreliable and I'm also starting to wonder if the vector returned by llWind() has always z == 0. If not, that explains the upside down bug.

As for llRotLookAt(), I think it's a bit overkill if the object doesn't use physics. llSetRot() is well enough to follow the wind.

 

Link to comment
Share on other sites

Interesting, Kaluura. I've been assuming that the vector returned by llWind always has its Z component == 0.0, although the wiki entry is dreadfully sparse and doesn't actually say so.  I'll try doing some tests to find out.

Thanks again.

Link to comment
Share on other sites

For what it's worth, I have had the following script running in test objects on two sims since Wednesday.

list SaveWind;default{    state_entry()    {        llSetTimerEvent(1.0);    }    timer()    {        vector Wind = llWind(ZERO_VECTOR);        if (Wind.z != 0.0)        {            SaveWind += [(string)Wind];            llSetColor(<1.0,1.0,1.0>, ALL_SIDES);        }        if (llGetListLength(SaveWind) > 100)        {            llSetTimerEvent(0.0);        }    }                touch_start(integer total_number)    {        llSay(0, llDumpList2String(SaveWind,"\n"));    }}

 So far, in over 500,000 sampling events it hasn't detected a wind vector with a Z component.  I suspect that wind is always horizontal in SL.  It was worth testing, though.

Link to comment
Share on other sites

Yeah, that's always true.  For right now, though, it looks as if wind in SL doesn't have a vertical component.....  not that it matters for my little windvane.  I'm using Kaluura's suggestion instead, so I don't need to test for a vertical component any more.  I was just curious.

Link to comment
Share on other sites

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...