llDie not working

[bomber1973]

hi,

I've written a script which listens for a command on a particular channel and on receipt will remove the object using llDie().

99% of the time this works fine but occasionally the object won't disappear.  Simply right clicking on the object will cause it to go.  This object is visable to others so I don't think it's a cache issue with my particular browser.  Also, some objects seem to do it more frequently than others - I can't find a pattern to this.

Has anyone else seen similar behaviour with the llDie function ?

 

bomber

[Rolig Loon]

Yes.  It's an issue that some people refer to as "ghosting."  Some objects manage to hang around visually even after they have supposedly been removed.  If you're lucky, you can kill them by right-clicking (in which case it's probably a client-side effect) but every once in a while they don't respond easily to right click. The only way to kill them is sometimes with a region restart (so it's a server issue). Your objects may be in that second group.  I'm not sure whether the behavior is a function of particular types of mesh, or the amount of other stuff going on in the region at the time, or whatever.  It's annoying, though.

[Xiija]

i wonder if calling something like llSetPos( llGetPos() + <0,0,0.1>):

...before doing the "Die" would help?

[Callum Meriman]

I'd agree with Xiija, you need to make an update to the prim, either nudging it's location or changing something like the alpha.

That should refresh it in the viewer and make the llDie() happen cleanly.

[Berksey]

I've been in the habit for a long time of setting things to go transparent before they die. It's so that even if it doesn't die right away, it'll at least look like it did. I've never had that problem since I started doing it.

[Fionalein]

5 minutes ago, Berksey said:

I've been in the habit for a long time of setting things to go transparent before they die. It's so that even if it doesn't die right away, it'll at least look like it did. I've never had that problem since I started doing it.

I hope I'll remember that, next time I script something (but might be a bad idea depending on why you want it. I think invisible cars spamming sims are even worse than those which do not self-delete)

Edited April 19, 2018 by Fionalein

[Berksey]

That's the thing though, setting them to change alpha values updates the prim so it dies properly, like people mentioned above my post.

I used it a lot for grenades and bullets, on a sim that told me I had gone over if I had more then 16 prims rezzed. It put an end to the sim telling me I was over the rezz limit, so I presume my objects were dying properly due to the changes I made.

To quote myself, "I've never had that problem since I started doing it."

Edited April 19, 2018 by Berksey
Unnecessary BlahBlahBlah Doody

[bomber1973]

Guys, thanks for all the suggestions.  I'll give the alpha idea a try as soon as I have a chance.

[Fionalein]

I did think about it yesterday: would not making it go temp be a more convenient was than going transparent? If it goes temp the garbage collector will destroy it soon in case lldie fails... if it goes invisble... have fun finding it when lldie fails.

Edited April 21, 2018 by Fionalein

[Wulfie Reanimator]

I think there's a couple unrelated things being talked about.

One is "llDie fails."

The other is "the prim becomes a ghost."

When #2 happens, the object did llDie successfully and no longer exists in the sim. It's just a client-side error caused by packet loss. I'm not sure how this might be fixed by updating the object before llDie. 

I would advice the same as Fionalein, setting the object's temp status before llDie would definitely make it more likely to get cleaned up even at sim/parcel borders where they might otherwise get stuck. 

[Fionalein]

As an overkill attempt you can even cascade it all:

1. go temp
2. go invisible
3. lldie

 

Edited April 21, 2018 by Fionalein

[Berksey]

Temp is so obvious I'm not totally surprised I didn't think to mention it. Awesome idea.

[Fionalein]

Just now, Berksey said:

Temp is so obvious I'm not totally surprised I didn't think to mention it. Awesome idea.

I batteled with vehicle rezzers last week so it was already on my mind's cache 

[Berksey]

 Rezzers, I'm not even gonna go there.

Edited April 22, 2018 by Berksey

[Fionalein]

It is a no brainer for vehicles... temps you sit on don't get cleaned up, so you can ride them as long as you like and as soon as the driver/last passenger stands up... - poof -  none of my problems anymore 

[Arduenn Schwartzman]

llSetLinkAlpha(LINK_SET,0,ALL_SIDES);
llSetRegionPos(<.1,.1,2999.9>);
llDie();

And then let next Tuesday's rolling restarts do the rest.

[anguschill]

I have the exact same issue, but setting alpha, temp or moving the items doesn't help. They still remain there as if no commands at all had been issued and only vanish after a right-click. Any idea about this? I found a JIRA in regards to this problem: https://jira.secondlife.com/browse/BUG-10908 But it is 5 years old and hasn't been fixed. Any idea what else to do to prevent this? It happens a lot with an item I recently scripted and I am at my wit's end.

[Rolig Loon]

13 minutes ago, anguschill said:

Any idea about this? I found a JIRA in regards to this problem: https://jira.secondlife.com/browse/BUG-10908

Yes, that's exactly what I was describing almost three years ago in this thread.  

Ghosting has been with us in one form or another as long as I have been in SL. It might become a little less common, now that regions are all in the cloud, but I wouldn't bet on it. Experiment with the standard suggestions that several people have already made here. 

 

[Nova Convair]

I have a rezzer at 2000m that rezzes ground scenes. If I derez one and TP down it's still visible. I can right click on every object or TP out and back in or log out and in. Anything that forces the viewer to reload the environment.

This does not happen when I derez stuff in range. That always vanishes instantly.

So it has nothing to do with llDie but with viewer updates.

[Whirly Fizzle]

Yep, can confirm BUG-10908 - Ghost Objects Left over when things are removed from play has never been fixed.

[anguschill]

Thank you for all your replies. This is crazy though, it should be fixed. With some objects it is crucial that the objects vanish properly. Why not do a viewer update at least when the person moves back into the range of those items/the items are within draw distance?

This bug practically makes it impossible to script objects which appear and disappear frequently. I tried so many things, I even dropped the llDie command completely and made them transparent, scaled them down, moved them to a far off position of the region and made them temp. I had a timer do all that repeatedly for a higher chance to actually have all viewers being updated until the garbage collector actually removes those items server-side. Still no luck. They visually remain in place for people that were in the region at the time but not within draw distance as if nothing had happened.

I can't think of any solution/workaround for this problem on my part... Very annoying.

Edited December 28, 2020 by anguschill
wrong spelling

[Wulfie Reanimator]

1 hour ago, anguschill said:

Thank you for all your replies. This is crazy though, it should be fixed. With some objects it is crucial that the objects vanish properly. Why not do a viewer update at least when the person moves back into the range of those items/the items are within draw distance?

This bug practically makes it impossible to script objects which appear and disappear frequently. I tried so many things, I even dropped the llDie command completely and made them transparent, scaled them down, moved them to a far off position of the region and made them temp. I had a timer do all that repeatedly for a higher chance to actually have all viewers being updated until the garbage collector actually removes those items server-side. Still no luck. They visually remain in place for people that were in the region at the time but not within draw distance as if nothing had happened.

I can't think of any solution/workaround for this problem on my part... Very annoying.

If you're experiencing "ghosts" for an object that still exists, or was not visible at the time it was supposed to disappear, your problem is probably something else or we'd have much more serious problems.

[anguschill]

No, I mean: Let's say I am at the ground level and objects are deleted via llDie up on a sky platform while I am on the ground level. Once I tp up there the items are still visually there and only a right click on them makes them disappear. This does not only happen to me but for all people in the region. And I also tested in multiple other regions, the same happens.

[Qie Niangao]

But this only happens to items that were rezzed into view first, and then later deleted while out of view, right?

If that's what we're talking about, "fixing" this could have prohibitive performance impact. Somehow the sim would need to keep track of every viewer that may have once rezzed and now has the object cached and who might return to within range of viewing it again. That seems hard. Or else send object updates to every still connected viewer that was ever within interest-list range of the updated object, which would be even more overhead for both the viewer and the sim.

First take: To support in-world experiences that depend on these "updates-while-absent" seems only tractable if there's active contextual management of interest lists and caches. That seems interesting, but also hard.

[Wulfie Reanimator]

6 hours ago, Qie Niangao said:

But this only happens to items that were rezzed into view first, and then later deleted while out of view, right?

If that's what we're talking about, "fixing" this could have prohibitive performance impact. Somehow the sim would need to keep track of every viewer that may have once rezzed and now has the object cached and who might return to within range of viewing it again. That seems hard. Or else send object updates to every still connected viewer that was ever within interest-list range of the updated object, which would be even more overhead for both the viewer and the sim.

First take: To support in-world experiences that depend on these "updates-while-absent" seems only tractable if there's active contextual management of interest lists and caches. That seems interesting, but also hard.

Alternatively the sim could send the llDie packet to every connected agent indiscriminately, and let those viewers decide what to do with the information. (If the viewer isn't aware of that object, they ignore it. If it is, it forgets about it.)

Edited December 29, 2020 by Wulfie Reanimator