Category: SL Tech

April 2018 Web User Group Summary

Posted on by Inara Pey
Grumpity and Alexa Linden host the Web User Group meetings on alternate Fridays at Alexa’s barn.

The following notes are taken from the Web User Group meeting held on Wednesday, April 25th, 2017.

These meetings are generally held monthly on a Wednesday, and are 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.

Meeting Format

A point to remember with the Web User Group meetings is that they are informal discussions on things like the Marketplace.

While the Lab does give information on the work they are carrying out, plans they have in-hand for updates to web properties, etc., equally, a lot of what is discussed is ideas and the taking of feedback from attendees, and should not necessarily be regarded as statements from the Lab as to what will happen, it priority, or anything else.

Within these reports, I try to indicate those plans / actions / projects that are in progress, and offer a differentiation between “firm” plans and ideas under discussion.

Web Updates

On April 16th, 2018, the Lab slipped out an announcement on a number of web property updates, which notably include the following.

Marketplace Guidelines Change

The SL Marketplace Fee and Listing Guidelines have been revised with regards to the policy on pricing products on the Marketplace in comparison to pricing the in-world. Previously, the guidelines stated:

The following actions are disallowed. Note that these actions are disallowed by the Second Life Terms of Service, and are restated here for clarification.

  • Anti-Competitive or Abusive Behaviour. Examples include, but are not limited to:
    • inflating prices on the SL Marketplace, in comparison to in-world or other e-commerce sites”

This has now been revised so that in-world pricing is no longer exempted, thus:

The following actions are disallowed. Note that these actions are disallowed by the Second Life Terms of Service, and are restated here for clarification.

  • Anti-Competitive or Abusive Behaviour. Examples include, but are not limited to:
    • inflating prices on the SL Marketplace, or other e-commerce sites”

With the Lab noting:

We’ve removed the section which applied to in-world stores.  This was contrary to your interests and our interests.  Marketplace is a tool to use in your overall product marketing strategy and if you’d like to differentiate pricing between on-line and in-world stores, that’s your decision to make.

Transaction History “Quick Filter” Options

A set of “quick filters” have been added to the transaction history page on the dashboard at secondlife.com. These provide the ability to list all transactions for the current day (“Today”), the last 24 hours (“1 Day”), the last 7 days and the last 28 days.

The new transaction history quick filters available through your Second Life web dashboard

Please refer to the announce for the full set of web-related updates.

Other Items

Legal Question: Resale Prices on Full Permission Items

Is setting a minimum resale price on full permission items legal? this is being referred to the Lab’s legal department. However, such things as recommended retail price options, FTC guidelines on supply chain selling (both of which are slightly different, admittedly), would suggest the practice is acceptable.

Lootbox Legal Status

Questions have been raised on the use of lootboxes in Second Life. In some countries (e.g. China, Japan, Australia, The Netherlands, the Isle of Man (UK) and now Belgium) they are regarded as gambling and subject to regulation / financial penalties. Additionally, lawmakers in the United States and mainland UK are said to be looking at the status of lootboxes. The questions asked in relation to Second Life are being referred back to the Lab’s legal team.

Premium Subscription Changes

At the April 20th, 2018 town hall event, Linden Lab CEO Ebbe Linden confirmed that as a part of pivoting Second Life’s revenue generation away from a heavy reliance on land, the Lab are looking at introducing a range of Premium account options which will have different levels of benefits associated with them – see here for more (includes an audio extract of his comments).

While details have yet to be finalised, Grumpity Linden spoke to some of the ideas under consideration at the Web User Group meeting. Because her comments are likely to be of interest beyond that meeting, I’ve provided a transcript of her comments, with an audio recording.

