Second Life and Virtual Worlds
On August 27 Firestorm 4.2.1 was released followed by an immediate OOPS! There is a problem that Tonya Souther describes as:
It turned out that 4.2.1 has a bug in it that makes most swinging doors not look like they act correctly (though they actually do). They appear to swing normally, then jump ahead, swinging farther all at once.
I’ve seen something similar in the Linden Development Viewers for some weeks now. So, this is probably not a Firestorm bug but something in the Linden Code.
Not much new news so far this week. We did learn a bit more about how the Materials System may be implemented.
Q: Will there be any veiwer settings requirements to see materials? such as lighting and shadows on. ac14 Hutson
A: I suppose Hutsom is asking will there be any visual settings dependencies. For instance having to have Lighting & Shadows on before you can turn on Sun/Moon shadows is a dependency.
A: Geenz Spad: Lighting & Shadows will be required, *however* you can disable the shadows part by setting that setting to “None”.
Update Note 2014-04-10: The Photo Tools are not part of the Firestorm Viewer and do not need to be installed.
I saw these tools mentioned on Hamlet’s New World Notes in an article titled: Want to Take Great SL Images? Get Mr. Weaver’s Phototools! These are tools made for the Firestorm Viewer (Firestorm 4.1.1 (28744) Jul 9 2012 21:43:46 (Firestorm-Release)). The tools will only work with the default skins.
This is an interesting addition to Firestorm. It is a rational and logical arrangement of the controls by William (paperwork) Weaver that affects how the viewer renders with world. If you are a photographer this is going to be a way handy tool. All the settings that affect the render appearance are in a single panel consisting of 6 tabs. Some of the controls open other panels, but basically it is one new panel, but what a handy panel.
First… there will be no MetaReality podcasts until September 24th, due to RL problems and RL work load. So, I doubt we will see an update on the Mesh Defomer before then. 🙁
If you use a Third Party Viewer (TPV), Second Life™ support can be really annoying. There are viewer problems and server side problems. If it is a server side problem, it really doesn’t matter which viewer you are using. Support should help out and get the problem fixed regardless of the viewer being used. That idea is taking root at the Lab.
Now that the MAJORITY of viewers in use are TPV’s, this problem is a significant pain. A process is starting to change that and hopefully reduce the problem. BUT… and this is a big butt… er but… first level support people have a hard time figuring out what are viewer and server side problems. So, some work is going into developing processes to help them decide.
To understand what is happening and what to expect one has to understand the problems support people face. One problem is the Lab’s support people are not trained in how to use or help with TPV’s. That would drive the support training costs and time requirements beyond anything reasonable. If only some TPV’s were supported to reduce cost and time required, there would be a load of drama about which viewers were selected. So, that means an all or nothing approach. It is going to come down on the nothing side.
Now Open: Second Life’s Firestorm Support Island by Firestorm/Phoenix – Click to visit.
Today is the official opening of the Firestorm Island. See: Firestorm Support Island Opening for more pictures and information. For information from an interview with Jessica Lyon see Inara Pey’s article: Helping the community: the Phoenix Firestorm Support region.
Update: Opening Speech.
Baker Linden got us some new information this week in the Server-Scripting UG on the fix for Large Group Editing Problems.
For the last two months he has been trying to solve the problem of getting large data sets to transfer reliably via the current API (application programming interface) running over UDP (an Internet protocol – think of it as a spoken language), which is the protocol all viewers use now to get group member lists. It is when that UDP transfer fails that people have problems with group member lists failing to load. Those failures also create some simulator side issues that degrade performance.
The practical limit for use with UDP is a member list of about 10,000 members. Any group larger will not reliably download. On some connections even the smaller 10k list will have problems. Sometimes larger lists will download. Sometimes they won’t. Baker has optimized the SQL query that pulls the list and eliminated as many timing problems as possible. I get the impression that several SQL tricks were tried, like breaking up queries and batching group of members for transfer were tried. But, in the end it simply is not going to work. So, the new API is going to use HTTP for the transfer. Eventually the UDP service tube for group member lists will be eliminated.