Category: SL User Group Meetings

SL project updates week 36/2: TPV Dev meeting + SL in the cloud

Posted on by Inara Pey

Brand New Colony; Inara Pey, September 2017, on FlickrBrand New Colony – blog post

Updated to reflect the release of the Wolfpack RC, which appeared after this article had been uploaded for publishing.

The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, September 8th 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 Deployments Week #36 – Recap

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

Region Return Issues

Whether connected to the Wednesday deployment or the grid-wide issues experienced later that day, but some regions reported significant returns of in-world objects (Mother Road, on the Main (SLS) channel, which I blogged about here, suffered the problem, as Heavenly Views (Magnum RC) also apparently did). Most of these problems seem to have been rectified by a roll-back of the affected regions.

SL Viewer

A new RC viewer, codenamed Wolfpack – version 5.0.8.328879 – was released late on September 8th. This viewer is functionally identical to the release viewer, but includes additional back-end logging to “help catch some squirrelly issues”.

[1:15-4:15] Otherwise have been no further viewer updates since the start of the week, leaving the current pipeline as follows:

  • Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
  • RC viewers:
    • Alex Ivy 64-bit RC viewer version 5.1.0.508209, dated September 5th
    • Voice RC viewer updated version 5.0.8.328552, dated September 1st
    • Maintenance RC viewer version 5.0.8.328812, dated August 31st
  • Project viewers:
  • 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.

The Alex Ivy and Voice updates bring these RCs into parity with the current release viewer. These updates have lowered the overall crash rates for both viewers, although the Voice viewer’s crash rate is still somewhat elevated compared to the release viewer. This elevated crash rate is something the Lab has seen in the various viewers for the last few months, and are working to lower.

Alex Ivy will likely have two more RC releases before it is ready for promotion to de facto release status, as there are a couple of issues the Lab wants to clear up before any promotion of this viewer.

It is hoped work will shortly be resuming on the 360-degree snapshot viewer, part of which will also be bringing it up to parity with more recent releases.

New Viewer Splash / Log-in Screen

[4:25-8:07] The Lab is in the process of revamping the official viewer’s splash / log-in screen. This should be inherited automatically by those TPVs using the Lab’s splash screen. This will see the screen have a different look and feel, with the information arranged a little differently, with the grid status made somewhat more prominent. Some of the information widgets associated with the splash screen are also being updated as a part of this work, and will require testing by TPVs when available (RSS feeds should not be affected).

This work is being carried out by Phronimos Linden, one of the more recent (3 months ago at the time of writing) Lab staff recruited to work on Second Life.

Moving to the Cloud

[15:52-25:25] As confirmed in a recent Lab blog post, Second Life services are moving to the cloud. There are no specific details on this as yet, but in short:

  • The work will be carried out in stages.
  • It will include providing regions from the cloud (rather than the Lab’s own co-located servers).
  • As many know, the asset services has been in S3 cloud servers for several years.
  • The order of moving services hasn’t been determined as yet, but the aim will be to move services, then test for reliability and performance before opening them up / moving to the next service(s).
  • Some testing has already begun, using services only accessed indirectly by users.
  • The Lab has been working on the infrastructure for this for a while, but none of the major services have been moved.

It is unlikely this will lead to regions of a different size to those presently on the grid, or which can be varied in size (a-la the OpenSim varregions), as region size is very deeply baked into the simulator and viewer code (and probably elsewhere in the overall SL code base); although some at the Lab would love to be able to have such a region capability. However – as indicated in the Lab’s blog post – it may allow the Lab to introduce new region products, possibly ones capable of handling greater loads.

It is hoped that this work will result in lower tier over time, but whether this will be the case of not is still and open question at this time, as it is unclear as to what costs will be involved in terms of cloud instance types., etc., that will be required to support simulators.

Overall, there is a lot the Lab hopes to achieve with the move, but the precise benefits are likely to only become clear once things have been tried and found to work / over time as the work progresses and beyond. However, at this point time scales are TBD, and it is liable to be some time before user-visible aspects of the service move to the cloud (although non-visible services – such as the log-in service, for example – could be moved sooner).

