The Tuesday rollout to the main channels is going to happen, provided nothing goes wrong over the weekend. As of late Friday it looked as if the Magnum channel would roll to the main channel. That update contains these fixes:
- SVC-7641: Object on land sending excessive messages. The messages sent from the simulator about objects now contain location information, making them easier to find and return.
- SVC-8146: llRezAtRoot() does not set correct parameters (for sale) on rezzed object in Second Life RC BlueSteel 12.08.03.263047
- SVC-7641: Add object location info to messages, was “Object on land sending excessive messages”
- SVC-8124: Excessive “ParcelOverlay reliable” messages sent by regions since last rolling restart (2012-08-08)
- SVC-8136: Attachment point pelvis not being released
Magnum does contain the SVC-8124 fix that most acknowledge as the one that will fix the high bandwidth use problem.
Simon Linden says the code on Magnum has the same fixes as are on Blue Steel, but with more fixes. I think he means more fixes as in more work was done on the items listed rather than more items were added. But, more item fixes are listed as running on Blue Steel than Magnum. So, one is left wondering if Simon is a bit behind, skipping detail, I’m missing his point, or I figured it out.
A number of items being tested in Magnum are the same items being tested in Blue Steel. There are just more items in Blue Steel.
I think Le Tigre has some patches for some network exploits, but I can’t know for sure. Whatever is being tested it does not change the simulator behavior according to Andrew and Simon. That means the Lindens not directly related to the fix or suffering from a problem it fixes, have only a cursory interest and that seems to include Andrew and Simon. So, we aren’t going to hear lots of details and if we did they really wouldn’t mean much to us.
Interest List Stuff
Andrew Linden has been looking into how the interest list code decides when and what to send to the viewer for terrain. The code decides when to send the patches (portions) of terrain data, based on your camera position. The server streams the terrain to your viewer when you turn around, or when the terrain changes.
This means we are likely to eventually see some improvements in this area.
There is occasionally a problem with inventory where folders appear outside the root My Inventory folder. There is no way to get those folders back where they belong and in general things start to fail and not work as intended.
Andrew was working on a script to fix the problem, and I think some other minor inventory problems. He completed that script and it has made it through QA. It has propagated through the support channels and can be used by support to fix the problems.
So… if you have or hear of people with the folders problem, remember the fix is to file a trouble ticket with Support. They can fix now.
Get the word around.
There is the old problem of inventory items going missing. Andrew says, “All of the cases I’ve seen so far are actually caused by using a viewer that uses 1.23 protocols for downloading inventory. The solution is to [either] clear inventory cache, connect with a _good_ internet connection, and to refresh your inventory.
The problem is that if you’re getting lots of packet loss while your inventory is downloading it will probably never full download. And when you first open it up, it will start downloading lots of stuff. So you want to get it started, and just wait for it to think it’s complete.
In this case a ‘good’ connection is one that is not suffering packet loss while you’re trying to download your inventory. So… for best results: don’t overstate your true theoretical bandwidth in your viewer preferences. If you say you have a 2Gb bandwidth but you really only have 500kb, then the server will probably try to send more packets than you can handle, which can lead to packet loss.
If you’re getting packet loss while a 1.23 viewer is trying to download your inventory then you may ‘lose’ lots of inventory — it will not show up in the viewer, although it isn’t actually missing in the database. ”
Tankmaster Finesmith, one of the Firestorm/Phoenix developers, had some interesting comments on viewer bandwidth. He says the viewers are capped at 3,000kbps. So, the default preference of 10,000kbps makes no sense.
Also, he advises there are bugs in the viewer that get triggered when the bandwidth is set higher than around 1800-1900kbps. As I remember the bugs have to do with hanging up the UDP process and throwing more load on the servers, but I’m winging that from memory. Whatever, the take away is to keep you setting for Max Bandwidth at or below 1,500kbps. See: SH-3149 – Lower max selectable bandwidth to be in line with the max of the server.