Category: SL User Group Meetings

Second Life project updates 27/1: server, viewer, Experience Keys

Posted on by Inara Pey

Jasmine's Hollow; Inara Pey, June 2015, on Flickr Jasmine’s Hollow (Flickr)

Server Deployments

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

  • There was no scheduled deployment to the Main (SLS) channel on Tuesday, June 30th
  • On Wednesday, July 1st, all three RC channel received a re-roll of the server maintenance project from week #26, minus the problem which caused that week’s roll-back.

BUG-197, “Cannot See My Chat Only In My Region/ Region Bad Performance” refers to a problem whereby a user can’t see any of their local chat on a region or parcel, and nor can anyone else, due to a scripted object which is spamming chat so badly, the chat throttle kicks in, but no warning would be provided to inform the user this was the case. with the deployed change, the user will now get a message about the chat throttle being hit, but unfortunately, the system will not identify the spammy object (so it might be removed / returned, if possible).

SL Viewer

On Tuesday, June 30th, the Experience Tools RC viewer, version 3.8.0.302622, was promoted to de facto release status by Linden Lab. An official blog post accompanied the promotion, and I blogged an updated overview of the viewer and Experiences.

On Thursday, July 2nd, the Attachment Fixes RC viewer (Project Big Bird) updated to version 3.8.1.303130, bringing it to parity with the release viewer. The Maintenance RC viewer and the Viewer-Managed Marketplace RC viewer will also be updated in due course.

Experiences and Experience Tools

As noted above, the Experience Tools viewer was promoted as the release viewer on Tuesday, June 30th. As a result of this, a number of questions were raised during the Simulator User Group meeting that day, some of which have been asked elsewhere, and so are reproduced here:

  • Will accounts other than Premium be able to create Experiences in the future?
    • No comment at this time
  • Will it be possible to purchase additionalKVP data storage (for storing information on an experience – players, their progress, etc.) in future?
    • This has not been ruled out by the Lab, but it is something they’re decided they don’t “need to figure out yet”
  • What happens to an Experience if a Premium user reverts to a Basic account?
    • The Experience is suspended; data saved to the KVP will not be immediately deleted
  • Will it be possible to transfer an Experience to, say an alt on Premium if downgrading the account associated with the Experience to Basic?
    • This is a possible idea for the future; however the Lab are not looking at it at present, due to the complexities involved
  • Can any third-party creators to sell no mod scripts for other people’s experiences?
    • Technically, no; contributors to an Experience have to be explicitly allowed by the Experience owner
  • Can an Experience run on a mainland parcel?
    • Yes
  • Can an experience run across multiple regions?
    • Yes, so long as it is Allowed by the land owner(s)
  • Will a region restart affect the information for an Experience stored in theKVP?
    • No.

Other Items

Windlight / Environment Changes

The Lab is looking to improve windlight / environment capabilities within the viewer. No work has actually started as yet, but there has been an offer from the Alchemy TPV team to contribute code that would allow the cloud textures to be changed without having to re-start the viewer when doing so.

An idea that has been suggested is that creating and saving windlight settings as local XML files could be replaced by saving them as assets. No decision has been made on this, but it is important to note that were this to go ahead, this would not prevent people from creating their own windlights. Rather, what it would mean is that such custom settings would be saved as SL assets, rather than locally, making them easier to share with others, resulting in a more easily achieved “shared experience” to be experienced.

Avatar Complexity

The release  of a project viewer for Avatar Complexity is still stalled due to the bug that’s been introduced that renders all avatars affected by the setting as invisible, rather than as the expected “Jelly Babies”.

Second Life project updates 26/1: server, avatar rendering

Posted on by Inara Pey
The DECADES event - Saturday, June 27th, 2015 only - details here
The Decades event – Saturday, June 27th, 2015 only – details here

