I opted to put the following under a separate projects update piece, rather than “Other Items” (as I usually do), as they are quite extensive and worth noting. All of these items were discussed at the Simulator User Group meeting on Tuesday June 3rd.
Scripted Object Detachment Issue
This problem has been around for a while (see JIRA SVC-7626 for a description, although there have been more recently JIRA filed), and Simon Linden has been digging into it.
It relates to the scripted detachment of objects using a
REGION_CHANGED event following a region crossing. When entering the new region, the order of the messages received by the viewer gets mixed-up such that it may get the order to “kill” (stop rendering) the object ahead of the message telling it to detach the object.
Should this happen, the viewer actually doesn’t know which object it should remove, and the result is that the object remains in visible to the wearer, but it cannot be detached or edited (because the server considers it removed). However, to other people in the region, the object will not appear to be attached, as they received the correct updates. So, if you have multiple attachments doing this, everyone may see different things.
One way to correct the problem is to re-log. This can cause the object to render properly and be detached. Simon Linden also offered a possible solution:
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 echos 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 [seen in-world rather than attached to an avatar] can often be fixed by clicking on them …
I’m not sure why but the click / selection thing seems to work more if you go back to the original region [where the object was still attached].
Why the order of the messages received by the viewer gets mixed-up is unclear, and there may be a number of possible causes, as Simon also explained:
Having controls [e.g.
PERMISSION_TAKE_CONTROLS] may affect how scripts get run, and thus the
REGION_CHANGED event gets processed faster [leading to the mix-up in the order of the messages]. 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.
It’s not clear what is going to be done to rectify the issue, given it is a timing issue touching on several areas of interaction. In the meantime, if you encounter the issue, you may want to raise an additional JIRA, citing location, behaviour, etc., and also try one of the workarounds mentioned above.
Problems with Inventory’s Received Items Panel
Received Items is a system folder introduced with Direct Delivery and intended to be used for the initial receipt of SL Marketplace purchases before moving them into “normal” inventory. Because it is intended to be a “temporary” store, Received Items isn’t included in any inventory searches, so any items stored in folders created there won’t ever be listed when using search.
Within the official SL viewer, Received Items appears as a separate section at the bottom of the Inventory Folder (shown on the right). When displayed like this, it is not possible to move Received Items. However, when receiving goods from the Marketplace, Received Items does appear as a folder in the Recent tab of Inventory – and it is here that problems can occur, for example:
- It is possible to drag the Received Items folder shown in the Recent tab into another folder, causing Received Items to vanish from the bottom of the Inventory floater following a re-log
- It is possible to right-click on the Received Items folder in the Recent tab and delete it.
Neither of these issues are unrecoverable, however, and neither leads to a permanent loss of inventory.
Recovering After Accidentally Deleting the Received Items Folder
- If you accidentally delete the Received Items folder in the Recent tab, you can recover it the same way as anything else – open Trash and drag it back under the My Inventory folder
- If you purge your Trash after accidentally deleting the Received Items folder from the Recent tab, simply go to the Marketplace and make a purchase – Received Items will be re-created on receipt, although anything stored within it prior to the deletion will be lost.
Recovering Recent Items After Accidentally Moving the Received Items Folder
If the Received Items folder is accidentally moved when viewing it in the Recent tab, and you haven’t re-logged, simply go to the Recent tab in your inventory floater, then open all the folders displayed there until you locate Received Items and drag it so it is inside the My Inventory folder in the Recent tab.
If the Received Items folder is accidentally moved when viewing it in the Recent tab and you log-off without realising what you have done, Received Items will not be displayed at the bottom of the Inventory floater the next time you log-in. Should this happen:
- Go to the Marketplace and make a purchase (can be a freebie)
- Open Inventory – the Received Items section will be displayed at the bottom of the Inventory floater as usual
- To prevent it from vanishing again following your nextrelog:
- Click on the Recent tab
- Open any folders listed in the Recent tab until you locate the Received Items folder
- Drag the Received Items folder back under the My Inventory folder
BUG-5874 reports an additional issue with Received Items which can occur when using a secondary inventory window (CTRL-SHIFT-I). If the Received Items folder in this secondary Inventory floater in accidentally moved, it will also cause Received Items to vanish from the bottom of the My Inventory tab following a relog.
Should this happen, the steps described above will restore Received Items at the bottom of your My Inventory tab but it will also cause the full contents of your inventory within Received Items (see the image on the right).
Should this happen, relog once more. Received Items should be correctly restored and only display your recent Marketplace purchases.
If this does correct things, try this suggested fix from Whirly Fizzle.
HTTP “bomb” and Forced Disconnects
An issue which seems to be on the increase is what is being referred to as an “HTTP bomb”. The effect of the attack is an immediate disconnect from a region for most of those on the region. It appears to be a similar to an attack vector has been used in the past, but which the Lab believed it had brought under control with a couple of server-side updates (some TPV and open-source developer meetings were subjected to this earlier form of attack).
The conjecture is that a new “tool” is now available and is being used as a means of attacking individuals, with the overall impact of disconnecting many. That it is not a sim crasher can be verified by the fact that when used, it affect around 80% of those on a region, who are instantly disconnected (and who will likely see their bandwidth drop to zero in their viewer logs at the moment of disconnection), while those who (for some reason) are not affected can confirm the region did not crash.
The problem here is that this kind of incident can be mistaken for a local disconnect or a viewer crash, and so may pass unreported. If you are on a region and suffer a disconnect along with others all at the same time and / or are disconnected multiple times from the same region along with others, please file a JIRA with the specific details of what happened, and append your viewer log files.