ghosted prims, for crying out loud

Nothing's funner than having to logout and back in every single time I delete a prim. With every new update, I get more and more and more "ghosted" prims, buildings, furniture,etc...

I have had to log in and out 15 times (and many many more to come over the next hour) in the past 10 minutes while working on my 15 story tower.

this may sound odd, but go in to edit mode on the ghosted item and send it to mars 200 m straight up..
since its a ghost, you're not litering, only you see it.. .In doing that now its out of site for your local area.

or drive it into the ground. either way, there is no need to restart the game every time you see a ghosted prim.

Champie

There is if you don't own it. (Yes, I realize that in this post Aaron is referring to his own prims. I just don't want to see this problem trivialized.)

I have found that dropping a script containing llDie() on an object instead of simply using the delete key or the delete pie menu option dramatically reduces the frequency of ghosting .

Both of those suggestions are very good. Now when things ghost on me, they end up at the edge of the world.

While it may not be an issue for you at the moment, since you're working alone on your own builds, you should keep in mind that when you use the launch/bury method, the prim only relocates in your client. To anyone else that it ghosted for, it sits right where it is. When you move it, they don't get updates (the server doesn't send out updates for objects that don't really exist), and they can't move it themselves because they don't have permissions.

This ghosting problem is a real PITA for building classes.

This is getting worse and worse. I'm trying to build a house right now, and I think 3/4 of the time that I delete a prim, it ghosts. I know about driving it into the ground etc, but it's STILL ANNOYING!

Larissa

I'm glad I'm not crazy about these ghosted prims. I kepted a tally last night while working on a skyscraper I'm building. Over the course of two hours, I had to bury 116 prims that ghosted.

116.

Grim, I have always worked alone, so I didnt give any consideration to a group situation where I was "Stuck" with a ghosted prim unless I restarted. Thanks for reminding me of that aspect of the problem.

I agree that this issue should not be trivialized. Even when it is easy to move ghosted prims, it is still frustrating. More than just the effort to move the ghosted prims, the concern is that it happens so frequently.

What can Linden Labs do about this? Are we just stuck with this sort of problem, or are there effective ways to fix it?

Champie

Simple logic dictates that if 20/20 people in a specific location all have the same object ghost, then the odds against it being client-side or even near the client end of the network connection are astronomical. Think about it, when 20 clients at various locations all over the world fail to receive the same packet, it's obviously a problem closer to the source than the destination.

Add to this the fact that the problem is significantly worse in a lagged sim.

It seems to me that there are a few probable solutions:
- for some reason, the sim just isn't sending that packet. Lag levels wold imply that the sim may be overloaded to the point that the network just drops packets in an attempt to keep up with the flow.
- network overload at the source. It's possible that the sim actually sends the packet(s), but but there's an over-burdened router somewhere in the datacenter that drops packets because it can't keep up. This wouldn't be a major issue if it were TCP instead of UDP, as the client would request a re-send of the packets that it's missing.
- If SL uses multicast routing, the router at the edge of the multicast network that has to split a single multicast packet into the separate unicast packets could be heavily overloaded, and only manages to send a couple of the unicast packets before it gives up and moves on to the splitting up the next multicast packet. This seems the most likely scenario (to me, anyway) in situations where an object ghosts for 25 people, but is actually deleted for 5 others. They were the lucky ones.

I'm under the impression, from previous discussions, that the LL/SL servers are colocated at a hosting facility, and they don't have their own datacenter. Unfortunately, if this is the case, it means that LL has absolutely no control, and probably limited input, where the datacenter hardware/capacity is concerned.

Meaning that there's probably nothing LL could do about it, even if they had the tools necessary to test and determine what the problem actually is. They only have control over the sim software/hardware, and it honestly seems to me as if that's the least likely culprit.

Not that I don't want to see it fixed. I just think the likelyhood is pretty low, unless someone at LL either boots a boot in the @55 of someone at their hosting center, or moves to a different colo facility.

The idea of moving to a different colo brings up another point that I've thought on several times. I was in central California in the fall of '89. What's going to happen to SL the next time there's a major earthquake in the SF bay area? We all know it's going to happen, we just don't know when, or how bad it'll be. Is LL prepared for this eventuality? Has anyone there even bothered to think about it and prepare disaster recovery scenarios?

Yep, in 1.6.4, after ghosting was fixed, objects are still ghosting for me. And with some frequency, too.