Server Deployments

  • There was no scheduled deployment to the Main (SLS) channel on Tuesday, June 23rd
  • On Wednesday, June 24th, all three  RC channels were updated with the same new server maintenance project, which included a fix for BUG-197, “Cannot See My Chat Only In My Region / Region Bad Performance” (not open to public viewing) and internal simulator fixes. As pointed out in the comments, this deploy was actually rolled back; I had forgotten to re-check the deployment page between originally drafting the first part of this article and publishing it.

The chat issue is a problem whereby a user can’t see any of their local chat on a region or parcel, and nor can anyone else due to a scripted object which is spamming chat so badly, the chat throttle kicks in, blocking their chat. However, no message would be provided to inform the user this was the case; with the change deployed on Tuesday, the user will now get a message about the chat throttle being hit, but unfortunately, the system will not identify the spammy object (so it might be removed, if you own it / the the rights to return it).

Avatar Complexity and Avatar Rendering in Busy Regions

Avatar Rendering in Busy Regions

During the Simulator User Group meeting on Tuesday, June 23rd, Simon Linden hinted that as well as the upcoming Avatar Complexity feature for which I recently gave a rapid overview, there are other options the Lab might consider in order to lighten the rendering load created by avatars:

We may experiment with a similar setting for crowds … setting a limit on the number of avatars we do any attempt at rendering.   In other words, if you were at a region with 75 people in view, and it was set for a limit of 64, you’d only get 64.  The remaining ones just wouldn’t be there in any form, similar to turning off avatars with ctrl-alt-shift-4.

He then went on:

That’s just an experimental idea now. To really make it better in a crowd, we’d probably want the server interest list to know and then it wouldn’t send you those updates.

As we’ve seen, the Interest list isn’t the easiest thing to play around with, so it’ll be interesting to see which, if either, of these ideas might be pursued.

Avatar Complexity

In terms of Avatar Complexity, questions have already been asked if the upper limit is adequate. With the test viewer, the Avatar Complexity slider runs from a value of 19,999 (which pretty much that no other avatars will render in your world view) means pretty much no other avatars will render in your field-of-view) through to 300K, above which sits “No Limit”, which means any avatar will render.

However, the suggestion has been made that the upper limit should perhaps be increased to allow for those who want to render particularly complex avatars used by friends. Responding to this, Oz Linden said, “It wouldn’t be hard to make the range somewhat wider, but at some point the control becomes too hard to use because each pixel is too big a jump.”

One issue that the new Avatar Complexity capability will not prevent (although, strictly speaking, it’s not designed to) is that it will not prevent worn mesh crashers impacting the viewer, because while the avatar is not actually rendered, the data on what is being worn still gets loaded into memory, and it is this that is used to crash things. Commenting on this, Simon linden said, “That sounds like something that should be looked at … if we can avoid loading that data, it would help everything.” Commenting on this, Oz Linden added:

There are a number of available optimisations; among them, using the complexity information from others to just pre-emptively not even fetch the appearance info for an avatar.

So again, it will be interesting to see what might come to pass in the future, should the Lab take this work up as well.

Second Life project updates week 25/2: TPV Developer meeting

Posted on by Inara Pey
Alpha.Tribe
Alpha.Tribe – blog post

The following notes are taken from the TPV Developer (TPVD) meeting held on Friday, June 19th. A video of the TPVD meeting is included below, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding.

SL Viewer

RC Viewers

[0:39 / 08:00] The Viewer-Managed Marketplace (VMM) viewer reached release candidate status on Thursday, June 18th with the release of version 3.7.31.302677. This means the VMM code is now officially available for TPVs to integrate into their viewers. When this viewer reaches release status, it will signal the end of the current VMM beta period.

[22:37] Currently, the Lab is aiming to promote the Experience Tools, VMM and attachment fixes (Project Big Bird) in order – although what that order might be, has yet to be finally determined.

A new Maintenance RC viewer, version 3.7.31.302685, entered the release channel on Friday, June 19th, with some 50 fixes, improvements and updates, covering building, snapshots, group ban fixes, rendering fixes, etc. Please refer to the release notes for full details.

