Looking for content that relies on attach() event when derezzing to inventory

Currently there is a bug in 1.6 where the attach() event is called _before_ the object is detached from the avatar when the object is "detached to inventory", as opposed to _after_ it is detached in the case of "drop into world".

In 1.7, due to some fixes in how the rotation/position of the attachment is more correctly saved on detach this bug is more problematic than ever. It occured to some of us that maybe no one actually relies on the attach() event triggering before the object is taken to inventory in which case we would like to not bother supporting it _before_ derez. It turns out that there is no gaurantee that the attach() event will happen anyway since if the script is in the middle of a deep loop, or a very complicated function, it may not escape that scope in the amount of CPU cycles granted to the script before it is derezzed.

So, I'm curious is anyone knows of content they have seen or made that relies on the attach() event being processed before "detach to inventory". What scenarios could you imagine where the fact that the event is called before derez is important?

Also, if anyone has such content already, I'd be interested in getting a copy of it so I can test it in 1.7. Thanks.

Hello Andrew,

Although I couldn't really understand what kind of bug you menstioned, I have a problem related to attach() event.

It is a horse. You have to rez it on ground and attach it to ride. Whenever I attach it, the horse comes back into my inventory but　the riding pose animation keeps being played. Some of my attachments　disappers and my avatar becomes female. Though I can see my avatar　in the screen, my friends say they can't see my avatar but a part of head.　They can't see even my account name above my avatar.

I sent a bug report a couple of days ago in world but I have got no response　except the first replying since then.

I'd like you to check it, but the horse is no transferable.
OK, I will also check it in 1.7 and report it here.

I used it, early on - mostly in a misguided fashion, actually - apparently my code still fruitlessly uses it. I can see uses for it though (in a vague, cloudy, undefined sort of way), I'm just not sure that they justify retention of the hook.

On the other hand, I'd hate to lose (a possibly potentially useful) hook, just because we might not have a use for it today. With HUD attachments looming, particularly, someone might just find a use for that hook tomorrow.

You know how it is...an event hook gets removed, and ten days after the next set of features lands in your lap you are suddenly wishing you had it back.

For my money, document it as attach() is called just before the item is detached, if it is being detached to inventory, as opposed to it's behaviour when being detached to world. Maybe the reliability of the event can be hacked on in future.

One idea that was kicked around the lab about how the attach() event could be used when detaching an attachment to inventory would be as a "I'm going away now" message to anything else that might be interested in knowing that the attachment was around or not, such as a backpack or sword that notifies a game controller that the player is leaving the game.

Anybody ever do that yet? Can anyone think of other useful things that can be done in that event before the attachment is derezed?

Seagel, that sounds like a crazy bugged horse. If we find each other in world and you rez it for me then I can take a copy of a no-transfer item for debugging purposes. Better yet, if you leave a copy of it rezzed somewhere I can just yank a copy of the entire region and run it in a local grid on my workstation. I'd need the name of the object and its location. Send me an IM if you do that and a I'll make it an official bug entry on my end.

Tateru, attach() should not be called before the object is actually detached, because that is different than the 'drop into world' case, and will cause things to do different things in each case. It is the discrepancy between the two cases that I need to fix.

I think its used in crystalshard foo's dance-foo sphere, so when you teleport out of the sim dancing with the sphere attached to you, it tells it to stop the dance, so you dont tp into somewhere dancing lol

I think it makes sense as a sort of destructor. I mean, for the obsessively tidy, abort your scans, terminate your listens, report pending detachment to the wearer, owner, or other dinguses that might be hanging around your person.

*drools*

I'd really like to be able to do llDie() when an object is detached to prevent the object from going back into inventory. I've used the attach() event to just remove all the old content from the object when it's dettached and then have it die the next time it's rezzed, but you end up with a messy inventory. It would be great to use a HUD just while you're playing a game and not have to worry about keeping it around for next time or end up with a thousand HUDs if you play something often.

