Firestorm doesn't remove HUD

[Hooten Haller]

I know Firestorm processes events a bit differently than the Second Life Viewer, but this one has e scratching my head.

I made a HUD giver. When touched it rezzes a HUD on the ground near the toucher. That HUD then asks permission to be attached as a temp-attach HUD. This all works perfectly in the SLV and FSV. When the avatar teleports to a new region the HUD waits a fraction of a second, requests permission to attach again, and then detaches. This part works perfectly in SLV but not FSV. FSV hangs onto the HUD at least visually. It remains on screen. It _sometimes_ continues to react to touch events, but doesn't properly update appearance in response. When I try to detach it the Detach command is disabled (as if it's already detached). Sometimes it then detaches, as if some FSV code now realizes there's no HUD for the image pixels it's showing.

Before I file a FSV Jira on it, maybe someone here recognizes this behavior and and knows what I can do to properly detach after a region change?

[Jenna Huntsman]

1 hour ago, Hooten Haller said:

I know Firestorm processes events a bit differently than the Second Life Viewer, but this one has e scratching my head.

I made a HUD giver. When touched it rezzes a HUD on the ground near the toucher. That HUD then asks permission to be attached as a temp-attach HUD. This all works perfectly in the SLV and FSV. When the avatar teleports to a new region the HUD waits a fraction of a second, requests permission to attach again, and then detaches. This part works perfectly in SLV but not FSV. FSV hangs onto the HUD at least visually. It remains on screen. It _sometimes_ continues to react to touch events, but doesn't properly update appearance in response. When I try to detach it the Detach command is disabled (as if it's already detached). Sometimes it then detaches, as if some FSV code now realizes there's no HUD for the image pixels it's showing.

Before I file a FSV Jira on it, maybe someone here recognizes this behavior and and knows what I can do to properly detach after a region change?

Sounds like an inventory bug. Happens every so often.

With that said, if you're looking for your HUD to be attached only when in region (x), why not use llDie()? This does not require any additional permissions, but functionally will detach the HUD (It would also delete it from the user's inventory, but as it's a temp attachment this does not matter).

Edited April 28, 2021 by Jenna Huntsman
Made a mistake (oops!)

[Lucia Nightfire]

2 hours ago, Jenna Huntsman said:

why not use llDie()? This does not require any additional permissions, but functionally will detach the HUD (It would also delete it from the user's inventory

I've never seen that functionality with llDie() before nor do I see it now.

[Jenna Huntsman]

6 minutes ago, Lucia Nightfire said:

I've never seen that functionality with llDie() before nor do I see it now.

My mistake. Forgot that llDie doesn't work on attachments (oops!).

Edited April 28, 2021 by Jenna Huntsman

[Hooten Haller]

Yeah, I found out llDie() won't work. I need to request ATTACH permissions then I can detach it. I do a short sleep as no sleep wasn't working even in the SLV. As this happens every single time I'll have to see if I can reproduce it in a small script for a FS Jira.

[Wulfie Reanimator]

18 minutes ago, Hooten Haller said:

Yeah, I found out llDie() won't work. I need to request ATTACH permissions then I can detach it. I do a short sleep as no sleep wasn't working even in the SLV. As this happens every single time I'll have to see if I can reproduce it in a small script for a FS Jira.

Just out of curiosity, can you show the detach code?

[Hooten Haller]

Die()
{
    //llOwnerSay("Die"); return;
    llDie();
}
...
    changed(integer changes) 
    {
        if (changes & CHANGED_REGION) {
            llSleep(0.1);
            llRequestPermissions(attachedTo, PERMISSION_ATTACH);
        }
    }
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_ATTACH)
        {
            if (llGetAttached()) {
                llDetachFromAvatar();
            }
            else {
                llAttachToAvatarTemp(ATTACH_HUD_TOP_LEFT);
            }
        }
        else {
            Die();
        }
    }

 

[Jenna Huntsman]

37 minutes ago, Hooten Haller said:

Die()
{
    //llOwnerSay("Die"); return;
    llDie();
}
...
    changed(integer changes) 
    {
        if (changes & CHANGED_REGION) {
            llSleep(0.1);
            llRequestPermissions(attachedTo, PERMISSION_ATTACH);
        }
    }
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_ATTACH)
        {
            if (llGetAttached()) {
                llDetachFromAvatar();
            }
            else {
                llAttachToAvatarTemp(ATTACH_HUD_TOP_LEFT);
            }
        }
        else {
            Die();
        }
    }

 