Project Viewers

An update to the Oculus Rift project viewer  (currently version 3.7.18.295296, and not updated since October 2014) is anticipated to be arriving “soon”, although no precise date is available.

[09:10] A new voice project viewer is expected to appear in week #26 (week commencing Monday, June 22nd), with fixes for voice issues directly from Vivox.

[09:32] A project viewer based on the latest HTTP updates (llcorehttp) that rider Linen has been working on is also expected to make its appearance shortly. This will likely remain at project viewer status for a while as it goes through various iterations as further improvements and revisions are made.

[10:00] A further project viewer with the Lab’s revamped notifications interface (see BUG-8000) is also anticipated as arriving soon as well.

A preliminary version of the proposed new notification panel (see BUG-8000). Note that is is a work-in-progress and may be subject to change prior to release (image courtesy of Whirly Fizzle)
A preliminary version from February 2015 of the proposed new notification panel (see BUG-8000). Note that is is a work-in-progress and may be subject to change prior to release (image courtesy of Whirly Fizzle)

Chromium Embedded Framework

[10:14] Work is progressing with the switch from webkit to the Chromium Embedded Framework (CEF) for media management such that it is entirely possible that a project viewer using CEF may be appearing in the next two weeks.

Snowstorm Project Viewers

[10:30] There are two Snowstorm (open-source contributions) viewers in progress. One of these includes the Avatar Complexity work and the ability to save graphics preferences for the viewer which are being developed by Jonathan Yap (see below for more on this viewer).

The second is a viewer build clean-up viewer that includes a number of TPV-contributed updates and fixes. This latter viewer is currently awaiting internal resources at the Lab, but should hopefully “very, very soon”.

Avatar Complexity

Work on the Avatar Complexity code has been halted due to the introduction of a bug
The introduction of a bug has paused work on the Avatar Complexity code

The Avatar Complexity (aka Jelly Babies) project is the upcoming functionality which provides greater control to user to define how other avatars are rendered in their world-view.

However, a recent  hiccup means that the project has been on hold. n making some changes to the code, Oz accidentally broke the code such that instead of rendering as a solid colour, avatars exceeding the limit are currently rendering as transparent, and this is yet to be fixed.

Commenting on situation at the TPV Developer meeting, Oz indicated any help any willing devs can provide to help sort the problem out, would be appreciated. The public repository for the code is here.

The code problem arose as Oz sought to make changes such that avatars above the rendering limit set by the user render as “Jelly Babies” (i.e. a solid colour, as previously indicated in discussing the project), those avatars with incomplete rendering data are rendered grey (as we currently sometimes see in-world), and those that the user has muted are simply not rendered at all.

Continue reading “Second Life project updates week 25/2: TPV Developer meeting” →

Second Life project updates week 25/1: server, viewer

Posted on by Inara Pey

Flux Sur Mer; Inara Pey, June 2015, on Flickr Flux Sur Mer (Flickr) – blog post

Server Deployments Week 25

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

  • On Tuesday, June 16th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels, comprising further Internal server logging changes.
  • There will be no deployment or restart to the three RC channels on Wednesday, June 17th.

SL Viewer

On Friday, June 12th, the Lab issued a new viewer directly to release status. Version 3.7.29.302599 offers no functional changes to the the previous release viewer, but does include two DLL files – MSVCP100.DLL and MSVCR100.DLL which were missing from the Windows version of the viewer, and as a result causing problems for some users by their absence.

As a result of this release, the Attachment fixes RC viewer (Project Big Bird) RC viewer updated to version 3.7.31.302640 on Tuesday, June 16th, and the Experience Tools viewer updated to version 3.8.0.302622.

