A new SL project viewer was released on September 3rd. The Snowstorm Project viewer 3.6.5.280476, brings with it a number of issue fixes, and includes two capabilities new to the viewer:
A “request teleport” feature (STORM-1838) contributed by Jonathan Yap, which allows users to request a teleport form another user (currently with caveats – see below)
A group eject confirmation pop-up (STORM-1952), submitted by Cinder Roxley, which some may be familiar with from using TPVs such as Firestorm.
Request Teleport
The new request teleport capability, which I first reported on back in week 4, requires both viewers to be using the code for it to work (so for the time being it is limited to the project viewer). Where this is the case:
Select the person to whom you wish to teleport (from your Friends list or Nearby list, etc.), and select Request Teleport
Enter a message in the pop-up, if required, and click OK.
Request teleport: making a request
At the “other end” the recipient of the request will receive the request as an initial pop-up notification and within CHUI:
Receiving a teleport request – pop-up and CHUI message
The recipient can than either accept the request, sending a teleport offer, or reject it, in which case no message is sent.
The teleport offer is again displayed in the requester’s viewer as both as an initial pop-up notification (below) and within CHUI.
Receiving the teleport offer
Note again, that the system will only work where both viewers are running the new code (e.g. the Snowstorm project viewer for the time being). If someone on a viewer with the capability to someone using a viewer which does not have the teleport request code, the request will not be received / displayed.
Group Eject Confirmation
The group eject confirmation sees the official viewer get a new pop-up asking for confirmation when ejecting someone from a group, in order to help with issues where the wrong name is selected and ejected.
The new group eject confirmation pop-up for the official viewer
Again, as noted above, the release notes for the viewer provide a full list of updates in the viewer.
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel – Tuesday August 27th
The Main channel received the update package which includes the “grey box” attachment fix, and which had seen previous deployment to some of the RCs. In all, the package comprises:
A fix for the “grey box attachment issue” (non-public BUG-3547, see the details here)
An update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”, (non-public JIRA BUG-3291)
Code to block avatars entering a region / objects being rezzed in a region during the last 60 seconds before a restart. In addition, restart warning pop-ups will include the region name
Fixes for further simulator crash modes.
Release Candidate Channels – Wednesday August 28th
All three RC channel should receive the same maintenance package comprising:
An update to region restarts initiated by region owners or estate managers which will see the region restart after the last avatar leaves, rather than waiting for the full countdown period to complete
Preparatory work to support new estate and parcel access controls – these will require a upcoming viewer-side update in order to be visible to users
Commenting on the upcoming estate and parcel access controls at the Simulator User Group meeting on Tuesday 27th August, Simon Linden said, “I can’t get into details on the access change but it’s not a huge one, so don’t get too excited about it. We hope to have a project viewer out in a few weeks or so that will have the new code and we can discuss it then.”
SL Viewer Updates
Release Viewer Updated
Following the Monday review meeting, CHUIStorm Release Candidate viewer was promoted to the de facto release viewer 3.6.4.280048, dated August 20th) on the 26/27th August. This viewer includes the latest CHUI updates from the Lab and a number of Snowstorm code contributions from third-party developers, including:
STORM-1892 – Add Apply button to the edit content permission floater
STORM-1910 – Count of the number of groups a person has joined, and number of remaining group slots
STORM-1911 – Go-to line function for the internal LSL script editor
STORM-1918 – Part of the group notice attachment box does not allow dropping of assets
STORM-1952 – Clicking “Eject” needs a confirmation before execution when ejecting members from a group
The full list of updates are available in the release notes.
The move currently leaves two RC viewers in the release channel: the Cocoa updates for Mac builds, and the next round of updates for Materials Processing, which include goodies such as correct ALM rendering underwater.
Commenting on the removal of the Google Breakpad RC viewer from the list, Oz Linden confirmed that it had been removed as it had done its job, allowing the new reporting mechanism to be tested. As the viewer contains no user-facing changes or anything outside of the Breakpad updates, it has been withdrawn, and the new stats reporting code will be integrated into the viewer code base without requiring a dedicated release.
The mesh deformer project viewer has also been removed from the viewer test builds wiki page. There is not anything untoward about this; prior to the SSA deployment the viewer was already significantly behind the times in terms of merges. As SSA has now been deployed, and the view lacks SSA support, it is currently pointless having it as a publicly available download option.
Group Ban List
Baker Linden supplied a brief update to his work on creating a function to allow group owners to ban people (e.g. known troublemakers) from joining their open-enrollment groups. Speaking at the Simulator User Group meeting, he said:
I’ve still been hooking up the viewer to the server, and can now add people to the ban list. I’m currently working on getting the ban list, which will allow me to get deleting from the ban list working. After that, it’s code cleanup, reviews, and adding server-side verification checks!
To which Andrew Linden added, possibly wryly, “Baker banned me from some groups on the beta grid. I can attest that there is progress there”!
The question was again asked if the capability will allow for banning someone for a set period of time – such as for a week. Baker confirmed that while the ability to do so won’t be in the first release, there is a code stub included which will allow him to add the ability in the future. This is likely to be the case with the ability for a group moderator to add a reason for banning someone from the group if they so wish.
Anti-griefing
As he has now moved away from Interest List work for the time being, Andrew Linden is looking into griefing vectors and ways and means of circumventing them, particularly on mainland. Some of the areas he’s looking at and mulling over in terms of possible actions are:
Andrew Linden – now looking into anti-griefing options
Allowing estate owners to admin parcel properties (ban lists, object options, etc), without having to take ownership of the parcel
Altering the “allow public to build on this land” flag to default to FALSE rather than TRUE when a parcel transitions to a new owner – this is seen as a means of preventing griefers from buildings and hiding hide malicious objects in unattended parcels which can then be used to grief the region / people in the region.
Nerf the use of recursive rezzing to prevent griefers getting around autoreturn by creating an object which rezzes a copy of itself, then gives a copy to the rezzed object. The original is then autoreturned, but the copy carries on before creating a copy of itself, and so on.
Andrew is particularly concerned that the third proposal might be damaging to content which may legitimately self-replicate itself (such as items placed by the parcel owner or members of the group the land has been deeded to). In order to prevent this, he plans to apply the nerfing only to objects to which the auto return would otherwise apply.
At the moment these ideas are still musings – although Andrew admitted the code for nerfing recursive rezzing has already been written – and he’ll be having further discussions at the Lab as well as looking at various alternatives / additions (one he mentioned himself was to perhaps have two auto return functions – one for objects whose owners in the region, and one for those lacking owners).
One of the problems here is that in planning to create any additional restrictions on land use, etc., is that people can always raise apparently legitimate reasons why things shouldn’t be done, or offer up ways and means of how changes can be circumvented. However, the fact remains that griefing – particularly on mainland – is once again a growing issue (as those of us have experienced only too well at recent in-world LL meetings). Therefore, change is needed. The skill in the work will be how that change is managed.
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel – Tuesday August 20th
The Main channel had Server-side Appearance (SSA) enabled, as per this blog post from the Lab. As I’ve previously noted, users will need to run a maintained viewer which incorporates the SSA code in order for other avatars to render correctly in their view. See the release notes for additional information to the above links.
There were no other updates in this deployment.
Release Candidate Channels – Wednesday August 21st
Magnum should receive a new maintenance package which “only includes a few internal bug fixes which shouldn’t show any visible changes to the residents”. In describing this at the Simulator User Group meeting on Tuesday August 13th, Simon Linden said, “There’s one performance fix that you might see in the viewer … you shouldn’t get those situations where you see lots of ‘duplicate caps. messages” – this package was deployed to LeTigre in week 33
Bluesteel and LeTigre will both be on an update to the package deployed to BlueSteel in week 33, which includes:
A fix for the “grey box attachment issue” (non-public BUG-3547, details below)
A (further?) update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”, which was also listed in the BlueSteel release notes for week 32 (non-public JIRA BUG-3291)
The code to block avatars entering a region / objects being rezzed in a region during the last 60-seconds before a restart. In addition, restart warning pop-ups will include the region name. This was again in the release notes for week 32, so would appear to be a further update to that code
Fixes for further simulator crash modes.
Further, all three RC channels will have Server-side Appearance enabled at the conclusion of the Wednesday August 21st deployments.
SL Viewer Updates
Release Viewer Updated
Tuesday August 20th saw a new update to the de facto release viewer, when the former Maintenance Viewer RC 3.6.3.279564, dated August 12th, was promoted. The full list of updates for this release can be found in the release notes. However, of most interest to many will be the fact that it includes the particle selection capability.
As previously reported in these updates, this capability (MAINT-2268) allows a user to right-click on a particle emitter and mute it, blocking the particle emissions from their viewer. This is liable to be very welcome to those using regions which are frequently the target of particle griefing, as it means that the emitter itself no longer needs to be located and blocked. In addition, the new code has a FPS limit on particles, and will stop generating new particles when frame rates drop to 4 FPS or lower.
Other SL Viewer Updates
The promotion of the Maintenance Viewer RC to release status leaves four remaining release candidate viewers at this time: CHUI, the MAC-focused Cocoa RC viewer, the Google Breakpad RC for better crash / stats reporting and the Snowstorm RC, which contains updates contributed to LL by third-party developers. As is now the practice, these will each be rebuilt using the “new” de facto release viewer code, and so will have updates appearing over the coming days.
Oculus Rift
Oculus Rift – UI work progressing at the Lab
Work is progressing with integrating Oculus Rift with Second Life. While I’m not overly interested in the Rift myself, one are that does interest me is that of the UI and how it is going to be integrated with the headset – as I’ve commented in the past, while others see it as a potential issue, I don’t necessarily agree, although I’ve felt that a balance would have to be struck in order to avoid the UI completely overwhelming / spoiling the first-person view.
Speaking at the Simulator User Group meeting on Tuesday August 20th, Simon Linden indicated that this is on the Lab’s collective mind as well – and that a potentially clever solution is being tried-out to ensure the UI menus, etc., are usable without interfering with the user’s view of things:
I know recently they were working on how to have the SL UI appear … having menus hanging out in your vision is an interesting design, but you’re not in a “window” anymore … In the Rift it’s projected on a surface around you … so you look up to see the menus and they float there in mid-air … I think they’re experimenting with the shape of that surface too … if it’s flat, the text can look funny as it’s slanting away from you.
This, I have to say, does sound intriguing, and I’d be curious to see it in action; if nothing else, it gets me thinking somewhat of Bruce Branit’s World Builder – although admittedly, the protagonist in that piece is physically “inside” his virtual realm…
If nothing else, that gives me an excuse to post the new HD version of World Builder Bruce posted to his YouTube channel earlier this month (yes, I know it’s not the first time I’ve posted it, but I do love the movie).
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
As noted in part 1 of this report, there was no deployment to the Main channel in week 33, as a result of the “grey box” attachment issue appearing in the week 32 BlueSteel deployment
The Magnum RC channel remained on SSA, with no other updates
The LeTigre RC received a new server maintenance package with “under the hood changes” which should not be visible / perceptible to users. This package saw the removal of SSA from LeTigre – Caleb Linden apologised at the Server Beta meeting for the confusion this caused as the forum thread & release notes did not initially make it clear
The BlueSteel RC received further updates to the fixes released in week 32 and the fix for the “grey box” attachment issue
Viewer Updates
The CHUI RC viewer updated to release 3.6.3.279849 on August 15th (download & release notes). The Materials project viewer also underwent a further update to release 3.6.3.279904 on August 16 (download & release notes).
Server-side Appearance
As noted above, SSA is currently only enabled on Magnum for the time being. A decision will be made on Monday August 19th on server-side updates and deployments, and until then the Lab is keeping quiet as to what may or may not happen in terms of SSA enabling. However, from comments passed in recent discussions and a hint in the forum deployment thread, it would appear that if the data obtained from Magnum during the week remains solid, SSA might be considered ready for “prime time” in week 34.
The removal of SSA from LeTigre did cause some confusion, with at least one JIRA (SUN-109) being raised as a result. Given the JIRA refers to the slowness of avatar rendering, rather than to any overall failures (which shouldn’t happen anyway, given the viewer code is currently backwards compatible with the “old” avatar baking service), this tends to point to the fact that the rapid nature of SSA baking is being appreciated.
Group Ban list
The obligatory Baker Linden shot 🙂
“Group bans are coming along pretty well,” Baker Linden informed his ‘Thursday after meeting class’. He went on:
I chose to take the rest of this week to improve the code rather than continue progressing. I really hated copying an entire source file without trying to refactor it … So now it’s refactoring, cleaning up, and after that the viewer will be finished. Well, I need to add the functionality to some other subsystems and have it actually send an HTTP message but that stuff is all stubbed in anyway.
Some of the cleaning up work apparently involves removing the, umm, colourful metaphors he used when first commenting on the code to highlight those bits he wanted to poke about at. These have apparently been causing a few giggles among those able to peek into the repository!
Given the work is still ongoing, there is no ETA for a project or beta viewer as yet, and this may be delayed a little more while Baker considers the problem of group chat.
Because of the way in which group chat works, anyone who is removed from a group while they have the group chat window open is actually able to continue chatting / spamming within the group until they close the group chat window, unless the group moderator remembers to block them from chat first. This hadn’t been on Baker’s radar, and he’s going to take a look around and see what can / needs to be done to try to make sure the group ban function won’t suffer this weakness, if possible.
As always, please refer to the week’s forum deployment thread for news, updates and feedback.
Second Life Server (SLS Main) Channel – Tuesday August 13th
There was no update to the Main channel. It had been anticipated that the package deployed to BlueSteel in week 32 would reach the Main channel this week, but this is not the case, for the reason given below (see the Grey Box Attachment issue notes, below),
Release Candidate Channels – Wednesday August 14th
Magnum remains with SSA enabled, but otherwise received no further updates.
LeTigre should receive a new maintenance package which “only includes a few internal bug fixes which shouldn’t show any visible changes to the residents”. In describing this at the Simulator User Group meeting on Tuesday August 13th, Simon Linden said, “There’s one performance fix that you might see in the viewer … you shouldn’t get those situations where you see lots of ‘duplicate caps. messages”
Bluesteel should receive a new server maintenance package comprising:
A fix for the “grey box attachment issue” (non-public BUG-3547, details below)
A (further?) update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”, which was also listed in the BlueSteel release notes for week 32 (non-public JIRA BUG-3291)
The code to block avatars entering a region / objects being rezzed in a region during the last 60-seconds before a restart. In addition, restart warning pop-ups will include the region name. This was again in the release notes for week 32, so would appear to be a further update to that code
Fixes for further simulator crash modes.
“Grey Box” Attachment Issue
This is a problem whereby a grey prim appears around any passenger(s) sitting on a boat / vehicle when crossing from a BlueSteel region to any other region (including another BlueSteel region) – the driver / pilot is left unchanged. The affected avatar has no control and requires a relog, while the prim itself appears to be linked to vehicle when edited.
The “grey box attachment issue” (image courtesy of Jen Cuddihy via the SL forums)
It is thought the bug was introduced during the week 32 BlueSteel deployment, and Simon Linden indicated it was the reason there was no Main channel deployment for week 33, saying:
We didn’t update the main channel today. There was a bug found involving vehicles and region crossings that needed to be fixed, so that update will go out tomorrow [the BlueSteel RC deployment]. Basically, don’t sit more than 1 person on a vehicle when leaving a BlueSteel region, otherwise it turns you into a box :P. It happens to the 2nd (and probably more, if you had a crowd) person seated on the object.
Kelly Linden explained what was happening to cause this:
Every agent has a ‘task’ representation on the server that is the same as a prim. The bug is in sending the linked set w/ avatars to the other region: avatars after the first are losing the special avatar treatment and getting passed as a regular linked prim. So that prim is what the server thinks all avatars look like.
Simon added:
The region crossing code basically un-sits avatars from an object, sends both the avatars and object to the next region [as separate sets of data], which puts them back together. In this case, the 2nd avatar doesn’t get detached properly and things go south from there. So the 2nd avatar gets sent over bundled up with the object … which it’s not designed to do.
The additional avatars on the vehicle at the time of the region crossing essentially end-up in limbo, with data caught between the two simulators. “The regions are very confused about that avatar data by that point, I’m sure a relog would be needed,” Simon said.
An interesting side-effect of this is that the bug makes it possible to exceed the 256-prim linkset limit – sort-of. Enterprising individuals have realised that if you rez a 256-prim linkset, sit a number of avatars on it and move it across a region boundary, it will acquire an additional prim for each additional passenger over the first avatar to sit on it. However, the ability is of limited value; make any changes to the enlarged linkset, such as unlinking a child prim or trying to texture one of the greyprims, and the entire thing turns no modify / no copy – and the fix being deployed to BlueSteel should correct the problem anyway.
Server-side Appearance
Just as a reminder. There are no further SSA deployments planned for week 33. This is to allow for some back-end updates to be made to the SSA servers. These updates shouldn’t result in any visible difference to users on SSA-enabled regions, and are intended to fix a couple of scenarios where the viewer would have to re-try requests when it shouldn’t have to. The Lab wants to get these updates deployed to the SSA server prior to making any move to rolling-out SSA to the entire grid.
There have been comments on the forums that SSA “must” be encountering major problems as the deployment has been so protracted. This is not the case. Linden Lab (via Nyx Linden) have always stated that the deployment would proceed very, very cautiously because it is such a fundamental change in how Second Life functions. Even though the Lab has indicated that very, very few problems have been encountered with enabling the service so far, and the load testing on both Magnum and LeTigre (representing a little over 20% of the grid) has been very positive, they are sticking to their softly, softly approach.
Viewer Updates
As the Vivox updates became the de facto release viewer in week 32, the remaining five release candidate viewers in the viewer release channel have been underground rebuilding using the updated release viewer code base. On Monday August 12th, updates for both the Cocoa Viewer for Mac (version 3.6.3.279554 – download and release notes) and the Maintenance Viewer (version 3.6.3.279564 – download and release notes) were released.
Materials Project
The Materials Project viewer was updated to version 3.6.3.279651 on August 8th. This release lists a large number of fixes, perhaps most notably those related to problems with the appearance of alpha textures under both local lights and sunlight, and numerous issues with mesh rendering and lighting within the materials viewer. Please refer to the full list of JIRA items in the release notes linked-to above.
ALM Concerns
Concerns have been raised about performance issues as a result of having the Advanced Lighting Model (ALM) enabled by default (as is now frequently the case for most graphics cards, as is a requirement in order to see materials in use in-world).
The amount by which ALM can affect the user experience is variable, and subject to a lot of influences, not just the graphics cards / computer system the viewer is running on. Some people with systems similar to my own (see the panel on the right for my system spec), have noted “significant” impact when running with ALM enabled on a materials-capable viewer.
Part of the problem is the “ALM” is a very broad term, and other options within the viewer can influence performance, but will not impact the ability to see materials even if they are turned off – such as having shadows set to None, for example, or having water reflections set to Minimal and turning off local lights (via debug or Phototools, for example). So part of the problem is that of communicating what can be done from within the viewer to help offset performance impacts should they occur, but which don’t limit their ability to see materials in use.
Quick ways to improve performance when running in ALM to see materials. Top left: you can uncheck Ambient Occlusion, keep Shadows set to None and drop water reflections to Minimal. Bottom Left: Using Debug Settings from the Advanced Menu, set RenderLocalLights to FALSE. Right: Firestorm / Phototools, ambient occlusion, shadows, local lights and facelights can all be disabled from the Light tab and water reflections lowered from the WL tab
There are currently five viewer release candidates sitting in the viewer release channel. These are:
CHUI updates
Cocoa updates for the Mac version of the viewer
Google Breakpad updates (fixes and updates to improve the level of crash reporting from the viewer)
Maintenance viewer updates
Snowstorm updates (third-party contributions to the viewer)
As the first release candidate has now become the de facto viewer release (the Vivox updates, see part one of this report), all of the remaining release candidates are undergoing rebuilds using the “new” release viewer code base, and this is expected to be completed in week 33.
The current number of release candidates is considered to be atypical of the process, and reflects the fact that there is a backlog of viewer updates to be cleared. Once this has happened, it is anticipated that the number of release candidates within the viewer release channel will fall. In the meantime, it means we could be seeing new viewer releases (i.e. release candidates being promoted to the de facto release viewer) at the rate of one a week, depending upon how well individual RCs perform in user testing, until such time as the number of RC viewers becomes more manageable.
Installing Multiple Release Candidate Viewers & the Auto-updater
By default, release candidate viewers are intended to install / be installed into the same location as the de facto release viewer. Therefore, if you wish to run multiple RC viewers, you must install them manually into separate folders.
However, there is a problem in installing multiple RC viewer under windows, whereby the last location used to install a viewer is recorded by the installer (presumably as a registry setting), and the auto-updater will automatically use that location to install any update. So, if you manually install “Release Candidate B” into its own folder, and then receive an update for “Release Candidate A” (already installed on your PC) via the auto-updater, it will be installed into the folder containing “Release Candidate B”, overwriting it. This may even happen if the auto-updater is “disabled” within viewer preferences (see here for notes on how to avoid this).
At least one JIRA (non-public BUG-3522) has been raised against this issue. However, while LL are still investigating the problem, if it lies within the installer itself, it may not be addressed as there is an unwillingness at the Lab to get deeply involved in the mechanics of the installer.
Viewer Downgrades
There have been reports of the auto-updater mechanism forcing people to downgrade their installed viewer to an earlier release. While it “shouldn’t happen”, and may have been fixed, anyone who does experience the problem when auto-updating a viewer is asked to raise a bug report with as much information as possible on what happened (i.e. version being run before the update, version running after the update, date of update, etc.).
Making the Viewer Management System Available to TPVs
The Lab is experimenting with making the viewer management system available to TPVs if they wish to make use of it. This will mean that TPVs will have to port the code for use in their own viewer / environments, but it could help them with automating viewer updates if they don’t already have such a mechanism in place. One of the potential benefits of this for those TPVs following the Lab’s lead is that, as a result of changes also being made to the Lab’s reporting mechanisms, they will be able to receive a range of stats reports on their viewers directly from the Lab.
Settings.xml Changes
The current Snowstorm release candidate includes a change to how the settings.xml file works (the file which controls your viewer settings). This change will only affect those who have more than one Linden Lab viewer installed on the same computer (for example, someone who has the release viewer, a beta viewer and several project viewers installed), and will see all of the installed LL viewers using the same settings.xml file, rather than each creating a separate version of the file. This should prevent issues where the settings from one LL viewer are incorrectly applied to another, as can sometimes occur at present.
Interest List News
As noted in earlier parts of this report, Andrew Linden has wrapped-up his current work on interest lists. However, the project viewer for some of the work still has yet to appear, and is apparently still encountering problems getting through LL’s QA process. The code has been “real close” to being ready for release in some form on a number of occasions before getting kicked back for further work. The hope is that it will appear as a project viewer – or possibly a beta or release candidate – “soon”.
Inara Pey: Living in a Modemworld 