Wont detect its new owner

When i transfer my helicopter with follow script it wont recognize its owner when he speaks on channel 0

rotation rot;
vector fwd;
vector pos;
default
{
    state_entry()
    {
        llListen(0,"",llGetOwner(),""); //This is set to listen only for the owner on channel 0
    }
    listen(integer channel,string name,key id,string message)
    {
        if (message == "stay")//This is the trigger message change the "go" to change the trigger.
        {
       llSay (0,"Roger That Holding this position");  //This is where you put the event thing .
        }
        //You can have a second message by adding something like this:
        if(message ==  "go")
        {
        llSay (0,"Roger Following flight leader");
    llSetVehicleFloatParam(VEHICLE_LINEAR_FRICTION_TIMESCALE, 0.1);
    llSetVehicleVectorParam(VEHICLE_LINEAR_MOTOR_DIRECTION, ZERO_VECTOR);
        }
        if(message == "shoot")
        {
                    rot = llGetRot();
        pos = llGetPos();
        fwd = llRot2Fwd(rot);
        pos += fwd;
        fwd *= 50.0;        // The ammount of force to push the object with

        llRezObject("missile", pos, fwd, rot, 0);
        }
        if(message == "help")
        {
            llSay (0,"Made by Hero Jimador");
            llSay (0,"say: go to make the heli move");
            llSay (0,"say: stop to make the heli stay still");
            llSay (0,"say: shoot to fire");
        }
    }
}

It just dosnt pick up the commands , but when i say it, it does the commands.

You made a common mistake with your use of llGetOwner. You put it in state_entry, which only gets called once, it doesn't get called again if you give a copy to someone else and they rez a new copy. So the script still remembers you as its owner. This is covered in the Wiki:

http://secondlife.com/badgeo/wakka.php?wakka=llGetOwner

The solution is explained in the Wiki too:



I follow this advice, and almost always put an llResetScript inside on_rez. That makes it so that state_entry is called every time someone rezzes a new copy, and then my listeners are set up correctly.

You can also go to Tools>Recomplie Scripts In Selection and that will work

Another nice addition is a changed event, one that's not all that well documented for some reason:

changed(integer c)
 {
 	if ( c & 128 ) // No constant for this one, I don't know why.
 	{
 		llResetScript(); // OR you could remove the old listen and install a new one here. Options, options!
 	}
 }

Heh, I think making this mistake is a scripter's rite of passage, like trying to fly and bumping into everything (ok, I still haven't outgrown that...), or how everyone ends up wearing a box on their head the first time they try to buy new clothes in SecondLife.

You've probably got it figured out now, but just for nostalgia's-sake (and because I just noticed it was EXACTLY one year ago to this date), here's me asking the same question and a few different solutions...

Over here

Jillian, nice snippet about detecting ownership change... Need to remember that!

If you don't want to reset the script when giving it to a new owner -- ie: and lose some persistant state/variables -- you can just remove the listen filter with llListenRemove and re-add it with llListen, using something Jullian's change event. According to the Wiki, the filter for the owner will be refreshed with the current owner.

In other words, llListen filter events are persistant. So doing llListen (0, "", llGetOwner(), "" causes the key for the current owner to be pushed to the listen filter chain, which doesn't get updated to the new owner even if that changes. (Push by value and not by reference, in other words.)

Of course, that means you have to track the handle for the listen event, which can be unwieldy if you have a lot of listens. So, using llResetScript() in on_rez() is the simplest way.

It's good to track the listen handles so you can turn them off when not needed.

The change owner event is actually a nice way to do it, even if you then pick llResetScript() - and there are certainly items that you don't want to reset willy nilly.

Multiple listens are general a bad thing™ - two tight listens ("on" and "off" say, with llGetOwner() too) might be better than one and an if statement on channel 0, but one looser listen is probably better than more than 2 listens under just most circumstances, as it avoiding channel 0 listens etc. Given that you're not that likely to be handling too many listen handles.