2018 SL UG updates #28/1: simulator user group / EEP

Aphantasia; Inara Pey, June 2018, on FlickrAphantasiablog post

Sever Deployments

Please refer to the server deployment thread for the latest updates.

  • There was no SLS main channel deployment on Tuesday, July 10th, 2018, leaving regions on that channel running on server release 18# However, due to the “14 day rule”, region on the main channel were restarted.
  • On Wednesday, July 11th, the release candidate channels should receive server update package 18#, comprising “additional internal tweaks”.

Both of the RC updates will include changes to the Animesh code currently deployed to the RC to allow better logging of Animesh related activities.

SL Viewer

At the time of writing, there had been no SL viewer updates to mark the start of the week, leaving things as follows:

  • Current Release version and dated June 15, promoted June 21 – formerly the Pálinka Maintenance Release Candidate – No Change
  • Release channel cohorts:
    • Quinquina Maintenance RC viewer, version, released on June 22.
  • Project viewers:
  • Linux Spur viewer, version, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Environment Enhancement Project (EEP)

This is the project to introduce a set of environmental enhancements. Rider Linden is now engaged in internal testing a viewer supporting the new EEP capabilities, together with the server-side support. During the July 10th, 2018 SUG meeting, he provided a brief summary as to how the basics of EEP will work:

You can create what are called settings objects in your inventory. These settings objects [they are not prim-like not can they be rezzed in-world] represent either a water, a sky or a complete day cycle. We are providing interfaces that will let you set the parameters for each of these types of settings. (Very similar to the existing WL editors).

[Then,] from the context menu for a setting object you can apply it either to yourself, the parcel you are in or the region you are in. (The last two if you have rights to do so; you may also open the editor and a button there will let you apply to region or parcel as well).

Scripted support for EEP will be provided for agents (avatars) in experiences, but as I’ve noted in previous EEP updates in these pages, this scripted support will not be part of the initial EEP release, but will be added later.

Will there is now the ability to present different windlights at pre-set altitudes (to to 1,000m, then 1,000m up to 2,000m and then 2,000m up to 3,000m and 3,000m+), this may be seen as a less flexible approach that can be achieved through some third-party viewers, which allow much closer altitude zoning of windlight settings (e.g. have a windlight from, say 22m to 500m, another from 500m to 1,000m, etc.). .

The bar at Holly Kai park exemplifies a potential limitation of EEP. The bar is built-in to the base of a rock plateau, and currently, it is possible to define a viewer-side windlight that applies purely to the bar’s interior (i.e. up to a height of 32 metres above the sea floor). Above that limit (“above ground” so to speak), the parcel uses the same daylight windlight as the rest of the region. EEP’s 1,000 metre altitude zoning effectively prevents this.

How big an issue this might be remains to be seen – but it is not unfair to say there is a reasonable number of regions scattered across the grid where EEPs altitude zoning could force a repositioning of different sky builds using local windlights, should it become the only means of applying localised windlight – which might not be initially popular.

In Brief

Retrieving Grid Statistics Page via llHTTPRequest (see BUG-216320): trying to retrieve grid statistics via a script results in a 499 error, although queries via web browsers will still succeed. No remedial work has been done on this.

JIRA Bug report fields issue (BUG-1074): the fields used in the Create form for a bug report do not use the same titles as the fields seen in a filed bug report, nor are they in the same order. This makes submitting a bug report confusing for anyone not used to the SL JIRA (they can’t even look at a filed report to easily see what they sound be entering in the fields of the submission form). This is something the Lab might fix following the deployment of an upcoming JIRA update.


Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.