Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, December 17th
This summary is published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
Official LL Viewers
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – NEW
Cool VL viewer Stable branch updated to version 1.26.20.39 and the Experimental Branch (Animesh) updated to version 1.26.21.5, both on December 16th (change log).
The following notes are taken from the TPV Developer meeting held on Friday, December 15th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.
SL Viewers
[2:35] The Alex Ivy 64-bit RC viewer has one more bug the Lab would like to resolve, this one with the updater within the viewer. The hope is a fix for the issue will be in a further update to the viewer at the start of week #51, commencing Monday, December 18th. If so, the viewer might be promoted to de facto release status before the holiday break.
[6:46] Once the Alex Ivy viewer is promoted to release status, the Lab will move to block versions of their viewer older than the 5.0.6 viewer (the HTTP updates from June 2017).
[4:00] The Voice RC viewer updated to version 5.0.10.330039 on December 12th. This is doing “very well” and is currently being held from promotion due to the wish to promote the Alex Ivy viewer. As a result, the Lab might do a further RC update for it, with a new update from Vivox.
[5:19] A new Maintenance viewer, version 5.0.10.330035, appeared on December 13th. It features a range of fixes, and is code-named Nalewka, in keeping with the Lab’s new habit of naming Maintenance viewers after alcoholic beverages. Nalewka is, according to Wikipedia, a rather interesting beverage mixing alcohol (vodka or neutral spirits) and fruits, herbs, spices, sugar / molasses and which has a liquer-like taste.
[5:43] The anticipated 360-snapshot viewer update has been held while it is integrated with Second Life Place Pages. This will allow 360 images to be uploaded to Place Pages and used in hero images, etc. It is anticipated that these updates will now appear early in the New Year and the viewer should move quickly to RC status thereafter.
[4:43] TPVs attempting to use the viewer updater have encountered issues, often resulting in them disabling it. Oz Linden acknowledges it isn’t easy for TPVs to update it, but has offered to work with them to fix issues once the Alex Ivy viewer (which uses a new version of the updater) reaches release status, coupled with a code refactoring to make updating it easier in the future.
Linux and the Viewer
[20:51-24:28] As per my previous TPV meeting notes, once the Alex Ivy 64-bit viewer (Windows and Mac) goes to release status, the Lab will look to TPV / open-source developers to help move the Linux viewer build to a Debian package without the additional libraries. this will allow TPVs to add the dependencies they require for their flavour of Linux build. If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.
A repository for code submissions will be made available, together with a blog post / open-source community notification on the specifics, after the 64-bit viewer has been promoted to release status. Those wishing to support the work will need to sign a contribution agreement with the Lab.
Texture Decoding and Texture Memory Limits
[28:23-29:52] The Lab is making improvements to texture handling (e.g. using raw texture data rather than encoded). Some of this work is in the current rendering project viewer; there is another non-public viewer which uses a new structure for the rendering cache – although this hasn’t been overly successful in testing thus far. Oz is anticipating his team spending more time on rendering in early 2018.
Environment Enhancement Project (EEP)
A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.
[10:01-11:34] “Rider’s been on a power trip since starting this project!” Grumpity joked at the meeting, “Moving these celestial bodies around the sky!” – which Rider admitted was fun.
Progress continues, and it is anticipated that test regions on Aditi and a project viewer will be available “soon after” the new year, although these may not initially support using environment settings and inventory assets.
Server-side Reset Skeleton
[30:10-35:25] Bento introduced a reset skeleton option for details with avatar deformations. However, it is viewer-side only – therefore, if someone swaps between skeletons / avatars + attachments and is displayed deformed (e.g. BUG11310) or with attachments wrongly place (or a combination), they, and everyone viewing them has to individually perform a reset skeleton on their avatar to correct how they appear.
A preferred means of handling this might be for a local reset to be sent update the appearance system to ensure everyone gets updated (so if I’m deformed, I can use reset skeleton, and everyone around me gets the update as well, rather than having to also use the reset skeleton option). Oz has requested clear, concise feature request on the idea. Grumpity has indicated she’ll follow-up on the specifics of BUG-11310, which the Lab thought to be resolved through and internal JIRA.
Simulator Resources and Simulator Crashes / Performance Degradation
[43:53-50:20] Discussion on simulator resource use / loading balancing. This proceeds from the false assumption that a region / simulator can be crashed “just” by overloading it via a resource / physics hungry script. While there may still be exploits where this might be the case, the Lab long ago imposed absolute limits on script and physics time per frame. What more usually happens is that excessive script / physics loading on a region as whole as a whole can degrade performance as some script / physics executions are skipped within a frame (so scripted objects are slow in responding / may not respond as anticipated, for example); although it is acknowledged that specific items – intentionally or through bad scripting – can have an undue impact on performance. Anyone encountering specific objects, which can individually adversely impact region / simulator resources / performance is asked to file a JIRA with details of the object in question, so that the Lab can obtain a copy and poke at it.
Other Items
[13:24] Estate access / ban lists: (Estate/Region floater) – work has stalled on this.
[14:21] A question was raised on the ability to teleport others home from, or out of, your own parcel, a capability that had been available in the older v1 (and v2?) viewers. Having an ability to remove people at parcel level is something the Lab will likely look at as they continue to work on the land tools.
[16:59] the updates to the estate tools will include a log of ban actions taken – who banned whom and when – which will be visible to all Estate Managers (not general group / land users).
[35:35-36:20] Semi-automatic viewer tests: Kitty Barnett (Catznip) have a number of semi-automated viewer tests (e.g. checking to see if all UI elements / floaters work in different languages). The Lab have found that as the viewer is updated / changed so often, such tests rarely maintain their value over a period of time. However, Oz is willing to learn more about at Kitty’s framework if it avoids such issues.
[36:39-37:53] Viewer support for local meshes: this has been a frequent request, particularly with content creators. It is also something the Lab and Firestorm have looked into. However, supporting multiple mesh formats, dealing with LOD compositing, etc., makes it complex and difficult to implement within the viewer. However, if the Lab can find a way for the viewer to do this, they would consider implementing it.
[50:43-55:07] Phishing/ URL link spoofing: a discussion on the use of URL link spoofing – which has affected Second Life and is a general issue on the web as a whole. Short version: always check URLs before clicking whatever you’re doing, and in terms of SL: always treat links receiving (e.g. via dialogue boxes, via unexpected / unknown IM, etc.) with caution, and while it does not eliminate risks, configure your viewer to use an external web browser to open external links. Obviously, and like any other company, the Lab cannot – and will not – every guarantee the safety of accessing URLs which are outside of its control.
While not foolproof, setting your viewer to use an external web browser or to only use the built-in browser for trusted links from LL, might provide some added protection against scam URLs you might obtain through in-world sources
Lab No Change window: runs from Thursday, December 21st 2017 through until Tuesday, January 2nd, 2018.
Next TPV Developer meeting: Friday, January 12th, 2018.
Firestorm release: the next Firestorm release now looks set to go to beta in the week commencing Monday, December 18th, with a release to be made early in the New Year.
Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models
The following notes are taken from the Content Creation User Group meeting, held on Thursday, December 14th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
Bakes on Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:
The current work to update the baking service to support 1024×1024 textures.
An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
This work does not include normal or specular map support, as these are not part of the existing baking service.
Current Progress
[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.
The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.
Animesh (Animated Mesh)
“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.
Project Summary
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
In short, an Animesh object:
Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
Can use many existing animations.
However Animated objects will not (initially):
Have an avatar shape associated with them
Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
Use the avatar baking service
Will not support its own attachments in the initial release.
These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).
[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.
These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.
Viewer Status
[6:21-8:01] The Animesh project viewer updated to version 5.0.10.330058 on Monday December 11th. This updates includes the following changes:
Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
Animesh objects now display animation information for objects you have permission to view.
Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
Fix for Animesh attachment getting removed after teleport.
Fix for some of the cases where animesh graphics state could get corrupted.
Various clean-ups and optimisations.
[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.
Testing Limits: Tri Count Increased to 50K
[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.
Avatar Animesh Attachments
[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.
Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult. It could allow hair to be a “pet” (a Medusa-like heads for of snakes).
Attachments for Animesh Objects
[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.
This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).
Bugs Focus
[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:
Some Animesh objects seeming to disappear when in their static (non-animated) state.
Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
Animesh objects do not always update correctly when camming onto them.
There are also a couple of feature requests that are still being considered around LSL capabilities.
In Brief
[34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another). As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
[39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
[54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.
On Tuesday, December 12th, the Main (SLS) channel was updated with the server maintenance package previously deployed to all three RC channels. 17#17.12.01.511131 comprises “internal improvements”, which should not result in visible changes for users.
No deployment is anticipated for the the RC channels on Wednesday, December 13th, leaving them on server package 17#17.12.01.51131. A potential deployment to the BlueSteel RC was cancelled, “I found a nasty little bug nest late last night,” Mazidox Linden reported at the Simulator User Group meeting, “Had to halt the move to RC.”
SL Viewer
Two viewers were updated by Linden Lab on Monday, December 11th, 2017:
The Alex Ivy 64-bit RC viewer updated to version 5.1.0.511248.
The Animesh project viewer updated to version 5.0.10.330058.
The Alex Ivy RC viewer release notes contain the following information, worth reproducing here:
Windows: there are now separate 32-bit and 64-bit builds for Windows.
If you use an HD 2000 or 3000 series video card on Windows 10, choose 32 bit
Otherwise, choose the one that matches your copy of Windows
If your computer can run 64bit, and most can, you will get better performance and fewer crashes running a 64 bit Windows and Viewer. If you chose the wrong one, the viewer will upgrade you again the first time you run it to the correct one (if you think it made the wrong choice, please file a bug in jira). This build further refines the determination of what is “the best” platform for your system.
Mac: the Mac build does not support 32-bit Macs (this is permanent, and not really a change since it’s been some time since LL supported OS X versions that would still run on a 32-bit system).
This build shows two icons on the Dock when running. The first one is a new launcher/monitor process (SL_Launcher) that checks for updates; the second is the viewer itself, but both are labelled “Second Life Viewer”. If you are going to pin the icon on the Dock, pin the first one or you’ll get a warning each time you launch. We hope/plan to get this sorted out so that only one shows.
Video media (QuickTime) usually does not play (the media handling is now the same as the Windows viewer).
The volume of web based media (e.g. YouTube) doesn’t change based on your distance from the source.
Linux: there is no Linux viewer yet. We hope to begin work on addressing this with the community after the release of the Mac and Windows versions.
The release notes for the Animesh project viewer include a summary of the key changes from the previous version of the viewer:
Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
Fix for Animesh attachment getting removed after teleport.
Fix for some of the cases where animesh graphics state could get corrupted.
Various clean-ups and optimisations.
The rest of the SL viewer pipeline remains as per the end of week #49:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC
Release channel cohorts:
Wolfpack RC viewer arrived, version 5.0.10.330001, released on November 30.
Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
Project viewers:
Project Render Viewer version 5.1.0.510978, December 4 (dated November 30).
Grumpity and Alexa Linden host the Web User Group meetings on alternate Fridays at Alexa’s barn
The majority of these notes are taken from the Web User Group meeting held on Friday, December 8th, 2017. These meetings are generally held on alternate Fridays, and chaired by Alexa and Grumpity Linden at Alexa’s barn. The focus is the Lab’s web properties, which include the Second Life website (including the blogs, Destination Guide, Maps, Search, the Knowledge base, etc.), Place Pages, Landing Pages (and join flow for sign-ups), the Marketplace, and so on and the Lab’s own website at lindenlab.com.
Not all of these topics will be discussed at every meeting, however, the intention within the group is to gain feedback on the web properties, pain points, etc., and as such is very much led by comments and input from those attending. Along with this are three points of note:
Specific bugs within any web property – be it Marketplace, forums, Place Pages or anything else), or any specific feature request for a web property should be made via the Second Life JIRA.
Alex Linden provides routine updates on the Lab’s SL-facing web properties as and when appropriate, which can be found in the Second Life Web thread.
Note that the SL forums are not covered by the Web User Group, as the management of functionality of the forums falls under the remit of the Support Team.
General
Work continues on improving Place Pages. One forthcoming update is support for 360 snapshots captured with the 360 viewer (still at project status at the time of writing), including support for 360 images as the hero (top) image on Place Pages, and gallery views support.
The 360 snapshot viewer is in the process of being updated to support higher resolution images, fix issues with level of detail loading for objects behind you, etc. It will include support for direct upload to Flickr as well as to Facebook. This update should be appearing “in the next couple of weeks”.
Web properties as a whole are also being examined as a part of the overall project to move Second Life to the cloud for delivery. Some services are already managed via the cloud (at least in part), but there is still considerable work to be done and significant infrastructure changes to be made to SL’s web properties, so this is going to be some long-term work.
Some are reporting that some Mainland Welcome Area now have Voice chat disabled – some of which might be intentional, due to people abuse Voice within these areas. However, if it is believed Voice has been disabled in error, the advice is to raise a bug report, using the LPDW (Linden Department of Public Works) reporting category, and indicate the affected region and the lack of Voice capabilities.
No Copy Exploits / Illegal Sales of No Copy Items
As I’ve previously reported, one area of concern / upset for content creators has been the use of server exploits to generate copies of No-Copy items, which are then placed for sale, generally through the Marketplace. A long-standing problem, this is now hitting some gacha creators. While the Lab is working to technically address such exploits, some of those experiencing frustration for what they perceive as a lack of action on the Lab’s part procedurally to remove content from the Marketplace / responding to reports of the illicit sale of goods.
These frustrations have most visibly been brought forward at in-world technical meetings – such as recent Simulator User Group meetings and the Web User Group meetings. While the Lindens chairing these meeting are prepared to discuss some options for dealing with such issues on a technical level (with obvious caveats around discussing the specifics of exploits, fixes, etc.), they cannot speak to issue of Governance, or on matters which may cross into legal areas. This means they cannot respond to questions about specific abuse reports, associated actions / investigations relating to them, or even how governance issues are managed.
While it does not provide an easement for the frustrations that are being felt, it does mean that such forums as the Simulator User Group, Server Beta User Group, Open-Source Dev Group, and the Web Group are not suitable venues in which to seek feedback on governance matters.
DMCA Update
Somewhat related to the above is the informal announcement that the Lab will be changing how people can file infringement notices (DMCA take-down notices) in the near future.
Currently, the Lab’s Infringement Notification Policy requires that such notices are filed with Linden Lab via mail or fax. Once this update has been implemented – possibly around January / February 2018, it will be possible to file notification with the Lab via an on-line form. I’ll hopefully have a full report on this when the forum has been deployed for general use.
Marketplace
It is believed that the underlying cause of items being de-listed from the Marketplace has been fixed, and there have been no further reports of new cases where de-listing has occurred. The Lab is continuing to work with those creators who have been affected to ensure all of their affected listing are recovered.
Blocking purchasers: some creators would like a means to block people they see as troublesome from purchasing their creations via the Marketplace (just as they can block people from their in-world stores). This is something the Lab is looking at – but again, it is difficult to implement / enforce because of the ease with which alt accounts can be created and used.
Marketplace facts: a couple of Marketplace-related facts:
There are around 40,000 unique monthly sellers using the Marketplace per month.
There are around 150,000 unique buyers using the Marketplace per month.
Seller Verification
: the idea of “verifying” or of at least having some means to control listings on the Marketplace (particularly scam listings / those trying to sell illicit items) was initiated at the inaugural WUG meeting as part of a wider discussion on Marketplace management.
The Lab is looking at various options which might be implemented to help with this, although nothing has been decided as yet. One idea put forward – and again, has not been adopted as something that will happen – is that of applying a listing fee, potentially tied to a benefit for Premium members (e.g. no fees, or X number of free listings). Given changes to fees for cashing-out will be made in January 2018, and LindeX fees were recently changed, this did not go over well with some at that meeting, although others seemed in favour, although it does potentially represent a higher barrier to entry into selling content.
A resident-voiced proposal is for those using the Marketplace to supply some aspect of their physical world information as a means of verifying who they are (already required for those cashing-out L$ balances to fiat money) – something which may discourage content copiers and MP spammers, but which might again discourage other who sell on the MP, but who don’t necessarily cash-out (they use the L$ income to support their in-world activities) from continuing to participate in the MP.
This approach might also allow those merchants who have verified their accounts with the Lab to have some form of “verified” / “trusted” icon displayed within their listings, although the legal ramifications for the Lab in doing this would likely have to be investigated (for example, how vulnerable might the Lab be to legal action should a so-called merchant “verified” as “safe” by them start selling illicit goods at another’s expense?).
In terms of stolen / copybotted goods on the Marketplace and scam accounts, Grumpity Linden stated the Lab’s broader aims:
Meeting Contents
It has been noted that Marketplace-related items are dominating the two WUG meetings held thus far, leads to some concerns that other web-related topics may get pushed out of meetings. Of all the Lab’s main user-facing web properties, the Marketplace is probably the most visible, and carries the largest potential impact with people, therefore a focus on it is to be expected (particularly given the Commernce Team abdicated their own in-world meetings around 5-6 years ago and have shown no willingness since to re-engage in them). However, Grumpity and Alexa acknowledged the wider purview of the WUG meetings, and suggested that a portion of future meetings might be set aside to discuss non-Marketplace web topics.
On Tuesday, December 5th, the Main (SLS) channel was updated with the server maintenance package 17#17.11.17.510835, previously deployed the three RC channels. This comprises:
IMs sent to an off-line resident will only be sent to verified email addresses.
Internal Changes to Outgoing Emails.
On Wednesday, December 6th, the three RC channels should be updates with a new server maintenance package, 17#17.12.01.511131, comprising “internal improvements”.
E-mail Verification
The Main (SLS) server deployment sees a further step in the Lab’s plan to reduce the volume of e-mail traffic it generates by only sending e-mails to those addresses Second Life users have actually verified as being valid with Linden Lab (see Making Email From Second Life (More) Reliable).
With this deployment, and if you have not verified your preferred SL-related e-mail address with Linden Lab, you will no longer receive off-line IMs as e-mails. So, if you haven’t already done so, ad wish to continue receiving off-line IMs as e-mails from wherever they originate in-world, make sure you have verified the e-mail address recorded in your viewer with Linden Lab. Should you require detailed instructions on how to do this, please refer to my blog post Important: verifying your e-mail address with Second life.
SL Viewer
The Project Render Viewer updated to version 5.1.0.510978 on December 4th (although the wiki page still lists it as dated November 30th). All other viewers remain unchanged from week #48 at the time of writing:
e have been no SL viewer updates since the end of week #45, leaving the current viewer pipelines as follows:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC
Release channel cohorts:
Wolfpack RC viewer arrived, version 5.0.10.330001, released on November 30.
Alex Ivy 64-bit viewer, version 5.1.0.511060, December 1.
Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Marketplace Listings Issues
For the last 10 tens there have been on-going issues with Marketplace items becoming unlisted/ associated with their related items. The issues have been subject to continuing investigation. The Lab has also been attempting to recover listings as investigations have continued. On Monday, December 4th, the Grid Status Page was updated:
Identified – We have identified a solution to this matter and are actively working through the support cases and JIRA tickets that have been submitted. If you have been affected by the issue (Marketplace listings unlisting) and have not reported it to us yet, please file a support case. Thank you again for your patience as we slay this dragon.
To which Oz Linden added, during the Simulator User Group on Tuesday, December 5th:
We found and fixed some problems and repaired many listings. I won’t claim we found all problems because I have no way to be sure of that (ever) … Anyone who lost a listing should file a support ticket. We have a process in place to recover the listings we can. So far I believe that’s most of them.
Enhanced Environment Project
Rider Linden is working on the Enhanced Environmental Project (EEP), which comprises a number of changes to how environmental (Windlight) settings are handle. They include the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters.
This work, which involves both viewer and server-side updates, is generally part of my CCUG meeting updates. However, Rider is still considering how best to convert existing custom Windlight settings people have created into inventory assets. If anyone has any ideas on how to make this work, to please file a JIRA for the Enhanced Environmental Project, and ask in the description that it be brought to his attention.
Inara Pey: Living in a Modemworld 