An “obsolete platform viewer” has also been issued by the Lab. Version 3.7.28.300847 of the viewer is a “static” release of the viewer which is aimed at providing users on Windows XP or versions of OS X below 10.7 to be able to continue to log-in to SL following the upgrade of the tools used to build the viewer. As I reported at the time, the key points to note about this viewer are:

  • It will not receive new features or bug fixes
  • It will not be promoted to release status
  • It does not change the Lab’s support policy on Windows XP or versions of OS X below 10.7, and is purely – as noted – an interim offering to help people
  • It will be provided for as long as is reasonable – but not indefinitely.

 Other Items

 Experience Keys  / Tools

As noted above, the Experience Tools RC viewer has been updated to match the current release version as the Lab continue to work on the back-end services. One issue that has been encountered  – albeit it in a single case so far – is that access to the KVP store used to hold information on the experience can be delayed in very permissive areas where there is a lot of natural in-world rezzing going on (e.g. public sandboxes) – see BUG-9027. This is because access to the store uses the same resources as used for rezzing objects.

The concern with the problem is that it could have an impact of grid wide experiences. However support for running experiences on a grid-wide basis is, in the Lab’s eyes, “still some time in the more distant future”, as they are focused on the region / parcel level and ensuring the capability works within these extremes first. As such, this issue is unlikely to prevent the initial deployment of the Experience Tools capability, although the Lab will look into this particular matter at a latter date.

Combat and Damage

During the Simulator User Group meeting on Tuesday, June 16th, the subject of damage, combat and protection within regions controls. Commenting on the matter Simon Linden said, “I’m beginning to think more and more we need regions set to different modes … something safe for general use, then raise the limits for combat (and the like) where you are freer to hurt yourself.  It’s just an idea at this point, but the one-setting-for-everything seems to always make someone unhappy.”

The problem here is that the existing Linden Damage system is seen as being somewhat inflexible, hence the development of various combat systems within SL. However, that there are so many systems now available, makes the Lab hesitant to change things, as Simon went on to explain:

We’ve talked before about working on the damage feature but I think that’s a case where everyone has their own usage, and so it would be better to have the features so others can make the damage systems they want. We probably can’t alter the current one. I’m sure somewhere somebody is using it and we can’t break their content. We could add to it, if it’s backwards compatible, but like I said, I think it would be better to hear what the CS and other system builders want to make their system nicer.

As Simon states, this doesn’t mean the Lab are about to make changes, or consider making changes where combat systems and damage are concerned; just that they are aware of the limitations within the current land settings.

That said, a recent change within the LL viewer has been noticed. Under it, damage cannot be set it the parcel level only; also, the viewer does not display the health meter on damage enabled parcels, but people can be “killed” and teleported home.  While Oz acknowledged this may be due to the Lab not fully following through on a set of changes to the viewer code, Simon also pointed out that the two-state on / off capabilities between regions and parcels has never really been fit for purpose:

Basically if you have any larger or high level setting, as well as a smaller scale (like regions vs parcels)  the higher one can’t just be “on” or “off”. It needs to be “on with override smaller settings” , “on without override”, “off override smaller settings” , “off without override” … It just doesn’t work with simple on/off settings.   You need more info about the intent on how it relates to the smaller areas

However, he again warned against anything being done on this in the near future, commenting, “if we want to fix this in SL, it means viewer UI changes, new data being passed back and forth to the simulator (which can be a hassle depending on the messages), new values in the database (which is another issue) and of course simulator changes.” In other words, were anything to be done, it would be a large-scale project, something which the Lab has yet to even consider taking on.

SL project updates week 24/1: server; VMM; group list changes

Posted on by Inara Pey

Goatswood; Inara Pey, June 2015, on Flickr Goatswood (Flickr) – blog post – visit soon, closes June 19th, 2015

Server Deployments Week 24

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

  • On Tuesday, June 9th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels, comprising:
    • Change logic on accessing group member lists for large groups – please see more below
    • Internal server logging changes
  • On Wednesday, June 10th, the three RC channels should all receive a new server maintenance package comprising further Internal server logging changes.

Group Member List Changes

