Experience Enabled HUD/Body Attachment does not detach on region change
closed
janetguise Resident
Attaching an item with experience enabled script as temporary attachment to either HUD or BODY part does not automatically detach when switching regions. The item remains in temporary attachments, without any attirbutes (on right click -edit), and after some times/teleports, it's object name changes to a UUID.
The only way to remove this "ghosted" item is to double click on it in temporary attachments. But this doesn't always happens. Sometimes the only solution is relog.
Furthermore in reality llDetachFromAvatar() is pointless, because the moment i switch region the item remains ghosted and broken, and no code is being executed.
What i noticed is this:
on region change the event experience_permissions_denied is triggered. The event changed is not triggered at all.
Whatever code exists in experience_permissions_denied is executed (ex: llSetTexture) but llRequestPermission won't trigger event run_time_permissions. Neither combining llRequestPermission with llDetachFromAvatar()
I alsop noticed that the name of the attachment changes from "testObject" to UUID only when another attachment is added to the same spot.
Thank you ,
Dee
Log In
Maestro Linden
Merged in a post:
Temp attachment doesn't detach after leaving experience
Sominel Edelman
My weather system distributes temporary attachments for thunder sounds. They get attached using llAttachToAvatarTemp, but in many cases when agents leave the area where the experience is allowed, the attachment doesn't detach. Scripts inside don't function anymore, the name of the attachment changes into a UUID, and an attachment slot stays occupied. Sometimes it cannot be detached by the agent, and sometimes it disappears when an agent tries to edit it.
When agents move back and forth between the weather system and another place the attachments accumulate, until the only way to get rid of them is to relog.
Maestro Linden
Hi Sominel Edelman, your attachment is not there, but your viewer is incorrectly showing it. This bug does not affect the Second Life Release viewer. Please see https://jira.firestormviewer.org/browse/FIRE-31264 for details.
Kitto Flora
This was posted in 2021 at https://jira.firestormviewer.org/browse/FIRE-31264 as a Firestorm bug.
janetguise Resident
Thank you very much for your effort and professionalism Maestro Linden. Indeed you are right, there is a report on this since '21
For anyone checking this I applied the following fix in Firestorm 7.1.13 (78266)
Launch Firestorm Viewer and log in.
Press Ctrl+Alt+Shift+S (Windows/Linux) or Cmd+Opt+Shift+S (Mac) to open the Debug Settings window.
In the search box, type: FSExperimentalLostAttachmentsFix
When the setting appears, change its value to FALSE.
Close the Debug Settings window.
Restart Firestorm to ensure the change takes effect.
Maestro Linden
marked this post as
closed
Maestro Linden
I tried this out about a few times, teleporting from my experience-allowing parcel to http://maps.secondlife.com/secondlife/Engey/134/114/5 , which causes the test script to automatically detach, as llAttachToAvatarTemp() objects disappear when the destination parcel doesn't allow the experience.
It looks like Kitto Flora is correct that this is a viewer bug. With Second Life Release 7.2.1.17108480561, I do not see this bug. With Firestorm 7.1.13 (78266) on the same machine and test regions, I do see this bug - the 'ghosted' attachment appears after TP. I was able to confirm that the Firestorm case was viewer-side by doing the following:
- Added this line to the on_rez()event of thellAttachToAvatarTemptest script, which announces the object key when the object is first rezzed:llOwnerSay("My key is " + (string)llGetKey());
- Added this script to some other object, and say the key from the "My key is" output in the TP-destination region. It announces if the object actually exists in the region:
default
{
on_rez(integer rez)
{
llResetScript();
}
state_entry()
{
llListen(0, "", llGetOwner(), "");
llOwnerSay("Say the key of an object to resolve");
}
listen(integer channel, string name, key id, string msg)
{
key target = (key)llStringTrim(msg, STRING_TRIM);
if(llStringLength(target) != 36) return; // exit for non-uuid
if(llGetListLength(llGetObjectDetails(target, [OBJECT_POS])) == 0)
{
llOwnerSay("Object " + (string)target + " does not exist in " + llGetRegionName());
}
else
{
llOwnerSay("Object " + (string)target + " exists in " + llGetRegionName()
+ " at position " + (string)llGetObjectDetails(target, [OBJECT_POS]));
}
}
}
When I reproduce the bug with the firestorm viewer build, I see that the 'ghosted' attachment really doesn't exist in the destination region. It's a figment of the viewer's imagination.
Since this bug appears to be unique to Firestorm, I would encourage you to file a bug in their bug tracker at https://jira.firestormviewer.org/secure/Dashboard.jspa , if one doesn't already exist.
Kitto Flora
This bug was reported on Firestorm a couple of years back. My testing indicated that Singularity correctly removes an Experience TempAttached HUD on TP to another Non-Experience region. Re-reported the bug to Firestorm a few months back. Still no action. Problem is showing up frequently for players of the current Paradox Puzzlement mega-game on Philae region. LL client performance: Unknown.
Maestro Linden
marked this post as
under review
Maestro Linden
marked this post as
needs info
Hi janetguise Resident, I'd like to try to reproduce this bug. Where can the 'testDetach' script from your instructions be obtained? Can you post the source here? (Edit: oops, I see that it's already attached - that's all the info we need to investigate).
janetguise Resident
Maestro Linden thank you Maestro. If you need mroe info please let me know
janetguise Resident
Maestro Linden to be honest i noticed similar behaviour in attachments w/o experience.
steph Arnott
janetguise Resident, the glitch can not be resolved because the issue is client side. If the glitch is intermittent then there is a problem with the persons computer memory management, such as failing RAM.