Tag: Simulator User Group 2014

SL projects update week 29/1: server, viewer, Experience Keys

Posted on by Inara Pey

Server Deployments – Week 29

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

Main (SLS) Channel

On Tuesday July 15th, the Main channel was updated with the Experience Keys project, which had previously been running on Magnum. This roll-out coincides with the release of the Experience Keys project viewer (see below) and the release of the Lab’s first Experience Keys demonstrator game, The Cornfield.  Please refer to the release notes for further information.

Release Candidate Channels

On Wednesday July 16th, the Magnum RC should be updated a new infrastructure project that adds support for the upcoming changes to the Skill Gaming policy. This would appear to be the changes required to support the new Skill Gaming region type. Release notes.

On Thursday July 17th, BlueSteel and LeTigre will both be updated with the Experience Keys project, but will otherwise remain on the same  server maintenance project as week 28, which addresses a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects. See the release notes (BlueSteel) for details, and part 2 of my projects update for week 28.

SL Viewer

As noted above, the Experience Keys project viewer, version 3.7.12.291846, was released on Monday July 14th. This provides viewer-side support for accessing and managing SL experiences using the new Experience Keys permissions capabilities.

The Search tab on the new Experience floater - part of the Experience Keys project viewer
The Search tab on the new Experience floater, accessed from the Experiences option in the Me menu in the Experience Keys project viewer

This viewer can be used in conjunction with the Lab’s Experience Keys demonstrator game, The Cornfield, and with other experiences as they are opened to public use. Please keep in mind that the viewer may not behave correctly until after the server-side deployment of Experience Keys support has completed on Thursday July 17th.

For further details on Experience Keys, please refer to the following:

There are also some further notes from Dolphin Linden on the subject, below.

Yet More on Experience Keys

Dolphin Linden at the Simulator UG meeting
Dolphin Linden at the Simulator UG meeting

Dolphin Linden again attended the Simulator User Group meeting on Tuesday July 15th, where he answered more question on the Experience Keys project.

Lucia Nightfire offered up a couple of points of feedback which appear especially relevant to the new capabilities:

  • An estate / parcel setting to disable all non-experience scripts. This would be useful in game experiences, as it could prevent participants cheating by using non-game scripted objects
  • An estate / parcel setting to block all grid-wide experiences from running on an estate / parcel. Currently, any grid-wide experiences which come on-line have to be explicitly blocked by name, which means if an estate / parcel owner didn’t want any grid-wide experiences running on their land, they’d have to keep adding them to their block list as and when they become aware of them. A single check-box option would eliminate this.

Feature requests are to be filed on both of these points, which the Lab have agreed to look into.

Other Bits

Sim Crossing Hiccups

There have been renewed reports of region crossing issues which seem to be occurring regularly, but only between certain regions when tested. The issues mainly appear to affect vehicles and take the form of the avatar taking an exceptionally long period of time to cross between regions – with the vehicle the avatar is say upon taking up to 30 seconds longer. When this happens, the avatar appears to be visually unlinked from the vehicle, but the vehicle itself fails to get auto-returned, as the simulators appear to consider the avatar and vehicle as still being linked.

Motor Loon provided some specific details on the issue, and has indicated he will raise a bug report using the information he has, as the Lab are unaware of any specific problems which may cause this. However, while it has yet to be confirmed, it was also reported at the meeting at a similar issue on a region crossing between two regions was resolved by restarting them in a specific sequence.

SL projects update 28/3: more server and viewer news

Posted on by Inara Pey

Banana Island - The Pilgrim's Dawn; Inara Pey, March 2014, on FlickrBanana Island, The Pilgrim’s Dawn, March 2014 (Flickr)

Server Deployments Week 28 – Recap

  • On Tuesday July 8th, the Main (SLS) channel was updated with the server maintenance project that was previously on BlueSteel and LeTigre.  This project adds the ability for LSL functions to view and modify the render materials (normal map, specular map, and diffuse texture alpha mode) properties on prims, via new prim parameters – release notes
  • On Wednesday July 9th, the RC channels were updated as follows:
    • BlueSteel and LeTigre received the same new server maintenance update to address a JSON-related bug, an interest list related race condition, and to improve L$ transaction logging for payments made by scripted objects
    • Magnum remained on the Experience Tools project, and receives the same updates as the Main channel, so LSL support for materials is now grid-wide.

 BlueSteel / LeTigre Updates

Commenting on the server maintenance update deployed to BlueSteel and LeTigre at the Server Beta UG meeting on Thursday July 10th, Maestro Linden explained one of the bug fixes (BUG-6466) and the L$ transaction update thus:

The LSL JSON bug fix, BUG-6466, just makes it so that numbers in the format “1.0e+2” get parsed as JSON numbers.  Previously, they’d be treated as strings (though “1.0e2”  would be treated as a number). The spec says that “+” is optional, so we added that support.  I’d be surprised if more than 2 people end up noticing that change 🙂 .

The one non-bug fix change in BS and LT is more verbose logging of certain L$ transaction types … Historically, a L$ transaction from scripted payment (llTransferLindenDollars or llGiveMoney ) would not include the name of the object that did the payment, when you viewed it in the “L$ Transactions” section of the website. However you would see that information if somebody had paid L$ into an object.

Previously, the entry would just look like this: Destination: Maestro Linden; Object Pays; Region: Morris.

But now, with the update to BS and LT, transactions in those regions will additionally include this line: Description: <Name of object which paid>. The page where you see the difference is https://accounts.secondlife.com/transaction_history/. Anyway, it could be useful for understanding which of your objects are paying out L$. Assuming they’re not all named “Object” :).

The remaining fix, “Temp Attachments are sometimes not removed on the viewer when detached from a region change event”, was related to a race condition, and explained by Simon Linden:

Updates were out-of-order there. Basically if your script took things off on the region change, anyone might get the updates out-of-order. It was worst on slow connections. For those who are curious, it went like this:  if the first update from the new region was slow, the “kill” message removing the object would happen first, and get ignored.

So in other words, items which should have been removed appear to remain in place, with Simon adding:

In this case you can’t detach it … because for the sim, it’s already gone. The viewers are the ones out-of-sync with the server. So you right-click and detach again and nothing happens.

The fix on BlueSteel and LeTigre should hopefully prevent this from occurring during a region change to regions on these channels.

SL Viewer

Maintenance RC Viewer

A new Maintenance RC viewer appeared late on Thursday July 10th. Version 3.7.12.291824 contains almost 40 MAINT fixes intended “to make your Second Life smoother”. The list of fixes include:

  • MAINT-3135 Cocoa Viewer: Mac: Maximizing the viewer leaves garbage on the screen
  • MAINT-3154 Alt zoom zooms way out when attempt to zoom in on Mac build running with external monitor
  • MAINT-3171 Alt-clicking while moving mouse can move the camera significantly
  • MAINT-2980 Reevaluate the 512 meg texture cap
  • MAINT-4216 Double clicking on anything in COF removes it from your avatar – including skin, shape, hairbase and eyes – results in bakefailed avatar
  • MAINT-4001 Received Folder is movable within Recent Tab – see my notes here on this issue
  • MAINT-3610 SL viewer partly ‘eats’ chat-message.

 

Please refer to the release notes link above, for the full list of MAINT fixes.

Library Refresh Project Viewer

The Lab issued a new project viewer on Wednesday July 9th, version 3.7.12.291799, which contains a number of updates related to the third-libraries used by viewer. This viewer has grown out of Monty Linden’s ongoing HTTP work, which required the update of several essential libraries used by the viewer, and Monty took the opportunity to undertake a more extensive update of the libraries.

These library updates should provide better security, stability and consistency improvements to the viewer. However, an advisory to Mac users warns that the updated libraries in the viewer have been built with a minimum OS level of 10.6. Therefore, this viewer, and future viewers based upon it, will not run on OS X 10.5.

While the viewer is primarily intended for testing purposes, and doesn’t contain updates which are liable to be noticed by most LS users, it is thought that it might help those encountering very specific SSA-related issues, the release notes stating:

A few users have experienced problems with avatar appearance due to their very specific network configuration. Gray avatars are accompanied by ‘Transferred a partial file’ errors in the SecondLife.log file. Linden has not been able to reproduce this internally but a possible workaround is found in this release.

A list of related JIRA reports is also given, but none of these appear to have been switched back to public access at the time of writing. They are: BUG-3323, BUG-3770, BUG-3877, BUG-3879, BUG-3882 and SH-4375.

Other Items

SL AIS Viewer login / Attachments Issue

Users on the SL viewer using the AIS v3 viewer code are reporting issues with attachments when logging-in to Second Life.

Some of the issues are described as a user logging-in to find their hair or (mesh) foot / hand or other attachment incorrectly positioned, and the only way to rectify the situation is to re-log. Some have suggested that swapping between a non-AIS v3 viewer and the AIS v3-enabled viewer may trigger the situation.

Some bug reports (BUG-890 and BUG-2772, both unfortunately non-public at the time of writing) have been pointed-to as examples of the problem, and further reports have been requested should it be encountered, with Coyot Linden noting for those wishing to file a JIRA on the matter:

One way to get a grapple on that sort of thing is to start a test run and keep track of the login times and regions.  When you hit a fail, logout and do one more and see if it succeeds.  If you provide that and the viewer logs, it would be easier for someone to do some log diving to figure out what the problem is.

Coyot Linden Takes the Driving Seat

Maestro Linden is  taking a three-week vacation from the Lab and Second Life. In his absence, Coyot Linden will be occupying the driving seat for the Thursday Server Beta meeting.

SL projects update 28/2: more on Experience Keys (Tools)

Posted on by Inara Pey

On Tuesday July 8th, Dolphin Linden, a member of the team responsible for the Experience Keys (Tools) project,  attended the Simulator User Group meeting, where he took time to provide further information on the project via what amounted to a Q&A session.

Dolphin Linden at the Simulator UG meeting
Dolphin Linden at the Simulator UG meeting

The following notes have been taken from Dolphin’s comments, and should be read alongside my original overview for Experience Keys, and the Lab’s invitation for experience creators to participate in the Experience Keys beta programme.

Note that because some aspects of Dolphins comments on Experience Keys have been covered in my original article (e.g. the concept of trusted Experiences running on regions with access control enabled, permissions covered by Experience Keys, etc.), they can not reproduced here.

  • Documentation for the projects will be finalised “shortly” – it is currently undergoing final review and update
  • Precisely how Experience Keys will be made available to people is still to be decided; as Dolphin reiterated at the meeting: “We are working out the details, but we want them to be reasonably available, but not so easy acquire that people will make throw away ones to try to grief people; we are still working on the rules about who can have them.”
  • Those applying to be part of the Experience Keys beta do not necessarily need to convert an existing experience they may have, but
    • They should be able to demonstrate that they have the experience with building/scripting to make use of the tools, and
    • They should provide as much information on possible about the kind of experience they’d like to present through the beta
  • Experiences and region maturity ratings:
    • Experiences must respect the maturity of the region(s) on which they run – so an adult rated experience cannot run on a general region, for example
    • Experience ratings are set by the experience owner, and this rating is used to determine the region maturity rating required in order for the experience to run
    • A sample Experience profile
      A sample Experience profile

      The rating is part of the Experience’s public profile, all of which must be G rated

    • The list of experiences running on a region is public information
  • Experiences and scripts:
    • A script can only be associated with a single experience
    • However, a single object can include multiple scripts belonging to different experiences, if required – although this might prove difficult to manage, depending on what the scripts are doing / how the object is used
    • Assigning an Experience to a script must be done by the Experience owner or by a member of the Experience’s group with the appropriate group power (“Contributor”)
    • Existing scripts can be converted to work within an experience, the permissions request to an Experience permissions request and then the event handler would need to be modified to handle tw new events – EXPERIENCE_PERMISSIONS and EXPERIENCE_PERMISSIONS_DENIED
    • An Experience is set on a script through a combo box in the script editor. This lists all Experiences the script creator either owns or has Contributor rights to
    • The selected Experience is set at compile time (similar to the compile type), and is part of the compiled script. The script must be re-saved if it the association is changed to another Experience
    • If a modifiable script associated with an Experience is passed to someone who does not have Contributor permissions for the Experience, they will not be able to save the script unless they remove the Experience or change it to one for which they do have permission
  • The Experience database:
    • Every Experience has its own database, which can be accessed wherever the Experience is running
    • The database is fairly simple, but should make storing the current state-of play for avatars engaged in an Experience (e.g. what they have been doing, what they have attached, etc.)
    • It is basically string-to-string mapping
    • The database supports create, read, update, delete, count, and iterate, and the update can be made atomic, so it can be safely updated from multiple scripts
    • The overall size of the database will be limited, although the Lab is still determining an appropriate limit
    • The database size is also configurable (per Experience), so the Lab will likely offer Experience creators the opportunity to increase their database size for a L$ fee, if needed, although this policy has yet to be finalised
  • As indicated in my original notes, an Experience can be refused or blocked by a user, and can be revoked by the Lab. Additionally, an Experience can be suspended by the Experience owner (so as to allow a bug to be fixed, for example). All of these will result in an EXPERIENCE_PERMISSIONS_DENIED event being sent to all scripts associated with the experience
  • Also as indicated in my original notes, private estates / regions with access restrictions will have an additional level of access which will allow anyone participating in a grid-wide experience running on that estate / region to access it. However, should they revoke the experience permissions while on such an estate / region, they will be teleported away in accordance with the estate’s / region’s access controls
  • All temporary attachments made to an avatar will die should the person go to a place where the Experience is blocked or if they block the Experience.