The “Change logic on accessing group member lists for large groups” refers to how the members list for groups with more than 5,000 members are now handled. A full explanation of the change and the reasons behind it can be found in my blog post on the matter. however, in short:

  • Groups with 5,000 or more members will no longer display the list of members unless:
    • You are assigned the Owner or Officer role within the group
    • You are assigned an ability within the group which requires the members list to be displayed (e.g. you are able to assign members to assigners roles, or are able to eject / ban people from the group, etc.)
  • Instead, and until corresponding changes are made to the viewer, all you will see on opening the members list as a message stating “Retrieving member list (0 / XXXXX)” – where XXXXX is the total number in the group,

The has already caused concern over how the change may be perceived as a functional breakage – see BUG-9393. In addition, two further issues resulting from the change have been reported:

  • BUG-9404: “Group members of large groups in a role which has “Invite people to this group” ability are not able to send group invites” (initially filed against the RC regions when the change was deployed in week #23, and now applicable to the grid as a whole)
  • BUG-9428: “Users using older viewers are unable to leave groups with >5k members on regions running 15.05.28.302161”

Scripting Memory Limits

A request was made for the Lab to consider allowing llSetMemoryLimit to request up to 128kb or 256kb of memory (whichever is more feasible), with a performance penalty for scripts using less than 50% of the memory requested – see BUG-9382.

The arguments for such an increase are not new; many coders run into problems with utilising memory for both code storage and code operation, resulting in having to write inefficient scripts and additional operations to communicate between scripts. A similar request has also been put forward (see BUG-8761), but which limits the additional memory allocation purely to Experiences on the ground that offering increased memory to all could lead to performance and other issues.

Commenting on the request at the simulator User Group meeting on Tuesday, June 9th, Simon Linden said:

I don’t think we’d want to limit performance … that seems like it would get into odd rules and conditions. Plus that’s likely to be in a place where we don’t want to add more code. FWIW, when you have lots and lots of scripts in a region, the time spent rotating through all the scripts becomes significant, so your script time isn’t just running scripts.

Oz Linden then added:

One of our frequent themes this year has been to look at various limits and consider making them better … perhaps we can look at the memory limit at some point too. One of the things I hope will happen as Experiences are adopted is that some of the code that’s being used to manage saving state and communicating can be replaced by simpler code to use the key/value store.

This drew agreement from Simon, who then continued:

I suspect larger script size has been limited by not having script memory limits. But at a smaller scale, it’s easy to add more scripts, so perhaps doubling or a bit more won’t really make it any easier to hog memory.

This doesn’t automatically mean that script limits will change in the future; as Simon also pointed out, script memory is the largest part of each avatar load, and can have an impact on things like physical region crossings and teleporting, which would likely have to be be considered. However, script memory is likely to get added to “The List” of things the Lab is looking at.

Viewer-Managed Marketplace

Some confusion has been evidenced over the use of the term “archived” in recent communications from the Commerce Team regarding what will happen during the auto migration process, and particularly with reference to items that have not seen sales in over a year.

  • The first point to remember is that any “archiving” will only occur for those merchants who have more than 5,000 items on the Marketplace when the auto-migration process reaches them. As noted in my last VMM update, all such affected merchants have already been notified
  • From information made available by those merchants so affected, it would appear that “archived” means “items will be returned to the merchant’s Received Items folder”. Firstly, any items the Merchant has stored on the Marketplace without any associated listing will be returned. If this fails to reduce their total count to below 5,000, then those items which have not seen sales for over a year will be unlisted and the items again returned to the merchant’s Received items folder.  From this it would seem that there will not be any actual “archiving” of listing information or items on the part of the Lab.

 

SL project updates 23/1: server, TPV Developer meeting

Posted on by Inara Pey

Crestwick Island; Inara Pey, June 2015, on Flickr Crestwick Island (Flickr) – blog post

The following notes are primarily taken from the TPV Developer (TPVD) meeting held on Friday, June 5th. A video of the TPVD meeting is included below, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding.

Server Deployments Week 23 – Recap

There was no deployment to the Main (SLS) channel on Tuesday, June 2nd, due to the week #22 RC deployment being rolled-back.

On Wednesday, June 3rd, all thee RCs received the same server maintenance package, which was the same update which had been attempted in week #22, but with additional back-end fixes to prevent a repeat of the earlier problems. The update comprises:

  • A change logic on accessing group member lists for large groups
  • Internal server logging changes.

SL Viewer

On Thursday, May 3rd, the attachment fixes RC viewer (Project Big Bird) updated to version 3.7.30.302190.  Presumably, this update is to bring the viewer up to parity with the current release viewer (formerly the avatar layers update), and so will hopefully clear the way for it to be promoted to the de facto release viewer in the near future.

[02:40] A new maintenance fixes RC viewer should be appearing in the release channel soon, the should also be an update to the Mesh Importer project viewer (currently version 3.7.28.300878) appearing soon; and work is progressing on updating the Oculus Rift project viewer.

Experience Keys (/ Tools)

[03:35] Work is continuing on the back-end of the Experience Keys systems prior to the capabilities being formally released across the grid as a whole.

“We are making progress on the back-end issues that have been delaying that,” Oz Linden informed the TPV Developer meeting. “But as far as I’m aware, we have not yet  … uncovered a viewer-related problem with that. so far these are all back-end related issues.” He went on:

To be a little bit more transparent, it’s really scaling issues. Experience actually work just fine at the scale we’re using them right now … but what we’re concerned about is what will happen when we turn them loose on a much, much larger population and there are lots more experiences running and there are a lot more simulators with experiences running on them. 

So what we’ve doing … is fairly intensive scaling and performance testing and we’re solving the problems that the testing uncovers. So, we’re making progress on it, and we’re fairly confident the problems are solvable, but we have run into a whole host of assorted issues with that.

In the meantime, it is expected that the current RC release of the Experiences viewer (currently version 3.8.0.300963) will be brought up to parity with the release viewer during week #24.

Viewer-Managed Marketplace

[05:53] For ease of reference, please refer to my update on VMM, available here.

Land Bans

[17:58] Oz Linden has issues an invitation to open-source contributors to assist the Lab in trying to improve the management of land ban lists. Again, for ease of reference, please refer to my separate report on this, available here.

Group Membership Changes

[22:15]  The update to the server RC channels referred to as “a change logic on accessing group member lists for large groups”, as noted in the server deployments recap at the top of this article, refers to a new way in which the members lists for larger groups (5,000 members and over) are handled.

In brief, the members lists for such groups will no longer load in the group floater in the viewer, unless the person attempting to see the list is in a role which requires they need to be able to do so. While this change is discussed within the meeting, I have been specifically asked not to blog on the change until it is deployed to the Main (SLS) simulator channel on Tuesday, June 9th, when I’ll have the details in full.

Unified Snapshot Floater

[33:12] As I’ve recently reviewed, NiranV Dean has updated the unified snapshot floater in his Black Dragon viewer. As he originally contributed the code for this floater to the Lab, he has also raised a JIRA (see BUG-9325) listing improvements and fixes and has contributed his updated code. This has been under review at the Lab, and commenting at the TPV Developer meeting, Oz indicated that the Lab are “fine” with the majority of Niran’s suggestions, although there are a couple that appear to be subject to further consideration, which might take a little while to sort through.

NiranV Dean's unified snapshot floater improvements, including the separate, resizeable preview panel, are now with the Lab, although it is not yet entirely clear which of the updates will be adopted, or when they will appear in the official viewer.
NiranV Dean’s unified snapshot floater improvements, including the separate, resizeable preview panel, are now with the Lab, although it is not yet entirely clear which of the updates will be adopted, or when they will appear in the official viewer.

Continue reading “SL project updates 23/1: server, TPV Developer meeting” →