Difference between revisions of "LlGetOwner"

From Second Life Wiki
Jump to navigation Jump to search
(In 4 years of script mentoring, wiki gnoming and forum diving, have I come across complaints about llGetOwner with animations, but many times I have seen it with listens.)
Line 5: Line 5:
|func_footnote
|func_footnote
|func_desc
|func_desc
|return_text=that is the current owner of the script.
|return_text=that is the object owner's [[UUID]].
 
(See additional ErenNotes at end of this listing)
|spec
|spec
|caveats=*When the owner of an object changes, code that depends on this function's return value will not automatically update for the new owner or be automatically re-evaluated.
|caveats=*When the owner of an object changes, code that depends on this function's return value will not automatically update for the new owner or be automatically re-evaluated.
**This requires the reregistration of [[llListen|listens]] and  [[llRequestPermissions|requesting of permissions]] from the new owner as needed.
**This requires the reregistration of [[llListen|listens]] and  [[llRequestPermissions|requesting of permissions]] from the new owner as needed.
***This is not limited to listens and permissions but anything that caches the return value, it is up to the programmer to work around this limitation.
***This is not limited to listens and permissions but anything that caches the return value, it is up to the programmer to work around this limitation.
**Detection of owner change can be achieved with the [[changed]] event in conjunction with the [[CHANGED_OWNER]] flag (see the first example) or by storing the old value and periodically (e.g. in [[on_rez]]) checking if it has changed. Both techniques are valid though the latter will not detect the sale of the object if it is sold with "sell original" in-world and not picked up.
**Detection of owner change can be achieved with the [[changed]] event in conjunction with the [[CHANGED_OWNER]] flag (see the second example) or by storing the old value and periodically (e.g. in [[on_rez]]) checking if it has changed. Both techniques are valid though the latter will not detect the sale of the object if it is sold with "sell original" in-world and not picked up.
|constants
|constants
|examples=<lsl>default
|examples=
<lsl>llOwnerSay( (string)llGetOwner()); // speaks in chat the "key" (UUID code) of the avatar.
llOwnerSay( llKey2Name(llGetOwner())); // speaks in chat the name of the owner if in the sim.</lsl>
 
<lsl>default
{
{
     state_entry()
     state_entry()
Line 27: Line 29:
     }
     }
}</lsl>
}</lsl>
|helpers
|also_functions=
{{LSL DefineRow||[[llGetCreator]]|}}
{{LSL DefineRow||[[llGetOwnerKey]]|}}
{{LSL DefineRow||[[llDetectedOwner]]|}}
|also_tests
|also_events
|also_articles
|notes=
To retrieve the owners name while the owner is in the region use [[llKey2Name]], [[llRequestAgentData]] should be used when the owner is not in the region.


<b>ErenNotes (the "Scripting for Dummies" section)</b>
The one problem many coders come up against is that previously-activated events referring to the owner don't automatically change when the owner changes.  The most often-seen result is a listen registered to owner will continue to listen to the PREVIOUS owner rather than the CURRENT owner.  It is often confused as a bug in [[llGetOwner]] or [[llListen]] it is not in fact a bug but part of the design.  There are several ways of working around this problem.  The easy solution is to reset the script when owner changes or it is rezzed. The easy solution is not always the right solution.


llGetOwner() returns the UUID (identification code) of the owner of the object.
There are two ways to detect if the owner has changed, the most reliable is to use the [[changed]] event.
 
<lsl>changed(integer change)
To get the owner's name, use llKey2Name(llGetOwner())
{
    if (change & CHANGED_OWNER)//if owner changes, reset the script.
        llResetScript();
}</lsl>


<lsl>Examples:
In many applications resetting the script when the object is rezzed is an adequate and easy solution.
llSay(0,(string)llGetOwner()); // speaks in chat the "key" (UUID code) of the avatar.
<lsl>on_rez(integer start_param)
llSay(0,llKey2Name(llGetOwner())); // speaks in chat the name of the avatar.</lsl>
{ //when the object is rezzed, reset the script.
    llResetScript();
}</lsl>


The one problem many coders come up against is that previously-activated events referring to the owner don't automatically change when the owner changes.  The most often-seen result is an animation function affecting the PREVIOUS owner rather than the CURRENT owner.  While this initially seems a "bug" in the llGetOwner() function, it is not.  What happens is that no event has happened to cause the code to recognize a new owner.  There are two simple one-line solutions to this problem. Both solutions cause the script to reset all values.
Resetting the script is not appropriate if the script needs to keep it's data when it's ownership is transfered or if script startup is slow, in these situations listens will need to be re-keyed to the new owner along with any other owner specific code, like who the script is supposed to be animating.


<lsl>changed(integer change){if (change & CHANGED_OWNER)llResetScript();} //if owner changes, reset the script.  Resets script once.
The [[on_rez]] and [[changed]] events can be harnessed to reinitialize owner specific code every time the object is rezzed or changes owner.


on_rez(integer start_param){llResetScript();} //when object rezzes, reset the script.  Resets the script every time object is rezzed.</lsl>
<lsl>integer listen_handle;