Again, please do be sure to read the above notes alongisde my original overview of Experience Keys.

Dolphin Linden will be available at the next Simulator User Group meeting on Tuesday 15th July to answer further questions.

SL projects update week 28/1: server and viewer updates

Posted on by Inara Pey

Server Deployments

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

Main (SLS) Channel

On Tuesday July 8th, the Main channel was updated with the server maintenance project that was previously on BlueSteel and LeTigre.  This project adds the ability for LSL functions to view and modify the render materials (normal map, specular map, and diffuse texture alpha mode) properties on prims, via new prim parameters – release notes.

Release Candidate (RC) Channels

On Wednesday July 9th, the three release candidate channels should be updated as follows:

  • BlueSteel and LeTigre should receive the same new server maintenance update. This project addresses some miscellaneous bugs, and improves L$ transaction logging for payments made by scripted objects.
  • Magnum remains on the Experience Tools project, and receives the same updates as the Main channel, so LSL support for materials will be grid-wide following the deployment.

SL Viewer

On Tuesday July 8th, the Snowstorm RC viewer, version 3.7.11.291465 was promoted to the de facto release viewer. The viewer includes multiple contributed updates from the SL open source community, including (but not limited to):

  • STORM-68 Allow setting of default permissions on creation of objects, clothing, scripts, notecards, etc.
  • STORM-1831 Obtain LSL syntax table from simulator so that it is always up to date
  • STORM-1972 Restore particle debug display
  • STORM-2011 Improve loading of Group member list
  • STORM-2015 Region restart sound alerts play only locally.
  • STORM-2020 Restore RenderSpecularExponent.
With the new release viewer, users can now set their own default permissions for newly-crated prims, textures, etc.
With the new release viewer, users can now set their own default permissions for newly created prims, textures, etc.

Windows XP users please note: with this release, you must have either Service Pack 3 (Windows XP 32-bit) or Service Pack 2 (Windows XP 64-bit) installed on your system in order to install this and future versions of the SL viewer – see the release notes. Please also note that no Windows XP operating systems are supported by Linden Lab.

Other SL viewers remain as per the Alternate Viewers wiki page and my Current Viewer Releases page.

 Experience Keys (Tools)

There was a Q&A session at the simulator User Group meeting on Tuesday July 8th with Dolphin Linden, to discuss the Experience Keys (Tools) project. For ease of reference, I’ve included notes from that session in a separate report.

 

SL projects update week 27/2: server updates, Experience Keys

Posted on by Inara Pey

Server Deployments Recap

There were no deployments to the Main channel or to the BlueSteel and LeTigre RCs. Magnum received an update to the Experience Tools project, intended to provide a fix for BUG-6438 “Objects attached via llAttachToAvatarTemp to object owner detach when script is removed from prim inventory” and UI updates. – release notes.

Week 28 Updates – LSL Support for Materials

Subject to last-minute hiccups, it is likely that the LSL support for materials (normal and specular maps, and diffuse texture alpha mode) currently on BlueSteel and LeTigre will be promoted to the Main channel and to the Magnum RC in week 28 (week commencing Monday July 7th).

LSL support for materials looks as if it will go grid-wide in week 28 (week commencing Monday July 7th)
LSL support for materials looks as if it will go grid-wide in week 28 (week commencing Monday July 7th)

There is still no additional throttling in place for the LSL materials functions, as testing revealed they may not be any need for them. adding to this, Maestro Linden said at the Server Beta meeting on Thursday July 3rd, “It’s throttled via the normal script time throttles, there’s no special X/minute throttle. Well, also there’s a throttle for accessing the materials list by viewers. So even when your viewer knows that an object got material X via the update, it may have to access the RenderMaterials capability to look up the render parameters, and that capability access is throttled (the viewer knows to request at a rate below the throttle so that it doesn’t hit failures).”

 Experience Keys

There is liable to be a discussion of the Experience Keys project at the next Simulator User Group meeting, to be held on Tuesday July 8th, with members of that project team in attendance. The meeting will take place in Denby, on the main grid, commencing at 12:00 noon SLT.

Webkit News

As I’ve previously reported on a number of occasions, Webkit is a third-party library used within the viewer for a number of tasks. For example,  it powers the built-in web browser, and is used to display profiles (unless you’re using a viewer supporting legacy profiles). It is also used with like Media on a Prim (MOAP) and many in-world televisions.  There have been an increasing number of issues with Webkit which have caused some pain (see BUG-4763 and FIRE-12642, and FIRE-11057), and Monty Linden has been poking at as a part of he ongoing work with the third-party libraries used in the viewer build process.

