Tag: Simulator User Group 2014

SL projects update 23/2: object detachment and inventory issues

Posted on by Inara Pey

I opted to put the following under a separate projects update piece, rather than “Other Items” (as I usually do), as they are quite extensive and worth noting. All of these items were discussed at the Simulator User Group meeting on Tuesday June 3rd.

Scripted Object Detachment Issue

This problem has been around for a while (see JIRA SVC-7626 for a description, although there have been more recently JIRA filed), and Simon Linden has been digging into it.

It relates to the scripted detachment of objects using a REGION_CHANGED event following a region crossing. When entering the new region, the order of the messages received by the viewer gets mixed-up such that it may get the order to “kill” (stop rendering) the object ahead of the message telling it to detach the object.

Should this happen, the viewer actually doesn’t know which object it should remove, and the result is that the object remains in visible to the wearer, but it cannot be detached or edited (because the server considers it removed). However, to other people in the region, the object will not appear to be attached, as they received the correct updates. So, if you have multiple attachments doing this, everyone may see different things.

One way to correct the problem is to re-log. This can cause the object to render properly and be detached.  Simon Linden also offered a possible solution:

If you click on it, it will likely go away. What happens then is the viewer sends up a “select” or some similar message with that local ID. The server can’t find the local ID, so it echos back a “kill” to the viewer … under the assumption that the viewer is confused and has this odd local ID.  That’s why similar problems of ghost objects [seen in-world rather than attached to an avatar] can often be fixed by clicking on them …

I’m not sure why but the click / selection thing seems to work more if you go back to the original region [where the object was still attached].

Why the order of the messages received by the viewer gets mixed-up is unclear, and there may be a number of possible causes, as Simon also explained:

Having controls [e.g. PERMISSION_TAKE_CONTROLS] may affect how scripts get run, and thus the REGION_CHANGED event gets processed faster [leading to the mix-up in the order of the messages]. I have to drop my bandwidth down to the lowest setting to make it happen … that’s another factor.

It’s an interesting bug because it combines region crossings with scripts, object deletions and the interest list updates … all pretty complicated parts of the server.

It’s not clear what is going to be done to rectify the issue, given it is a timing issue touching on several areas of interaction. In the meantime, if you encounter the issue, you may want to raise an additional JIRA, citing location, behaviour, etc., and also try one of the workarounds mentioned above.

Problems with Inventory’s Received Items Panel

received-itemsReceived Items is a system folder introduced with Direct Delivery and intended to be used for the initial receipt of SL Marketplace purchases before moving them into “normal” inventory. Because it is intended to be a “temporary” store, Received Items isn’t included in any inventory searches, so any items stored in folders created there won’t ever be listed when using search.

Within the official SL viewer, Received Items appears as a separate section at the bottom of the Inventory Folder (shown on the right). When displayed like this, it is not possible to move Received Items. However, when receiving goods from the Marketplace, Received Items does appear as a folder in the Recent tab of Inventory – and it is here that problems can occur, for example:

  • It is possible to drag the Received Items folder shown in the Recent tab into another folder, causing Received Items to vanish from the bottom of the Inventory floater following a re-log
  • It is possible to right-click on the Received Items folder in the Recent tab and delete it.

Neither of these issues are unrecoverable, however, and neither leads to a permanent loss of inventory.

Recovering After Accidentally Deleting the Received Items Folder

  • If you accidentally delete the Received Items folder in the Recent tab, you can recover it the same way as anything else – open Trash and drag it back under the My Inventory folder
  • If you purge your Trash after accidentally deleting the Received Items folder from the Recent tab, simply go to the Marketplace and make a purchase – Received Items will be re-created on receipt, although anything stored within it prior to the deletion will be lost.
When
SL viewer: following the receipt of a purchase, it is possible to accidentally move the Received Items folder in the Recent tab to another folder (l). Should this happen, then following a relog, it would appear as if the Recent Items section at the bottom of the Inventory floater has vanished (c). Also, when displaying Received Items as a folder under the Recent tab, it is possible to right-click it and accidentally delete it (r).

Continue reading “SL projects update 23/2: object detachment and inventory issues” →

SL projects updates 23/1: server, viewer, group bans

Posted on by Inara Pey
Simulator UG meeting (stock)
Simulator UG meeting (stock)

Server Deployments Week 23

As always, please refer to the server deployment thread in the Technology forum for the latest updates, news or changes to the deployment schedule and for any issues which may have been reported.

Main (SLS) Channel