The "changed" option is good when programming animations.  Since the animation system requires the owner to grant permission for the animations to act, you don't want to reset the script every time the animation device is worn.  You want to grant permissions once, and have the item work after that.  Thus, you use the "changed" event, which will reset the script once.
init()
{
    key owner = llGetOwner();
    llListenRemove(listen_handle);
    listen_handle = llListen(0, "", owner, "");
    llRequestPermissions(owner, PERMISSION_TRIGGER_ANIMATION);
}


The on_rez event is used when it is desirable to reset the script every time the object is rezzed or worn. 
default
{
    state_entry()
    {
        init();
        //insert additional startup code here that doesn't need to run each rez/owner change
        //for example, reading settings from a notecard
    }


Both events will insure that all following script funtions will refer to the current owner.
    on_rez(integer start)
    {
        init();
    }


|helpers
    changed(integer change)
|also_functions=
    {
{{LSL DefineRow||[[llGetCreator]]|}}
        if (change & CHANGED_OWNER)
{{LSL DefineRow||[[llGetOwnerKey]]|}}
            init();
{{LSL DefineRow||[[llDetectedOwner]]|}}
    }
|also_tests
 
|also_events
    run_time_permissions(integer perm)
|also_articles
    {//always use the run_time_permissions event with llRequestPermissions, never assume
|notes
        if(perm & PERMISSION_TRIGGER_ANIMATION)
        {
            //setup your animation code here, start your timers, etc.
            llOwnerSay("I have animation permissions");
        }
    }
}</lsl>
|cat1=Owner
|cat1=Owner
|cat2=Object
|cat2=Object

Revision as of 12:43, 25 February 2008

Summary

Function: key llGetOwner( );

Returns a key that is the object owner's UUID.

Caveats

  • When the owner of an object changes, code that depends on this function's return value will not automatically update for the new owner or be automatically re-evaluated.
    • This requires the reregistration of listens and requesting of permissions from the new owner as needed.
      • This is not limited to listens and permissions but anything that caches the return value, it is up to the programmer to work around this limitation.
    • Detection of owner change can be achieved with the changed event in conjunction with the CHANGED_OWNER flag (see the second example) or by storing the old value and periodically (e.g. in on_rez) checking if it has changed. Both techniques are valid though the latter will not detect the sale of the object if it is sold with "sell original" in-world and not picked up.
All Issues ~ Search JIRA for related Bugs

Examples

<lsl>llOwnerSay( (string)llGetOwner()); // speaks in chat the "key" (UUID code) of the avatar. llOwnerSay( llKey2Name(llGetOwner())); // speaks in chat the name of the owner if in the sim.</lsl>

<lsl>default { 

   state_entry()
   {
       llInstantMessage(llGetOwner(), "Only you can hear me. Isn't that eerie.");
   }

   changed(integer change)
   {
       if (change & CHANGED_OWNER)
           llResetScript();
   }
}</lsl>

Notes

To retrieve the owners name while the owner is in the region use llKey2Name, llRequestAgentData should be used when the owner is not in the region.

The one problem many coders come up against is that previously-activated events referring to the owner don't automatically change when the owner changes. The most often-seen result is a listen registered to owner will continue to listen to the PREVIOUS owner rather than the CURRENT owner. It is often confused as a bug in llGetOwner or llListen it is not in fact a bug but part of the design. There are several ways of working around this problem. The easy solution is to reset the script when owner changes or it is rezzed. The easy solution is not always the right solution.

There are two ways to detect if the owner has changed, the most reliable is to use the changed event. <lsl>changed(integer change) { 

   if (change & CHANGED_OWNER)//if owner changes, reset the script.
       llResetScript();

}</lsl>

In many applications resetting the script when the object is rezzed is an adequate and easy solution. <lsl>on_rez(integer start_param) { //when the object is rezzed, reset the script. 

   llResetScript();

}</lsl>

Resetting the script is not appropriate if the script needs to keep it's data when it's ownership is transfered or if script startup is slow, in these situations listens will need to be re-keyed to the new owner along with any other owner specific code, like who the script is supposed to be animating.

The on_rez and changed events can be harnessed to reinitialize owner specific code every time the object is rezzed or changes owner.

<lsl>integer listen_handle;

init() { 

   key owner = llGetOwner();
   llListenRemove(listen_handle);
   listen_handle = llListen(0, "", owner, "");
   llRequestPermissions(owner, PERMISSION_TRIGGER_ANIMATION);

}

default { 

   state_entry()
   {
       init();
       //insert additional startup code here that doesn't need to run each rez/owner change
       //for example, reading settings from a notecard
   }

   on_rez(integer start)
   {
       init();
   }

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

   run_time_permissions(integer perm)
   {//always use the run_time_permissions event with llRequestPermissions, never assume
       if(perm & PERMISSION_TRIGGER_ANIMATION)
       {
           //setup your animation code here, start your timers, etc.
           llOwnerSay("I have animation permissions");
       }
   }

}</lsl>

See Also

Functions

•  llGetCreator
•  llGetOwnerKey
•  llDetectedOwner

Deep Notes

Search JIRA for related Issues

Signature

function key llGetOwner();
Retrieved from "https://wiki.secondlife.com/w/index.php?title=LlGetOwner&oldid=55876"