A precursor to this project is the continuing work to update the servers to newer version of Linux, work which is making “good progress”.

Other Items

Asset HTTP Messaging and Asset HTTP Issues

[10:11-10:45 and 12:10-15:23] With the promotion of the Asset HTTP viewer to release status in June 2017, the majority of assets are now delivered to the viewer using HTTP via the Content Delivery Network(s) used by the Lab. This means that UDP messaging for all of the affected asset types will be turned off at the server end at some point.  Currently no date has been set for this, and it looks like it may not occur much before February 2018.

There is still an issue related to fetching assets over HTTP in general which is experienced by some users some of the time   whereby something causes the pipeline textures to get out of sync and things to go awry. As the problem happens for some and not others, the Lab is still trying to determine the root cause for the problem, but it is a matter the Lab is trying to resolve.

Catznip viewer reports issues with textures over HTTP “stalling” for between 5-10 minutes on their pre-release viewer with the latest HTTP updates, but this isn’t something the Lab is aware of as a more general issue.

Estate Tool Ban List Improvements

[10:48-11:43] The Lab did some initial work to improve ban lists at the estate / region level a while ago, but the intended work to improvement to overall layout for the lists, etc., has been delayed do to work on dealing with viewer crashes, etc. This work is apparently now “next in line” once some of the existing viewer projects are shipped.

The conversation from 26 minutes to the end is more general chat on viewer stats, speculation on the reason for the texture load stalls, and an ad for the Firestorm birthday party.

SL project updates week 36/1: server, viewer

Posted on by Inara Pey

Savor Serenity; Inara Pey, August 2017, on FlickrSavor Serenity – blog post

Server Deployments Week 36

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

SL Viewer

  • On Tuesday, September 5th, the Alex Ivy 64-bit RC viewer updated to version 5.1.0.508209.
  • On Friday, September 1st, the Voice RC viewer updated to version 5.0.8.328552.
  • On Thursday, August 31st, a new version of the Maintenance RC viewer was released, version 5.0.8.328812, replacing the earlier version, pulled shortly after release due to BUG-134213, [Maint: Moonshine] breaks clickable functionality for certain HUDs.

The rest of the viewer release pipelines remain unchanged from the end of week #35:

  • Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
  • Project viewers:
  • 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.

Feature Request

The Lab  welcomes well thought-out and present feature request via the Second Life JIRA. Not every feature request is accepted – which is not the same as saying they aren’t looked at / considered. Commenting on how and when requests are taken up, coming out os a conversation about script functions, Simon Linden had this to say:

We have a long list of “it would be nice to do” script features. We don’t make final decisions on anything until we get to the point where we’d actually work on them. There’s always a tough choice which one is the best thing to spend limited time on.

When we look at features, we have to juggle how hard it might be to implement, if it’s going to affect a narrow or broad set of customers, if it’s really a new thing or something you might already be able to do (most often with scripting features), potential for lag, griefing or privacy problems, how much would break, etc.

 

 

SL project updates week 35/2: Content Creation UG

Posted on by Inara Pey
Content Creation User Group Meeting, Hippotropolis Camp Fire Circle

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, August 31st, 2017 at 13:00 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.

Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article. These notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so the provided time stamps may appear to be out of sequence in places. All time stamps are provided as links which will open the video in a separate browser tab, allowing the discussion to be heard in full.

Animated Mesh (Animesh)

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation.

  • Animated objects can be any rigged / skinned mesh which is correctly flagged as an animated object (so it has a skeleton associated with it), and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • The capability will most likely include a new flag added to an existing rigged object type in order for the object to be given its own skeleton.
  • At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life.
  • Animated objects will not (initially):
    • Have an avatar shape associated with them
    • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
    • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
    • Use the avatar baking service
  • The project may be extended in the future.
  • It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents).

LSL Animation Functions

[1:18-3:04] The LSL functions needed for animating mesh objects are being tested. These comprise:

