llGetOwner & change & CHANGED_OWNER

heyas;

okay, somebody just told me that llGetOwner is buggy and if you use it in a script, you MUST include a change & CHANGED_OWNER check to reset it on owner change.

BUT

reading the wiki... it seems to say that llGetOwner does run anew whenever you call it. and it seems to me... SHOULD work without resetting the script, IF it is used properly. that is, called every time you want to use it, and not stored somewhere.


example:

key owner;

state entry: owner = llGetOwner();

=NEEDS RESET


example:

state entry: llListen(blah blah llGetOwner() blah blah);

=NEEDS RESET


example:

touch_start if(llDetectedKey(0) != llGetOwner())

=OKAY



do i have this right? lord, i hope so! otherwise, its back to changing fifty-level mailboxes AGAIN!!!

Of course it does.


Yes.


No. Absolutely NOT.


True.

As for storing the owner key vs. asking it everytime you need it, it depends on how many times you need that key. In llListen(), once in a while, that's ok not to store the owner key but it becomes a waste of CPU in any repetitive event like listen(), touch() or sensor(). In other words, it creates lag.

Besides, I wouldn't recommend the use of CHANGED_OWNER which also waste a tiny bit of CPU time with a test. Instead, use the event:

on_rez(integer param) { llResetScript(); }

Just use it as first line of every state and you'll be able to safely store and reuse the owner key. For example:

key OwnerKey;

state default
{
on_rez(integer param) { llResetScript(); }

state_entry()
{
OwnerKey = llGetOwner();
}

touch_start(integer num)
{
if (llDetectedKey(0) == OwnerKey)
{
llInstantMessage(OwnerKey, "Hello Owner!";
}
}

}

(Fifty-level mailboxes, Blood? The idea of watching your avatar "go postal" has a certain appeal, but no need, I think.)

This variant of the on_rez / llReset superstition is new to me.

To clarify what may be some confusion between your post and Kaluura's, the llListen() on llGetOwner() in state_entry *would* require a reset because the listen() event would only be triggered if it heard something from whoever was the owner at the time of state_entry, when the llGetOwner() was called. (There's nothing special about llListen() that makes this necessary; it's just that it's executed at state_entry, so the filters are set at that time according to whatever llGetOwner returns then.)

As for why ever to use CHANGED_OWNER to trigger a reset, the only reason I've encountered for this is selling an item as Original to remain in situ, in which case no on_rez event will be triggered.

and just to add to the fun...

it's not absolutely neccessary to reset the script, even if you use a one time call like get owner in the state entry.

what you can do instead is reinitalize the variable, for instance setting the variable from the changed event

in the case of the listen you would also want to close the old listen, which is another line of code, so most just simply reset the script.

the following is a perfectly valid example

key gKeyOwner;

default{
  state_entry(){
    gKeyOwner = llGetOwner;
  }

  //-- some other events that use the owners key

  changed( integer vBitChanged ){
    if (CHANGED_OWNER & vBitChanged ){
      gKeyOwner = llGetOwner;
    }
  }
}

which would update the owner, w/o reseting any other data, dropping any queued events, or temporarily disabling the code while it's restarted.

another method would be to add variables like that to the begining of a different state, when the change is detected, it updates those variables, while preserving others that aren't initalized there... the drawback is you can still lose queued events during the state change, the upside would be the automatic closing of old listens.

It's not that llGetOwner is buggy, it's that when you take a scripted object into inventory, the script retains the script state it was in (meaning the values of all global variables and whatever event hander was executing, if any) when the transfer occurred. So, using your examples:

If you write and compile this script, it begins running, and assigns your key to the owner variable. If you then give that script to someone else, it doesn't start over with defaulttate_entry, it continues from wherever it was, which almost certainly means that it still has your key assigned to the owner variable.


As above, this establishes a listen filter using your key. And when you transfer it to someone else, it still has that filter using your key.


This would test the key of whoever touched it at the time, so there is nothing held-over from one event to another. This would only be an issue in the unlikely instance that you took the object into inventory or transferred it to someone else WHILE a touch_start event was executing, in which case it would continue execution with the assumption that llDetectedKey(0) == your key, until the end of the event handler, at which point it will no longer matter.

one other note, on WHY people store things like the owners key and use that instead of the call...

it's faster to reference a script variable than it is to make a call. the call uses more bytecode and more resources on the sim than the refrence to a pre stored variable,

which is also why you see sctiprts store llDetected* calls to a variable if that call would normally be made several times within that event.

so, basically...


llGetOwner DOES work right. when you use it properly.

that's what i thought.

thanks guys!