A major problem here is that Webkit itself has deprecated, leaving the Lab needing a replacement. Speaking at the Future of SL meeting, hosted by the Firestorm team on Wednesday July 2nd, Oz Linden indicated that a decision has been made to replace Webkit with the Chromium Embedded Framework (CEF). There is no indication of how long this work will take, as it is a very non-trivial effort which is leveraging work already carried out on the Lab’s next generation platform and other internal services.

GPU Updates

Also during the Future of SL meeting, Oz indicated that there are two upcoming changes which will affect GPUs and GPU memory usage.  Both are currently with LL’s QA team.

The first eliminates using the GPU card name as a means of recognising the card’s capabilities. Once released, the viewer will be able to recognise GPUs a lot more dynamically. One benefit of this is that people with state-of-the-art GPUs should no longer experience the viewer failing to recognise their card and defaulting to basic graphics

The second is a fix for how the viewer uses a GPU’s memory. “Many of you will have noticed that we don’t use all of the video memory on your video cards,” Oz said of the fix at the meeting. “It turns out that’s because of a very old bug that plagued us a long time ago and we sort-of arbitrarily, in order to avoid tickling the bug, we capped how much memory we would ever use.”

With the fix, the viewer will be able to measure the amount of GPU memory and then allocate itself what is liable to be a reasonable share of that memory.

SL projects update 27/1: server updates, HTTP, group chat hardware updates

Posted on by Inara Pey

Server Deployments – Week 27

As always, please refer to the server deployment thread in the technology forum for any latest news, updates, issues on this week’s deployments.

As many noted on Tuesday July 1st, there was no Main (SLS) deployment, although there was a period of grid-wide maintenance.

There will be no deployments on the BlueSteel and LeTigre RC channels on Wednesday July 2nd. As such, these channels remain with the following simulator releases:

  • Main channel: inventory updates (AIS v3) – 14#14.06.13.29103 (release notes)
  • Bluesteel and LeTigre: LSL support for materials (normal and specular maps, and diffuse texture alpha mode) – 14/#14.06.20.291351 (release notes  – Bluesteel; LeTigre is the same).

On Wednesday July 2nd, the Magnum RC should receive updates to the Experience Tools project, intended to provide, “user facing fixes to address both UI and long-standing HUD updates included in this build.” – release notes.

SL Viewer

There will probably not be any viewer promotion from RC to de facto release this week. The sole RC in the snowstorm RC, version 3.7.11.291465 has yet to generate meaningful stats. Current SL viewers are as listed on the Alternate Viewers wiki page and on my Current Viewer Releases page.

HTTP Pipelining Viewer

Monty Linden has been continuing to work on the HTTP side of things, directing his efforts towards HTTP pipelining, which should yield further benefits in rendering texture and mesh, and in generally efficiency of HTTP connectivity between the viewer and the SL servers. As a part of this, and while it is not formally publicly available as yet, he has produced a viewer using HTTP pipelining.

This has been undergoing testing among a group of SL users, and is showing considerable promise in terms of texture rendering improvements, and a similar level of improvement is anticipated with Mesh.

Whirly Fizzle has produced a video comparing texture rendering between the HTTP pipelining viewer and the current release viewer, with the tests carried out under identical conditions.

Experience Tools

The new Experience Tools project will be officially announced on Wednesday July 2nd, with a blog post, video and the release of a project viewer.

Group Chat

Oz Linden: SL's Technical Director talks about coming updates to Group Chat
Oz Linden: SL’s Technical Director: work is continuing on group chat issues, including hardware upgrades for the service

“We have been looking much more deeply into why the problems which exist than we ever have before,” Technical Director for Second Life, Oz Linden stated at the Firestorm The Future of Second Life meeting on Wednesday July 2nd, in reference to group chat issues. “We’ve added a lot of instrumentation to the way it’s implemented, and we have learnt a lot from that.”

He went on to cover the fact that the Lab has begun to make changes as a result of this data-gathering which are starting to have an impact, although he emphasised that while this work is going to continue in the coming months, there is unlikely to be a single update which will be “the” dramatic change which instantly “solves” group chat lag. Things are liable to be a lot more in the way of incremental improvements (no doubt due in part to the sheer complexity of the chat service).  given this, he also suggested that there may be some fundamental work required in the future which could affect the viewer side of things as well.

He went on to say, “We’re going to be upgrading the hardware that the group chat servers run on, I believe this week or possibly next. We won’t announce when that is, because it would be bad science to tell anybody when it’s happened. We want to watch the stats, we now have very good visibility to what performance and failure rates are. So we have the way to measure what’s going on.”