The following notes were taken from the Tuesday, September 14th, 2021 Simulator User Group (SUG) meeting. The meeting was recorded by Pantera Północy, and the video is embedded at the end of this summary. Note this summary focuses on the key points of the meeting; where there is something to report, the video should be referred to should full details of the meeting wish to be reviewed.
At the time of writing, the server deployment thread had not been published.
- Tuesday, September 14th: no deployment to the Main SLS channel.
- Wednesday, September 15th all simhosts should be updated to the same revisions to the new server configuration that was deployed to the Ferrari RC in week #36.
Monty Linden deployed the new HTTP-out proxies in week #36. It wasn’t entirely glitch-free (but not as bad as the August attempt), with issues occurring in a part of the configuration that didn’t allow for immediate correction. Monty hopes that the lessons learnt with make future deployments smoother.
No updates to the current batch of official viewers to mark the start of the week, leaving the current pipelines as follows:
- Release viewer: version version 184.108.40.2061752, formerly the CEF Update RC viewer, issued July 24 and promoted August 10.
- Release channel cohorts:
- Project viewers:
- 360 Snapshot project viewer, version 220.127.116.113579, issued September 3.
- Performance Floater project viewer, version 18.104.22.1682625, issued September 2.
- Mesh Optimizer project viewer, version 22.214.171.1242614, issued September 1.
- Legacy Profiles viewer, version 126.96.36.1990519, dated October 26.
- Copy / Paste viewer, version 188.8.131.523365, dated December 9, 2019.
- The question was asked on why, when set using llCollisionSound, the sound heard on colliding with an object will revert to the default if the script making the change is removed, rather than being retained as a prim property (like other sounds “scripted into” an object). This is because currently, the sound remains a property of the script, but there are plans to make it consistent with other prim properties.
- LL are working on “stuff” (Mazidox Linden’s term) to help with more efficient script running within regions. The precise details remained unspecified, although some aspects of the work are already on at least some of the RCs channels, and the hope is to get more grid-wide by the end of the year.
- The Percentage Script Run metric within the viewer stats (CTRL-SHIFT-1) is not seen by the Lab as a particularly useful metric when compared to something like total scripts run, as the Percentage Run metric can depend on circumstance, rather than being indicative of actual simulator performance.
- Example: a region running 1000 out of 1000 scripts in a frame will report 100%, whilst a region running 1000 out of 10,000 will report 10% – but both are processing the same number of scripts, and so performing equally in this regard.
- Monty Linden also pointed out that the Percentage Run metric can easily be warped simply by the behaviour of a single script, and noted he has some new internal metrics he is testing that he hopes might provide a better perspective of script performance within a region.
- The above points led to an open discussion on script processing as a whole: the use of “fairness” policies to prevent parcels within a region making too heavy a call on simulator / simhost resources (including being swamped by heady script loads on avatars, etc.); allocating script memory size; general ideas on improving script efficiency through the use of things like regular expressions; etc.
- This conversation included a comment from Rider Linden that LL would be interested in the Firestorm script pre-processor were it to be contributed.
- The suggestion was made that LL could provide HTTP-out access using the AWS Dynamo DB for those who need bigger KVP databases – and it was pointed out that users can always rent their out Dynamo DB stack.
- No specifics on what the Lab might or won’t do vis scripts and script management, although Monty Linden revealed he’s been personally speculating on the advantages (or otherwise) of “higher level functionality” in the LSL libraries so that “more could be done with less code” – although he has only general ideas of possible functions in this regard.
- See the video for more on specifics.