Viewers

Brains and Beauty – Whirly @ Server Scripting 2014-31

The Zip RC Viewer came back Wednesday. This is the fast install viewer. The release notes say there is a fix for the XUI Preview Tool… I think that fix has something to do with previewing user interface changes. It also got all the updates now in the main SL Viewer 3.7.12.

Experience Tools

For the everyday SL user there isn’t much news here. The testing in Beta is progressing. The Lindens are deciding if they need more testing or will move toward ‘experience users’ testing. Currently they are working with experience creators. The Cornfield Experience is a test with the experience users.

The next stage of Beta testing will turn users loose on user created experiences. If there are any serious problems they should turn up during that stage of testing.

Currently Experience Keys have to be white-listed to run in a region. There are currently no grid wide keys. There will be in the future, unless something changes. It will however be possible to black-list experiences from a region/parcel.

Recent information from Oz conflicts with information provided by Dolphin Linden a couple of weeks ago. It is hard to know if someone is confused or if things have changed or will change. My question to Oz/Simon on the point went unanswered. A few of us have the same understanding from listening to Dolphin. But, Oz says it isn’t that way. So, I’ll have to wait to see what we eventually get.

Some testing by Lucia Nightfire seems to show Oz is mistaken. (See: 12:30 in UG transcript 7/29)

The point in debate is whether I can compile an experience script with my Experience Key, put it in an object then distribute the object to others without the Experience Key and they can still have it work when they rez it. This is a case of where object ownership changes. This subtle distinction makes a big difference in how the Experiences Tools can be used. Lucia’s testing supports what Dolphin told us. But, does what Oz said mean a change is coming? I hope not.

Group Chat

The Lindens are still studying and tweaking on group chat. Changes have been made. The Lindens have found several bottlenecks. They are looking for ways to remove the bottlenecks.

One of those has to do with how the system handles logging into and out of group chat. A huge amount of work is generated for status updates as users sign in an out of group chat. So, this is now an obvious area to target for improvements.

We have learned that the backend hardware running group chat is scheduled to be upgraded. No ETA.

I would guess this whole group chat thing is going to be a research project that feeds into both SL1 and 2 development.

I hear many people say just use IRC (Internet Relay Chat). If you are participating in OSGrid you probably use IRC to ask questions. It works well. But, I don’t know of any IRC that has tens of thousands of permanent members and checks the status of all those participants each time one logs in or out. So, SL has some complications that IRC groups don’t. So, the Lindens have to figure out how to provide the chat we have in a smarter way. And that way is likely to be used in SL2 also. I suspect that means this is going to be a focus point for both teams, SL 1 & 2. We will probably see some big improvements over the next 12 months.

Prim Problems

There is a problem when you use alpha and prims to animate or change things. Some use cases require making prims in a linkset visible and invisible. But, when large sets of prims are used they don’t always behave. Some avatar attachments use alpha swapping to create the desired effect. So, we see the problem in both objects in SL and avatar attachments.

In some cases some of the prims don’t update when the swap is made. That seems to happen across all viewers. But, there is some question about that. In some viewers some people don’t see the problem while others in other viewers do see it.

Those that have their bandwidth turned down to 500 kbps see the problem more often and those with it turned up don’t see it.

I suspect this is a server update message delivery-receive  problem. Fortunately it is up to the Lindens to figure this out.

Bandwidth

The viewer has a max bandwidth setting (Preferences->Setup). The setting only affects the UDP data flow. The default value is 500. In Debug Settings I believe the value is named: UpdaterMaximumBandwidth.

For some time the Firestorm Team has preached to not set the value above 1500 kbps. However, Simon Linden says 3 mbps is a secret magic number which sets a dont-bother-to-go-higher flag. Setting higher values does nothing. For this to be used you must have a connection to SL that delivers 3 mbps or better end to end. For many of us that means 1500 is the upper limit we’ll use.

The Firestorm Team adopted the doctrine of using 1500 because they saw communications choke at higher settings and have a hard time recovering. Their rule is to set the value at 80% of you max download speed or 1500 whichever is smaller.

Simon’s information would suggest that those with good connections to SL (not the same thing as a good Internet connection) could increase the setting. You can experiment to see what works best for you.