Tag: Simulator User Group 2019

2019 SL User Groups 9/1: Simulator User Group

Posted on by Inara Pey

Endless; Inara Pey, January 2019, on FlickrEndless – blog post

Server Deployments

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

  • There was no deployment to the SLS (Main) channel on Tuesday, February 26th, leaving it on server maintenance package 19#19.01.25.523656. As regions on the channel were restarted in week #8, there was no restart this week.
    • The planned deployment was cancelled due to a list minute issue being found, and also led to the planned RC deployment(s) being postponed.
  • No deployments are planned for Wednesday, February 27th, 2019, leaving the RCs on the following simulator versions:
    • BlueSteel and LeTigre: server maintenance package 19#19.02.16.524516 EEP).
    • Magnum: server maintenance package 19#19.02.16.524515, comprising further internal fixes.
    • Simon indicated at the SUG meeting that regions on the RC channels might be restarted, although this is unclear, as the channels have not hit the 14-day restart barrier.

SL Viewer

There have been two recent RC viewer updates:

  • On Tuesday, February 26th, the BugSplat RC viewer updated to version 6.1.0.524670.
  • On Friday, February 22nd, the Estate Access Management (EAM) RC viewer updated to version 6.1.0.524240.

The rest of the viewer pipeline remains as follows:

  • Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • BugSplat RC viewer, version 6.1.0.524348, February 13th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
    • Love Me Render RC viewer, version 6.0.2.523177, January 16th.
  • 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.

Inventory UDP Messaging Deprecation

The planned deployment to Magnum (cancelled for this week) should include the updated simulator code that removes all asset fetching UDP messaging from the simulator code. Once deployed, this will mean anyone using really old viewers that do not have HTTP asset fetching on regions running on the Magnum RC channel will no longer be able to obtain responses to asset requests – and this will increase as the code is deployed to the remaining channels.

It’s not clear yet if the two “legacy” viewers currently offered by the Lab (the Linux Spur viewer and Obsolete Platform viewer) will remain available after the update has been fully deployed, as both will be unable to fetch assets.  Those wishing to test older versions of viewers against the updated simulator code can do so on Mesh Sandbox 3 on Aditi.

The Question of Script Load

The core of the SUG meeting revolved around the question of scripts and simulator loads. The discussion started with a request to make scripts run % data accessible to SLS, so scripters might coder periodic, intensive scripts hold off loops of execution if they can see a region is busy.

This spun out to a discussion of making information on scripts (as seen at the region level via Top Scripts) available at parcel level. However, a concern here is the risk of unnecessary drama: if X on parcel Y can see top scripts across the region, and sees A’s scripts on another parcel gobbling script time, it could lead to an assumption (right or wrong) it is the scripts that are responsible for all issues X is experiencing, resulting in potential local drama.

Another idea put forward is to make script use tied to parcel size (as is the case with land capacity / impact) in an effort to make script usage fairer within a region (see BUG-225391). While potentially good in theory, such a “fair use” approach has some potential issues:

  • Script usage isn’t balanced by parcel within a region. It is possible to have multiple parcels using little or no script time, and one using more than its “fair share”. Currently, this means things can balance out within a region, but with a capped script use, the “high use” parcel could be penalised when there is no need. As Oz Linden noted, “We could do that, but suppose we did. In many places people would see a big script performance drop even though the region had lots of idle time.”
  • Scripts are the only thing that can impact local performance: Physics Time, for example, can be over-used and impact performance, leaving very little script time per frame.
  • There is a difference between in-world scripts and attached scripts, so there is a question of how would the latter be accounted for? Making them part of the parcel allowance isn’t necessarily fair, as the parcel owner has no direct control over others without something of a draconian approach (depending on parcel size) – upping the potential for drama / upset.

Simon Linden also pointed out that there is pretty significant overhead moving between the scripts versus running actual bytecode (that is figuring out what to run against actually running it), so monitoring everything could add more of an overhead than actually letting scripts run – although there have been discussions on how to improve this. But, he also cautioned that adding further checks would have to be a “real clear win”.

There are some reports that the percentage scripts run seems to be falling across Mainland, without a noticeable increase in script count, which if true, would indicate something is going wrong. But as pointed out at the meeting, without data, it is hard to tell what is going on. Is a slow-down a case of having too much useful stuff going on for the available resources, or is it a case of someone going compute-bound in their script, lagging a region.