ROFL, I actually said that IRL when I saw him say that.

As far as content, the backpack for DarkLife says "see you next time" or some such when you detatch. I can certainly see instances where it would be nice for it to fire... such as the HUD example above. For one time use or game/sim specific items. It would be a lot easier for game 'system' to try to keep track of people by just listening for the attach/detatch messages from an attachment than trying to poll each user on a semi-regular basis. </me shudders>

L8r,
UU

Does this bug affect the function llDetachFromAvatar()? If it does/does not, could someone explain?

Andrew, I could't find you whenever I log in. So I called another Linden, Harry. He made sure that bug and enjoyed. He could also disappear completely.

More people use this then you might expect. I'm pretty sure attach() is used in those particle poof scripts to make them poof when you tp in and out.

When an object is detached to inventory, is there ever a time when it's no longer attached to the avatar but still exists in-world? If not, having the attach() event fire just before the object is actually detached seems like the most appropriate behavior.

I'm not exactly sure I understand the question here. Are you saying that the solution to the discrepancy between drop and detach-to-inventory would be to run the attach() event after the object is already off the avatar and sitting in the inventory? What does it even mean for a script to be running in an object that doesn't even exist in-world? What happens if it tries to rez objects, llSay, or do other "in-world" things? Silent failure?

I know one very common thing for scripts to do during detaching is to stop animations. Whatever solution you come up with, that still needs to work, so my arm doesn't stay stuck out when I detach my beer Your explanation of how this can happen when a script is too busy to allow the detach event to happen makes a lot of sense... it explains why sometimes attachments I've created will fail to stop their animations on detach.

I do definitely have at least one object that depends on being able to proclaim its death to a server object when it detaches. It's a game called HoloBall that's set up in the northwest corner of Eldora... although to play, you'll need to get a copy of the racket attachment from me. The way it's scripted, it's not CRITICAL that rackets let the server know they've gone away when they detach, because we also have to deal with the case that the player just wanders off, racket attached.

Still, from the sound of it, unless I'm misunderstanding, if the attach() event happens after the object is already removed from the avatar, lots of "in-world" things would fail, which I think would be a bad (and potentially very confusing) thing.

From a quick test it seems this is working as well kinda like it was bugged lol

Its firing on attach, detach to floor and detach to inventory (also the hovertip in the script editor says it should fire on detach too)

Yes, attach() is fired when the object is attached and when it is detached. There is no detach() event at this time; attach() serves for both cases. To distinqush between the two you must examine the 'key' that is provided as an argument to the event.

I've submitted my fix for this problem in 1.7 already. The script will still try to execute its attach() event on detach-to-inventory. Under the hood the object is still attached to the avatar at this time however I added some trickery to make llGetAttached() correctly return '0', and calls to llSetRot() or llSetPos() will do nothing after the detach operation is started. It may be that a few other calls are "broken" in this case... such as llGetLocalPos(), which may actually return the attachment's avatar-local position instead of whatever an in-world object would return.

As mentioned earlier there is no gaurantee that the attach() event will complete before the object gets derezed. In particular, if you call an expensive operation within the attach() event the script may be descheduled enough to cause the derez to happen before the attach() event is complete. Although llSetPos() is a no-op during detach-to-inventory it will still cost the script the same amount of execution time because the schedule cost is computed before the operation fails -- an inflexibility of the script engine that exists at this time.


Seagel, I'm almost never in-world. Send me an IM when you're in and if I can I'll try to log in. But not late today, because I'll be out unavailable after 11:00 this morning.

seconded!!
Fox

Sorry for soiling this thread with my personal bug reporting. Andrew, I told you that I'd already given it to Harry Linden. Should I contact to you, too? My usual time for login is around 6:00 a.m.

I have relied on it more than once in the past. It's even in the wiki code samples, I think. The content doesn't matter to me anymore though so personally I wouldn't care if this was removed.