SL Server Deployments

Week 15

It’s pretty simple again this week: there are no server deployments scheduled for either the Main (SLS) channel (which remains on maintenance project 14.03.12.288004) or the RCs (which collectively remain on 14.03.28.288552). As always, please refer to the server deployment thread in the forums for the latest news and updates / issues.

SL Viewer

The de facto release viewer updated on Monday April 7th, with the promotion of the Google Breakpad RC, version 3.7.5.288464 (release notes).

As a result of this promotion, the StatTest viewer (formerly version 3.7.5.288371), which was never intended for promotion as a release viewer but issued as a means of assisting with bug-fixing the Google Breakpad code, has been removed from the viewer release channel.

Group Ban Lists

“I’ll be working with Maestro this week to try to get the group ban services and back-end stuff grid-wide on Aditi,” Baker Linden informed the Simulator User Group meeting on Tuesday April 8th. He went on: “I have a handful of smallish bugs to finish up, and then I’ll look at my options for development viewers and such, so group ban will be grid-wise soon [on Aditi] (I hope, depending on the amount of releases in the pipe). And then after we see there’s no big issues, we’ll get that pushed out to Agni.”

Other Items

Aditi Log-in Issue / Inventory Update Issue

As reported in part 2 of the my week 14 updates, there has been an issue in getting passwords and inventory to correctly sync on the Aditi beta grid following a password change. Normally, a script is run on daily basis during periods of relatively low SL use (around midnight-02:00 SLT) which should synchronise a user’s password and inventory between Agni and Aditi. However, several people had noted that their Aditi passwords / inventories were not updating despite several days passing after making password change (see BUG-5563).

It had been thought this issue had been dealt with in week 14; however, a forum thread notes it is still causing problems for some people.

Transaction History Oopsie

There was a brief issue with Transaction History pages on Tuesday April 8th which caused some consternation when it happened, although it was quickly rectified.

The problem first came to light when merchants noticed that their Transaction History page was no longer showing totals or options to download the history in anything other than .CSV format (the previous options had been .XML or .XLS). Further issues were noticed as time went on, as noted in a Commerce forum thread and also in a JIRA (BUG-5664).

The root cause of the problem appears to have been the URL for the familiar Transaction History page being swapped for a new page. The concerns this raised were sufficient for the URL to be reverted back to the original a little over an hour after the problem was first noticed, allowing people to once more access the familiar Transaction history page. Whether the change of URL is indicative of an upcoming change that is in preparation, or simply a mistake on the part of someone at the Lab, is unclear.

Experience Permissions / Tools / Keys

This project has been around a while and keeps resurfacing, although finding out exactly what it fully entails is proving hard.

The original capabilities tools were first seen in the Linden Realms game in 2011, and allowed for automated teleporting and other abilities useful for building a range of experiences and the like. The first cut of the tools was deployed to the Magnum RC channel in June 2012, when they were referred to as the Second Life Advanced Creator Tools. However, they were almost immediately compromised, resulting in the capabilities being rolled-back.

On August 1st, 2012, an updated version of the capabilities was deployed in what the Lab referred to as the “first set” of the tools. But since then there have been no visible updates, although towards the end of 2013, there were server-side infrastructure changes made to the RC channels and Main channel in preparation for “Experience Keys”, which were believed to be a part of the same overall project (which people are now referring to as the Experience Project, or XP). Since that time, little has been heard.

Commenting on the project at the Simulator User Group meeting, Simon Linden could only say, “I dont’ have any news or progress to report on the XP functions, unfortunately. I know they’ve been working on polishing it up, but there’s a lot to work out (or I’m clueless) about how it’s to be released.”

Somewhat related to this, a forthcoming server update should see a fix for SVC-382 / BUG-5533 (llTeleportAgent() and llTeleportAgentGlobalCoords() can break any script in any attached object that contains a change event). The fix has passed through LL’s QA and has been deployed to at least one region on Aditi (Annelie), so should hopefully be appearing in an RC update in week 16.

Feature Request: Add option to region/parcel to allow intra region/parcel TP when a landing point exists

BUG-5222 is a feature request to allow region / parcel owners a finer level of control over where people can teleport (such as via a double-click to teleport) once inside their region / parcel when a landing point is set.

This feature request would theoretically allow parcel / region owners to set a landing point to which all incoming teleports (from other regions) would be directed, but then to decide whether they additionally want all teleports within the region to also be redirected to the landing point, or whether they wish to allow visitors to freely teleport within the region / parcel.

In this way, for example, a store owner could set a landing point for all new arrivals coming into their store from elsewhere, but once people have arrived, the store owner could allow them to teleport around their store to their heart’s content. However, if the owner of a role-play region or game region wished to discourage people from “cheating” by teleporting around the region, they could have both teleports from outside of the region / parcel and teleports from within the region / parcel routed to their landing point.

While it is not clear how this will be handled, Maestro has suggested that as a part of any change, the landing zone option within About Land > could be updated with three options:

Allow direct teleport anywhere

Allow direct teleport from within the estate (from outside the estate, force them to the telehub)

Disallow all direct teleport (force all TPs to the telehub).