This is likely to be a discussion that will continue.

2019 SL User Groups 8/1: Simulator User Group and EEP oddities

Posted on by Inara Pey

A Way of Life; Inara Pey, January 2019, on FlickrA Way of Life – blog post

Server Deployments

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

  • On Tuesday, February 19th, there was no deployment to the SLS (Main) channel, leaving it on server maintenance package 19#19.01.25.523656; however, region on the channel were restarted. The planned update for the channel was again postponed due to a late-breaking bug.
  • On Wednesday, February 20th, 2019 the RCs are likely to be updated as follows:
    • BlueSteel and LeTigre should receive EEP update server maintenance package 19#19.02.16.524516, comprising the following fixes:
      • BUG-226252 [EEP] Please create an internal error code for llReplaceAgentEnvironment() & llSetAgentEnvironment() that distinguishes whether an agent does not have the experience allowed and if the experience is not allowed at their location.
      • BUG-226246 [EEP] llGetEnvironment() reports SKY_LIGHT fade_color as a rotation instead of a vector. (SKY_LIGHT only returns vector light_direction and vector total_ambient. fade_color is removed https://wiki.secondlife.com/wiki/LlGetEnvironment)
    • Magnum should receive server maintenance package 19#19.02.16.524515, comprising further internal fixes.

SL Viewer

The EEP Project viewer updated to version 6.0.2.524476 on Tuesday, February 19th. The remaining viewer pipelines remain as  follows:

  • Current Release version 6.0.1.522263, dated December 5th, promoted December 13th, 2018. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • BugSplat RC viewer, version 6.1.0.524348, dated February 13th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
    • Estate Access Management (EAM) RC viewer, version 6.1.0.523351, dated January 23rd.
    • Love Me Render RC viewer, version 6.0.2.523177, dated January 16th.
  • 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, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

EEP Deployment Oddities

There are some oddities being witnessed while EEP is being deployed. These should all go away once the code is fully deployed on the servers and the viewer code has reached all release versions of viewers.

Day / Night Cycle Differences

With the EEP updates currently on around 20% of the main grid, it is possible for very different values to be returned to the viewer when travelling between adjacent EEP and non-EEP regions, and this has been causing some confusion. Rider explains it thus:

EEP changes how the time is calculated. llGetSunPosition is dependent on the environment. It was not before. Legacy regions determine the beginning of the day differently than EEP regions. So until [they] have been [updated] there will be some disruption.

The way the start of the day has changed. It is now GMT-8, this [also] may not align with neighbouring legacy regions.

Other Oddities

  • There are also reports of jarring region crossing transitions that can sometimes occur when moving between regions with different EEP settings – see BUG-225689.
  • Stars on EEP regions will appear black against the daytime sky when seen on a non-EEP viewer with Advanced Lighting Model (ALM) enabled, or as white stars with ALM disabled.

Marketplace Gifting

There is an issue with the redelivery of gifts made via the Marketplace that (depending on the age of the original gift delivery) might result in the redelivery going to the sender, rather than the intended recipient – see BUG-226124. If you encounter this, please raise a support ticket.

2019 SL User Groups 7/1: Simulator User Group

Posted on by Inara Pey
Ponto Cabana; Inara Pey, December 2018, on Flickr
Ponto Cabana – click any image for full size

Server Deployments

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

  • On Tuesday, February 12th, there was no deployment to the SLS (Main) channel, leaving it on server maintenance package 19#19.01.25.523656; nor was there a restart.
    • The planned deployment was cancelled due to a last-minute bug.
  • On Wednesday, February 13th, 2019 the RCs are likely to be updated as follows:
    • BlueSteel and LeTigre should receive EEP update server maintenance package 19#19.02.08.524296.
    • Magnum should receive server maintenance package 19#19.02.11.524360, comprising further internal fixes.

EEP Update

The EEP server update to be deployed to BlueSteel and LeTigre comprises:

SL Viewer

There have been no viewer updates at the time of writing, leaving the current pipelines as:

  • Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • BugSplat RC viewer, version 6.1.0.523335, January 23rd. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
    • Estate Access Management (EAM) RC viewer, version 6.1.0.523351, January 23rd.
    • Love Me Render RC viewer, version 6.0.2.523177, January 16th.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November, 2017 – 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.

In Brief

  • Viewer disconnects / crashes: some people on “older” hardware have been reporting what appear to be viewer disconnects / crashes of late after only being logged-on for around 15-30 minutes (see: this forum thread). This has been noted by the Lab, and a potential fix is being tested on Aditi. The problem here is that forum posts don’t always give the level of detail required for LL to really diagnose matters. Jira is always the preferred method of logging issues – and it is important to use the official viewer when doing so.
  • Name Change Issue: as reported in my last SUG meeting summary, a creator preparing for the upcoming Last Names / name changing capability encountered an unusual situation: the Lab had changed a user’s account name. However, when sending information to an external HTTP request (object UUID, object name, owner name of the object, etc.), to the creator’s customer database, a HUD used by the user was sending their original account name not their revised name. The issue is now believed to be a stale cache issues, as noted last time.

2019 SL User Groups 6/1: Simulator and Governance User Groups

Posted on by Inara Pey
[Valium]; Inara Pey, December 2018, on Flickr
[valium] – blog post

Server Deployments

  • On Tuesday, February 5th, 2019 the SLS (Main) channel was updated with server maintenance package 19#19.01.25.523656, comprising internal fixes.
  • On Wednesday, February 6th, 2019 the RCs are likely to be updated as follows:
    • BlueSteel should receive EEP update server maintenance package 19#19.02.01.523934.
    • Magnum and LeTigre should receive server maintenance package 19#19.02.01.523959, comprising further internal fixes.
  • There is currently a small Cake RC on Agni that is being used to iron out some transient network issues with the newest server operating system update, prior to it being move to a full RC for testing. Cake may grow a little larger before this happens.

SL Viewer

There have been no viewer updates at the time of writing, leaving the current pipelines as:

  • Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • BugSplat RC viewer, version 6.1.0.523335, January 23rd. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
    • Estate Access Management (EAM) RC viewer, version 6.1.0.523351, January 23rd.
    • Love Me Render RC viewer, version 6.0.2.523177, January 16th.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November, 2017 – 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.

Other Items

Name Change Issue

A creator preparing for the upcoming Last Names / name changing capability has encountered an issue that may have broader ramifications. In sort, one of their customers was forced to take a new user name (their original name was considered “objectionable” by the Lab). However, the creator found that when sending information to an external HTTP request (object UUID, object name, owner name of the object, etc.), the object (in this case a HUD) was sending the original (objectionable) user name, not the updated user name. This suggests the user name is being caches somewhere within SL, and not being correctly overwritten if replaced.

Effort are on-hand to try to trace down the issue, but the problem is also a demonstration if why agent UUIDs should be used to trace avatars now and going forward, and not user names, particularly in light of the upcoming Last Name changes.

Governance User Group

Governance User Group (GUG) meetings are generally held on alternate Tuesdays at 13:00 SLT. They are intended to provide a forum for the discussion and education of issues involving Governance.  They are chaired by the GTeam supervisor, Kristen Linden and are open to the public. Details on dates, times and location can be found on the Governance User Group wiki page.

The Governance Team is responsible for dealing with Abuse Reports, in-world abuse, forum reports, Marketplace reports, etc. It is not responsible for issues with accounts being compromised, account subscription delinquency, fraud, IP infringement, etc.

  • These matters cannot be discussed at the GUG meetings.
  • Issues relating to them should be reported through the recommended channels (e.g. Support for account-specific issues, via the DMCA process for IP infringements, content theft, etc).

Similarly, individual cases involving Governance issues (e.g. the outcomes of abuse report filings), cannot be publicly discussed.

Resources

Meeting CliffsNotesTM

  • Are weapons testing sandboxes given more lenience by Governance WRT reports of harassment? Generally, yes, simply because these are environments designed for testing objects that can affect others. However intentional attempts to harass or grief will be responded to.
  • If someone is griefing / harassing a private region and is booted by the region owner, can they still be reported? Yes, just make sure the Abuse Report has all the necessary information as is correctly filed.
  • Objectionable names / Display Names: Governance will handle reports of offensive / objectionable user names, but are slightly more relaxed on Display Names. The latter is because users can disable the displaying of Display Names in their viewers. However, reports of intentional offensive or objectionable Display Names will be investigated.
  • Date of Next meeting: Tuesday, February 19th, 2019.

 

2019 SL User Groups 5/1: Simulator User Group

Posted on by Inara Pey
Wild Edge; Inara Pey, December 2018, on Flickr
Wild Edge – blog post

Server Deployments

At the time of writing there was no server release thread, I’ll update this article should one surface. The following notes are directly from the Simulator User Group.

  • On Tuesday, January 29th, 2019 the SLS (Main) channel was not update, and remains on server maintenance package 19#19.01.09.523003, comprising logging to gather baseline information on simulator performance in various areas of interest together with additional logging.
  • On Wednesday, January 30th, 2019 the RCs are likely to be updated as follows:
    • BlueSteel will hopefully receive an update to the EEP code. However, this is dependent on Rider Linden resolving a bug that is currently blocking EEP progress. This causes the time on a EEP region to become “stuck”.
    • Magnum and  / LeTigre will receive a server maintenance package, details undefined; the other should receive an update with internal changes.
  • There is currently a small Cake RC on Agni that is being used to iron out some transient network issues with the newest server operating system update, prior to it being move to a full RC for testing. Cake may grow a little larger before this happens.

SL Viewer

There have been no updates to the current official viewers to start the week, leaving the pipelines as follows:

  • Current Release version 6.0.1.522263, dated December 5, promoted December 13. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts:
    • BugSplat RC viewer, version 6.1.0.523335, January 23. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
    • Estate Access Management (EAM) RC viewer, version 6.1.0.523351, January 23.
    • Love Me Render RC viewer, version 6.0.2.523177, January 16.
  • 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.

Misc Items

Mesh asset UUID flipping

Being able to flip between mesh objects via script used to be possible in SL. However, it was blocked as it was being used as a means to animate meshes – but not very efficiently (the option places a lot of strain on the asset and physics server).

Recently, there have been requests to re-enable the capability because “now we have Animesh, there’s no need to flip this way.” There are also some use-cases that could benefit from the capability – such as being able to provide customisation options to customers who can then use a scripted mean to add them.

However, as Oz Linden pointed out, the availability of Animesh doesn’t necessarily negate mesh UUID flipping being abused. There is also a risk that the ability could be used to enable IP theft, and the approach – as noted – doesn’t really fit with the current SL design due to things like the asset load, etc. Ergo, it is highly unlikely to be allowed.

SL QA Engineer

If you’re a QA engineer and in the San Francisco  / Bay area, you might be interested in a QA job at Linden Lab working on Second Life.

2019 SL User Groups 4/1: Simulator User Group

Posted on by Inara Pey
Bay of Dreams; Inara Pey, December 2018, on Flickr
Bay of Dreams – blog post

Update: Magnum and LeTigre did not see a deploy on Wednesday, January 23rd, leaving them on server maintenance package 18#18.12.05.522294.

Server Deployments

As always, please refer to the server release thread for the latest news and updates.

  • On Tuesday, January 22nd, 2019 the SLS (Main) channel was updated with server maintenance package 19#19.01.09.523003, comprising logging to gather baseline information on simulator performance in various areas of interest together with additional logging.
  • On Wednesday, January 23rd, 2019 the RCs will be updated as follows:
    • BlueSteel will receive server maintenance package 19#19.01.18.523336, comprising the simulator support for the Environment Enhancement Project (EEP), and which will see the Snack channel currently used for EEP rolled into the BlueSteel RC.
    • Magnum and LeTigre were still TBD at the time of writing. I’ll update this article when more is known.

Region holders who wish to test EEP can contact support and ask for their region to be moved to an RC channel once the deployment has been made. Rider Linden currently has a request to have the SL wiki updated with the LSL functions for EEP, and has offered to provide a forum post on them, if required.

Remember, to work with EEP, you need the EEP project viewer, available from the Alternate Viewers wiki page.

SL Viewer

There have been no SL viewer updates to start the week, leaving the pipelines, at the time of writing, as follows:

  • Current Release version 6.0.1.522263, dated December 5th, promoted December 13th. Formerly the Spotykach Maintenance RC viewer – No Change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Love Me Render RC viewer, version 6.0.2.523177, January 16th.
    • Estate Access Management (EAM) RC viewer, version 6.1.0.522564, December 19th.
    • BugSplat RC viewer, version 6.1.0.522614, December 18th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
  • 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.

General

The SUG meeting was dominated with questions when upcoming features – grid-wide experiences,  new premium benefits, etc – may appear, and when the Lab anticipates completing the migration to the cloud. As always, and given the fact that SL is a dynamic environment with a lot going on, the replies were more-or-less “when they are ready”.