Discussion: Listen not working for new owner

I found that people are running into a problem..when they give objcts away or sell them new owners cant use the commands..here an answer!

Just copy and past this into your scirpt

    changed(integer change)
    {
        if(change & CHANGED_OWNER)
        llResetScript();
    }

One less comparison:

for attachments:

attach(key id)
{
   llResetScript();
}

for other stuff:

on_rez(integer params)
{
   llResetScript();
}

Not only resets listens in state_entry() when you have a new owner, but also convienently helps block against a lot of general errors that occur when a script runs continously for a large amount of time without a reset.

-Kokiri

Actually, going back to the root of the problem... Its caused by people storing the owner id in a variable, often at state_entry. Resetting the script can be a pain, especially when storing stuff in the variables. Instead, either cause the state to reset somehow, or just get out of the habit of storing the owner's id at state entry, instead do something like...

attach(key id)
{
   owner = llGetOwner;
}

Assuming the variable used is called owner, lol.

Not really Ayrn, the issue I believe Guitar is addressing is listens, so really the way to approach this would be to use:

integer listen_handle;

nnResetListen()
{
    llListenRemove(listen_handle);
    listen_handle = llListen(0,"",llGetOwner(),"");    
}

default
{
    state_entry()
    {
        nnResetListen();
    }

    on_rez(integer pass_param)
    {
        nnResetListen();
    }
    
    attach(key attach_target)
    {
        nnResetListen();
    }

    changed(integer change)
    {
        if(change & CHANGED_OWNER)
        nnResetListen();
    }
// ... rest of code
}

remove attach and changed events. those are both triggered AFTER the object is rezzed so on_rez alone covers it. Personally id get rid of rez/attach because if you change on new owner the listener will be keyed to that owner for the duration of ownership.

Randomly asking the server to deschedule and reschedule speech handlers is a waste of resources.

And Aryn:

its generall not the storing of the owner uuid thats the issue. Far more often its people who call llListen keyed to the owners UUID in state entry and then give the object away with the listener only keyed to the creater and not to the new owner. The only time saving the owner key is an issue is when the scripter is at least knowledgeable to already be trying to restart the listen event at some interval but forgets to update the uuid to the new owner.

Oh yeh, I was getting muddled, lol. What I posted below was what I thought a few weeks back until I realised it wasn't the case, I seem to of regressed a bit since.