SL project updates 34/1: server, viewer, MIME Type updates

Cocoon, Japan Rose; Inara Pey, August 2017, on Flickr Cocoonblog post

Server Deployments Week #34

Please refer to the deployment notice for the week for latest updates and news.

  • On Tuesday, August 22nd, the  Main (SLS) channel was updated with server maintenance package, 17#, comprising internal fixes and the following feature requests:
    • BUG-5398: llGetObjectDetails() constants OBJECT_SELECTED & OBJECT_SAT_UPON. This sees the addition of two new parameters:
      • OBJECT_SELECTION_COUNT – returns how many agents are selecting any link in a linkset
      • OBJECT_SITTER_COUNT – returns how many agents are sitting on any links in a linkset.
    • BUG-9666: llGetObjectDetails() constants OBJECT_REZ_TIME, OBJECT_CREATION_TIME and OBJECT_RETURN_TIME.
    • BUG-134057 OBJECT_CREATION_TIME output precision possibly clamped – this sees a shift to 6-digit precision.
  • The three RC channels are, at the time of writing, TBD on the status of any update. However, it is believed (as per Rider Linden at the Simulator User Group meeting), should have additional logging for altitude changes, a couple new constants for llGetObjectDetails and some additional validation for mime types passed into HTTP requests. There is also a change that lets you customize what is passed in the Accept header.

SL Viewer

There have been no viewer updates so far this week, leaving the various pipelines as follows:

  • Current Release version, released on May 26, promoted June 20 – formerly the AssetHTTP RC viewer – overview
  • Release channel cohorts:
  • Project viewers:
  • Obsolete platform viewer version, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

llHttpRequest MIME Types Updates

On Thursday, August 17th August, Oz Linden opened a forum thread of on the latest MIME type update the Lab is implementing. The latest changes involve validating the MIME type values:

  • The HTTP_MIMETYPE parameter to llHTTPRequest is checked. LSL will validate these for proper format; requests that attempt to send an improperly formatted type will send a debug channel error, not send the request, and return a null request key.
  • If you use the new HTTP_ACCEPT option to llHTTPRequest (which allows you to further restrict the type your script expects), the Content-Type of the response is checked to see that it matches your restriction; if it does not, the http_response event will be a 415 error and the body will be “Unsupported or unknown Content-Type”. Further details about HTTP_ACCEPT can be found in llHTTPRequest on the SL wiki.
  • Incoming HTTP requests to a script check to see if the Content-Type in the request is formatted correctly and that it is an allowed type (it always checked for allowed types). Previously, it was possible to send a type that was syntactically invalid but matched an allowed wildcard type. Incoming parameters are not validated. If an incoming request has an improperly formatted or unacceptable MIME type, LSL responds with a 415 error response and no event is generated for the script.

Scripts using any of the above can be tested on the following regions:

Other Items

Script Memory

The Lab periodically receives requests for the Mono script memory limit (64Kb) to be increased.

There are concerns about any increase. Not everyone writing Mono scripts do so efficiently or conservatively; any increase in limits could lead to avatars carrying much larger script loads (even allowing for multiple scripts to achieve functions which might otherwise be managed in a single, large script), impacting teleports and regions during the same. Some suggestions have been offered by users for reducing such potential impact:

  • Limiting additional script memory to creators of experiences – which is not seen as overly positive.
  • Limiting any increased script memory for premium members – which might be an incentive for some to upgrade.
  • Limiting the number of scripts (currently around 2,500) a single avatar can have attached.
  • Forcing limits on memory use at compile time – which presupposes the about of memory a script in operation will require at compile time, which might not always be the case.

As it stands, it is unlikely the Lab will have time to investigate any increase in script limits – but they are aware of the requests.