You can remove the Die() from the run_time_permissions event as that will never work (as Lucia reminded me earlier!).

No idea if this will have any affect on the detach behaviour, but I wonder - if you replace the llGetAttached() call in run_time_permissions with an integer representing the attach state (so you may need to add an attach event) - so instead the if(llGetAttached()) becomes if(isAttached) - Reasoning is that llGetAttached() can return 0 if 'the object is not attached, or pending detachment', meaning the check won't pass.

My gut feeling though is probably an inventory bug is the cause, but can't hurt to try.

Edited April 28, 2021 by Jenna Huntsman

[KT Kingsley]

In the Die() function, doesn't the preceding return statement terminate the function, so any subsequent code – in this case the call to llDie() – isn't executed?

[Hooten Haller]

Die() exists so when I am debugging I can uncomment the first line to just print that it "died" without actually deleting it. I had included it for completeness of my example. Removing the leading double-slashes will uncomment it.

[Hooten Haller]

Jenna: I tried testing for a flag set by at attach event instead of llGetAttached. No change of behavior. The hud image remains attached until I interact with it. As I tested I noticed that something messages me BEFORE the teleport visually starts:

Quote

Second Life: Teleport completed from XXX

Of course the teleport _has not_ completed since the whole black screen/reappear elsewhere visuals start after this. I suppose what's happening is the event code is called while the script is still executing in the region being left, suspended, restored in the new region, and somewhere messages from the region(s) about attachments is confusing FSV. This message does not appear when I use SLV, for whatever that's worth. 

So I thought "What if on teleport FSV is executing script actions in a different order from SLV?" I changes the sleep time from 0.1 to 10.0. Bingo. It detaches properly in FSV. Now I'm concerned that scripts execute differently between viewers. Just as bad is sometimes teleports take a very long time, so I don't know if I need a long or short sleep time to counteract FSV's behavior.

Well, I'll play with various sleep times for "typical TPs" and hope that's good enough.

PS: The die command in run_time_permissions is absolutely required so the HUD, just lying on the ground at that point, deletes its unwanted, rejected little self. And it works in that situation since it is not attached.

[Jenna Huntsman]

41 minutes ago, Hooten Haller said:

Jenna: I tried testing for a flag set by at attach event instead of llGetAttached. No change of behavior. The hud image remains attached until I interact with it. As I tested I noticed that something messages me BEFORE the teleport visually starts:

Of course the teleport _has not_ completed since the whole black screen/reappear elsewhere visuals start after this. I suppose what's happening is the event code is called while the script is still executing in the region being left, suspended, restored in the new region, and somewhere messages from the region(s) about attachments is confusing FSV. This message does not appear when I use SLV, for whatever that's worth. 

So I thought "What if on teleport FSV is executing script actions in a different order from SLV?" I changes the sleep time from 0.1 to 10.0. Bingo. It detaches properly in FSV. Now I'm concerned that scripts execute differently between viewers. Just as bad is sometimes teleports take a very long time, so I don't know if I need a long or short sleep time to counteract FSV's behavior.

Well, I'll play with various sleep times for "typical TPs" and hope that's good enough.

PS: The die command in run_time_permissions is absolutely required so the HUD, just lying on the ground at that point, deletes its unwanted, rejected little self. And it works in that situation since it is not attached.

I wonder then, if you have the sleep interval at 2 seconds, and add a check before getting perms to check if the region is not the expected one (e.g. if(llGetRegionName() != myRegion)), if that passes, then request perms, if not, then jump before the sleep to add 2 more seconds, and this will repeat until the check passes.

[Hooten Haller]

In fact I tried a 2 second sleep and it works fine. If this becomes critical I'll try adding the code you suggest. 

I also tested this across a logout/login region change, and it work fine that way too.

Not to cast aspersions entirely on FSV, SLV had a similar issue but the 0.1 second sleep was all I needed to fix that. (For SLV it didn't get confused about the detachment state, it simply didn't detach after the TP.)

Now my fellow dancers can enjoy the temp-attaching HUD while dancing, and it will vanish when they TP elsewhere.

Thanks everyone for the advice and patience.

[VirtualKitten]

On a slightly different point Firestorm has a menu option that hides huds from screen . I don't know if this is your problem but it could be a problem for you . I wish it had a preference setting as they didn't put one in .