2018 SL project updates 28/2: TPVD meeting

ChouchouMemento Moriblog post

The majority of the following notes are taken from the TPV Developer meeting held on Friday, July 13th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. This was a short meeting – just over 30 minutes in length, but with some significant pauses throughout.

SL Viewer

The Quinquina Maintenance RC viewer updated to version 5.1.7.517594, on July 12th. All other SL viewers in the various pipelines remain as for the start of the week:

  • Current Release version 5.1.6.516459 and dated June 15th, promoted June 21st – formerly the Pálinka Maintenance Release Candidate – No Change
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.

Animesh

[0:44-2:20] Some bugs have surfaced in the server-side Animesh code which may delay the code from being deployed to the Main (SLS) channel in week #29 (commencing Monday, July 16th).

There is still some validation testing going on for the LOD / bounding box issue in Animesh viewer, but the viewer should be promoted to release candidate status “fairly soon”, possibly by the time the server-side code has been deployed grid-wide.

Bakes On Mesh

[2:21-2:38] A further update to the Bakes on Mesh project viewer is anticipated, possibly in week #29 (commencing Monday, July 16th). This will include several bug fixes.

Upcoming Project Viewers

Environmental Enhancement Project (EEP)

[3:01-3:40] A project viewer for EEP should be surfacing soon, but the functionality will not be available on the Main grid until the supporting back-end inventory updates have been deployed to Agni.

Texture Caching Updates

[3:44-4:21] A project viewer (the TCO viewer) with new texture caching capabilities is still anticipated as coming soonTM.

Estate Management Tools Updates

[4:45-5:27 and 21:59-23:31] A viewer supporting the updates to the estate management tools – improved ban lists, etc., had been held up while some issues around Friend requests and group invites are fixed (these issues are related to the recently introduced capability to deliver off-line IMs, etc., via HTTP rather than UDP, with group invites and friendship offers requiring more back-end updates in order to work correctly through the new capability). These issues have now been resolved, and both the server-side updates and the viewer changes are with the Lab’s QA team.

Last Names

[16:30-20:25] Still no date for roll out, but as these keep coming up:

  • There are no plans to re-introduce legacy last names (i.e. no Pey, Widdershin, Sideways, Munro, Fizzle, etc.).
    • [27:27 (text) and 28:18-28:25] However, a suggestion was put forward in the meeting to offer legacy names at a higher price than other last names, and Oz indicated this might be considered.
  • People will be able to suggest last name options (excluding legacy last names, per above).
  • There will be no change to Display Names, which will remain available as an option for those wishing to continue using them.
  • Changing your name will levy a real-world fee – the exact amount is still TBD.

A focus on the work for this is updating back-end services so they properly support / recognised changed names. Until this work is completed, the Last Names capability cannot be deployed.

In Brief

  • [5:43-6:36] Dynamic user interface (DUI): referred to at the recent Meet the Lindens sessions at SL15B, the ability to separate floater and panels out from the main viewer window is not being worked on at present, and so it is extremely unlikely anything on this will appear in 2018.
    • For a broader discussion on the idea and some of the Lab’s thinking on is – please refer to this section of my SL15B summaries.
  • [7:11-7:30] Multi-core graphic pipeline: raised at the meeting, this is not something the Lab is liable to tackle at the moment. A more important focus is how to handle Apple’s deprecation of OpenGL.
  • [9:29-9:45, with text comments to 11:43] BUG-225039: “with transparent texture and alpha masking at cut-off 1, the underlying colour shows through in small patches” – the Lab is actively investigating this.

 

Advertisements

2018 SL project updates week 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#18.06.14.516450. 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#18.07.03.517389, 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 5.1.6.516459 and dated June 15, promoted June 21 – formerly the Pálinka Maintenance Release Candidate – No Change
  • Release channel cohorts:
    • Quinquina Maintenance RC viewer, version 5.1.7.516813, released on June 22.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, 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 3.7.28.300847, 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.

