Ensure the ATTACH event has fully completed before really detaching the object.
Gael Streeter
At present, it is not guarantee that your code will execute fully when running instructions in the attach event during detachment.
This can be particularly annoying — for instance, when trying to revert avatar deformations upon detachment.
Additionally, there are cases where this code may unexpectedly run during the attachment process, as it remains in the object's execution queue.
For example put this script in an object and wear it then unwear it several times:
default
{
attach(key id)
{
if (id==NULL_KEY) // DETACH
{
llOwnerSay("DETACH 1");
llSleep(0.5);
llOwnerSay("DETACH 2");
llSleep(0.5);
llOwnerSay("DETACH 3");
}
else
{
llOwnerSay("ATTACH");
}
}
}
On first ATTACH you will have these logs :
> ATTACH
On first DETACH you will have these logs :
> DETACH 1
On second ATTACH you will have these logs :
> DETACH 2
> DETACH 3
> ATTACH
The end of the "detach" code is completed on the attachment !
It would be highly beneficial if the object could delay detachment until the attach event has fully completed.
Log In
Gael Streeter
I’d like to share some details about my use case. I have avatar-deforming animations running, which need to be stopped during the detaching event. They take some time to fully stop and I then need to trigger my undeforming animation. This process requires sufficient time within the detaching event to ensure everything executes smoothly and in the correct sequence.
ST33LDI9ITAL Resident
No can do, as then could make things that couldn't be detached. For this to be a thing, users would first need a way to stop/start scripts on no mod items as a way to get around and detach bad objects.
Do agree it would be nice to have better detach functionality but it's a dilemma that currently works mostly fine.
Gael Streeter
ST33LDI9ITAL Resident I'm not sure I fully grasp your point.
Naturally, a skilled developer would avoid placing a deadlock in the 'detach' code. Are you suggesting that malicious individuals could deliberately introduce a deadlock here? After all, deadlocks can be introduced elsewhere in scripts, and they can be especially frustrating when their source is unknown...
But ok, indeed, there could be cases where an object gets stuck in the detaching process. There are certainly alternative solutions to prevent such 'undetaching' issues—perhaps forcing the detachment if the user requests it a second time, or simply allowing more time for the script to complete the process (allowing 2 to 3 seconds for detachment would be more effective than under 0.5 seconds—though naturally, the object should detach sooner if the code has already completed)... Linden Lab likely has a better understanding of what can be done to prevent such issues.
ST33LDI9ITAL Resident
Gael Streeter
Pretty much, I'm all for any improvements to it so long as we have a way to bail out so to say and remove any attached objects that may be stuck. I'm not sure what the best solution to it would be.. allowing more time for it to trigger would be a good start, do agree with that. Subsequent detach request after that delay forcefully kill and detach it makes sense as well.
Bavid Dailey
what happens if you take out the llSleep calls? If it works as you expect that says to me that the detach is given a short period to do its thing, and no more. Which sounds reasonable to me. Also , a script 'in sleep' is consuming resources, but not doing anything for thr detah process. Maybe that is special cased?
Gael Streeter
Bavid Dailey This script is intended to illustrate the issue. If the script you want to execute during detachment is 'somewhat lengthy,' it may not complete during the detachment process but instead during reattachment. The main problem is that you cannot guarantee the script set for detachment will be executed in full.
As you can see in this script example, you have less than 0.5 second to execute your detach tasks as the llOwnerSay("DETACH 2"); is not executed on detachment.
Bavid Dailey
Gael Streeter my point is that the llSleep itself may be the cause of the problem, but I'm just guessing
Ross Myhre
Bavid Dailey I think you mean to say the delay itself is the cause, not the llSleep() function. You would get the same result using a timer with the same 0.5 delay. Without the delay only two of the three llOwnerSay() events will trigger before detaching, so 'cause' is probably not the right choice of words. But yeh, you're right in the sense that it states on LSL Portal:
"When detached to inventory, an object is only given limited time to execute its attach events. If these events are active when the script derezzes but have not completed, execution will finish when the object is next rezzed."
Anyway, the delay itself is just semantics because the limitation does indeed exist, and Gael is correct, regardless of the script example.
I for one would love a method of guaranteeing all attach events fire before the actual detach happens. +1