SL project updates 24/3: TPV Developer meeting

Le Sixième Sens, Les Reves Perdus; Inara Pey, June 2017, on Flickr Les Reves Perdusblog post

The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, June 16th, 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. Timestamps in the text below will open the video in a separate window at the relevant point for those wishing to listen to the discussions. Note that the timestamps may not be in chronological order, reflecting the fact that some topics were discussed more than once during the course of the meeting.

Server Deployments, Week 24 – Recap

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

There was no deployment to the main (SLS) channel on Tuesday, June 13th. Nor, as the channel was updated in week #23, was there a restart.

On Wednesday, June 14th, two of the server RC channels were be updated as follows:

  • LeTigre received a new server maintenance package (#17.06.12.327066), comprising additional internal logging and features and improvements to region start
  • BlueSteel received a new server maintenance package (17#17.06.13.327122) containing internal fixes

[15:20] The Magnum RC was initially updated with a newer version of the new operating system update (#17.06.12.327060), which included a fix for BUG-100737 “Shoutcast receivers unable to relay on RC Magnum” (see part 1 of this report for more on this issue). However, this deployment had to be subsequently rolled-back as the corrective intent of the BUG-100737 didn’t work as expected. This update will likely be re-deployed to Magnum ion week #25 (commencing Monday, June 19th).

SL Viewer Pipelines

Asset HTTP Viewer

[1:39] The Asset HTTP viewer should be promoted to release status at the start of week #25 (week commencing Monday, June 19th). The promotion has been delayed while the viewer goes through a complete regression test (something the Lab does every X number of viewer releases).  This viewer sees delivery of all remaining asset types (wearables, gestures, animations, sounds, etc) over HTTP via the CDN.

[11:39] This viewer should hopefully see faster first-time playback of sounds and animations, as these will be obtained via the CDN, which should be faster than being obtained through the simulator. It also means obtaining assets should also be a lot more reliable when you’re in a busy region, because – again – the assets are not coming via the simulator, but through a CDN node.

The Lab will – several months hence from now – remove the server-side UDP messaging support for these asset types. This will in turn mean that any viewers not updated to the HTTP support at the time the messaging is removed from the simulator will no longer be able to receive these asset types.

Maintenance RC Viewer

[5:25] The Maintenance RC viewer updated on Thursday, June 15th to version 5.0.6.327125. This includes an update to prevent the viewer crashing if it receives a UDP message from the simulator that it doesn’t recognise, by having the viewer ignore all unrecognised messages.

Voice RC Viewer

[5:04] The Voice RC viewer has been updated, but the update has a high crash rate and so the update is unlikely to see the light of day.

Alex Ivy 64-bit Project Viewer

[2:23] The next version of the 64-bit project viewer is completing testing. This includes the new Windows SL Launcher and updater, together with a 64-bit version of the Havok sub-libraries. As noted in my last TPV Developer meeting update, the launcher is essentially a 32-bit executable that checks a Windows system to see if it is 32-bit or 64-bit, and then endeavours to download the correct version (32- or 64-bit) of the viewer if an update is available, install it and then launch it. SL Launcher is only required for Windows as the Mac version of the viewer will only be provided in 64-bit once the Alex Ivy viewer reaches release status.

A follow-up build for RC release has apparently been built, and this should appear soon after the project update, and work has commenced on updating the wiki build instructions for building the viewer to match the 64-bit build process.

[38:26] The wiki instructions are being updates to reflect the requirements of the 64-bit build, so care should be taken when following them for other builds.

360-degree Snapshot Project Viewer

[6:21] The 360-snapshot viewer is now up-to-date and includes code to generate a 360 equirectangular images and their metadata, which can then be uploaded to suitable websites supporting 360-images. The update will appear once it has cleared the Lab’s QA testing.

There is still further work to be done on this viewer – the UI is going to be updated to allow integrated uploads of 360-images to SL Place Pages (and this may be done for Flickr, etc), and SL Place Pages will be updated to accept 360-degree images from the viewer.

TP Throttle

[13:28] The Lab is still looking at throttling the speed at which teleport requests can be re-tried when trying to access a busy region. An initial change is currently on the LeTigre RC, and further changes are liable to be made. As previously noted, these updates shouldn’t impact manual teleports, but may affect teleport HUDs which are scripted to repeatedly re-try teleports in rapid succession until one is  successful (requiring the scripts running them to be modified so they don’t exceed the throttle).

This change is being made because a high incidence of failed teleport requests hitting a busy region places an additional load on the region’s simulator, adversely affecting performance for those already in the region.

Other Items

Uploading Meshes Rigged to Attachment Points

[17:48] This subject came up at the Content Creation User Group meeting as a part of the discussion on animating weapons to follow hands. There was some confusion on whether mesh objects rigged to attachment points could be uploaded, after it was reported that the LL viewer supported it, and Firestorm didn’t (see FIRE-21000 – which now has a fix).  While there is a server-side validation error which can cause some issues when uploading meshes (fix in progress) which might cause upload problems, it is believed that the current behaviour here should be that new objects rigged to attachment points should be blocked from upload, but existing items rigged to attachment points previously uploaded to SL will still work.

Supplemental Animations and Animation Priorities

[24:17] The question was asked if there was any historic reason for not being able to change the priority of an animation post upload (see SVC-8094). It is thought this might be because the priority is set within the animation asset, which cannot be edited. However, it is hoped the forthcoming server-side supplemental animation updates will help eliminate some of the conflicts created by priority clashes.

Providing a Means to Compile Experience Scripts in the User’s Inventory

[35:21] Some people working collaboratively on experiences are finding it problematic when having to update scripts used by the experience, but which are contained in another user’s objects for that experience, as it requires a lot of swapping and changing, rather than simply editing the script in question (see BUG-8180).

While the Lab understands these difficulties, it was a conscious decision to have experience management work as it does, and while at some point in the future they might revisit things, doing so isn’t on the short-term roadmap.

Resetting Scripts in No-Mod Objects

[36:47] This is a request the Lab is unlikely to implement, because it would violate the expectations of the script authors.

SL project updates week 24/2: Content Creation UG w/audio

The Content Creation User Group meeting, at the Hippotropolis Camp Fire Circle (stock)

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, June 15th, 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided within the text, covering the core points of the meeting. Please note, however, that comments are not necessarily presented in the chronological order in which they were discussed in the meeting, but are ordered by subject matter.

Animated Objects

Vir is continuing to work on this project, which has been given the informal name of “animesh” – which, as was pointed out in the meeting by some, sounds a lot like “any mesh”, although it seems to have some support among attendees, who have been doing their best to propagate the term ahead of the Lab settling on a project name.

Viewer Status

There is no ETA for a project viewer, as the current test viewer still has a habit of crashing other viewers in the same region by sending them unrecognised messages. This need to be fixed before a viewer supporting animated meshes goes into circulation, even as a project viewer.

Scaling Animated Objects

There has been some discussion around editing animated objects in order to adjust their scale, with the associated skeleton being automatically adjusted to match the desired size of the object. In testing the idea, Vir has found it a lot harder to do than expected due to how things are coded in the viewer. Essentially, there is no overall way to scale the skeleton; every individual bone in the skeleton has to be scaled.

However, these does appear to be one viable means of achieving the scaling up / down of an animated object, and Vir is going to take a look to see if it can be made to work in a semi-predictable way.

Suggestions on how to handle this have included adding a root prim to animated objects or using a script to apply scale or using the object’s bounding box (the physics bounding box isn’t seen as suitable, as some animated objects may not have physics associated with them). While the latter might be a little more fiddly to use, it is the option Vir seems to prefer, although as he notes, he still needs to do more testing. If the approach doesn’t work, use of LSL commands might be looked at as an alternative.

Baked Textures on Meshes

Anchor Linden is working on the project. At the moment the focus is on baking service infrastructure updates to support the increased baking requirements (including support of 1024×1024 textures, which is seen as the “easy” part).  There is no ETA for this work at present, but the rough work flow is:

  • Update the baking service
  • Carry out performance testing – increasing the number of avatar bakes for a large number of avatars is going to increase the cost of the baking process, so the Lab needs to be sure any requirements for additional baking servers are understood
  • Issue an updated viewer which supports rendering the new bakes, and has a compatible “local baking” (used to define your initial look for transfer to the baking service) which is fully consistent with the baking service.

Once these are in place, then work can commence on how to flag mesh faces as being surfaces on which the baked textures are to be applied. This will include  a mechanism  for hiding the existing (default) avatar body without using an alpha layer.

Updating the baking service to support bakes on meshes will not involve adding materials support to the baking service, although that may be considered as a future project. The focus here is purely on extending the baking service to support using the baked textures already available on mesh avatar bodies.

Alpha Masking Mesh Bodies

The question was raised on whether use of the baking service would allow clothing creators to use alphas as a means to hide body elements to stop them showing through mesh clothing worn by an avatar (as tends to be done with the system avatar and mesh clothing today, rather than or alongside side of the current mechanism where a mesh body (Maitreya, Slink, TMP, etc.), is split into numerous parts with multiple faces which can have individual alphas applied too hide them.

Vir believes the baking service should be able to provide suitable body masking, given it can already for the system avatar, where alpha baked into an appearance can be used to hide all or parts of an existing system avatar when seen by others.

Cathy Foil also suggested a means to “turn off” the default body parts on the system avatar (head, upper body, lower body) or the use of a second alpha channel. The first option is useful, but constrained – you can’t turn off hands or feet, for example as they are defined within the upper / lower body part. A second alpha channel offers greater flexibility, but adds to the complexity of implementation.

Overall, masking through the baking service – given there have been tests by body creators in the past to see how alphas within bakes work on mesh bodies – is seen as the more direct answer. It will obviously require people to go through a learning curve, vis understanding applying bakes to meshes and any UI changes, etc. The project viewer – once available – is seen as a means of starting on this learning process, as well as a means of determining what has been missed / may additional be required to make the capability useful.

Mixing Bento Hand Animations and Non-Bento Hand Morphs

BUG-100819, “Default hands spread wide during bento hand animations, making it impossible for Bento and non-Bento owners to play together” came up for discussion at the meeting.

In brief: the default system avatar uses a set of morphs to allow the hand to form a series of basic shapes: a relaxed hand pose, a fist pose, a spread fingers (default) pose, etc. Which can be triggered by an animation utilising an identifier. Bento animations, however, directly manipulate the 30-odd bones the hand to produce hand and finger poses. As the system avatar cannot used these bones, the Bento animations are effectively ignored when run on a system avatar.

However, the underpinning system hand morphs can still be used by the system avatar providing the required morph is identified within the animation itself. When this is done, the animation will play for Bento avatars, or be ignored by system avatars in favour of the defined morph. But if no morph value is specified within the animation, the system avatar hand will adopt the default splayed fingers morph – which appears to be what is happening in the JIRA, possibly combined with an animation priority clash.

Medhue Simoni recently produced a live stream walk-through of mixing Bento animations and default hand morphs, and provided the link to that session at the meeting, which I’ve embedded below.

It has been suggested that the splayed fingers issue could be avoided by changing the system so that if a null value is specified in an animation (as opposed to leaving the field blank), the system avatar will adopt the relax hand morph. While Vir has agreed to look into this, adding such a null value will not automatically resolve the problem for animations which doe not have any morph value defined – the system avatar will continue to use the splayed fingers morph.

Another suggestion is to have the exporter in the tool used to create the animation (e.g. Avatar) display a reminder that hand animations should have a morph value defined. This would make more sense, as it would be within the application where the animator can easily add a value if they had forgotten to do so.

General Discussions

  • Re-purposing Bento bones for pets – yes this can be done, providing the re-purposed bones are not being used for anything else (e.g. if a pet attached to your avatar skeleton uses facial bones and you have a Bento head using the same bones, wearing both at the same time will result in conflicts.
  • Animated object will overcome this, by allowing completely independent pets, but is it’s not clear at this point if these could be attached to an avatar, as that would me combining two independent skeletons.
  • A request was made to increase the largest allows size for prim creation (64m x 64m). This is unlikely to happen.

Bento Bones and Weapons

Bento bones can be used with weapons, again providing they do not class with other mesh using the same bones. In this, the wing bones would seem to be a good choice, given groin, tail and rear leg bones can have a wide variety of uses, and may be more prone to clashes.

One problem with weapons is getting them to align with the hands. As Medhue pointed out in the meeting, he has discovered that getting rigged weapons to stay aligned to the hands when the avatar’s shape is changed is next to impossible. Instead, he recommends not rigging the weapon, then using the hand attachment point and animating that instead. This both allows the weapon to be animated and ensures the weapon remains closely matched to the hand no matter how the avatar is resized.

SL project updates 24/1: server updates

Le Sixième Sens, Le Sixième Sens; Inara Pey, June 2017, on Flickr Le Sixième Sensblog post

Server Deployments, Week 24

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

  • There was no deployment to the main (SLS) channel on Tuesday, June 13th. Nor, as the channel was updated in week #23, was there a restart.
  • On Wednesday, June 14th, the server RC channels will be updated as follows:
    • LeTigre should receive a new server maintenance package (#17.06.12.327066), comprising additional internal logging and features and improvements to region start
    • BlueSteel should receive a new server maintenance package (17#17.06.13.327122) containing internal fixes
    • Magnum should receive an update to the new operating system update (#17.06.12.327060), which includes a fix for BUG-100737 “Shoutcast receivers unable to relay on RC Magnum” – see below for more.

Shoutcast Issue

The original OS deployment to the Magnum RC channel resulted in breakages to scripts used by various streaming service DJ boards (as noted in BUG-10073, above). This week’s deployment to Magnum fixes this issue, but it will require all scripts affected by the problem will require update.

The fix means the server will no longer allow newlines or other characters that don’t belong in URLs in the url parameter, but there will now be a new option HTTP_USER_AGENT that will allow a specific agent value to be added to the one generated by the server. The wiki documentation will be updated to reflect this update.

SL Viewer

There have been no updates to the LL viewers in the various pipelines. This leaves the list as:

  • Current Release version 5.0.5.326444, dated May 18th, promoted May 23rd
  • Release channel cohorts:
    • Maintenance RC viewer version 5.0.6.326731 dated June 1st
    • Voice RC viewer, updated to version 5.0.6.326589 dated May 31st
    • Project AssetHttp viewer updated to version 5.0.6.326593 dated May 26th
  • Project viewers:
    • Project Alex Ivy 64-bit viewer, version 5.1.0.505089, dated on May 11th
    • 360-degree snapshot viewer updated to version 4.1.3.321712 dated November 23, 2016
  • 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.

Windlight environmental enhancements

At the Simulator User Group meeting on Tuesday, June 13th, it was confirmed that the Lab is starting work on a set of environment enhancements, including parcel windlight support. For the  fully details, please refer to my separate article. The informal name for this work is EEP – Environment Enhancements Project (!).

SL project updates, 23/2: Content Creation Meeting

The Content Creation User Group meeting, at the Hippotropolis Camp Fire (stock)

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, June 8th, 2017 at 1:00pm SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.

A video recorded at the meeting by Medhue Simoni is embedded at the end of this update, my thanks to him making it available. Timestamps in the text below refer to this recording. The meeting was disrupted by three region crashes, and this is reflected in the stream recording.

Asset HTTP Viewer

[2:50] The Asset HTTP RC viewer (version 5.0.6.326593 at the time of writing) has an update with LL’s QA. As noted in my last TPV Developer meeting update, this includes the new viewer update management code. It is now expected to appear in the release channel and an RC update in week #24 (week commencing Monday, June 12th).

Animated Objects

[3:18] Vir is continuing to work on the animated objects project, and now has an internal version of the viewer that hooks-up to a correctly configured simulator. It is still some way from being ready to be offered as a project viewer, however.

Skeleton Positioning

[4:09] One issue to be considered with animated objects using the avatar skeleton is where the skeleton is supposed to be positioned. Avatars are placed by the simulator providing information on where the agent is, and the bones are then positioned and things like hover height are applied, and whatever rigged objects are being worn are positioned relative to the skeleton’s position. With an animated object, the reverse is true: the object has a defined location, and some means needs to be found for the system to position the bones accordingly; it’s not currently clear how this should be done.

Vir has tried experimenting using the mPelvis bone, and aligning that with the object’s position, with mixed results. So, should the Lab simply pick a convention and have people build their animated objects accordingly, or should a smarter, more adaptive solution be sought?

Collisions

[10:50] Collisions (being struck by avatars, other objects). Collision detection isn’t currently carried out in SL for skinned objects, however, Vir is considering calculating collisions based on the collision volume of the skeleton, although this has yet to be investigated.

Setting a Prim as Object Root

[11:19] Cathy Foil has suggested using a prim as the root for an animated object, with the skeleton positioned relative to that prim. This has the advantage of potentially allowing the skeleton, as a child linkset of the root, to have physics; further, the prim could be set statically at a fixed location in a region, and the skeleton  / object animated to roam independently or it could be scripted to move (and even use Pathfinding), with the animated skeleton / object carried along with it. Thus, it could offered a flexible approach to the problem.

[14:34] One of the things Vir is aiming for is for creators to be able to take existing skinned mesh content and turn it into animated objects, without the need for the model to be re-worked / re-uploaded.

Multiple Rigged Meshes in an Animated Object

[17:38] With his current work, Vir believes it should be possible to have multiple rigged / skinned mesh objects animated by a single skeleton (e.g. so an avatar body can be split into the notional lower body, upper body, head). This could have some interesting uses providing the meshes don’t try to use the same bones.

Frame Rates

[20:05] Vir has had a number of animated objects running at the same time, and he has not seen a significant impact on frame rates. However, the caveat here is the relative rendering complexity of animated objects and how that affects client-side processing. The current hope is that the impact of any given animated object will equate to that of a similarly rigged and complex avatar, so the potential for performance impact is there; it’s just too early in the project to make any definitive statements.

Editing Size

[20:45] At the moment, the size of an object is governed by the size of the skeleton; it could be more flexible if the size of the objects could be set / edited, and this determines the size of the skeleton. This might, for example, be done by sizing the skeleton to the object’s bounding box (which adjusts as the object is resized). However, it’s again too early in the project to offer a definitive way this might be done.

[23:12] Cathy points out that having a root prim for an animated objects, sizing them could be tied to the size of the root prim. So, for example, doubling the size of a root prim would double the size of the object.

Applying Baked Textures to Mesh Avatars

[33:41-35:45] A short explanation of this project for those unfamiliar with it. In brief, a means to apply composited textures bakes (skin, tattoo, clothing layers, etc), to mesh bodies using the SL baking service, with the aim of potentially reducing the complexity of avatar bodies.  This work is being carried out alongside of animated meshes, but is not dependent upon that project (or vice-versa).

[29:06] Updates to the baking service to support baking textures on mesh avatars has now started. This is currently infrastructure work – updating the baking service to a newer version of Linux, etc.

After this, the first step in getting the service to work with mesh bodies will be updating it to support 1024×1024 textures and producing a corresponding viewer update. Once the latter is available for testing, then the Lab will be ready to look at the feature set for supporting bakes on mesh.

Materials Support and the Baking Service

[30:30] There may be a misunderstanding circulating that the baking service will “disable” materials on meshes. This is not the case.

The baking service has never supporting materials processing, and the work to enable texture baking on meshes will not include extending the baking service to handle materials  – this would be a huge undertaking. However, it will not prevent materials from being used via other means (application directly on the mesh, etc.), or any other way in which materials are used in-world.

The baking service uses is a composited diffuse (texture map). This may be less than is currently possible when using applier systems (which should continue to work alongside bakes on mesh). [40:34] It will also be possible to still manually apply normal and specular maps to an avatar mesh using the bakes.

Baked Texture Delivery to a Mesh / Persistence

[31:53 and 38:47] Once a bake has been completed it would be delivered to the mesh by means of flagging the face to which it is to be applied. This flag will remain persistent, so when the avatar appearance is updated texture will be re-applied to the face, until the face is flagged as requiring a different baked texture.

Arbitrary Use of Bakes

[36:24] As noted in my last Content Creation UG update, there has been some discussion of a more arbitrary use of bake textures and applying them to other objects, but this in not the focus of this current work. However, these ideas might be considered in the future.

Anchor Linden

[41:58] Anchor Linden is a new name at the Lab, and is currently working with Vir, focusing on the texture baking project.

Supplemental Animations

[41:38] The supplemental animations work, designed to overcome issues of animations states keyed by the server-side llSetAnimationOverride() conflicting with one another, is still on the card, just no further movement as yet.

General Discussion

[44-22-end] General discussion: mesh uploads, proper management of LODs, etc.

SL project updates 23/1: server, viewer, environment updates

Out on the Calas horse trails, Caitlyn leading the way – blog post

Server Deployments

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

  • On Tuesday, June 6th, the Main (SLS) channel was updated with a server maintenance package (17.05.26.326655), containing fixes to help with the caps (capabilities) router, particularly with reference to trying to teleport to regions which have a heavy avatar load (see here for details).
  • On Wednesday, June 7th, the RC channels should be updated as follows:
    • BlueSteel and LeTigre should each receive the same server maintenance package (17.06.01.326763), comprising internal fixes.
    • Magnum should receive a server maintenance package, but details were still TBD at the time of writing.

Capabilities Losses at Region Restart

Some regions are still suffering capabilities failures at restart (see this forum thread for an example, and see these wiki pages for more information on capabilities: Capabilities and Current Sim Capabilities). This overall caps system is shared at the server level, so when problems like this occur, it affects all of the regions on that server, which then require an individual restart to correct.

SL Viewer

There have been no further viewer updates since my last project updates article. This leaves the current viewer pipeline as follows:

  • Current Release version 5.0.5.326444, dated May 18th, promoted May 23rd – formerly the Maintenance RC viewer overview
  • Release channel cohorts:
  • Project viewers:
    • Project Alex Ivy 64-bit viewer, version 5.1.0.505089, dated May 11th
    • 360-degree snapshot viewer, version 4.1.3.321712 dated November 23rd, 2016 – ability to take 360-degree panoramic images
  • 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.

Other Items

Environmental Update

“We are going to kick off a set of environment improvements – exact scope is still TBD,” Oz Linden states at the Simulator User Group meeting on Tuesday, June 6th. “[but] there are a couple of hot problems that need to be stomped first.”

While the exact nature of these improvements is still TBD, the comment sparked a conversation on parcel windlight settings, which Oz indicated the Lab is still planning on implementing. While all discussion on this is still somewhat speculative, the current thinking on this at the Lab is:

  • The precedence will be 1) viewer local (so if you set a windlight through the viewer, that will take priority over any windlight indicated by the region / parcel) , 2) parcel (if allowed by estate), and 3) region
  • Currently, it is unlikely that the parcel controls will allow setting windlight environments by altitude (aka Firestorm zoning).

The latter point is perhaps the most contentious for those using the current Firestorm zoning for windlight – not only does this allow different windlight conditions for different altitudes (particularly useful in role-play regions which may have different locations stacked vertically, each of which is ideally suited it its own environmental setting), it also things like caves and caverns to have their environment set to midnight, naturally darkening them (a technique we use at Caitinara Bar for the benefit of those using Firestorm).

In addition to parcel windlight, the Lab is looking to add an experience-controlled way to change environment for an individual avatar – so that those joining an experience will have their viewer automatically adopt the windlight setting for the experience, if one is set. This could also provide a means for “altitude zoning” of windlights to some degree.

None of these additions will prevent users applying their own viewer-side windlight should they wish (as noted above).

Other subjects possibly on the list of environmental settings:

  • Selectable cloud textures (similar to the capability in Firestorm)
  • The ability to change the moon texture
  • Adjustable day length (so, for example, one SL day =  a physical world day)

As Oz noted in the meeting, the details of what the Lab would consider working on with the environment improvements has yet to be fully defined; however, he also added, “When we get to the point where we’re ready to start work on it (hopefully very soon), we’ll post a description of what we’ve got in mind … and yes, we’ll accept suggestions for improvements then.”

SL project updates 22/2: TPV Developer meeting

Chess Wonderland, Egypt; Inara Pey, May 2017, on Flickr Chess Wonderlandblog post

The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, June 2nd, 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. Timestamps in the text below will open the video in a separate window at the relevant point for those wishing to listen to the discussions.

Server Deployment – Recap

  • On Tuesday, May 23rd, the Main (SLS) channel was updated with a server maintenance package (#17.05.22.326523), containing a fix for BUG-100704, “[Server] If Anyone Can visit is selected after Allow Group was set only group members can enter”, related to the parcel overrides update.
  • On Wednesday, May 31st, the RC channels were updated as follows:
    • BlueSteel and LeTigre received the same server maintenance package (#17.05.26.326655), comprising “Tweaks to help with capability loss”.
    • Magnum received a server maintenance package (#17.05.26.326659) for the simulator operating system update, which does not contain and functionality changes.

SL Viewer

[0:20] The Voice RC cohort updated to version 5.0.6.326589 on Wednesday, May 31st.

[0:31] The Asset HTTP viewer is doing reasonably well in its latest RC update (version 5.0.6.326593, dated May 26th), and this might be the next viewer to gain promotion to release status.

[28:22] Once the asset HTTP viewer has been promoted, the Lab plan to develop a schedule for removing simulator support for the old UDP messaging the HTTP updates have replaced. The actual removal of the messaging paths might not occur until 2018.

Maintenance RC

[0:40] A new Maintenance viewer was released as a RC cohort on Thursday, June 1st, 2017. Version 5.0.6.326731 includes a range of bugfixes and updates, including further updates to Trash management:

  • Fix for number of items in Trash calculation
  • Trash is full floater wasn’t showing in some conditions when it should have been. It will do as it should now.
  • Fix for when Trash version gets out of synch
  • A delete warning will now show up once every session to cut down on accidents
  • Trash purge message will include number of items deleted.

Alex Ivy (64-bit viewer)

[0:55] A new update for the 64-bit viewer will be appearing soon, it will include the new viewer update code, to help ensure the correct version of the viewer (32-bit or 64-bit) is delivered to the user.  Additional changes to the server-side viewer update manager (the code which tells the viewer there is a newer version available) have delayed this update from appearing sooner.

[2:10] When this version of the viewer is issued, it is anticipated that work will commence on building and QAing a Release Candidate version of the viewer. At this point the Lab will also start work on updating the SL wiki instructions for building the viewer.

[5:35] The Lab’s reocmmendation is that if Windows users are using the 32-bit version of the viewer on a 64-bit system, they should swap to a 64-bit version of the viewer for a less crash-prone experience.

[6:16] A caveat to this is 64-bit systems using the Intel HD and Intel HD4000 GPU chipsets. These systems cannot run the 64-bit version of the viewer and require the 32-bit version.

360-degree Viewer

[3:43] An update to the 360-snapshot viewer is expected soon, pending the fix for an issue with the Mac OS X build.

When the update appears, it will not require any post-processing of a ZIP file (as is currently the case). Instead, it should produce an equirectangular image with all the necessary metadata required for displaying on sites which support 360-degree images.

OTR and Chat Text Encryption

[7:14-18:56] Questions have again been raised on the use of end-to-end encryption of IM conversations by TPVs. This was a thing several years ago, largely derived out of misplaced fears that LL staff where reading people’s IM conversations willy-nilly. However, as it used viewer code never intended for that purpose, it was “broken” when the underpinning code was updated / removed.

At the time the encryption was used, it was problematic for the Lab, as it interfered with things like verifying abuse reports by checking IM logs (if the conversation is encrypted, LL cannot verify what was said, and so cannot take any action, even if warranted), and could also be an issue assisting in other types of necessary investigation (e.g. possible fraud / money laundering acts).

The circumstances under which someone from LL can view IM files are strictly limited and controlled, both in terms of who can view them, when then can view them and how much of them can be viewed. As such, there is no risk in IM logs just being casually read at the Lab. Given this, and the issues it can cause, use of any form of encrypted IM exchange would likely be frowned upon or be regarded as a “normal” function of SL (and so wouldn’t be safeguarded from potential “breakage” during future changes to the viewer). Instead, those feeling they need secure communications with other are encouraged to use other means of doing so.

Shoutcast / Streaming Scripts Issues

[23:30-26:33] The Magnum channel RC has resulted in breakages to scripts used by various streaming service DJ boards (see BUG-10073). The issue has been diagnosed, and a means to allow these services to keep operating is being developed. However, when deployed it will mean that the scripts themselves will also need to be revised, and it will not be backwards compatible with systems that are not updated by their creators, which will remain broken. As the change causing the issue is integral to the HTTP updates being made to improve SL’s performance, it will not be rolled back.

Griefing Following Ban

[30:02-35:39] Some estate managers are finding themselves specifically targeted for griefing after banning someone from their land (identified by the griefer as ban notifications carry the banner’s name). In some cases the griefing can extend to groups associated with the land. One solution is to use a bot for banning purposes, however, the request has been made for better anonymity for those carrying out the ban. A JIRA has been requested, providing the fullest possible description of the issue, what happens, and how, and what is believed to be needed to counter it.

General

  • [19:17] BUG-40824, “Missing Offline Group Notice (Unreliable Delivery)” is still proving a problem for some. The Lab haven’t looked at the issue recently, but will get back to it.
  • [21:25] Local and group chat has been lagging – again, it’s been noted, but no specifics on possible causes.
  • [21:49] Increasing limits (physics, etc) – currently the focus is on the simulator OS update, which includes, software tools and libraries. Once this work has been completed, the Lab hopes to look at all the limits and see what can be adjusted, either directly or with some up-front work.