2018 SL project updates week 27

The Vault – dare you enter? – blog post

Sever Deployments

Due to this week being July 4th week in the United States, there are no planned server deployments.

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 5.1.6.516459 and dated June 15, promoted June 21 – formerly the Pálinka Maintenance Release Candidate – No Change
  • Release channel cohort:
    • Quinquina Maintenance RC viewer, version 5.1.7.516813, released on June 22.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, 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 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Retrieving Grid Statistics Page via llHTTPRequest

There is a known LSL bug when trying to retrieve grid statistics via a script, which results in a 499 error – see BUG-216320. However, queries via web browsers will still succeed.

This Week

Project news will be in short supply, again due to it being 4th of July week.

 

2018 SL project updates 26/3: TPVD meeting

San Monique; Inara Pey, June 2018, on FlickrSan Moniqueblog post

The majority of the following notes are taken from the TPV Developer meeting held on Friday, June 29th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it.

SL Viewer

No changes to see out the week, leaving the current pipelines as:

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

Week #27 Deployments

[2:53-3:29] Animesh is now on all the major release candidate server channels. However, due to the US 4th July holiday occurring mid-week in week #27 (commencing Monday, July 2nd, 2018), it will not be deployed to the Main (SLS) channel, as the Lab wish to avoid “high risk” deployments during the week.

Bugsplat Testing

[3:34-4:08] The Lab is about to start experimenting with viewer crash reporting using BugSplat, a commercial service.

As a part of this, a new release candidate viewer with code for using Bugsplat should be arriving in week #28 (commencing Monday, July 9th); aside from this, code, it will be functionally identical to the de facto release viewer. It will be used to evaluate whether or not to commit to a move to using Bugsplat over the current home-grown Breakpad crash reporting mechanism.

Environment Enhancement Project

[4:40-5:50] The EEP project viewer is seen as being “not too far away”. It is currently awaiting the deployment of the back-end inventory management changes, which are required to support the new EEP inventory assets. This includes a new inventory Settings folder, designed to contain windlight assets.  Please refer to my week #26 CCUG update for more on EEP as well.

[6:13-8:04] It’s not clear when the experience-based LSL support for EEP will be available – probably not during the initial deployment, but will become available as the project iterates. Also things will be set such that during testing, those on regions supporting the new EEP settings will see them; those on regions without the back-end support will see things as they are now (the “old style settings”).

Upcoming Changes

Monday, July 2nd, will see the introduction of the new private region prices, together with the increase in Linden Dollar purchase transaction fee see Linden Lab announces major SL private region pricing restructure for more.

[15:03-16:50] Also coming up is the new land auction system, which will allow users to auction their own Mainland.

The system is currently in the final stages of testing internally, and the current plan is for the Lab to wind-down auctions using the existing system by the end of week #27, then switch to the new system. Initially, only auctions of Linden held land will be available through the new system, but this will be expanded to include land held by users hopefully by the end of July 2018.

The new land auction system will be run through Place Pages, so those having Mainland they want to auction should consider creating a Place Page for it (if they haven’t already done so).

Other Items

  • [8:20-8:46] It appears that once Animesh, EEP, Bakes on Mesh, etc., are all deployed, the focus may be more on server-side updates and work (region crossings?). The easing of viewer-related projects should give TPVs some room to catch up with the Lab, if necessary, although bug fixes, etc., will still be appearing (via Maintenance RC releases).
    • [29:11-29:43] One of these projects will be ARCTan, the project to re-evaluate object and avatar rendering costs. However, this will remain a deliberately slow process.
  • [8:59-9:23] There are still two major open-source contributions to the viewer in development:
    • Camera presets, which will allow users to set and save their own preferred camera presets in the viewer see STORM-2145.
    • Porting of the poser feature from the Black Dragon TPV to the official viewer.
  • [9:32-12:40] As noted in my previous TPVD meeting summary,  there are concerns about unintended consequences of experiences when combined with tools such as avSitter (and / or RLV), and the potential for abuse. A JIRA was raised, but subsequently closed by the Lab. However, the matter is still under discussion internally, and may result in changes to how experiences work to address the issue.
  • The next get-together of everyone at the Lab who works on Second Life to discuss plans and options should be taking place towards the end of July.
  • [18:16-18:37]The latest official viewer sees the minimum object LOD raised from 0.0 to 1.0; this is unlikely to be reversed.
  • [19:00-20:05] The Lab currently has an update to Voice running internally. Vivox are due to deliver a new SLVoice.exe update “real soon”. When this happens, the test Voice viewer will likely move to a public project viewer, with the new SLVoice package.

 

