Second Life project updates 28/1: server, viewer

Umbral Photography, Hydra Isles; Inara Pey, July 2015, on FlickrUmbral Photography, July 2015 (Flickr) – blog post

Server Deployments

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

On Tuesday, July 7th, the Main (SLS) channel received the same server maintenance package deployed to the three RC channels in week #27.

As noted in my project update for week #27, BUG-197 referred to in the package release notes relates to an issue 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).

There will be no RC deployments to the RC channels on Wednesday, July 8th, leaving all of the main grid on the same release. A new RC deployment, described as a “minor update” is in preparation for deployment to the RC channels in week #29.

SL Viewer

On Tuesday, July 7th, The Maintenance RC viewer was updated to version 3.8.1.303166, bringing it into line with the attachments RC viewer updated in week #27, and just leaving the Viewer Managed Marketplace viewer to be updated in the release channel, which will likely happen later this week.

Chromium Embedded Framework

At the Monday Open source Developer’ meeting, Oz Linden indicated that an anticipated project viewer,  the Chromium Embedded Framework (CEF) viewer which will provide media support via HMTL 5, should be appearing “Pretty Soon”™.  While Quicktime and Flash  may work on this viewer for some users, given the age / status of both, the Lab does not plan to support either going forward, and recommends media creators migrate to HTML 5.

It had been hoped that this viewer would have been out by now; however there appear to be one or two issues still to be resolved. “I heard the developer working on it today say he was deep in the middle of keyboard issues,” Simon Linden said during the Simulator User Group meeting on Tuesday, July 7th. “Getting frameworks like that to cooperate with OS events like keyboard, mouse and screen is always tough.”

Experience Keys / Tools

Simon is continuing to work on tweaks to the Experience Keys / Tools code, and in doing so passed an interesting comment at the Simulator User Group meeting.

“I’ve been working on updating the KVP code that runs on our server,” he said, “and had the most frustrating time integrating the newest version into our code … The code we have is dated and we should have better performance and stability with their latest.”

Quite what the difference is between “our” and “their” code might be isn’t entirely clear at this point in time – although the question was asked during the meeting, and may well be asked again in the future.

Simon also hopes to put some work into getting KVP access moved onto a separate thread to ordinary asset handling. As previously mentioned in these updates, that KVP access is currently on the same thread as asset handling can, at times, cause issues, as noted in BUG-8946.

Group Chat

The recent improvements made to group chat continue to make themselves felt, with many reporting that the old issues of lag with the chat on large groups has largely dissipated. Such are the improvements that Whirly Fizzle has suggested that http://isslgroupchatstillbroken.com/ should be updated. Even so, despite all the the improvements, Simon has indicated that there are still “a few things” he’d like to tweak a little more.

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

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

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

Alpha.Tribe
Alpha.Tribeblog 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

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

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.