There was no main channel deployment on Tuesday June 3rd. Instead, the maintenance work which had been scheduled for May 22nd, but which had to be postponed due to problems earlier in the week, took place. Some of us who report on server updates, etc., had mistakenly believed that this maintenance work was actually carried out May 28th; so ho-hum on that score!

Release Candidate Channels

The release channel updates for week 23 will be:

  • BlueSteel will remain on the inventory update project, and will not be rolled this week.  This project enables support for a new version of the inventory service, AISv3.  To make use of this new feature, login with the Sunshine RC Viewer
  • Magnum will remain on the Experience Tools project, but will gain some minor changes related to the project – release notes
  • LeTigre will move to the “group ban” project.  As the name implies, this project adds the ability to ban users from groups (more below)  – release notes

The release candidate channel rolls (Magnum and LeTigre) should take place on Wednesday June 4th.

SL Viewer

On Tuesday June 3rd, the Lab released the MemShine release candidate viewer, version 3.7.9.290582. This viewer combines updates from the MemPlugs RC viewer (a variety of fixes to address memory leaks in the viewer and to improve crash rates), and the Sunshine / AIS v3 RC viewer (additional server-side appearance improvements and AIS v3 improvements aimed at outfit changes). Both of these RCs also remain listed on the Alternate Viewers wiki page at the tim of writing.

For the status of all SL viewer releases, please refer to my Current viewer Releases page.

Group Bans

As noted above, the server-side code for group bans is due to start its deployment to the main grid. This functionality, which comprises both server-side and viewer updates, provides the means for owners (and selected roles) in an open enrollment group to selectively ban people from either joining / re-joining their group, in order to help with issues such as group spamming.

The following general points apply to the group bans functionality:

  • By default, only the Owners role is assigned the ability to ban other avatars from a group
  • The ability can be granted to other roles, if required
  • Roles which are granted this ability are also granted the Eject Members and the Remove Members from Roles abilities
  • Group members with the Manage Ban List ability will be able to add or remove other users to and from the group ban list
  • When a group member is banned from the group, they are automatically ejected
  • A user who is banned from a group will not be able to join it either directly or through an invitation (once the capability is fully deployed)
  • The ban list for a group can store a maximum of 500 entries
  • Group Owners cannot be banned
  • When a user is banned from a group, their viewer version does not matter; they will be ejected and banned whether or not they are also using a viewer with the group ban ability
  • Additional notes on the capability can be found here.

The code is initially being deployed to the LeTigre RC, and the remaining RCs and the main channel will follow in due course.

There is currently no formal release of a project viewer able to use the group ban functions available via the Alternate Viewers wiki page. According to Baker Linden, speaking at the Simulator User Group meeting on Tuesday June 3rd, the project viewer will most likely be formally released once the server code is fully deployed across the grid.

Group bans provides the ability to ban (and remove, where appropriate) people from a group. The Group Bans prject viewer contains the necessary updates to manage the ban process.
Group bans provides the ability to ban (and remove, where appropriate) people from a group. The Group Bans project viewer contains the necessary updates to ban individuals or lists of people from a group (whether or not they are already members of the group) and to view the names / dates of all those banned

However, those wishing to test the capability can obtain the current version of the project viewer (Windows / Mac / Linux). If you opt to do so, please keep in mind that until the server-side functionality has been fully deployed across the main grid, group bans will only be enforced by simulators which support the feature.

This means that user who was banned from a group may still be able to join or re-join the group by moving to a region running on a channel which does not currently support the group bans. This may  result in them appearing on both the Members List and the Banned Residents list, so once the project has gone grid-wide it might be necessary to either eject or re-ban them once more.

I’ll be providing a complete overview of the group ban function once it has been fully deployed to the grid and the project viewer is officially available via the Alternate Viewers wiki page.

SL projects updates 22/2: LSL functions for materials avialable for Aditi testing

Posted on by Inara Pey

Maestro Linden used the Server Beta meeting to announce that Simon Linden’s work on adding some LSL support for materials is now available for testing on Aditi.

Regions roller-test102 and roller-test103, both on channel DRTSIM-253, have the server-side scripting support (note the SLurls are for ADITI).

Please note that this is very much a work-in-progress, and the Lab’s own testing is still underway.

The following details can also be found on the Server Beta Meeting wiki page.

LSL fucntions for handling materials
Parameters have been added to the llSetPrimitiveParams() and llGetPrimitiveParams() functions to enable scripted control of materials maps