2018 SL project updates 26/2: CCUG summary

Eri-Ador; Inara Pey, June 2018, on FlickrEri-Adorblog post

The majority of the following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, June 28th, 2018 at 13:00 SLT.  These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Note that the audio presented here may not be in the exact order of discussion during the meeting; as subjects were at times returned to following their initial discussion, I have attempted to bring together key points of discussion by topic / subject matter. Also, please note that audio drop-out when Vir is speaking appears to be an ongoing problem at his end.

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. It involves both viewer and server-side changes.

Resources

Current Status

  • On Wednesday, June 27th, server-side Animesh support was deployed to all three of the major release candidate channels – Magnum, LeTigre as well as BlueSteel. Test regions for Animesh are as follows:
  • The Animesh viewer remains at project status, but was updated to version 6.0.0.516979 on Monday, June 25th, 2018. The viewer is liable to remain at project status until the bugs currently being worked on have been resolved. These bugs include, but are not limited to:
    • Encroachment / Position / Offsets.
    • Rigged Mesh Level of Detail / Bounding Box Issues (BUG-214736).
    • Broken Rotations Issues (see below for more).
    • Dynamic bounding box issues: the project viewer (5.1.4.515420) includes updates for keeping dynamic bounding boxes going for rigged avatars (including Animesh). The calculations used in these updates for Animesh attachments “isn’t quite right” and the extent calculations can be incorrect (particularly if an Animesh object is being rendered as an imposter).
  • Vir now has a number of issues related to level of detail which he is starting to dig in to, including BUG-224971.The revised bounding box calculations related to this will be in the next Animesh project viewer update.
  • The z-offset issue with Animesh objects failing to respect z-offset height setting specified at upload for a rigged mesh should now be fixed.
  • It’s been reported that while Animesh objects will show info in the same way as avatars do with Developer > Avatar > Animation Info is enabled, it reports different info to  llGetObjectAnimations()
    • This might be a bug.
    • It might be that the debug information isn’t updated on a frequent enough basis.
    • Either way, a bug report has been requested.

Rotation Issues

These cover a number of areas, including:

  • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
  • The second problem is that when linking a series of objects into a single Animesh, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

Both of these problems predate Animesh, but have been effectively “hidden” because until now, rigged meshes could only be attached to an avatar, effectively masking the issues.

The recommendation for trying to deal with them at present is for Animesh objects to have a non-mesh root object, and associate any physics representation to that non-mesh root object. This should hopefully eliminate the current issues and help ensure that any mesh being propelled via scripts in the root object will move in a predictable manner (.i.e. moves forward when driven forward by a script).

There have been two user-led moves to try to resolve / reduce these problems:

  • Beq Janus and Elizabeth Jarvinen (polysail) have also contributed code to correctly apply the bindpose matrix within the viewer.
  • As the physical rotation issues tend to manifest with Avastar, it is being updates so that models are automatically oriented so that x+ is always forward. This may not help with all legacy content being converted to Animesh, but it should help with new content created via Avastar.
    • Vir has a concern that even with these changes, a  linked Animesh object using mesh items created in different tools might still exhibit unexpected behaviour – that an animation to move the Animesh forward might correctly drive the root mesh, but cause other elements to move (for example) sideways …
    • He also notes that the solutions don’t necessarily address the physics rotation / placement issue.
  • It’s also been suggested the llLookAt provides documentation on what might be regarded for expected object behaviour.
  • It has been pointed out that the orientation of a model can be checked in the mesh uploader preview window prior to upload, although the uploader doesn’t explicitly report an objects rotation.
  • The debate on how best to approach the issues is likely to continue.

