There was not deployment on the Main (SLS) channel on Tuesday, November 14th, leaving servers running simulator version #17.10.06.509394.
On Wednesday, November 15th, the three RC channels should be updated with a new server maintenance package #17.11.11.510664, comprising internal fixes and a user-visible fix for BUG-139176, “Issue with OBJECT_REZZER_KEY reporting incorrectly after linking and delinking prims.”
SL Viewer
There have been no SL viewer updates since the end of week #45, leaving the current viewer pipelines as follows:
Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
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. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
Animesh Mod Keys Proposal
One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects. In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets / characters Modify opens them to the risk of exploitation.
To this end, the Content Creation User Group has been a focus of discussion on overcoming this problem (see here and here). One proposal for handling the issue, which would also allow for broader capabilities, has been put forward via feature request BUG-139168. However, this could take some time to implement, delaying Animesh.
As an alternative, Vir Linden put forward the idea of a scripted mod key capability which would allow attachments to be linked and unlinked from an Animesh object, and more recently he has expanded on this idea with an outline proposal. This could provide a suitable foundation for allowing Animesh to move forward with a link / unlink capability, allowing further capabilities for a broader range of use cases to be added later.
Vir’s proposal will most likely be a core subject of discussion at the next Content Creation User Group meeting on Thursday, November 14th, 2017.
Breedable Issues
The HTTP updates earlier in 2017 resulted in issues with ABC horses being unable to give birth, which came down to the volume and timing of requests being made by the horses (see BUG-134275). The issue was eventually fixed by the horse maker making some changes in the number and timing of the requests sent by each horse, and by a server-side change in how the requests were authenticated.
However, issues have been noted on some regions breeding Stray Cats. It’s not clear if this a similar issue, or something else. Those experiencing similar issues might want to raise a JIRA so the Lab can investigate and advise whether the creators of their breedable animals need to make an adjustment to their scripting.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, November 12th
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.8.329115, dated September 22nd, promoted October 13th – formerly the “Moonshine” Maintenance RC – no change.
Cool VL viewer Stable branch updated to version 1.26.20.36 and the Experimental Branch (Animesh) updated to version 1.26.21.2, both on November 11th (change log)
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, November 10th, 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 two 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.
Marketplace Related
Marketplace Search
Search can be too broad (even with the boolean functions). for example, attempting to search by store name can bring up avatar names, many of whom do not have an active store. Addition of more refined filtering mechanisms (check boxes?) could help eliminate some of these problems. This was noted at “useful feedback”.
Boolean search, whilst useful, can also be limited in impact when trying to eliminate things like demos from results, although this seems to be down to the creative use of demo item descriptions to foil the use of booleans like “XXX NOT demo”, and is thus harder to overcome.
Marketplace Listings
Default order for listings on the Manage Listing page is date ascending (oldest to newest). It would make more sense – particularly when creating new listings – to have the default as date descending (newest to oldest), so that the newest listings – and the ones most likely to need editing – appear at the top / on the first page of a listing – or have the merchants preferred listing order saved. This has been a JIRA issue since 2014 – see BUG-4705. It’s now regarded as something that “should be” fixable, and has been added to internal tracking by Alexa.
Grouping Colour variants for items has often been requested – for example, see BUG-6424 and feature request BUG-10853. This is seen as a much harder capability to add to the MP.
Marketplace Gifting
Some people apparently get confused over the gifting work flow: this should be: find the item > click Add to Cart as a Gift > enter recipient’s name & a message > click Finished > go to the shopping cart icon (top right of the window) to purchase / send. However, after entering the recipient’s information, some people at clicking on the Buy Now button in error, thus purchasing the item for themselves. See also WEB-3020 and feature request WEB-3531.
Gifting requires recipient’s full user account name not Display Name – as the latter can default to sending a gifted item to a recipient with an account name matching the display name. Note that “Resident” should be automatically appended to any single name account entered.
Marketplace Clean-up
Another long-standing request in for some form of Marketplace clean-up. For example, there are good for say that may contravene more recent SL policy changes; there are goods for sale and unsupported because the creators have long since left Second Life; there are goods listed on the marketplace that have not sold in years, and the creators (if still active have not removed), and so on.
The problem here is how should any removal be policed? Even if a creator has departed SL, it doesn’t mean their goods are no longer being purchased? How should a time limit for force removal of non-selling goods be enforced? One year without a sale? Two? Three? More?
Clean-up is something the Lab has been struggling with and considering different approaches. There may also be possible alternatives to removal – such as more refined weightings on search capabilities, or the ability to see when an item was last updated. At the moment, Alexa and Grumpity are on a feedback mission concerning this issue, so except this subject to droll forward in future meetings.
Listing fees: once suggestion for handling the proliferation of various listing types was for listing fees to be added, potentially tied to a benefit for Premium members. This understandably caused heated debate (particularly given the January 3rd 2018 increase in fees for processing credit transactions) – with creators at the meeting divided on the matter. However, it’s important to note this was just a suggestion; it is not something the Lab is planning on introducing.
Second Life Maps
Two specific requests were made:
Update the map generation to properly display mesh in map tiles.
Fix region surrounds causing a region’s map tile to be displayed as a blank green tile.
Commenting collectively on these, Grumpity Linden said:
Maps… yeah, we’d like to do that and have several ideas for how, but none of them are easy fixes. Map tile generation is different from displaying them… and none of the ideas for fixing the generation are easy or fast.
A Note on JIRA Acceptance
This routinely comes up at Content Creation meetings and came up at the Web meeting, so is worth repeating.
Following initial triage by Linden Lab (roughly daily for bug reports, usually weekly for feature requests), the status of a JIRA may be updated to “Accepted”. However, this does not mean it will be actionedin the near future.
Depending on the nature of the JIRA, “Accepted” may result in it being prioritised and actioned in the short-term; however it may also mean it has been imported and tracked by the Lab, but held for action pending the clearance of more urgent items / ideas that necessarily need to be actioned ahead of it or it may be tracked until such time as it (or something like it) fits into a tranche of work / updates the Lab is planning to implement.
SL Viewer Updates
The SL viewer is not specifically discussed at the Web User Group, however, in keeping with my summary of recent viewer updates which generally forms a part of my SL project updates, here’s an end-of-week summary of changes.
The current Maintenance RC viewer updated to version 5.0.9.329795 on Wednesday, November 8th.
The Animesh project viewer updated to version 5.0.9.329815 on Thursday, November 9th – see here for more.
Otherwise, the SL viewer release pipelines remain as:
Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
Release channel cohort:
Alex Ivy 64-bit viewer, version 5.1.0.510354, November 2 (still dated Sept 5 on the wiki page).
Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
The following notes are taken from the Content Creation User Group meeting, held on Thursday, November 9th, 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. 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.
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).
[3:51-5:33] The project viewer updated to version 5.0.9.329815 on Thursday, November 9th.
The major change is that Animesh linksets can now include non-rigged items (e.g. prims), and allow the root objects to be a prim rather than a rigged mesh.
Animesh objects should now render the same way as mesh attachments and generate shadows.
The viewer also includes a number of bug fixes.
[42:25-44:50 + text chat] However, while the root of an Animesh object can now be a prim, this doesn’t mean mesh objects such as pets can be dropped in-world (e.g. so someone could “pick up” their Animesh pet, carry it, then put it down again somewhere else), because the code required for “dropping” mesh is not provided on the simulator on the ground that dropping meshes can cause physics issues.
Animesh Attachments
Note: there is an extensive discussion in text chat around this subject from the 13:00 minute mark which continues throughout the meeting.
[12:59-18:06] One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects (see here and here). In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets / characters Modify opens them to the risk of exploitation.
One proposal has been put forward via feature request BUG-139168. Vir Linden has also put forward a number of ideas. Of these, the mod key proposal (2nd bullet point in Vir’s notes and somewhat aligned to BUG-139168) is seen as a potential solution, with LlAllowInventoryDrop used to avoid the need for the root Animesh object having to be modify (and leaving it exposed to the exploits outlined by Piscine and Medhue). Vir is currently seeking further feedback from people on this being a possible approach, or if there are other potential alternatives.
[21:11-22:51] Two concerns on this approach are that a) any scripted mod key capability could be withdrawn at any time by the creator, potentially leaving users with broken content. However, there is no obvious means of safeguarding against this (unless it is made some kind of one-time function operation by the Lab, if possible); b) there is a risk the mod key could be accidentally exposed / leaked in being shared between those using it.
[25:52-26:12] The most “obvious” means of handling this issue would be to implement a change to the permission system to cater for the specific user-case of allowing attachments to be added to Animesh objects. However, the Lab is hesitant to consider such changes due to the risk of unintended impact, risk of content breakage, etc. As such a precise proposal on how to update the permissions system and the use cases it would meet would have to be properly defined for consideration.
[28:15-30:40] A suggestion is made to have a new flag “only allow scripts compiled by the object creator run on this object”. However, this could limit cases where models are built by one person, animated by another and scripted by someone else, or situations where a creator is using full permission scripts sold by another creator, etc., and so seen as potentially less than ideal.
[56:07-1:01:56] Determining whether Animesh attachments capabilities (e.g. using the mod keys idea) can or cannot be implemented relatively easily is seen by the Lab as a critical aspect to moving Animesh towards a release. If doing so proves problematic, the project will likely move ahead without such a capability being implemented. In the meantime, as there isn’t currently an available solution, creators are advised to handle Animesh the same as any other product they are developing for the time being, and focus on Animesh at the functional level.
[1:01:57-1:05:05] An example of complexity is defining how a mod keys capability would work. If it is limited to one specific group of people creating a poduct line, it is relatively easy to control. However, if a creator wants too support an ecosystem whereby other creators can all offer attachments for a product, then it becomes far more complicated in terms of keeping the mod key secure.
Given the complexity of this subject, continued discussion through the Animesh forum thread is encouraged.
Animation Playback Speed
[51:47-52:37] It has been noted that the speed of the animation depends on the distance from the viewer’s camera to the animated object – see BUG-134259 and this MP4 (note particularly the two elephants). This appears to be the result of the debug UseAnimationTimeSteps being set to TRUE (default viewer behaviour). Setting it to FALSE fixes the issue, and doesn’t appear to cause any other performance impacts.
Land Impact and Other Limits
[54:53-56:05] It’s unlikely that the current baseline limits (LI, tri count, rendering), will be altered until there is confidence that the viewer functionality is relatively stable in terms of features, bugs, etc., at which point reliable performance testing can begin. Once this point is reached, then the Lab will be able to gather reliable data in order to start adjusting / potentially relaxing the limits.
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; 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.
Current Status
[8:25-10:32] Rider Linden is “very close” to removing the old windlight environment code from his EEP version of the viewer, allowing it to use all the new EEP assets, allowing the local environment to be set via windlight inventory assets.
Once this can be done, test regions capable of supporting the assets will be established on Aditi (the beta grid), and a project viewer will be made available for more general testing.
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 avatar mesh surfaces (and potentially other mesh objects as well). 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
[35:41-36:33] The performance testing has been carried out, and the results point to the need for additional bake host servers to account for the additional load in handling the higher resolution textures.
Other Items – In Brief
[36:30-37:29] Region crossing loads: the question is asked about what is the biggest load / cause of lag on region crossings (direct or TP). The short answer is scripts. That is, suspending them, saving their state, packaging them, handing them off to the next simulator, unpacking them alongside everything else (e.g. the avatar and / or vehicle they are running against), setting them back to running from their saved state. Obviously, the more individual scripts an avatar (+ vehicle, where used) is running (regardless of individual script size), the bigger the load placed on the hand-off process / receiving region.
[47:03-47:19] Materials system update: this is frequently requested, but currently the Lab do not have any plans to revisit the materials system.
[49:32-49:45] Cannot pathfind through a hollow object – intentional? Short answer – yes; physics simulations going into concave objects is expensive
[49:45-50:18] Will RenderVolumeLOD be revisited? – Short answer – yes, as a part of the work in re-evaluating rendering costs, land impact, etc.
As always, please refer to the server release thread for updates and the latest news.
On Tuesday, November 7th, the planned Main (SLS) channel deployment was cancelled when the restart system overloaded while trying to restart a few thousand regions around the same time. Some reported that RC regions were also being restarted during the deployment attempt, which may have contributed to the problem – although this has yet to be confirmed as being the case by the Lab.
Once the cause of the problem has been diagnosed, the deployment will be re-tried, although Oz Linden indicated this may not be before the usual Tuesday deployment in week #46.
There is no planned deployment to the RC channels on Wednesday, November 8th, 2017.
SL Viewer
The Wolfpack RC viewer which was functionally identical to the release viewer, but included additional back-end logging, was withdrawn from the Alternate Viewers page at the start of week #45. Otherwise, the viewer pipelines remain as for the end of week #44:
Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, November 5th
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.8.329115, dated September 22nd, promoted October 13th – formerly the “Moonshine” Maintenance RC – no change.
Inara Pey: Living in a Modemworld 