Another third party Viewer meeting and some more interesting news.
The Lindens have promoted the Maintenance RC viewer to the main release. That makes the main viewer 3.6.7-281793. You can see the release notes here.
This release has improvements for avatar render speed and other fixes and improvements. Most notable are:
- Automatic avatar render limit and feedback system
- rendering optimizations
- avatar render cost information
- simple impostors
- graphics pref update
- new debug setting “RenderAutoMuteRenderCostLimit” sets render cost cutoff point (default 0 = disabled cutoff check)
- Extra particle parameters: http://wiki.secondlife.com/wiki/LlParticleSystem
- Orientation data no longer lost on TP
- Multiple Crash fixes
- Cocoa regressions fixed
- Bugfixes – Lots of fixes. See the release notes.
The other RC Viewers will get the code from this release rolled into them. In this case “them” is four RC viewers. The four are:
- Google Brakepad version 3.6.7 – 281561
- Mac 10.6 Viewer version 3.6.4 – 280048
- Share Viewer version 3.6.7 – 281331
- Snowstorm Viewer version 3.6.7 – 281414
If you’re using Mac 10.6 you have probably seen some unusual update behavior. Lindens ran into some problems and did some forced downgrade updates. Confused? They used the viewer pipeline that normally upgrades new or versions to force a rollback. Now they’ve change that rollback to an optional back in use will have a choice. Only some Mac 10 users were affected by bugs in the viewer.
Mac users should be made aware that the viewer crashes far fewer times on Mac 10.7 and 10.8. I hear that on the app store one can get Mac updates for $50.
Oz Linden said he did the update from 10.6 to 10.7 and later to 10.8 and it was really easy. Push the button, wait five minutes, and it’s done.
Apple has a fairly aggressive dropped the old stuff policy. So, check your hardware will handle a new OS before attempting an upgrade.
Inventory Service Version 3
Brooke and Don Linden were at the meeting to explain changes to the Inventory Services. These are not changes users are going to see anytime soon. When we do see these changes, it will be as less bake fails.
Inventory service is getting new API’s. They call this version 3. The point of the API’ s is to better handle the Current Outfit Folder. The service will first rollout on ADITI. We may see it first appear during week 41.
Another aspect to the change is the removal of a bottleneck. The new API’s allow the viewer to go directly to the inventory services. As it is now there is a data server that handles multiple simulators inventory requests. It is a single threaded data server process. So, busy regions where people are changing appearance can get bottlenecked.
So, we may see a bit of improvement in the performance of our inventories when cleaning or rearranging.
You probably already know that most of our bake fail problems are currently coming from how inventory services are handling the Current Outfit Folder. The new API’s are an attempt to solve that problem. Don explains more of the technical aspects of the problem, which are more than I want to get into. Mostly it has to do with Internet protocols and problems with the current UDP verses the new HTTP protocols the viewer is being moved to. (TM-4:30).
The existing API’s will remain in place. But, new viewers will eventually rely mostly on the new API’s.
At this time the code is just becoming available to third party viewer developers. This means we’re weeks away from even seeing a Linden SL Viewer that uses the new API’s.
Baker Linden was at the meeting to explain where he is at with Group Bans. The code is going into internal testing, QA. Baker is turning to writing and documentation for the new code.
This is the feature that will allow group owners to ban up to 500 people. The list of banned people will be maintained on the server. As long as avatars are in that list they cannot join the group.
You will also be able to preemptively ban people. You will have to wait until they’re in a group creating a problem to ban them. If you know they are a problem, you can enter their name into the list at any time.
The Invite Panel’s going to allow you to invite or ban people. So using the banned list should be easy.
The banned list will basically show the avatar name and the date banned. Eventually the list will also include a reason for the banning. Baker’s not exactly sure how he wants to implements the reason field. It is already built into the database. His thinking for now is that reasons will be from a list of drop downs with five or so reasons.
There is no time-period banning, meaning you can’t ban someone for two weeks. Baker felt the amount work he would have to do on the viewer and the server side would outweigh the user time saved. Of course, all that additional work would delay releasing the ban list. It’s already taken quite a while to get the feature out. AFAIK, this is the biggest project bakers worked on. So he was learning a lot about the servers and the viewer.
Developers in the TPV meeting felt the simple ban tool is best. They wanted Baker to forget adding the time expiration bans and get the simple feature out.
So who gets to ban people from the group? By default group owners. But, they will be able to grant the right to other members of the group. So, there will be a new ability in the abilities list for various roles. Those with the ability will be able to ban and un-ban people. There will be bulk un-ban.
On the table is the possibility of adding LSL functions. This would allow scripters to write scripts to automatically handle some of the banning. So, it may be possible to write a script that would handle time oriented bands. But, that’s not something we are going to see in the first release. Baker has been thinking about it.
This new features can have some notices. If the user tries to join a group from which they are banned, they will get noticed that says you can’t join because you are banned. If a group member attempts to invite a band person into the group they will get a notice that they’re trying to invite a banned person.
There’s some debate about whether or not to send a notice when the person is banned. Current thinking is that is going to create a lot of drama. So, some think it’s unnecessary. But, there’s no final decision on that point.
The current ban function adds a name to the banned list and ejects the avatar. There is a bug in the eject function that allows the person to continue talking in chat. That bug has not yet been fixed. So, will see the same problem with man that we see with eject. Group moderators will still need to mute the person that was just banned/ejected. I suppose that will eventually get fixed.
While dating to the server in working on the code to handle banning people Baker fixed some other bugs to be found. One of those is removing people from your mute list or block list. Now when you remove them they will actually be removed.
There has also been a problem where people have been putting spaces before their Display Name. Baker’s fixed it so that’s no longer possible. In the situation for regular spaces Unicode spaces and other flavors of spaces have been handled in the process.
Richard Linden was to appear to talk about the interest list changes that are coming. But scheduling conflicts or something prevented that. So, that information is scheduled for a meeting next Friday in week 41.
We should see an RC viewer for the interest in this project in week 41.
The Lindens are recommending support personnel or the someone from support management be at the next meeting. Lindens think there may be some changes in how stuff renders. So, they won’t support people be aware of what they may be running into and how to report it.