Animesh Attachments

  • Animesh attachments are currently limited to one per avatar. This is viewed by some as too restrictive.
  • This limit was set to allow the overall potential for a performance impact of attached Animesh objects to be limited (e.g. going to a club where everyone is wearing 4 or so Animesh attachments – hair, pets, and the like, all with their own skeleton and animation, all doing their own thing, could see the viewer take a significant performance hit).
  • Some are seeing it as a tablets-of-stone limit and are wanting it raised from the outset (to between 2 and 3 Animesh attachments per avatar – in part, this appears to be due to a preference for using Animesh over the additional bones within the avatar skeleton for some attachments).
  • Vir has indicated that the limit will not be increased during this initial deployment of Animesh, but the Lab will monitor the limit, and a possible future increase is not out of the question.
    • It is easier to relax an initial than it is to restrict them after rolling-out a capability – which is the situation the Lab wants to avoid (e.g. by – say – allowing 3 Animesh avatar attachments out-of-the-gate, then having to cut it back to 2 or 1 at a later date,due to the performance impact the capability is having).

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing Bake  Service.

Resources

Current Status

  • Anchor Linden is continuing to work on viewer-side bugs. In the next version of the viewer, an avatars appearance should correctly update in the Edit Appearance mode when changing applied textures.
  • The project viewer updates are now with the Lab’s QA team. However, and update made to the project viewer doesn’t mean that it will be progressing to release candidate status just yet.
  • As per my previous CCUG summary, the project viewer will not initially have LSL support for Bakes on Mesh – this will likely be added as the project as a whole iterates.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days that can be stored in inventory and traded through the Marketplace / exchanged with others.
    • Day assets can include four Sky “tracks” defined by height: ground level (which includes altitudes up to 1,000m) and (optionally) 1,000m and above; 2,000m and above and 3,000m and above, plus a Water “track”.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.
  • There are no EEP parameters for manipulating the SL wind.
  • EPP will also include some rendering enhancements  and new shaders as well (being developed by Graham Linden), which will allow for effects such as crepuscular rays (“God rays”)
    • These will be an atmospheric effect, not any kind of object or asset or XML handler.
  • The new LSL functions for finding the time of day according to the position of the windlight Sun or Moon have been completed,and are more accurate than the current options.
  • EEP will not include things like rain or snow.

Resources

Current Status

  • Work is progressing on the project viewer, which should be appearing SoonTM – possibly in the next two weeks, with back-end EEP support available on Aditi (the Beta grid) – supported regions TBD.
  • There is a long-term issue with land ownership on Aditi which is unlikely to be resolved before EEP is deployed to Aditi.  This means that it is likely the Lab will set up a series of test parcels on Aditi and assign them to people manually for testing EEP capabilities at parcel level.
  • It’s not clear how walls and other structure will affect crepuscular rays.

Additional Discussions

Particle System Updates

Particle wizard Tyrehl Byk (learn more about his work here and here) is back in Second Life and looking to produce more of his stunning shows. In the meantime, he has filed a feature request to improve particle capabilities in Second Life (see BUG-214757 – “Within the current llParticleSystem parameters, three new data points would be established that could be referenced by a particle script which would facilitate an exponential change in how particles are seen by SL residents”).

Oz Linden has indicated this is something the Lab would like to implement; however, while the feature request has been imported for tracking in their internal JIRA,they currently do not have the viewer-side resources to take on the work.

That’s one I would like to have had … The hardest part of that one is the viewer side, because that’s where the particle stuff actually happens. So if you’re interested in accelerating that one, Tyrehl, then find a third-party viewer dev who will dummy up the support in the viewer, then we’ll be able to do the server-side relatively easily.