The first two commands are fairly straightforward in terms of use. The GetObjectAnimationNames function is intended to stop all animations currently playing in an animated object, or to check whether a particular animation whether an animated object is currently playing (the animations and scripts being stored in the object’s Contents tab inventory).

The documentation for these commands is still in progress, so the information on the wiki pages is subject to update. Also, keep in mind these commands will not work until a public animesh project viewer is available.

[10:12-11:16] These commands could, in theory, be used with a scripted HUD to provide some degree of control over animated objects by their owner. An example HUD may or may not be provided in the test content the Lab may supply (see below).

Test Content

[3:23-4:43] Test content for animesh has been a request at past meetings, the idea being to have models available in the Library people can use to familiarise themselves with created animated mesh objects and using the associated scripting controls. The Moles are now looking at adding some content for the Library in preparation for animesh becoming more widely available.

[41:26-45:12] A more general discussion on promoting animesh (when available), test content, and making people aware of animesh.

General Performance

Alexa Linden has been converting existing mesh content  into animesh objects. She’s been using the mesh werewolf starter avatar originally released in 2014, and which is already available in the Library, for this work, and produced a short video of the result, presented as an animated GIF, below.

Alexa’s test use of the Lab’s mesh werewolf avatar as an animated mesh object

Again, note that these are not actual avatars connected to the simulator via individual viewers; they are purely in-world objects being animated by scripts they contain driving a set of animations also contained within them.

[8:00-9:04] More work is also required on the general controls / limits on animated mesh objects: how many are going to be allowed in a scene, the numbered of animated attachments an avatar can wear, calculating their rendering impact, etc. These will not be final when a public viewer appears, but will be used as a baseline which can then be tweaked one way or another once more intensive testing gets started.

[22:05-24:29] In her initial tests with dancing werewolves, Alexa managed to get over 300 dancing together, each using 6 dance animations and a control script. She didn’t notice much in the way of a frame rate impact whilst also moving her avatar around. However, she did notice some update issues with the Interest List (which controls how things are rendered in the viewer as you move your avatar / camera) when zooming in / out of the scene.

The test was by no means definitive. For example, it was using multiple copies of the same basic mesh model and animations, and this may have boosted performance somewhat than might have been the case with 300 different mesh models running in a scene, each with its own unique animations. She also carried out her tests on a region that doesn’t have a lot of other content on it.

[25:24-26:36] Comparing Alexa’s tests with avatar capacity / performance (e.g. 40 avatar in a region) isn’t easy as avatars can be a lot more individually complex. There are also various aspects of managing avatars which don’t necessarily apply to animated objects. For example, animesh items should really only have a limited number of updates associated with them, whereas avatars tend to have a lot more going on (interactions, messaging, etc.,), all of which increases the volume of traffic the simulator and viewers must handle.

Project Viewer

[6:47-7:58] Still no date for when a project viewer will appear, other than the Lab will release it “as soon as we can”.

Right now the biggest piece of work within the viewer is defining  how the skeleton get positioned relative to the object with which it is associated. This currently various depending on the model being used, and currently can result in things “jumping” as they start to animate.

This problem also has an impact when trying to use an animated object as an attachment (e.g. when holding and animated pet), with the result the object can be “floating” around the avatar, rather than obviously attached to it, and does not rotate / move appropriately as the attachment point moves relative to the avatar.

[11:55-12:30] Vir doesn’t believe this is a huge problem to solve, it just requires work on the transform matrix, and this shouldn’t add a significant delay in any project viewer appearing.

[21:05-21:45] However, should fixing it prove to be more complicated than anticipated, it may have to be taken into account in terms of lead times, particularly as having the ability to wear / carry animated pets is seen as one of the more popular user-cases for animesh.

Finally, internal testing of the viewer by the Lab has resulted in some suggestions being made which may also be incorporated into the viewer prior to a public project version appearing, in order to ensure that what does appear offers a solid foundation on which to build, and gives creators an opportunity to give feedback.

Tracking Complexities

[15:03-15:56] As animated objects will be manipulating avatar skeleton bones whether they are attached to an avatar or operating as in-world objects, it will require more tracking of such movements than is currently the case to ensure they are correctly represented by viewers able to see them.

