My apologies for this appearing a little on the late side; things have been a bit manic in the physical world of late (not helped by the Tour de France and the German GP this weekend!), and I’ve been slipping behind on blog posts (I’ve also got to talk to my minions about vacation scheduling….).
Note that the following notes are taken from both the Server Beta User Group meeting of Thursday July 17th and the TPV developer meeting on Friday July 18th, the video of which is supplied below (my thanks to North, as always). Items taken from the later are time stamped within the text, so you can locate and listen to the discussion in full via the video.
Server Deployments Week 29 – Recap
- On Tuesday July 15th, the Main channel was updated with the Experience Keys project, which had previously been running on Magnum. This roll-out coincides with the release of the Experience Keys project viewer (see below) and the release of the Lab’s first Experience Keys demonstrator game, The Cornfield. Please refer to the release notes for further information
- On Wednesday July 16th, the Magnum RC was updated a new infrastructure project that adds support for the upcoming changes to the Skill Gaming policy. Release notes
- On Thursday July 17th, BlueSteel and LeTigre were both be updated with the Experience Keys project, but otherwise remained on the same server maintenance project as week 28, which addresses a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects. See the release notes (BlueSteel) for details.
Group Ban Viewer
The Group Ban viewer reached release candidate status on Wednesday July 16th, with the release of version 126.96.36.1992031. This viewer allows certain group members to ban avatar from a group or from joining a group When an existing group member is banned, they are also automatically ejected from the group. Please refer to my Group Bans overview for further information, if required.
Maintenance Release RC
[04:20] This viewer, version 188.8.131.521824, has been tracking with the same crash rate as the current release viewer (184.108.40.2061465), and as such is expected to be promoted to the de facto release during week 30 (week commencing Monday July 21st). However, it has been reported that the Mac Alt-Cam bug (BUG-6760) fix doesn’t work and has been referred back to the Lab for further investigation.
Oculus Rift Project Viewer
[04:56] It is anticipated that an updated version of the Oculus Rift project viewer will be appearing soon, potentially in week 30. The update will bring the viewer up to par with the current 3.7.12 release code base.
Log-in Test Viewer
[04:44] There is a special log-in test viewer currently on closed use (there is no publicly available version), which is being used for some kind of A/B testing related to logging-in to Second Life. Precisely what this testing is geared towards is unclear.
Viewer Autobuild Process
[05:50] Oz Linden has been working on improving the viewer autobuild process, and there is a new version of autobuild, together with a wiki page on the changes and improvements. The new version brings with it a number of improvements, such as stricter library version checking, full transitive dependency checks, additional error checks, etc. This is considered to be one of the steps required in order for the viewer to be compiled using Visual Studio 2013. Full details in the video for those into self-compiling viewers.
Third-party Viewer Directory Updates
[00:20] The Third-party Viewer Directory, which lists all Second Life viewers and clients which have gone through the self-certification process, has been revised.
Until recently, the directory was listed by viewer crash rate – with the most stable at the top. However, this was something of a hit-and-miss approach due to a number of factors, including significant changes made to the code within the viewer which is used to detect and report crashes. So instead, viewer and clients are now split into three categories:
- Those which are actively maintained “full” viewers which are updated regularly to track new developments in the Linden Lab viewer, and implement a full graphical environment
- “Lightweight”, text and mobile clients, such as Lumiya, Group Tools, Radegast and so on
- Those viewers which have not been updated recently enough to be considered fully compatible with current Second Life services (e.g. they lack things like server-side appearance, etc.).
[11:56] Work is continuing on group chat. At the TPV Developer meeting, Oz Linden summarised this work as:
We are working on group chat; I don’t really have much to report on that this week. We’re doing a set of experiments and collecting a lot of data, and then we’re going to come up with the next round of changes to make. One of the things we’ll try to do, once we think we’re done with this project – and I have no predictions for when that will be – is tell people how it went and what we’ve done.
It may well be that before we’re done, we’ll come back to this group and say we’re making changes to interfaces to viewers for group chat in order to improve the situation. I don’t know of any of those yet, but I’m not ruling them out. We’re going to try to make group chat a lot better, and if that means not being 100% backwards compatible, then that’s what it means. At this point we’re not looking at changing the protocol with anything else. Not ruling it out, but that’s not the correct direction.
The current creator beta programme for Experience Keys has now been filled. Commenting on it at the Server Beta meeting, Coyot Linden referred to it as proving “wildly popular” and that the Lab have “heard some really cool ideas for new experiences”. He also referred to this being “round on” of the beta programme – so there may be more opportunities for creators to be involved in the future.
During the Server Beta meeting, a request was made for the Linden to consider allowing the popularity of an Experience (e.g. the number of people engaged on it) to be made available, with the suggestion it could be done in a number of ways:
- As information made available only to the Experience owner (so they can see how popular a given experience they’ve created is proving to be
- As information which can be (perhaps optionally) published by the Experience owner (e.g. via the Experience Profile)
- As information which can be displayed in the Search tab of the Experience floater, allowing users to search for the most popular experiences at any given time.
Commenting on this, Simon Linden said, “The numbers will definitely be interesting, but we’ll have to think carefully about what and how to expose it. As an owner, it makes sense for you to have an idea what’s going on with your experience. I’m not so sure about others.”
Part of the concern here is about the popularity figure potentially being used by griefers as a means of targeting popular regions / activities and causing disruption. Following Simon’s observation, Dolphin Linden added, “yeah, technically the number can be made available. But how and to whom needs to be thought about, but numbers about your own xp can be tracked if you want with a little bit of work. We might also be able to just get an ordered list of the top 10 experiences or something, without disclosing actual numbers.”
[27:45] Monty Linden is continuing to work on the HTTP project, which involves both viewer and server-side work. Concerns have been raised about a possible issue in serving textures and meshes over HTTP in regions with more than 20 avatars. Commenting on this, Monty said:
There is a server part coming up in the work ahead, mostly having to do with the fact that we throttle certain asset downloads, meshes and textures, and I’m going to be revisiting that a little bit. The problem with load, though, is beyond that. It is something I’ve also been looking at for the past two years and getting data and getting various people ramped-up on. And that’s also going to get looked at in the future.
He went on to say that the HTTP pipelining work is looking stable and robust, with internal testing delivering some impressive figures in terms of downloads and speeds. While these won’t be matched to the same degree over the links between a viewer and the Lab’s servers, the work should still result in visible improvements for people, particularly those further away from the Lab’s data centres. There is, however, further work involved, some of which goes beyond pipelining itself.
Z-offset Height Adjustment Proposal
[14:06] This was first raised at the last TPV Developer meeting as a means of providing the Lab with a clear understanding as to why an “on-the-fly” ability to adjust an avatar’s height offset is still required, despite the Lab’s provisioning of the hover function. Commenting on this at the TPV Developer meeting, Oz said:
We did have a very good and illuminating discussion, illuminating to me, personally, in which the people who understand it as well as anyone does, gave me a very thorough briefing on all of the things that contribute to the avatar hover problems. We had a good discussion based on the suggestion that we got at the last TPV meeting a month ago, and I hope to be able to actually do something about that. I’m still not committed to any particular solution, but I am certainly convinced we need to find a solution, and I’ve got somebody exploring what the shape of that solution might be. That will certainly require viewer updates.
While the work is not yet a committed activity on the part of the Lab – although Oz, as he states, would like to see it resolved – it was further indicated that it would likely require TPV developers to assist with any viewer-side changes which might be required.
BUG-6648 Animated Agents Appearing at 0,0,0
The recent viewer-side interest list updates seem to have caused a bug somewhat similar in nature to an issue first reported in 2013. In BUG-6648, avatars animated at altitude or seated are randomly appear to be at 0,0,0 on both the mini-map and when zoomed-in. Commenting on the problem during the Server Beta meeting, Simon Linden said, “I think I have an idea what’s going on, but am not sure when I can take a look. I believe there’s an update getting lost or out of order … when you sit on something, your position becomes relative to that object. If the viewer doesn’t understand that, you end up looking like you’re near 0,0,0.”
BUG-6382 Persistent Blurred Textures
Those using viewers with the latest Sunshine updates (e.g. 220.127.116.110582) are seeing issues where textures will randomly fail to fully load and render (see BUG-6382). This is not the same as the oft-reported texture thrashing issue, where the textures may be constantly re-loading. Instead, the affected textures simply never fully render and remain blurred, with the texture console showing no activity. Relogging or teleporting away / back can clear the issue, and tests have shown the problem doesn’t occur with version of the viewer that predate the 3.7.9 updates.
Commenting on the issue at the Server Beta meeting, Simon could only say, “Someone is working on 6382 now – and yeah, it’s ugly since it’s difficult to reproduce.”
[19:00] At the TPV Developer meeting, Oz further added:
Despite many hours spent on it, It is proving distressingly difficult to actually get an analysis of what is going on … It seems to be very much aggravated by having lots of users around, on the same sim or in sims on the same host. So you may be in an empty region, but your sim is running on a sim host that has got some gigantic party going on, and you’ll get the effect. But it’s really difficult to reproduce in a controlled way. We’re doing some other experiments, but i can’t offer you any hope that there’s going to be any fix in-hand any time soon.
BUG-6487 “Wear ” Behaves Erratically
This issue (see BUG-6487) appears to be related to the AIS v3 updates. When using the inventory
WEAR option to attach an item to an avatar should, when there is an item already occupying the specified attachment point, replace that item with the one being worn. However, with this bug, see in viewer 18.104.22.1681134, using
WEAR in this situation can result in one of two situations:
- Both of the items will appear attached at the same attachment point – which is the expected behaviour if
ADD, rather than
WEARhad been used for the second item
- The selected object replaces the original object (the expected behaviour when using
WEAR), but the original item is listed in inventory as “worn on invalid Attachment Point”.
while this issue is still subject to further investigation by the Lab, user-led testing has shown that this issue does not occur on Aditi regions which are not running the server-side AIS v3 updates.
Assorted Other Items
The following are not necessarily currently high on the Lab’s priority list / may not be subject to work or focus at present, however they may become projects within the Lab at some point:
- Finding out and correcting why changing group tags seems to resolve a wide range of problems
- Possibly implementing an “avatar awareness” capability (aka radar) within the official viewer, which may not be as feature-rich as some TPV radars, but which would be aimed towards helping users locate people, and for identifying who might be the deliberate or accidental cause of problems
- Mac keystroke entry lag issue: the Lab believes that this is a Mac problem rather than specific to the viewer, given the same problem occurring when using the Safari browser, etc., and they have not been able to find an instance of the issue which is clearly identifiable as an issue within the viewer