llGetOwner() vs llGetOwnerKey()

I am having trouble associating the difference between these two. What I am ultimately looking for is if the object is attached to an avatar, it returns the key of the attachee.

llGetOwner() is giving back my key since I am the owner of the object and the owner of the script. But it does not return the key of the individual wearing the attachment.

What am I over looking?

Uhh, well, it is attached to you, so you are the owner.

You cannot attach something you own to someone else. They have to own it.

llGetOwnerKey is good for getting the owner of another object, either from a chat message received in a listen() event, or a detected key in a collision*() event, or a touch*() event.

llGetOwner() returns the key of the script's owner.

llGetOwnerKey(key id) returns the key of the owner of object with the UUID passed to to function.

Ok... i understand the confusion from my question, so here is the restate.

I have created an object. If I give this object to someone else and that person wears it. I want it have the script inside this object to get that person's UUID. Not mine.

Hopefully this clears up some of that confusion.

Then llGetOwner() is what you want.

For reference, llGetOwner() === llGetOwnerKey(llGetKey()).

Yeah, if you give it to someone then they *are* the owner.

You get demoted to merely the creator

Perhaps you are seeing your key because you call llGetOwner in state_entry and don't reset the script?

For example:

key id;

default{
    state_entry(){
        id=llGetOwner();
    }
}

That code will have your key assigned to the id variable even after you give it to someone else. To get round that, either call llGetOwner() when it is needed, or use the changed event to detect a new owner.

key id;

default{
    state_entry(){
        id=llGetOwner();
    }

    changed(integer change){
        if(change & CHANGED_OWNER)
            id=llGetOwner();
    }
}

You could also call llResetScript() to reset all variables and return the script to the default state.

This is a mistake I make more often than not as well. Usually if the script allows I'll put llResetScript() in the on_rez() event so that as soon as it' attached the script resets and gets the new owner data etc.

Doesn't on_rez start EVERY time the object gets rezzed? Like sim changes, or teleports? This isn't what I am looking for. Now if the change state will work without this affect then that is what I am looking for. Does this seem right?

Another thing for clarification...

If I set a key variable, much like Sys's code, in the state_entry like:

state_entry()
{
id = llGetOwner();
}

This variable will be set to the original owner no matter who it is given to from that point on? So the attachment can change hands (if transferable) to other but 'id' will always have the original owner's key? And the only way of correcting this is by a 'change' event or on_rez event that has the id = llGetOwner() in it?

Correct, because state_entry is only called when the state is entered. Re-rezzing the object does NOT trigger the state to change, therefore any code in the state_entry only executes when you originally start up the script, or when the state is changed via script.

You could simply set the id within the on_rez event, which would be safe for most things.. but if you are creating a house/furniture/etc that will change ownership but remain rezzed in place (selling a home for example) then using the changed event really is the most full-proof.