In Brief

  • Need to comment on a JIRA item (bug report or feature request) and cannot? send an e-mail to letmein-at-lindenlab.com giving your avatar name to request JIRA comment access. Note that if a JIRA has been imported by the Lab or had its status changed, you may still not be able to comment on it.
  • Linden Homes size increase: Linden Homes are currently undergoing a face lift, and Grumpity indicated the plan is to increase them in size (presumably to 1024 to match the “free” tier offered to Premium members. There is no time frame on when the updated Linden Home will be available, although it is hoped they will be ready before the end of 2018.

 

2018 UG updates #17/1: Simulator User Group

Posted on by Inara Pey

Motorheadz Café / Route6; Inara Pey, March 2018, on FlickrMotorheadz Café / Route66 – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • According to the deployment thread, on Tuesday, April 24th, 2018, the Main (SLS) channel was updated with server maintenance package 18#18.04.09.514272, previously deployed to the RC channels and containing internal fixes and a fix for BUG-214702. However, a check on the simulator release via Help > About in the viewer reveals the simulator version to be 18.04.13.514504, which doesn’t appear to have associated release notes.
  • According to the deployment thread, there was no deployment to the three main RC channels – LeTigre, Magnum and BlueSteel – on Wednesday, April 25th, which reportedly remain on server maintenance release 18#18.04.09.514272. However, as with the Main (SLS) channel, these channels report as being on simulator version 18.04.13.514504.

Region Crossing Updates

On Wednesday, April 25th, the Snack RC was updated with a release designed to assist with region crossings.

“We’ve made some changes on the back-end with respect to message reliability,” Rider Linden stated at the Simulator User Group meeting on Tuesday, April 23rd. “We are hoping makes the transitions [from one region to the next] a bit more reliable … mostly it was a number of internal changes dealing with how agents get passed between simulators during a crossing or teleport.”

The simulator regions with the updated messaging code are:

Blake Sea – Atlantic
 Blake Sea – Galilee
Blake Sea – Cattewater Blake Sea – Crows Nest
Blake Sea – Mizzen
 Blake Sea – Nelson
Blake Sea – Thunderer
 Blake Sea – Hawser
Blake Sea – Indefatigable
 Blake Sea – Jones Locker

All of these can be accessed via the Blake Sea Half Hitch rezzing zone for those wishing to access them. I addition there is a block of region centred on “Est Full2” on Aditi that also have the updated region crossing code.

SL Viewer

There have been no updates to the viewer channels so far, leaving them as follows:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

Other Items

A recent back-end change made to PRIM_MEDIA_CURRENT_URL reportedly broke a lot of content (see BUG-216032), causing a lengthy debate during the Simulator User Group meeting. As a result of this discussion, Oz Linden provided an update on the change and on a further change the Lab has made which they hope will assist those experiencing issues as a result of the original change.

We installed an important security patch, which happened to no longer infer http for a URL that had no scheme (in my opinion a good change). That broke some scripts that had used the field for a URL but left off the scheme (e.g. “myserver.example.com/myapi”) so those were broken. In order to get those slightly sloppy but legit uses working again, we added the scheme for them (but used https because everyone always should).

Storing data in that URL field was never intended to work.

The fact that we broke uses that were never legit is unfortunate, but not something I feel an obligation to maintain compatibility with. We’ll try to help you recover data that’s trapped there, but we won’t change it so you can keep doing that. If you have scripts that you need to get the data back out of, let us know and we’ll try to work with you.

Those still experiencing issues should report them via the JIRA.

2018 viewer release summaries week #16

Posted on by Inara Pey
Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, April 22nd

This summary is generally published on 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.1.3.513644, dated March 27th, promoted April 13th – formerly the Media Update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • No updates.
  • Project viewers:
    • Animesh project viewer updated to version 5.1.4.514468 on April 16th – project overview.

LL Viewer Resources

Third-party Viewers

V5-style

V1-style

  • No updates.

Mobile / Other Clients

  • No updates.

Additional TPV Resources

Related Links

2018 SL UG updates #16/2: Content Creator User Group

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, April 19th, 2018 at 13:00 SLT.  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 summary. My thanks to him for providing it. Time stamps are included in the text below to allow easy referencing to the video for details.

Initially, the meeting opened on Aditi at the Animesh test regions.however, Voice issues across the beta grid regions resulted in the meeting decamping to the TPVD amphitheatre on Agni, and these notes reflect the meeting from that point onwards, starting at the 7 minutes 19 seconds point in the video.

Animesh Project

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.

Project Viewer

The project viewer with the updated Animesh land impact / tri count formula was released on Monday, April 16th. Version 5.1.4.514468 also brings the viewer to parity with the current release viewer.

Vir’s provides a detailed explanation in the Animesh updated limits and cost formulas forum thread, However, in summary:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
  • These values are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

[7:23-8:43] The viewer also incorporates a change where it will automatically switch to skeleton based rendering for Animesh as soon as it detects the use of an avatar skeleton in an object, rather than waiting until an animation starts playing on an Animesh object in order to make the switch. It is hoped this will avoid issues between an Animesh object’s static and animated states, which can cause visual glitches when the animation based switch is made. It should also avoid potential exploits with people using multiple Animesh objects without necessarily animating them.

[9:13-9:32] It is believed the majority of bugs for Animesh are now in hand, however if any finds specific issues with the new impact calculations or with the latest project viewer in general, they are asked to file a JIRA bug report.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

[8:44-9:12]  Graham Linden has been investigating these, as has some proposed changes which he and Vir hope to implement in the near future, the implication being these will be folded into the Animesh viewer.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current Status

[10:35-11:05] Rider Linden has been involved in dealing with other issues, which have delayed progress on EEP. He hopes that with this worked cleared, he’ll be able to focus on getting the viewer updates out in a project viewer.

Continue reading “2018 SL UG updates #16/2: Content Creator User Group” →

2018 SL UG updates #16/1: Simulator User Group

Posted on by Inara Pey

La Virevolte; Inara Pey, March 2018, on FlickrLa Virevolte – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, April 17th, 2018, the Main (SLS) channel was updated with server maintenance package 18#18.03.29.513939, previously deployed to the RC channels and containing internal fixes.
  • On Wednesday, April 18th, 2018, the major RC channels, BlueSteel, Magnum and LeTigre should all be updated with the same server maintenance package 18#18.04.09.514272, containing internal fixes and a fix for BUG-214702.

SL Viewer

With the exception Animesh project viewer (see below), there have been no updates to the current SL viewers thus far in week #16, leaving the pipelines as follows:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC – NEW
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Animesh Project Viewer Update

The Animesh project viewer updated on Monday, April 16th. Version 5.1.4.514468 brings the viewer to parity with the current release viewer. In addition this viewer has revised streaming cost/land impact formula for Animesh objects, which are also reflected in ARC (avatar rendering cost) calculations for Animesh items.

In summary, the updates are:

  • Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
  • Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
  • Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
    • High LOD: all of the estimated triangle count included in the effective_tri_count.
    • Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.

See Vir’s explanation in the Animesh updated limits and cost formulas forum thread for a complete explanation of these limits and how they have been arrived at.

An important point to note is that these formulas only apply to Animesh; there is a second, and longer-term project – ARCTan – a re-evaluation of all object and avatar rendering costs (and which may see further changes to Animesh calaculations). It is hoped that overall, ARCTan  will improve viewer-side performance and provide creators with positive incentives to build more performant content.

You can find out more on ARTan in this blog post and this blog post in this blog.

Viewer Texture Cache

As noted in several of my TPV Developer meeting updates, Linden Lab are trying to improve viewer caching – starting with the texture cache. Commenting on the work, Oz Linden said, “We’re experimenting with a number of different changes. Some that you might think (I did) would make things better turned out not to, but we’re making progress.” It’s not clear if / when any project viewer utilising any new texture caching capability will be available for general use.

LlRequestUserKey and LlName2Key

The Lab has released two new LSL functions: llRequestUserKey and llNameToKey, both of which are in connection to the upcoming return of Last Names (see this blog post and this blog post for more):

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

Kokua: new faces, the future and release 5.1.3.43129/43130

Posted on by Inara Pey

In March I reported that Chorazin Allen, had joined the Kokua viewer development team. He volunteered after Nicky Perian’s decision to step back from day-to-day management of the project, announced in October 2017 to allow him to enjoy more of his retirement, failed to elicit hoped-for volunteers to take over the general management of the project.

Chorazin, although he modestly describes his C++ coding skills as “rusty” (causing him to initially hold back from volunteering sooner), has considerable experience in project management, software development and build experience coupled with many years of experience of in-world LSL scripting and working with RLV/RLVa.

Since joining Kokua, he has been getting familiar with the rest of the Kokua team, and together they have been working on updates to the Second Life viewer to bring it up to parity with the current Linden Lab code base, including full integration with the Alex Ivy 64-bit code. I’ve been tracking these updates – made through the projects Sourceforge pages, rather than being “official” releases, for the past few weeks via my Current Viewer Releases page and my weekly viewer release summaries.

Kokua: The Future

On April 15th, this work reached a point where the team were ready to resume making formal Kokua releases, and to publish a blog post outlining the viewer’s future development. I strongly urge all Kokua users to read this post in full, and am only bullet-pointing the key elements here:

  • Until such time as an OpenSim developer can join the project, Kokua will only be actively maintained for use with Second Life.
  • Kokua for Second Life will be developed as a 64-bit bit viewer only, offering both RLV and non-RLV variants.
    • The Windows and Mac versions will be actively maintained, based on Linden Lab’s  Alex Ivy 64-bit code base.
    • Effort will also be put towards a 64-bit Linux flavour of the viewer based on the Lab’s Alex Ivy code. However, this will doubtless be dependent on the Lab’s broader attempts to work with the Linux community to develop a 64-bit Linux viewer.
  • In keeping with a request from Linden Lab, the major version numbers for Kokua releases will reflect the Lab code base release they are based on. So, for example Kokua 5.1.3.xxxxx indicates it is based on the Lab’s 5.1.3 code base.
  • Legacy 32-bit versions of Kokua will remain available via the download page, but will not be actively maintained.
  • The Kokua group within Second Life is the preferred medium for user-to-user support and will also be used for group notices about new versions or other significant developments. All other channels of outward  communication (IRC, Twitter, etc), have been discontinued.
  • The Kokua wiki will continue to be used for viewer release notes (as seen in the viewer when a new version is launched) and for the summary of current versions and download sites.
  • The preferred method of inward  communication to the team is via a ticket raised in Sourceforge against the Kokua Project.

Kokua 5.1.3.43129/43130

The formal release the release of Kokua’s Alex Ivy based 64-bit viewer for Windows and Mac, offers the viewer in both RLV (5.1.3.129) and non-RLV (5.1.3.43130) variants on both platforms. It brings with it a full parity with the Second Life viewer up to and including (at the time of writing) the current official release viewer, 5.1.3.51364, formerly the Media Update RC viewer. The RLV version of the viewer also gains parity with RLV 2.9.23.0.

Performance Feedback Capabilities

The core element of the updates made by the Kokua team comprise new performance and information feedback capabilities, including the ability to report on changes in the number of scripts in a region, changes in the server channel with changes of region.

All of the new settings can be found in two new Preferences tabs: Preferences > Kokua > Performance 1 and Preferences > Kokua  > Performance 2:

  • Performance 1 deals with notifications on entering a new region and agent (avatar) and script notifications, which must be enabled on a group basis – agent and / or script notifications, and then individual options within group set as required.
  • Performance 2 provides notifications on Frame Timing and Basic Performance.

In addition, it should be noted that:

  • Performance 2 also includes a check box to display the information from these features either as a notification in the top right of the viewer window and in chat history, or have them only displayed in chat history.
  • All of the options have default values which are intended to be representative of fairly average performance. If you aren’t familiar with what they do, it is probably preferable that you don’t randomly enabling them, as you could end up  swamped in notifications and feedback.
  • It is important to not that any changes made relate what is reported by the viewer and when – changing these values does not change actual simulator performance.
The new Preferences > Kukua Performance 1 tab, allowing users to set notifications for region, agent (avatar) and script notifications.

Some of these options mirror similar capabilities found in other TPVs – such as reporting a change in the server channel when moving between regions; others may be of more benefit to region holders and their estate managers than they are for general consumption. The idea with them is not to simply turn everything on, but to select those options which might be of specific interest.

For example, while knowing how many avatars (agents) are in a region might be of use to some users when hopping about Second Life, information on how the physics  simulation is performing or on overall timing information within a region, together with the active object count and script count is only likely to be of interest to those managing a region. Similarly, enabling the Physics time section of the frame monitoring options in the Performance 2 tab could help creators monitor vehicle performance during testing (e.g. on region crossings.

The new Preferences > Kokua > Performance 2 tab, providing Frame Timing and Basic Performance notifications

For a more rounded examination on how these options might be used, please refer to the Kokua release notes, which provide a range of examples of now the tabs might be used. It should also be notes that general “real-time” monitoring of the options provided can also be done via the Statistics (CTRL-SHIFT-1) and Scene Load Statistics (CTRl-SHIFT-2) floaters. Finally, those particularly interested in learning more about the viewer’s statistics reporting abilities and on tuning viewer performance should refer to the Viewer Statistics wiki page, and the Viewer Performance Knowledge Base article respectively.

Feedback

While the lack of OpenSim maintenance for Kokua – at least until such time as an OpenSim developer volunteers to work with the team, as noted – will probably be lamented in some quarters, the “return” of mainstream release announcements of Kokua, together with information how the viewer’s development will proceed into the foreseeable future is to be welcomed.

That Kokua is only being maintained on Windows 64-bit might cause frustration for some. However, given that systems capable of running 64-bit Windows (e.g. supplied with more that 4Gb of RAM) are far more prevalent on the marketplace; ergo, the decision to focus the team’s limited resources on providing support for the one flavour of Windows  makes sense.

It’s hard to judge how well the two new Performance tabs will be utilised. Aso noted, for the likes of those engaged in region management, or scripting, they could potentially be very useful. For others, the tabs might rarely see the light of day. But that’s what TPVs are about – providing choice for users.

I’ve not had an opportunity to run Kokus 5.1.3 hard, having only spent part of a morning bouncing around SL with it. However, in that time I found it to be (as usual) robust and providing frame rates and general experience with the official viewer and – on a frame rate basis – somewhat above that managed by Firestorm on the basis of very rough-and-ready “like for like” testing across some of my preferred regions where things like agent numbers., etc tend to remain constant.

Additional Links