Scripts Running on Attached Objects?

What happens to objects (with running scripts) when attached to an avatar?

I have a script which when it is created picks a time. If I was to apply the script to an object then manually attach the object to my avatar would the script stay in execution and the timer fire when neccessary?
What about other behaviors of scripts? Does it even matter to a script if the object it is running on is attached or not?

On another note how do I 'Touch' an attached object in order to trigger the touch event?

Sorry if these seem like simple questions but I couldn't seem to find the answers to them in the WiKi..

Thanks! =)

yes



mostly, it doesn't matter. I know of some things that are different. For example, llGetMass() behaves differently and maybe llDie() (not sure).



don't think touch works on attached objects, but not sure.



that's what the forum is for.

I was answering your timer question and I just remembered the biggest difference between attached and non-attached scripts.

When an avatar teleports, all of the attachments get re-rezzed with new keys and I think it wipes any timers, listens, and similar things. You can detect the attach() event to set these things back up.

Not quite...

Yes, the object gets re-rezzed, but the scripts maintain their state (including timers and listens).

If you would want to do anything when the attachment is teleported (such as email its new key somewhere), you'd want to use the "on_rez()" event handler, and not the "attach()" event handler.

- Ace

Au, a very interesting note indeed. I was hoping to get away without having to detect rezing at all for the script, but if teleports has such a dramatic effect on it then I'll definitly need to keep an eye on the effects such an event would have on the script.

Thanks for the heads up!

Okay, this is good. It's one of those areas that I haven't fully explored.

Then, the question for me is, "Does it cause any bad things to happen when you reinitialize timers and listens in the attach event?" Should I be detecting that it is an attach associated with a teleport or maybe it really doesn't make much difference.

There was a thread a while back where Cross said something about listen's getting multiply registered because of this situation, but I haven't noticed it yet. Is it something I should look out for?

This code would be bad in an attachment...

default
{
    state_entry()
    {
        llListen(0, "", llGetOwner(), "listen for this");
    }

    listen(integer chan, string who, key id, string msg)
    {
        // do something here
    }

    on_rez(integer param)
    {
        llListen(0, "", llGetOwner(), "listen for this");
    }
}

The "listens" would accumulate, and the script would incrementally be adding a load to whatever sim it happens to be in.

However, there's no need to do a new llListen() call, because the old one is still active even after the re-rez.

On the other hand, all listens are destroyed on a state transition, so you could do a state change if you wanted to make sure there was only one listen at a time.

- Ace

The attachment that I have been working on sets up the listen when when it is attached and removes the listen when it is unattached.

Maybe this is what's happening:

1) The attachment gets an attach() event just before the teleport that causes the listen to be removed.
2) As a result, the attachment is re-rezzed after the teleport without the listen.
3) Then, the attach() event fires again and the listen is reestablished.

I don't know. Clearly, I need to do some experiments.

In answer to the above question, yes, the touch event is triggered on attachments.

For most of my attached scripts, (obviously depending on their intended task) I use this code:

on_rez(integer start_param)
{
	llResetScript();
}

That just automatically resets the script upon teleport or attaching the object. Obciously, if you need to retain information between teleports, you'll want to look at just disabling and re-enabling the listen events, rather than resetting completely.

Looks like the Lindens have fixed some of the problems with llListen.

The code below runs correctly:

If you chat a number between 0 and 63, it hears it exactly once.

Also, if you call SetupListens( 1, 65 ), then you get a runtime error. So, the number of listeners is still limited to 64, but if you call llListen more than once with the same parameters, it doesn't create duplicate listeners anymore.

SetupListens( integer repetitions, integer numListens)
{
    integer i;
    integer j;
    for (j = 0; j < repetitions; j++)
    {
        for ( i = 0; i < numListens; i++ )
        { 
            llListen(0, "", llGetOwner(), (string) i);
            llSay(0, (string) i );
        }
    }
}

default
{
    state_entry()
    {
        SetupListens( 3, 64 );
        llSay(0, "Hello, Avatar!");
    }
    
    listen( integer channel, string name, key id, string message )
    {
        llWhisper( 0, "hear: " + message );
    }
 
}

I can't find any evidence that an unattach happens just before teleport.

See my other post. Looks like llListen no longer creates duplicate listeners.

default
{
    state_entry()
    {
        llListen(0, "", llGetOwner(), "listen for this");
    }

    listen(integer chan, string who, key id, string msg)
    {
        // do something here
    }

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

this however...would be fine.

This is my expernce with attchments. IT is impoprtant to determin if it's attached or teleported. other wise you'll end up with the situtation where you have two ons and one off. Also this is me.. but after teleports lissons can stop working, even though they are still active. So on a teleport into a new sim, the lisson should be shut down, and then a new one should be started.

touch will work, unless they changed some thing. You can even detec the touch, and compare it to the owner or a list of keys.

It's also posible to check if an object is attached at the biggeing of the state. witch is usefull fore recompling scripts, while the object is attached to an avatar.

detach is only triggered on detach.

The real pain is when you teleport into a no-script area, so your attachment's initialization doesn't happen. Not much can be done about this, I guess...

A note with touching attachments that tripped me up: it seems to me that you don't get the "pointer finger" mouse cursor over a touchable attachment like you do over a normal touchable object. Nevertheless, clicking the touchable object does trigger touch_start.

Interesting find.

Does the touch trigger a 'touch' or 'touch_start' event? Or do both events happen? If they both happen does one happen before the other in general?

Just wanted to summarize what I think I know about attachments (after reading some more):

Touch works on attachments, but it can be confusing to the user because there is no pie menu for it and the cursor doesn't always animate properly.

Attachments get re-rezzed with new keys on teleport and the on_rez() and attach() events fire. However, listens and timers are preserved.

Attachments have zero mass. Rickard Roentgen just stated this in another thread and I did some experiments to support this. So, llGetMass() in an attachment returns the mass of the avatar. Avatar mass is not constant. All of this comes from this thread.

What to do about listens after a teleport? Should you leave it alone? Should you do llScriptReset() in on_rez()?

All I can say here is that llListen appears to work better than it used to. Calling llListen multiple times with the same parameters is not currently a problem, but you should probably code defensively with the llScriptReset technique or something similar.

good thread guys. i found out most of this today when i attached "follow me" drone to my head. it carried me around as it followed different people. when one of my tour guides put one on, the two scripts/drones each competed with the other, raising us both ever higher. experimentation is the key!