Simon Linden is working a problem to fix a problem that leaves attachments appearing to still be attached. The problem is especially noticeable when a script removes an attachment after a region crossing. See SVC-7626 – Script object detachment doesn’t appear to remove worn object in the viewer. This is an older JIRA of a related problem. Apparently the actual JIRA being worked on got MOVED into the Linden’s private MAINT channel rather than cloned.
The apparent problem is some timing issue in how the servers send messages to viewers. Simon describes the problem as:
“…it’s pretty simple … on a REGION_CHANGED event, [the script is to] remove the attachment. When you enter the new region, there can be a mix-up of the order messages are received on the viewer. If the viewer gets a “kill” message before it gets the first update, it doesn’t know what to remove … so the object lingers in the viewer’s world, but is gone from the server.
That applies to both the AV wearing the attachment, and others watching them. If you have multiple attachments doing this, everyone can see different things.
If you click on it, it will likely go away … what happens then is the viewer sends up a “select” or some similar message with that “local id”. The server can’t find the local id, so it echoes back a “kill” to the viewer … under the assumption that the viewer is confused and has this odd local id. That’s why similar problems of ghost objects can often be fixed by clicking on them. Actually, that’s not a ghost object, but a zombie one …I think.
Having controls may affect how scripts get run, and thus the REGION_CHANGED event gets processed faster.
I have to drop my bandwidth down to the lowest setting to make it happen … that’s another factor. It’s an interesting bug because it combines region crossings with scripts, object deletions and the interest list updates … all pretty complicated parts of the server.”
Some have found that returning to their original login region will allow the item to disappear. “
So, this seems to be a timing issue in the order of messages received by the viewer. The viewer and servers get a bit out of sync and do not easily recover in this case.
Baker Linden gave us an estimate that a project viewer would appear on the RC/Project Viewers page in a couple of weeks. They do not want a project viewer out until the server side rolls across the entire main grid. They fear it would otherwise be too confusing to those not following the project closely.
Apparently there are some problems with the Received Folder, or more accurately in how people use it.
The design idea is you would open it and move received items into your main inventory. You would mostly keep it empty. For that reason you will find that Inventory Search does not include the Received Items Folder. Some people consider that a problem.
Others are creating folders in Received Items and filing stuff there. Others in moving folder out of Received move the Received Folder by mistake. I think that is only possible when in the Recent Items panel. When you log off and back on your big Received Folder is gone. It’s looking like a regular folder but, is inside another folder.
BUG-5874 – Received Items Folder Vanished — when forced to appear, repeats normal inventory instead of MP purchases.
The fix for the problem appears to be to buy something from the market place. In inventory click to show RECENT items. The Received Folder will show up. Move it to the main system folder: My Inventory. Those using the SL Viewer say this works. I don’t plan to test it.
You can move the Received Folder into trash and discard. That will break your avatar. Whirly says you can buy something and the Received Items Folder will re-create itself. But describes the FIX this way:
To Fix – Once the last DD [Direct Delivery] purchase has been made, this forces received items folder to show in Recent items – if it doesn’t show, in recent tab, go to filters and set back an hour or so or reset filters or choose always show folders. Then drag received items folder back into its correct place within the My Inventory window and relog.
This is in the Linden’s ‘fix it cue’.
This is a new type of griefing. The problem is growing as the code moves from hackers to the script kiddies. The Lindens have a start on it and thought they were ahead of it. But, the problem seems to be growing.
The effect of this attack is most of the people in a region are bumped off the region hit, they see an SL disconnect. This was a common attack effect some time ago. It seemed to stop of a time. So, this is probably a new attack method that produces the same result, a disconnect.
You can tell if you were griefed verses having connection problems by looking at your bandwidth use. It will drop from whatever to ZERO. You can look in your logs. If you have been, file a JIRA or trouble-ticket using the name HTTP Bombing and include the exact time and the location. The Lindens then know where to look in the logs for details.
Our response to most crashes is to relog and never bother to look for the cause. Only if I crash again and again do I start to look for a problem. I then first consider whether it is me or SL. I usually do this by going to another region. If I am OK I assume it is SL and avoid the problem region until tomorrow. But, it can be griefers and their goal is often to get you to avoid a particular region. So, we may need to be more concerned this and next week.