Size Limitations

[16:00-18:12] Animated objects will likely be limited in terms of both their physical size and their poly / tri count. Limits for both have yet to be determined; however, high poly count objects will likely in part be limited by the impact they have on performance. The physical size of animated objects, unless  special limits are set, will likely be defined by the same rules as currently exist for avatar skeleton.

[24:31-25:22] The Interest List / animation issues Alexa encountered (e.g objects some distance from the camera position moving much faster than the should be, and then slowing down to a “normal” speed when zoomed at) are not unique to animated objects. These are issues which the Lab is liable to look at in more detail, but are not seen as something which will necessarily delay progress on animesh, simply because the issue has been around for some time (it can be seen when zoomed out from a group of dancing avatars, for example).

Continue reading “SL project updates week 35/2: Content Creation UG” →

SL project updates week 35/1: server, viewer

Posted on by Inara Pey

Les Reves Perdus; Inara Pey, August 2017, on Flickr Les Reves Perdus – blog post

Updated, September 2nd: to reflect the Maintenance RC viewer 5.0.8.328612 being replaced by version 5.0.8.328812 on Thursday, August 31st.

Server Deployments Week 35

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

  • On Tuesday, August 29th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels in week#34, #17.08.11.328152, comprising the MIME type changes for HTTP.
  • On Wednesday, August 30th, the RC channels were updated with a new server maintenance package 17#17.08.22.507928 comprising some tool changes made to the simulator software build systems, which should not change functionality anywhere.

Dual Region Restarts

For around the last month, it appears that some regions have been undergoing unintended double restarts: the first sees the region comes back on-line on the same simulator version as before the restart, but on a new host. The second restart – occurring roughly an hour later – sees the region restart on the new simulator version, but still on the same host as the first restart.

This is not normal behaviour, and JIRAs are request – with logs – from anyone witnessing their region doing this following a weekly deployment,.

SL Viewer

On Thursday, August 31st, 2017, the Lab released a new Maintenance RC viewer, version 5.0.8.328812, comprising a wide range of bug fixes.

This RC has been pulled due to BUG-134213, [Maint: Moonshine] breaks clickable functionality for certain HUDs.

The rest of the viewer release pipelines remain unchanged from the end of week #34:

  • Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • 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.

Animation Syncing