Materials can be added to object faces with llSetPrimitiveParams() functions using the following parameters:

  • [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]
    • Valid alpha_mode options are PRIM_ALPHA_MODE_NONE, PRIM_ALPHA_MODE_BLEND, PRIM_ALPHA_MODE_MASK, PRIM_ALPHA_MODE_EMISSIVE

Materials can be read with the various llGetPrimitiveParams() functions using the following parameters:

  • [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Additional Notes

  • Behaviour for both getting and setting materials parameters should basically correspond to behaviour with PRIM_TEXTURE
  • The color vectors use 0.0-1.0 as the range, as with llSetColor()
  • The integer parameters for PRIM_SPECULAR correspond to the same values that you see in the build tool
  • Components of a material can be ‘reset’ as follows:
    • PRIM_NORMAL and PRIM_SPECULAR settings are set to default values by setting the texture to NULL_KEY
    • PRIM_ALPHA_MODE settings are set to default values by setting the alpha_mode to PRIM_ALPHA_MODE_BLEND – mask_cutoff is actually reset to 0 unless the alpha mode is PRIM_ALPHA_MODE_MASK
    • When PRIM_NORMAL, PRIM_SPECULAR, and PRIM_ALPHA_MODE settings are all set to default values, the material is deleted from that prim face, and LI may be updated accordingly
  • This new scripted capability will only work on the nominated test regions
  • ALM must obviously be enabled.

Known Issues

  • The version currently on Aditi lacks proper throttling, so there could be performance issues if scripts behave badly. A throttle will be added in due course
  • There is a viewer rendering issue, where the face will not be rendered and you’ll see log spam (BUG-6187). This can happen:
    • If the viewer has ALM enabled
    • And a prim face has a material on it
    • And PRIM_ALPHA_MODE is PRIM_ALPHA_MODE_BLEND (this is the default after a material is added)
    • And the diffuse texture does not have an alpha channel (e.g. plywood)

With reference to BUG-6187, Maestro added, “One thing to keep in mind …  is that if your diffuse texture lacks an alpha channel, you’ll also want to set the alpha mode to PRIM_ALPHA_MODE_NONE to avoid the bug, even if you really just want to add a normal map.”

The bug itself doesn’t mean the alpha mode should be set every time a materials map is changed, only when adding a material to a face which previously didn’t have a material. Maestro went on to give some further information on the issue:

What happens when you add a material via the build tool, is that the viewer inspects whether the current diffuse texture has an alpha channel and automatically sets the alpha mode to ALPHA_MODE_NONE if the diffuse texture is opaque, but keeps it at _BLEND if there’s an alpha channel. Unfortunately, the simulator can’t do this, because it doesn’t necessarily have the texture asset and doesn’t have the right libs to process texture assets in that manner. The build tool has some trickery where it always greys out the UI for alpha mode when the texture doesn’t have an alpha channel. Anyway, it’s kind of a hassle, but once PRIM_ALPHA_MODE is set to something ‘friendly’, you should be able to update normal or specular settings without touching it again.

As this is a viewer rendering bug, there is no timescale as to when a fix may appear.

The Lab is particularly interested in seeing how use of these new parameters may affect performance (such as through rapid and repeated changes to maps), and what kinds of rates cause these issues, so that they can more accurately assess the required level of throttling.

Depending upon how further testing goes, what additional changes the Lab needs to make, and what has already been scheduled at the time, these updates might be available on an RC on Agni in a few weeks.

SL projects updates week 22/1: LSL functions for materials, group bans

Posted on by Inara Pey

It’s a light start to project news from the lab this week.

Server Deployments Week 22

There are currently no planned deployments for the week.

Materials LSL Functions

There’s still no firm date for when this are liable to surface for testing, but speaking at the Simulator User Group on Tuesday May 27th, Simon Linden indicated the time is getting “closer”. In the meantime he re-iterated the get and set functions currently being worked upon, which remains as per my week 21 report, namely:

Get functions:

  • [PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:

  • [PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
  • [PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
  • [PRIM_ALPHA_MODE, integer face, integer alpha_mode, integer alpha_cutoff]”

The same access rules will apply to materials as for diffuse (texture) maps.

Most people may already be aware that llSetTextureAnim() will apply an animation equally across all three maps applied to an object / object face. However, the Lab is not currently looking to add additional parameters to llSetTextureAnim() so that each type of map independently of the others. Offering an explanation as to why this is the case, Simon said:

I’m guessing that would be pretty ugly to implement … or would need some careful design and thought as it couldn’t create new material entries under the hood.  I think that will have to be a follow-on feature … I can imagine it might create some cool effects but it would have to be carefully done not to blow up the materials accounting.

Group Bans

Simon indicated that the remaining back-end server updates for the group ban service may have been deployed on Tuesday May 27th. If so, it is possible that an initial server-side RC deployment of the group ban code might occur in week 23, together with the appearance of the group ban viewer. however this is pure speculation, and depends on how long the Lab want to let the back-end updates run prior to making a visible code deployment. More is likely to be known following the Server Beta meeting later in the week.

SL projects updates 21/2: grid issues, server updates, viewer

Posted on by Inara Pey

Server Deployments week 21 – Recap

On Tuesday May 20th, the Main (SLS) channel received the server maintenance package deployed to Magnum in week 20.This includes a bug fix for a networking-related issue that sometimes affects busy sims. Issues encountered during the deployment, but unrelated to it (see below) meant it had to be curtailed.

As a result, the Main channel deployment resumed on Wednesday May 21st, with the result that the deployments scheduled for the 21st in fact took place on Thursday May 22nd, as follows:

  • The BlueSteel and LeTigre RCs remained on the Sunshine / AIS v3 server-side code, and received the networking-related bug fix deployed to the Main channel
  • The Magnum RC received a new project, which includes changes related to the ‘Experience Tools’ project.

More on the Log-in and Grid Issues, Tuesday May 20th

Simon Linden identified the issue which caused log-in issues on Tuesday May 20th
Simon Linden identified the issue which caused log-in issues on Tuesday May 20th

During the Server Beta meeting on Thursday May 22nd, Simon Linden, who identified the problem, gave a further explanation of Tuesday’s grid issues, which prevented people from logging-in to SL.

Essentially, the log-in server was failing to give the viewer the correct token for it to connect to a region, so people actually got through the log-in phase when starting their viewer, but never connected to a region. “The conversation between the login server, your viewer and the region didn’t work any more,” Simon said.

Maestro then added, “After logins were restored, there was a period where the inventory servers got pretty ‘heated up’, probably from people logging in after hours of downtime, so inventory was bad for an hour or two.” It was apparently at this point that the decision was taken to suspend the Main channel server deployment and resume the work on Wednesday May 21st, pushing the RC updates into Thursday.

It is not anticipated that the problem will recur now it has been identified and rectified.

As a result, the scheduled maintenance that had been planned for Thursday May 22nd was cancelled. This work has yet to be rescheduled, and is apparently to be focusing on the database hardware. “Sims should have slightly faster access after the maintenance,” Maestro said of the work, “though I wouldn’t promise anything major.”

The Grid Status page will carry the revised date and time of the work once it has been rescheduled.

SL Viewer

As noted in these pages, The Lab released its Oculus Rift project viewer to the public on Wednesday May 21st, with an announcement in the main blog. The viewer, version 3.7.8.289834, is aimed at getting people started on using the Oculus Rift in Second Life, rather than at providing a finished product with UI optimisations, and appears to be aimed towards encouraging early adopter of the Oculus Rift to try-out Second Life.

Also on Wednesday May 21st:

  • The Zipper viewer for faster installation was promoted from project viewer status to release candidate status with the arrival of the Zipper RC viewer, version 3.7.9.290133 in the release channel
  • The Sunshine / AIS v3 RC viewer returned to the release channel in the form of version 3.7.9.290131, referred to as “Sunshine v2”.

These two viewer updates see the total number of release candidate viewers in the release channel rise to four once more. As also, details of updates in my Current Viewer Releases page.

Group Ban list

One of the required central updates for the group ban updates was deployed to Agni on Wednesday May 21st. A further update is needed before a server RC with the group ban code gets deployed, however. These updates are related to the central service to manage group bans.

 Other Items

LSL Functions for Materials

Not a lot to add here. As mentioned in part one of this report, Simon is now actively working on this functionality. He didn’t have too much to add during the Server Beta meeting, other than Maestro Linden has also been looking at the work Simon has done and has fixed a few issues. There’s still no date when the work might become visible for people to poke at.

LSL Functions for Projected Lights

Talk of LSL functions for materials saw talk of LSL functions for lighting projectors resurface (see SCR-163), prompting Simon to ask, “Does anyone have ideas how people might cause trouble with the projector LSL functions? I wondering how it might cause problems, other than lots of updates … and if it would be any different from rezzing stuff?” Nothing of any serious impact could be identified, although it’s not clear whether the Lab will poke at that or not once the materials LSL functions have been sorted.

Hiding Objects from View and Parcel Privacy

BUG-5671 is actually a feature request, and concerns the provision of a check box in the viewer’s Parcel Properties so that all objects outside that parcel would be not be rendered for anyone within the parcel boundaries. The request appears to be for a server-side function, and the JIRA has seen some heated debate on the matter.

Simon Linden revealed that while working on the parcel privacy option (which hides avatars inside a parcel, and blocks their chat from those outside of the parcel (and vice-versa), he looked at also blocking object views, “and even played with a prototype,” he said. “It’s pretty ugly because you end up with nothing there … at least in my simple code. “Then you walk onto the parcel and all the trees and house and stuff pops up … it was odd.”

However, he revealed the request has been imported by the Lab, so there might be some interest in doing something with it. Part of the debate around the idea on the JIRA has been on whether the setting should be enforced server-side or just within the viewer (so the user retains the choice as to what they see outside a parcel). Commenting on this, Simon said, “server-side would be better so you wouldn’t get updates for things you can’t see, but a cosmetic viewer-side option might be possible.”

So that’s another one to watch out for.

SL projects updates 21/1: server, viewer, LSL and materials

Posted on by Inara Pey

Server Deployments Week 21

Main (SL) Channel

On Tuesday May 20th, the Main (SLS) channel received the server maintenance package deployed to Magnum in week 20.This includes a bug fix for a networking-related issue that sometimes affects busy sims.

Issues encountered on the grid, but unrelated to the new code deployment, interrupted the latter. Commenting on the situation at the (late-starting) Simulator User Group meeting, Simon Linden said, “I believe the rollout stopped in the middle, and things will get patched up tomorrow morning. We’re still picking up the grid pieces and will sort out the clean up plan later in the day.”

BlueSteel and LeTigre RCs

On Wednesday May 21st, the BlueSteel and LeTigre RCs remain on the Sunshine / AIS v3 server-side code, and receive the networking-related bug fix deployed to the Magnum RC in week 20 and to the Main channel on Tuesday May 20th – see here for details.

Magnum RC

On Wednesday May 21st, the Magnum RC should receive a new project, which includes changes related to the ‘Experience Tools’ project.

SL Viewer

The de facto release viewer updated on Monday May 19th to version 3.7.8.289922, formerly the Maintenance RC comprising fixes in Recent tab, Chat, LSL editor, land management, etc; GPU table updates; crash fixes & performance improvements – release notes here.

Also on Monday May 19th, the following RC viewer updates occurred:

  • The Sunshine / AIS v3 RC was temporarily removed from the Alternate Viewer page, but is expected to return soon
  • A new Memplug RC viewer, version 3.7.8.289942 was released, containing a number of fixes for memory leaks which are expected to result in improved viewer performance and a reduction in crash rates.

LSL Functions for Materials

Materials processing: LSL capabilities for materials
Materials processing: LSL capabilities for materials now being looked at

Further to discussions in week 20, Simon Linden had some news on the much-requested LSL functions for materials processing, saying, “I can say I was trying to grief myself with materials LSL functions the other day. I hope we can talk more about that on Thursday at the beta user group.” He went on to outline some of the functions for manipulating materials that he’s been playing with:

Get functions:
[PRIM_SPECULAR, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face] returns [string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face] returns [integer alpha_mode, integer alpha_cutoff]

Set functions:
[PRIM_SPECULAR, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians, vector color, integer glossy, integer environment]
[PRIM_NORMAL, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians]
[PRIM_ALPHA, integer face, integer alpha_mode, integer alpha_cutoff]

He went on, “There is a magic default value using NULL ids that represents “no material” … so it can be removed.”

Simon also indicated that at some point soon (no date as yet), there will a few regions (most likely on Aditi, the beta grid) to try-out the new functions with the aim of seeing how the capabilities are used, how they get abused and then how SL behaves, so that some appropriate limits can be imposed to prevent deliberate or accidental abuse.

Other Items

New Mesh Avatars and the AMD/ATi Issue

On Thursday May 15th, Linden Lab launched their line of new mesh avatars to something of a mixed response. Unfortunately, said avatars may have fallen a-foul of a long-standing  rigged / fitted mesh rendering issue affecting people used AMD / ATi graphics systems with recent Catalyst drivers, and which sees rigged / fitted mesh stretching to the 0,0,0 coordinate of a region – see BUG-6065, which offers advice on circumventing the issue.