Day: September 4, 2013

SL viewer gets “request teleport” feature and group eject confirmation

Posted on by Inara Pey

A new SL project viewer was released on September 3rd. The Snowstorm Project viewer 3.6.5.280476, brings with it a number of issue fixes, and includes two capabilities new to the viewer:

  • A “request teleport” feature (STORM-1838) contributed by Jonathan Yap, which allows users to request a teleport form another user (currently with caveats – see below)
  • A group eject confirmation pop-up (STORM-1952), submitted by Cinder Roxley, which some may be familiar with from using TPVs such as Firestorm.

Request Teleport

The new request teleport capability, which I first reported on back in week 4, requires both viewers to be using the code for it to work (so for the time being it is limited to the project viewer). Where this is the case:

  • Select the person to whom you wish to teleport (from your Friends list or Nearby list, etc.), and select Request Teleport
  • Enter a message in the pop-up, if required, and click OK.
Select the person to whom you wish to teleport (from your Friends list or Nearby list, etc.), and select Request Teleport. Enter a message in the pop-up, if required, and click
Request teleport: making a request

At the “other end” the recipient of the request will receive the request as an initial pop-up notification and within CHUI:

Receiving a teleport request - pop-up and CHUI message
Receiving a teleport request – pop-up and CHUI message

The recipient can than either accept the request, sending a teleport offer, or reject it, in which case no message is sent.

The teleport offer is again displayed in the requester’s viewer as both as an initial pop-up notification (below) and within CHUI.

Receiving the teleport offer
Receiving the teleport offer

Note again, that the system will only work where both viewers are running the new code (e.g. the Snowstorm project viewer for the time being). If someone on a viewer with the capability to someone using a viewer which does not have the teleport request code, the request will not be received / displayed.

Group Eject Confirmation

The group eject confirmation sees the official viewer get a new pop-up asking for confirmation when ejecting someone from a group, in order to help with issues where the wrong name is selected and ejected.

The new gtoup eject confirmation pop-up for the official viewer
The new group eject confirmation pop-up for the official viewer

Again, as noted above, the release notes for the viewer provide a full list of updates in the viewer.

SL projects updates week 36 (1): server releases, HTTP notes, anti-griefing

Posted on by Inara Pey

Server Deployments

As always, please refer to the week’s forum deployment thread for news, updates and feedback. Deployments are a day behind the usual schedule due to the US Labor Day long weekend.

Second Life Server (SLS Main) Channel – Wednesday September 4th

The Main channel should receive the maintenance package deployed to all three RC channels in week 35, comprising:

  • An update to region restarts initiated by region owners or estate managers which will see the region restart after the last avatar leaves, rather than waiting for the full countdown period to complete
  • Preparatory work to support new estate and parcel access controls – these will require an upcoming viewer-side update in order to be visible to users
  • A fix for a physics-related griefing mode (see below)
  • A crash mode fix.

Release Candidate Channels – Thursday September 5th

All three RC channel should receive the same maintenance package, which comprises  server-side HTTP updates which require a future viewer-side update. In the meantime, these changes should not be apparent in any current viewer release. The updates specifically comprise:

  • When connections between viewer and web services were closed by the server, the last response was sent without a ‘Content-Length’ or ‘Transfer-Encoding: chunked’ header. Last response will now be sent with ‘chunked’ encoding.
  • Throttling actions on Capabilities URL result in 503 status codes back to clients. These responses may include a ‘Retry-After’ header with a delta time giving a hint as to when the client may retry the request. In the absence of such a header, client is expected to make ‘reasonable, best-practices’ delayed retry attempts.
  • Adds support for a new capability, ‘GetMesh2’ for fetching mesh assets with keepalives enabled.

HTTP Notes

The RC deployments look to be the first part of Monty’s continuing work on HTTP connectivity between the viewer and the SL servers. As noted in recent reports, the core focus of this work is on improving mesh fetching capabilities between the two, although Monty is also working on a number of other updates, all of which are aimed at improving the HTTP services between the viewer and the SL servers and making them more robust, as well as paving the way for HTTP pipelining in the future.

Group Ban Lists

Baker Linden continues to work on the new group ban list functionality. The focus is currently on the UI hook-ups and back-end validation checks. It will still be a while before a project / RC viewer is likely to appear, but hopefully not too long.

Anti-griefing Work

Andrew Linden continues to work on “anti-griefing” measures, reporting that the “physics-related griefing mode” which forms a part of the Main channel deployment and which is already on the three RC channels, is to prevent the use of “faux rotating megaprims”.

These are megaprims which used a physics collision exploit to knock avatars out of that region using the ‘resolve interpenetrating objects’ collision logic. “We had  some collision-bypass code there specifically for avatars, but it had been broken some time ago,” Andrew explained, the break apparently allowing the exploit. He’s now fixed the code breakage, and reports from a number of RC sandboxes is that it appears to have worked.

Other Items

There was a report made during the Simulator User Group that some LSL events are failing to execute or aren’t being queued / cued when a script is caught in a loop. details were sketchy, but a BUG report was due to be raised.