Object ownership not transferring

Dang weird, but I've now seen it happen twice, and others have told me they've seen it too.

Last night I was working on an object for somebody; a scripted belt. Very simple; three listen commands, with llListen(0, "", llGetOwner(), "" set up. My name or explicit key was not tied to the object in any way.

I finished the item, acquired it, put it on the ground, put it up for sale, with buyer modify/copy off. The person I was building it for bought it, acquired it, attached it, and tried the commands...nothing. I tried speaking the commands, and it worked.

We both logged on and off, she put the object down and reaquired it. No good, it still recognized me as owner. I had to create another copy of hte object with llListen(0, "playername", "", "" to get it to work, the item would just not let go of me. I actually prefer this technique since it means the object will only be good for that one buyer, but this was an easy one so I'm not really guarding any deep dark secrets. No multiple states, not even a custom function. Very simple script.

I've been told the issue can be remedied if the new owner resets the script. That means giving modify rights

I saw this same problem in Nexus Prime while working on an object with Bel (the object would not recognize me, it continued to recognize Bel as the owner), and Elzar has told me he's seen it too.

Silly question: Where are the calls to llGetOwner? Scripts in inventory maintain some state, and the state_entry event might not be being called when the new owner rez'es the object (so the script still remembers you as the owner).

If I'm writing something to sell, I usually make a "startup()" function that first de-initilizes anything I use (listens, timers, targets), then initalizes. Then I call this function from state_entry and on_rez

Sorry damn tab key/spacebar.

state_entry()
{
llListen(0, "", llGetOwner(), "";
}

listen(etc.)
{
if (m == "command1"
{
}
if (m == "command2"
{
}
}

So...what is actually occurring. Does the key of llGetOwner get loaded once on state entry and that's that (I don't think so because I've never seen this problem before and this isn't the first time I've sold an object like this at all...), or is the Listen filter referenced each time the listen event is triggered, and llGetOwner checks dynamically.

In other words, does the above code manage a key in the same way as a global declaration;


key kPlayer;

default
{
state_entry()
{
kPlayer = llGetOwner();
llListen(0, "", kPlayer, "";
}


}

...which I could see causing the issue.

I also know that you can go m == "blah" && id == llGetOwner(), and that you can check in a custom function, or use onrez. But that would seem to take down the elegance of the filter and impose a different coding model on objects for sale, and I'm not sure that's the intent. A forced reset on an object purchase is also probably not a bad idea.

In answer to your coding question, yes, llGetOwner() is only called once, and then the result of that call is passed to llListen.

I would go further than that and say that it is unexpected, surprising and error-causing for scripts to keep state while in inventory.

Objects and their scripts keep state while derezzed. If you need the script to reset every time it is rezzed or when it first starts, write an init() function and call it from on_rez() and state_entry().

There are scenarios where you want objects to maintain state across a stash into inventory, and the workaround is simple enough for that feature to stay intact.

Do all the standard rez rules apply to attaching an object from inventory...or do we have to structure an init function and call it from attach/rez/entry?

Nice tag line Phoenix.