Q re llDetectedKey(0)

I see llDetectedKey(0) used in a lot of places in example scripts in a check to see if the person touching an object is the owner.

In the Wiki it says:

key llDetectedKey(integer number)

Returns the key of detected object number (returns NULL_KEY if number is not valid sensed object).

which makes it look to me as if it will return the key of the Object Being Touched, in this case the key of the Root Prim - '0'.

However, I assume it gets used in an example like this (from the Wiki) because it works to identify the key of the Avatar/Agent touching the object, and in this case sending an IM to that key.


touch_end(integer num_detected)
{
llSetTimerEvent(0.0);
llInstantMessage(llDetectedKey(0),llDetectedName(0) + " you held down your mouse button for " + (string)time + " seconds.";
time = 0.0;
}
}

So - for the purposes of the Wiki is an Avatar/Agent an object?????? Is it something to do with the number (0)??

I'm trying to debug a script that always works for me but hangs with a new owner.
Is there any problem with doing something like this to reliably get the key of the new script owner.

Av_Key = llGetOwner();
Av_Name= llKey2Name(Av_Key);
if (llDetectedKey(0) != Av_Key)
{
llSay(0,"Sorry - only the owner " +Av_Name+ " can adjust me ";
state_entry();
}
llSay(0," HI " + Av_Name);

The number in the touch_start() type events is the number of people detected touching the object at once. As far as I know, only one person can fire a touch event at a time so it's always 0.

This is different from a sensor(integer detected) where many objects/avatars might be returned. If detected is 5, that means 6 people have been detected by the scan, numbers 0-6. Then you'd use the llDetected functions to retrieve information about each detected person.

If you want to detect when the owner changes, see the changed event:
http://wiki.secondlife.com/wiki/Changed

Something like this:

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

Simultaneous touches can come in a single event. It's rare, but it happens.

The number argument is simply used as an index to the list of detected objects (yes agents are also objects) and is often used as 0 with the assumption that only one avatar can click an object at once. But it is *possible* for more than one to click to be sent in a single event, so I generally structure my touch events to go through them all this way:

touch_start(integer num) {
    while (num--) {
        if (llDetectedKey(num) == llGetOwner()) {
            etc();
        }
    }
}

The touch*() events can only be triggered by agents, but the sensor() and collision*() events can contain object or agents or BOTH (depending on the filter used in the case of sensor()). If necessary you can sort this out using llDetectedType():

sensor(integer num) {
    while (num--) {
        if (llDetectedType(num) & AGENT) { // is an avatar
            agent_etc();
        }
        else { // is NOT an avatar
            object_etc();
        }
    }
}

(For the purists out there, I do know it's not canonical to be altering your arguments.)

BTW:

Slight correction, if detected is 5, that means that 5 objects/agents have been detected, numbers 0-4.
0-6 would be 7 items.

Yes, you can detect an owner change and reset the script if necessary, but in the case of a touch you'll likely just be calling llGetOwner() once, to filter the touches, so I don't see the need for script resetting. llGetOwner() will always return the current owner, the problem only comes when the result gets stored locally. If you wish to store the owner's name then yes, I agree that you'll need a changed() event and store the new owner, or reset the script as needed.

Thanks a lot for the great replys - and the suggestions for program structure.
This makes a lot more sense now.
Much appreciated!

The reason for looking at a complete reset is trying to get as much assurance as possible that the new owner will be recognized by a script that has a lot of different states - and the fact that inventory with running scripts can be taken into inventory and transferred while in various states - including while waiting from a dialogue response from a previous owner.

I will have to check the llChanged event but on_rez() for example would need to be in every state to catch the event and reset the key to the new owner. I now have a timer in the object programming state so if there is no response it will time out and reset the script.

I wonder how many "broken" scripted objects out there just need a reset to be fine. I've been in the situation of not being able to reset a script because I sold the object so am not the owner, and meanwhile the owner can't reset it because its No Mod. The No Mod setting is described in stuff from the Lindens as being there to protect intellectual property. I personally don't see how enabling a simple script reset by the owner would affect this and I think it might solve a number of problems.

You can reset a script even if you do not have Mod permissions. Double-Clicking the script will open it inside the LSL editor with the contents of the script no visible, but the Reset button will be there. There also is a Reset all Scripts option on the Tools menu, which resets all scripts with an object.

Not if the *object* is no-mod.