Ghosting becomes intolerable

I am getting ghosted objects with extreme frequency, that is, sometimes 50 percent or more of the things I delete remain onscreen. It is making scripting and building unpleasant.

I don't seem to have this occur if I drop a die script into the
objects, but to do that is much less convenient than pressing the delete key.

I've some references to ghosting but not seen anything that one might do to minimize the occurence of the annoyance. Is there anything I can do to help reduce ghosting?

What's your network connection like? If you're using a wireless network, it can cause a lot of ghosting. In Help > About SL, what does it say your packet loss is?

In Alt-1, what is your ping time?

Ghosting HAS been on the rize, and I use three different connections, three different machines, and two locations. All get it rather bad.

Its getting very bad, and no with just prims but with av's also!(even worse, since after playing awhile ill have to restart SL to get the FPS decent again).. I dont see how such an obvious and large bug has survived so long..

The reason it's been allowed to persist for so long is because, as I understand it, it's a very annoying problem to solve, and in fact, a significant portion of the networking code must be rewritten for it to work right.

Also, I get the feeling like at least a couple of the developers may not want to fix their code, since the problem isn't with the code, it's with the net itself. It's not so much a bug as it is a failing to accomodate for network interruptions. The client only draws the data it gets from the server -- if not all the data is recieved, the client doesn't know to stop drawing the object.

The solution, as I've said before, is for the Lindens to implement an error-checking feature to the network protocol, possibly designed to only kick in when packet loss is detected? (Obviously, a "switch to error-checking mode" toggle would be handy in Debug for those instances where it's just too annoying to put up with.)

Interesting... However, Cat, I think that there still is a problem with that. UDP, the protocol SL uses, is, by nature, a lossy data transfer protocol. It was implemented because SL is a dynamic real-time environment, so if a packet was dropped 3 minutes ago, the system doesnt need to take the time to resend it, since there's a 99.9999% possibility that its outdated data. Wether this packet was an object movement request, or an object unrender request, the client doesnt know, and the server doesnt care.

Plus, I think SL already uses a correction system... Ever see "Packet out of order got 233 expecting 200" and "Discarding duplicate request" in your debug view? Anyways, even if a person checked the error checking option after the ghost happened, the packet was already lost.

What I think would be a bit better, and quickly implementable, would be a total object status re-request button. It would work just like re-teleporting into the area. You cant do this currently because of the telehub system. It would solve the ghosting problem because the client would treat all rendered objects as invalid, and just rerequest the objects from the server.

Another more complicated way, could be to use both TCP and UDP simultaniously. TCP would be used for data that must be sent to clients, reguardless of age (like object derez requests), and UDP would be used for realtime data. Im not sure how feasable this is though...

==Chris

EDIT: Added comment about SL's current data correction system.

Its hard to imagine they don't use both a UDP and TCP port already.. you'd think some packets simply cant be missed.
They could also make av's leaving a sim and derezed/deleted objects/prims info packets require a response. So if after a second or two if client doesn't say "ok" it send it again untill it does.. (UDP with your own packet delivery guarantee).

Yeah, it seems to me that a manual override on the Debug menu that just re-requested all the avatar and object positioning data would be the easiest to implement.

If I move a ghost, it should be telling the server about it, right? The server should then know that I'm trying to manipulate an after-image and re-send the delete signal to my client. Any update or interaction with the object should trigger this.

It doesn't solve the problem in the first place, but it's a fairly easy fix and it make life easier in the meantime...

I could accept that ghosting comes as a consequence of lost UDP packets, but then why doesn't the opposite problem happen sometimes on rezzing an object?

If this were the case, both should happen with equal frequency, but in reality, I've never seen an object not rez. Sometimes it takes a while, though.