Much of the Simulator User Group meeting of Tuesday, August 29th, focused on animation syncing. Animations are largely handled by the viewer, and there are minimal user control over how animations sync (e.g. couples animations when dancing, except when loaded. There have long be calls for more granular levels of user control over animations – such as a scripted means of pre-caching (such as can be done with sounds) to help with smoother playback, and better syncing control.

Firestorm offers a degree of individual user control of animations through the resync animation command / button. However, there’s no easy way to synch animations between viewers to ensure everyone is seeing the same thing – which can be an issue when dealing with the likes of games and things, and could complicate matters with animated objects / animesh.An interim suggestion might be for the Lab to adopt the Firestorm resyc function, were it to be contributed.

SL project updates week 34/2: TPV Developer Meeting

Posted on by Inara Pey

Yamagata; Inara Pey, August 2017, on Flickr Yamagata – blog post

The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, August  25th 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 Deployments Week #34 – Recap

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#17.08.11.328159, 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.
  • On Wednesday, August 23rd, the three RC channels all received a new server maintenance package, 17#17.08.11.328152 comprising the MIME type changes for HTTP.

SL Viewer

[2:35] The Maintenance RC viewer, version  5.0.7.328060 and dated August 9th was promotion as the de facto release viewer on Wednesday, August 23rd.  A new Maintenance viewer is expected to appear around the middle of week #35 (commencing Monday, August 28th).

[1:23] The Alex Ivy 64-bit viewer failed a QA test as a result of issues being introducing in refectoring how the SL Luncher code (used to determine whether the 32-bit or 64-bit version of the viewer should be installed on Windows systems). The issues aren’t serious, so it is hoped this viewer will appear some time in week #35.

[10:50] A further delay in promoting this version of the viewer, which currently remains at version 5.1.0.507412, is that accurate crash reporting data isn’t being gathers, due to issues with the back-end crash analyser, which are in the process of being addressed.  This problem isn’t uinque to the 64-bit build, but does seem to impact it the most.

[2:13] The Voice viewer, currently version 5.0.7.327253, dated June 21st, has been updated for parity with the release viewer, but has yet to pass QA testing at the time of writing.

This leaves the overall pipeline as follows:

  • Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • 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.

[2:50] It is likely the the Lab will, at some point in the future, move to block some of the older and more outdated versions of the official viewer from accessing Second Life.

Texture Memory Increase and Cache Improvements

[13:58] The 64-bit viewer build will see an increase in the texture memory size, although this isn’t part of the current Alex Ivy build. This work includes:

  • [14:23] Changes to texture caching, including some re-organising and optimisation, and improvements to  statistics gathering to assist in understanding how well it is performing.
  • [15:25] Changes to format of the stored texture data, using the post-decoding raw data, rather than the JPEG2000 data, which should “significantly” improve the amount of textures which can be loaded per second by the viewer, when visited a location previously cached.
  • [16:18] An expansion of the cache version guards so that if a TPV changes versions of their texture decoding software (e.g. KDU) or change from 32- to 64-bit, the cache will get wiped, and force the start of a new one (this is something Firestorm already does).
  • An increase in cache size.

Further changes will follow from these, including possibly changing how the static VFS cache is handled, but this work has yet to be fully characterised.

BUG-10515: Unable to Rez Due To Invalid Mesh Data

[24:42] The have been increased report of mesh rezzing failures with the message “Unable to rez object because its mesh date is invalid.” It has been noted across different objects, but multiple reports have been made for it occurring with the Maitreya Lara 4.1 body.

The problems seem to occur randomly on different simulators, and the Lab has had problems getting the issue to reproduce, as often a simulator restart may clear it, so Grumpity Linden is seeking reports of the problem which can be made as they occur (object, region name, date / time, etc.), so that an attempt to reproduce the error can be be made and log files immediately gathered before any restart takes place (and/or log files are lost).

Other Items

[3:32] Infrastructure work:  the events of Tuesday, August 22nd (see April Linden’s blog post) became an accidental way of testing some of the new infrastructure changes (in this case, the log-in servers) the Lab is implementing, and will continue to implement over the next several months. This encompasses Second Life and the Lab’s various web properties related to it. This includes further operating system updates as well as various component updates.

[24:09] Part of this work involves inventory, although whether it will lead to user-visible improvements to inventory handling is unclear at this point.

[4:19] Place Pages: this have received a number of fixes recently, for those who wish to use them (see here for general information on Place Pages if you are unfamiliar with them).

[5:32] Estate Tool ban list improvements: The lab did some initial work to improve ban lists at the estate / region level a while ago, but the intended work to improvement to overall layout for the lists, etc., has been delayed do to work on dealing with viewer crashes, etc. However, work will be resuming before the end of the year, and possibly sooner. However, this work is unlikely to see an increase in the number held by the ban list, but will focus on usability improvements.

[28:44]  McAfee Total Protection Issue: This is a problem being experienced by some users on TPVs (e.g. Alchemy and Firestorm) where the viewer is being flagged by McAfee Total Protection. This might be down to a code signing issue, however, to assist in further investigations, the problem needs to be reproduced and reported using the LL viewer.

[33:35] BUG-6925, HUDs and Attachments randomly detaching on region crossings / teleports: This has been investigated and determined to most likely be the result of a race condition, but a fixed has yet to be implemented.

[39:56-end] General discussion on documentation (e.g Axon animation; Objectllsd) and avatar physics calculations.

 

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

Posted on by Inara Pey

Cocoon, Japan Rose; Inara Pey, August 2017, on Flickr Cocoon – blog 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#17.08.11.328159, 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 5.0.6.326593, released on May 26, promoted June 20 – formerly the AssetHTTP RC viewer – overview
  • Release channel cohorts:
  • Project viewers:
  • 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.

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.