Oz Linden on feature request BUG-214757

So if there is a third-party viewer developer out there who is interested in working with Tyrehl on this feature,please contact him in-world.

Get Animation Length

While not specific to Animesh, but seen as potentially useful, is a long-starting feature request, VWR-12518, “llRequestInventoryData() – Get length of an animation (in seconds)”.

A problem here is that at present, the simulator doesn’t actually read the contents of animations to ascertain what they are doing, how long they run, etc (while there is some analysis carried out during the animation upload process, this information is not retained for later use). So for an idea like this to be implemented would require a considerable amount of server-side work which might also have performance implications, as such this request is unlikely to be implemented unless part of a much large overhaul of back-end animation support.

Next Meeting

The next Content Creation User Group meeting will be held on Thursday, July 19th.

2018 SL project updates 26/1: Simulator User Group meeting

Oboeru; Inara Pey, June 2018, on FlickrOboerublog post

The majority of the following notes come from the Simulator User Group meeting of Tuesday, June 19th, 2018.

Sever Deployments

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

  • On Tuesday, June 26th, the Main (SLS) channel was updated with server maintenance package 18#18.06.14.516450, previously deployed to the LeTigre and Magnum RC channels, comprising internal fixes and logging improvements.
  • On Wednesday, June 27th, the release candidate channels should be updated with server maintenance package 18#18.06.22.516968, which includes Animesh on a first-time deployment for LeTigre and Magnum (having been deployed to BlueSteel in week #25), and “new Main Channel code”.

Some SLS channel regions reported double restarts on Tuesday, June 26th, and these are being investigated by the Lab.

Animesh Deployment

Follow the Wednesday, June 27th, Animesh will be live on all the major RC channels – however, as previously noted in this updates, it is still in development, and not product-ready.

The Animesh project viewer, necessary for working with Animesh and rendering it correctly, can be obtained from the Alternate Viewers wiki page.

Animesh Resources

You can find further information on Animesh via the following resources.

SL Viewer

Recent updates:

  • The release viewer updated to version 5.1.6.516459 (dated June 15th) on June 21st, formerly the Pálinka Maintenance Release Candidate.
  • A new Maintenance RC viewer, version 5.1.7.516813 and code-named Quinquina, was released on June 22nd.
  • The Animesh project viewer updated to version 5.1.6.516525 on June 22nd, and again on June 25th to version 6.0.0.516979.

The other SL viewers in the current pipelines remain as:

  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, 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 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Environment Enhancement Project (EEP)

The is still some confusion as to how EEP will work with different region / parcel windlight settings at altitude when compared to Firestorm’s parcel windlight capability. In short:

  • Firestorm allows the windlight within a parcel to be changed at any altitude using a command line construct in the About Land description floater.
    • However, this is purely a viewer-side change.
    • Anyone entering a region using a viewer that does not have the same windlight support will not automatically have the setting defined in About Land applied to their viewer.
  • EEP should ensure that windlight settings set by altitude will apply to everyone in a parcel, regardless of the viewer they are using.
    • However, windlight changes by altitude are limited to four heights: from ground level up wards; 1,000m and above; 2,000m and above; 3,000 and above.

Top Scripts and Region / Parcel Management

Some people are experiencing region performance issues  – notably around scripts, etc. It’s been suggested that making Top Scripts and Colliders visible to parcel holders within a region so they can see what in their parcel might be impacting performance has been suggested.

  • This isn’t a fresh request (see JIRA SVC-835), but it is one that hasn’t been discussed recently.
  • The concern was raised that allowing Top Scripts to be more widely visible could lead to harassment between parcel holders in a region.
  • There is also some concern that over-use of the capability could itself impact region performance, because Top Scripts is an intensive query to run.
  • Even so, it is something being take back to the Lab for further discussion, and is seen as “reasonable”, providing the ability to start / stop scripts isn’t included (griefing vector).