Day: March 11, 2012

Code change impacts RLV functionality

Posted on by Inara Pey

Update 12th March: As can be seen from the comment from Trinity below, Brooke Linden has responded to concerns over this issue, and has confirmed that the code causing it will be rolled-back from LeTigre and BlueSteel this Wednesday (RC channel release window) and won’t be re-deployed until the problem is fixed.

Kitty Barnett reports via JIRA SVC-7748, that functionality related to the InventoryAPI maintenance project adversely impacts the widely used RLV / RLVa functionality within Second Life.

RLV provides a means by which, and under controlled conditions (the user “opts-in” to the process by clicking an acceptance button), a folder is created within the #RLV folder under MY INVENTORY. Items are then delivered into the new folder, wherein a script runs to attach the items to the recipient avatar.

While this functionality does have a direct use within the BDSM community, it can have uses elsewhere as well.  However, changes rolled-out to the BlueSteel and LeTigre RC channels this week as a part of the InventoryAPI maintenance project, have inadvertently broken the functionality – the required redirection to use #RLV doesn’t occur and the associated script fails – hence JIRA SVC-7748.

The degree of impact on RLV is debatable. As Marine Kelley states within the JIRA:

On a positive note, if LL decides not to do anything and leave things as is (i.e. in a broken state), the RLV could simply check what’s coming into the “Received Items” folder and move it automatically under #RLV if the name matches. This would be transparent to the user and would overcome this breakage. 

Nevertheless, it would be preferable for LL to ensure the functionality isn’t broken in the first place (as Marine herself goes on to state).

A potential problem here is that, despite Kitty’s own efforts to point out that Received Items itself is not the problem per se, many of the comments appearing on the JIRA are further critiques of Received Items rather than a discussion of the problem as identified by the JIRA itself.

As strong as feelings are around the subject of Received Items, what is more important here is that functionality that is key to a range of user expectations / desired experiences has been inadvertently broken within LeTigre and BlueSteel, and there is a risk that this could become more widespread if the fix is rolled-out beyond these two RC channels. As such, it is important that LL hear, read and understand the core issue itself (i.e. via use-cases where the update breaks things), in order for them to try to correct the matter.

Given it is the weekend, it will likely be a while longer before any response on this matter is heard from LL – which also gives people more time to submit specific examples on the issue that outline the problem. It’s also worthwhile pointing out that LL are prepared to reconsider proposed actions – as has been demonstrated around the concern relating to llGetAgentStatus (which Oz has indicated is on-hold as a result of the number of clear-cut use-cases received), and have shown a willingness to re-think elements of Received Items based on constructive feedback from users.

Received Items: LL provide feedback

Posted on by Inara Pey

On March 1st, due to the level of concern arising from the initial beta, LL put out a call  for feedback in the form of a short survey (now closed). This weekend they provided feedback to those who participated in the survey in the form of a proposal on how the new functionality might be improved and a further request for people’s views on the proposal itself.

The notice of feedback came through a notecard from Brooke Linden which was delivered in-world via Dakota Linden. The notecard reads:

Hi all,

We’d like to thank you for your feedback on the use of the Received Items folder. Based upon the feedback, we have pulled together a similar, but hopefully improved, proposal. Please take a look and provide feedback.

After which there are links to the proposal and an additional survey.

The proposal offers the promise of some improved functionality over the initial beta, including:

  • Context-sensitive menus within Received Items that allow you move specific asset types directly to their system folder OR to the Objects folder (so that notecards can be moved directly to the Notecards folder, landmarks directly to the Landmarks folder, etc.), without the need to drag-and-drop manually
  • Selecting multiple items (as opposed to folders) within Received Items will display a similar context menu allowing the items to be moved to an appropriate folder or to the Objects folder
  • Selecting multiple folders will display a menu presenting options to move the folders either to the Objects folder or you MY INVENTORY root folder
  • The promise to “fix” current issue around offline delivery problems through the use of the Received Items folder.

There are a number of other changes outlined, some of which LL are requesting specific feedback against (for example: they are proposing capping the number of items a resident can receive in an hour to prevent the system being used for griefing, and they are looking for suggestions as to a reasonable number at which to cap hourly deliveries), as well as instigating measure that are presumably aimed at getting people to manage Received Items: such as blocking the ability to rez items directly from the panel (which may actually become a floater in its own right).

Overall, the proposal is a step forward compared to the initial beta system, but it is unlikely to address all concerns – which is why open feedback via the JIRA and on blogs / the SL forum relating to specific concerns remains important. However, what is being offered in terms of context menus, the ability to search (and hopefully sort) Received Items does make the idea something of a stronger offering, and if the system does solve issues around failed deliveries, etc., then that alone might well outweigh some of the shortcoming people might otherwise feel the system has – although there are still potential problems that need to be addressed.

It will be interesting to see how the RI project develops, and whether there are further revisions based on the feedback given to the new survey – and whether all the ideas outlined in the proposal are implemented. However, what is really important within this process is the fact that LL are demonstrating a willingness to pro-actively engage with the community and seek solutions where a fundamental change in the way most people work with SL is seen to be counter-intuitive to the ways in which people use the platform, or which seemingly fails to offer any significant advantages over current capabilities – and this is to be applauded.