Received Items: the good, the bad and the “$%^&*!”

So, as I was updating the Viewer Round-up for this week, I thought I’d have a run with the new Received Items Beta launched last week.

Those familiar with Direct Delivery testing will already be somewhat familiar with Received Items – it is a section of the Inventory floater wherein anything purchased from the Marketplace will show up. However, the overall functionality has now been extended so that anything you obtain or receive by way of a “new” inventory item will pop-up within it.

To test the new functionality, you’ll need to run one of the following versions of the official Viewer: the Beta (3.2.9.249510 or later), Development (3.3.0.248913 or later) or the Direct Delivery Project Viewer (3.3.0.249395 or later). For testing, I used the latest Beta, 3.2.9.249510, which has been available since before the Received Items Beta was announced, but which has the Received Items capability available within it.

You’ll need to be on the Beta grid (Aditi) to carry out the tests, and will need to visit one or more test regions, as detailed in the Received Items Beta wiki page and my original blog post on the subject.

Where to Find the Panel

I’ve read reports of people having problems finding Received Items. It should appear as a “button” at the bottom of your Inventory floater. Clicking the “button” will open-out the panel.

Opening Received Items

If, for any reason, the button is not apparent within your inventory floater, try this (with thanks to Innula Zenovka):

  • Go to the Fast Return test region on Aditi (this is the LIGHTER GREEN area within the GC Test 9 region)
  • Rez a prim and wait for the auto-return to send it back to you – it’ll take around a minute
  • Open your inventory floater and the Receive Items “button” should now be visible – click on it to open it as described above, and your prim should be sitting inside it

I spent an hour or so playing in the test regions to see what Received Items does / does do, and here’s a summary of my findings, together with some broader observations and feedback.

Situations where there is no change to current behaviour

  • Rezzing an item from inventory – the item will still return to its originating folder when you TAKE it back
  • Taking a copy of a rezzed object you own will still return it to your Objects system folder
  • Trying to rez / build in a no rez area will generate the usual warning without anything being rezzed / returned
  • Trying to move an in-world object into a parcel with NO OBJECT ENTRY set: item will be blocked and the usual pop-up displayed

Situations where Received Items IS used

  • Creating a new object or linkset and taking it to inventory
  • Taking a copy of an object belonging to someone else (permissions allowing
  • Purchasing / taking anything from an in-world object (prims set to give / sell, Vendor systems, etc.)
  • Anything returned to you manually by someone else, or via parcel auto-return
  • Anything someone else gives you in-world
  • Items sent to you while off-line
  • Multiple items in a single delivery (e.g. items from a suitably scripted giver or passed to you via folder)
  • Anything you purchase via SLM or which is brought for you as a gift.

Other points of note

  • When receiving items via a transfer when on-line, you will still receive a pop-up notification – but without the ACCEPT button, which has been replaced by SHOW – clicking this will open your inventory floater and the Received Items panel. The remaining options, DISCARD and BLOCK remain unchanged
  • If you are offline when an item is sent, you’ll still get a notification sent (which will appear when you log-in and get sent to your e-mail, if you have IM forwarding set-up) as per current behaviour
  • Recently received items tagged as “New” (click to enlarge)

    Recently received items will be tagged as “New” in Received Items, helping with identification (right)

  • Received Items provides almost the same degree of functionality for items it contains as the rest of your inventory. However:
    • You cannot directly rename items (i.e. right-click and select RENAME from the menu), although you can select the item’s Properties and rename it from there, if permitted
    • You cannot paste a copy of an object into Received Items (but you can obviously paste it into your main inventory panel wherever you like)
  • If you delete items from Received Items and they will go to your Trash, as usual. However, if you subsequently restore an item from Trash that was in Received Items – it will go to the most appropriate folder in your inventory (so a notecard will be restored to Notecards, a landmark to Landmarks, etc.)

Received Items as a Folder

Received Items seen as a folder in the RECENT tab (click to enlarge)

For those that like to use the RECENT tab in inventory, it is worthwhile pointing out that Received Items also appears here as a folder (although there is no corresponding folder in the main inventory view). The folder view has the same functionality as the panel, but offers an alternative way of viewing incoming items. The major difference between the two is, when viewed as a folder in the RECENT tab, Received Items does not display “New” against recently received items.

However, this will only last during your current SL session – as soon as you log-out from SL, the “Received Items” folder will vanish from RECENT, just like everything else, leaving you with just the Received Items panel to peruse the next time you log-in.

On the good side

Providing a single “point-of-entry” for new items coming into inventory may well ease the process of understanding how works inventory and getting newcomers started on good inventory husbandry and may encourage those who don’t engage in inventory  housekeeping to do so… Which is not to say this new approach is without issues or necessarily preferable. Right now, it has to be said the negatives outweigh the positives.

On the poor side

There is no hierarchy to Received Items: Outside of items that are received into folders via their delivery mechanism (e.g. SLM or a scripted object), Received Items presents a “flat” view of incoming goods. This is liable to create a headache for some.

For example, many in the rental business put-out “for rent / sale” signs on their vacant parcel, and may add trees and other bits and pieces – up to and including houses and sim extenders on the parcel as well. Some or all of these get returned by the new tenant when the parcel is rented – and until now have gone to the Lost and Found folder, where they can be easily identified and disposed of.

But under the new system, all this now gets lumped-in with everything else the Estate Owner / Manager is receiving as well. This could get very onerous in terms of sorting through stuff and separating the wheat from the chaff.

There is no capability to sort / order / filter items: Obviously, the intention is for Received Items to be routinely cleared-down by users on receipt of incoming goods, no matter what the source. However, there are going to be times when – even with the best intent in the world, the Received Items panel is going to run the risk of getting choked  – such as in the case of estate management as mentioned above, or where information is specifically requested via notecard (such as requests for product help) and so on. Even someone being away from SL on vacation for a week or to could come back to find their Received Items brimming. As such, it would be nice to offer people the ability to sort / order / filter contents.

Creates an artificial divide in inventory: The Received Items panel does tend to split inventory into two, and unless it is clearly and properly explained to the likes of new users, it could end up creating as main problems as it is intended to solve, particularly if new users are no encouraged to use it as intended, but simply allow incoming items to reside in the panel. Communication is the key here – and that’s not really LL’s strongest suit.

(Currently) does not appear to solve the capped IM problem: I have read from feedback elsewhere, but have been unable to verify myself, that this new approach doesn’t presently overcome the problem of goods failing to be delivered if IMs are capped. Whether this is because the code itself doesn’t contain a “fix” for doing so, or whether it’s actually not working as hoped, I can’t say. However, this is causing concern, and may still need to be addressed.

Opinion

There has been a lot of negative feedback from users on this new approach. Whereas Received Items was accepted for the forthcoming Direct Delivery system, people are questioning why everything now has to go into Received Items, rather than the more intuitive approach we currently have.

I personally can see both sides of the coin: as an established user, I’m very familiar and comfortable with the current behaviour – notecards coming in go to Notecards, landmarks to Landmarks, and so on. As such, I can only see this approach as being something of a step backwards – and I’m someone who is pretty obsessive about keeping my inventory sorted.

However, for new users, then the system – again with the caveat of “as long as it is properly explained” – offers a much easier-to-understand approach to the receipt of goods and items. At least initially. There is also the fact that it does present (or should eventually present) one consistent mode of behaviour for new items entering inventory – and consistent can be often be good.

The problem really is that this approach is one in which – yet again – established users appear are being faced with something that is definitely less intuitive and potentially useful than the current system in order to “improve” matters for the ever-elusive new user. Even for those (like me) who are obsessive about keeping inventory sorted, this approach adds an irritating additional level of management, simply because we do now have to faff around moving various received items around that once pretty much took care of themselves in the first instance.

As such, Received Items does run the risk of leaving people with the impression that the existing user community simply doesn’t figure in LL’s thinking, and how we use SL on a daily basis simply isn’t really understood. I could say more on that topic, but Saffia Widdershins already has, and very eloquently.

Related Links

Viewer release summary 2012: week 8

Updates for week ending: 26 Feb, 2012

This is intended to be a weekly round-up of current public SL viewers (of which I’m aware). Links to my most recent reviews of said viewers will be included, but may not reflect the current release. As few Viewers are static, and releases are made according to individual development cycles, further versions of any given Viewer may well be released between these updates, and as such the information here may become out-of-date as the week progresses. Please check with the relevant download pages.

Changes since the last round-up shown in green.

SL Official Viewers

Available for: Windows, Linux, Mac

V3.2-based TPVs

V1-based TPVs

  • Cool VL version 1.26.2.19 (stable) / 1.26.3.8 (experimental)
  • Imprudence version 1.3.2 (stable) / 1.4.0 (beta 2)
    • Released: 1.3.2 – May 18th, 2011; 1.4.0 – Sept 25th, 2011 (download page)
    • Available for: Windows, Linux, Mac
  • Phoenix Version 1.6.0.1600
  • Singularity version 1.6.0.3

Related Links

LL update their TPV Policy

Linden Lab have issued an update to the Third Party Viewer Policy, and it is causing something of a stir.

The key additions to the policy are sections 2.a (iii), 2.i, 2,j, and 2.k. These were discussed during the Viewer development meeting, and additionally announced via a blog post which followed the meeting.

Each of the clauses are given below together with key bullet points for each of them taken from Oz Linden’s presentation given during the Viewer Developer’s meeting. An audio transcript of the entire meeting is also available on-line.

Privacy Clauses

Three of the four new clauses (2.a.(iii), 2.i and 2.j are related to privacy issues.

2.a.(iii): “You must not provide any feature that circumvents any privacy protection option made available through a Linden Lab viewer or any Second Life service.”

  • Any privacy protection options that are coded into the Viewer cannot be removed, but must be implemented within a TPV in a compatible manner
  • This does not in any way limit or impact the use of client-side radar tools
  • If there is a feature in Profiles, a Second Life Service or the official Viewer which says, “I do not wish people to see this about me”, then the function cannot be overwritten or ignored
  • Directly affects “on-line truth” tools, whether built-in to a Viewer or scripted via LSL (llRequestAgentData())
    • The function will be altered such that it will only return true presence data if the script or object containing the script is owned by or created by the subject of the request
    • When the change is made, it is anticipated that any scripts using the function will simply return a false value (unless the subject is the owner or creator) rather than breaking
    • Objects like club or store-based on-line indicators will still work, providing they contain scripts created by the individuals whose status is being checked
  • For Viewers such as Phoenix, which include the functionality within the Viewer code, it means the capability will be removed in the next update (via Jessica Lyon in a Phoenix Viewer blog update)
  • The code change is in development, but LL do not currently have a release date for it
  • There is a possible use case situation with regards to sandbox tools (and similar) that run a check to see if a person is still within the region prior to requesting / running a clean-up of their prims, and this will be investigated for impact

2.i: “You must not display any information regarding the computer system, software, or network connection of any other Second Life user.”

2.j: “You must not include any information regarding the computer system, software, or network connection of the user in any messages sent to other viewers, except when explicitly elected by the user of your viewer.”

  • These more-or-less directly applies to Third Party Viewer client tags
  • A region update scheduled for next week (Tuesday / Wednesday) will be break the tagging system for all Viewers
    • The changes to be implemented will also break people’s abilities to set colours against the tags they see in their own world view
  • These clauses do not impact the ability for a TPV to include a check box users can use to specify their Viewer within, for example, Group chat (again as is the case with Phoenix / Firestorm support, as such a system in “opt-in”
  • An “opt-in” capability for people who wish to display their Viewer tag will not be allowed
  • These  clauses do not prevent people from voluntarily adding the name of the Viewer they are using to a Group tag

Shared Experience

2.k: “You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer.”

This is the hardest clause to summarise, and the one that presents the greatest number of issues.

Essentially, LL are ring-fencing certain aspects of Viewer development – a move which is liable to stifle a degree of innovation within TPVs. To help understand the clause, Oz cited a couple of examples of what the clause isn’t directly about:

  • The clause is not about different ways of presenting the world – so things like an improved renderer, such as seen in the likes of Niran’s Viewer or Exodus, is not (to quote Oz), “A big deal”
  • The clause is not about changes to control mechanisms – so if someone develops a new means of moving objects in-world, that’s not an issue providing the way in which the object moves is seen to be the same no matter what Viewer is used by anyone witnessing the object in motion
  • The clause is intended to prevent is having a Viewer change the manner in which objects and / or the world behave without working in concert with Linden Lab.
    • As an example of this, Oz cited the old “second attachment” system initially seen in the Emerald Viewer, in which objects additionally attached to an avatar using Emerald’s secondary attachment point (“hand 2”, “shoulder 2”, etc.), would present “correctly” to other users of the same Viewer, but would not be presented correctly to anyone using any other Viewer (they would generally appear to be trailing along behind the wearer’s bum)
  • In terms of developing such “shared experience” features within the Viewer, Oz said: “That’s fine, that’s good. But you have to do it with us, and we have to get it into our Viewer and then propagate it out from there.”
  • Linden Lab is working hard to improve its responsiveness to Viewer shared experience feature requests and to better engage with developers – Qarl’s Parametric Deformer was cited as a case in point
  • However, if a shared experience feature is rejected by Linden Lab, then it cannot appear in any TPV used on Second Life
  • LL hope to “work as fast as we can” to get things done on the server-side, and then work as fast as possible with TPV developers to get things done on the Viewer side
  • LL request that in order to make this work, that TPV devs work on the LL code base rather than their own code when it comes to shared experience functions
  • The stated reason behind the addition of this clause is (51:06): “We have observed user confusion and problems that result from  the fragmentation of the experience depending upon what Viewer you are running. And we think that all users should have … fundamentally the same world to be in, regardless of which Viewer it is.”

Thoughts on the Changes

I’ll be honest and say that the first three changes to the policy leave me in a neutral frame. The proposed changes to llRequestAgentData() strike me – admittedly a non-coder – as fair and reasonable and that they should overcome issues relating to fear of breakages.

TPV tags (and colours) are something I’ve never had an interest in, and while I can see cases where they are useful, I don’t actually see their removal as that big a loss. Certainly, when it comes to the issue of user harassment based on Viewer usage, I will say that Oz is not the first person I’ve heard this from; much the same has been said in TPV development circles – so eliminating tags could be a good thing.

The final clause, 2.k, on the subject of “shared experiences” is proving to be the real kicker however, stirring a lot of reaction – most of it negative.

I actually find myself sitting in the middle of the road somewhat when looking at it. Which probably means I’ll get run over from both directions…

On its own, the idea of ensuring all users are presented with a world that behave predictably the same way not matter what Viewer is in use, and with which users are assured they are seeing and sharing the same experiences as those around them are seeing and experiencing, is fair enough. There is actually a lot to be said for the approach in principle –  as was said in the meeting, “It doesn’t help anybody, really, if someone implements a feature half-arsed … in whatever manner they can manage without the proper back-end support, versus the whole feature getting a project and … get proper back-end support and get it on-line properly for everyone at once, versus it getting half implemented and getting used, say like, by half the grid instead.”

There is also the fact that Linden Lab has, as a company, changed somewhat over the past year or so. While they do still have problems within and of themselves, the fact is that they have become more responsive, are putting more time into the platform, dealing with issues and working hard to bring the Viewer on. They’ve responded to user irritation with the V2 / V3 UI, they’ve taken-on feature development such as region Windlight settings (whether this is a result of Viewer parcel Windlight settings or hasn’t quite been implemented as some hoped isn’t entirely relevant – the point is, the Lab responded). We’ve seen them begin to solicit TPV developers for help in general Viewer functionality (such as with Kitty Barnett porting and re-coding her Spell Check for inclusion in the official Viewer). As such, when it comes to the company stating they want to work with TPV developers in order to implement accepted shared experience features as quickly as possible, one should perhaps take them at face value.

But in trying to ring-fence specific aspects of Viewer development, Linden Lab risks unravelling what has otherwise been years of highly innovative and beneficial (for users, to the grid and to LL itself) Viewer development which has not only dramatically improved their product as a whole, but which has been able respond to user requests and implement them with a level of flexibility and imagination that Linden Lab cannot hope to emulate, allowing the Lab to remain focused on core issues.

There is a very real risk that this policy change will completely stifle Viewer innovation – or even drive it away from Second Life entirely. One can well understand developers no longer wishing to invest their unpaid time into code and functions that LL might ultimately decide is unsuitable for the Viewer and SL as a whole.

Even if a feature is accepted by Linden Lab, things don’t appear to get any easier for the TPV developers. For a start, the function will have to propagate through LL’s development and release cycle – which means it is at the whim of the Lab’s own priorities well beyond the control of the developer. Then there is the added fact that should LL opt, for whatever reason, to alter the submitted code / function, the TPV also has no choice but to go back and change their original code to match. Finally, even if the code is accepted and percolates through the Lab safely, the TPV developer still can’t release it until after it has reached a release version of the official Viewer. All of which could leave even the most stout-hearted thinking, “Why even bother?”

Of course, it should again be emphasised that clause 2.k doesn’t apply to every function developed by a TPV. As such, it is currently hard to see how this will pan out. Certainly, TPVs are going to have to mull over the revised policy and determine how they are going to respond in terms of their development plans. Perhaps they’ll opt to bite the bullet and move ahead as best they can; perhaps they’ll opt to refocus efforts purely on those aspects of the Viewer that are not affected by clause 2.k.

One thing that is clear is that with Viewer tags due to be broken next week as a result of the server-side changes – something that is bound to bring matters to the attention of a wider public within SL –  coupled with requests for the matter to be discussed at the next developer meeting, this is an issue that will be reverberating for a while to come.

Related Links

Call for Imprudence volunteers – meeting this weekend

When the decision to proceed with the development of Kokua was made, a problem remained for the Kokua / Imprudence team in how to support those users in the wider metaverse who still prefer to use – or even rely on – Imprudence. While the team hoped to be able to bring the 1.4 release of Imprudence to maturity, it was noted that this would only be done if it did not impact work on Kokua.

Following on from this, Onefang Rejected, aka David Seikel who is known to many as the developer of the Meta-Impy Viewer (itself based on Imprudence 1.4) stepped forward with a stated desire to continue Imprudence development.

As a result of Onefang’s willingness to volunteer himself, the Kokua team have opted to bring him into the fold as a team member, where he can hopefully build and lead an Imprudence-focused team that will work alongside of, but independently from, the core Kokua team.

To help establish this new Imprudence team, the Kokua / Imprudence project has put out a call for volunteers, requesting that anyone interested in getting involved in Imprudence as a  developer or tester or some form of support category put themselves forward. Those wishing to join the team are asked if they can attend the next All Hands meeting, which will be devoted to Imprudence and its future.

As ZATZAI (Sean Greyhound) put it in the Kokua blog, “This will not be a ‘reboot’ of the project but a continuation. So for all of you out there who lamented the ‘death’ of Imprudence, here is your chance. Join us this Sunday, be you a potential developer or tester and help us to bring Imprudence into the future alongside Kokua.”

The meeting will take place at the usual time and venue: 12:00 midday SLT (20:00 GMT), Sunday February 26th at the Hoagie sim of the 3rd Rock Grid. Requests for further information should be directed to the Kokua / Imprudence blog.

Viewer release summary 2012: week 7

Updates for week ending: 19 Feb, 2012

This is intended to be a weekly round-up of current public SL viewers (of which I’m aware). Links to my most recent reviews of said viewers will be included, but may not reflect the current release. As few Viewers are static, and releases are made according to individual development cycles, further versions of any given Viewer may well be released between these updates, and as such the information here may become out-of-date as the week progresses. Please check with the relevant download pages.

Changes since the last round-up shown in green.

SL Official Viewers

Available for: Windows, Linux, Mac

V3.2-based TPVs

V1-based TPVs

  • Cool VL version 1.26.2.17 (stable) / 1.26.3.6 (experimental)
  • Imprudence version 1.3.2 (stable) / 1.4.0 (beta 2)
    • Released: 1.3.2 – May 18th, 2011; 1.4.0 – Sept 25th, 2011 (download page)
    • Available for: Windows, Linux, Mac
  • Phoenix Version 1.6.0.1600
  • Singularity version 1.6.0.3

Index of release summaries

Kokua team issues “small update”

kokua-logoIt’s been a little over two weeks since the Imprudence/Kokua team announced they’d be moving towards focusing on Kokua for future development, but work is progressing. On the 16th, ZATZAI (sean Greyhound) from the team put out a “small update” on progress, which reads in part:

Work continues on the new Kokua viewer. We’re moving forward using the v3.2 Linden viewer as a base, we feel this version of the viewer is stable enough and has solved enough of the UI problems from v2 that our users will be happy with it. It’s also what many of you recommended in previous blog comments and at our meetings. We’re currently focusing on releasing a stable viewer on at least three platforms, Linux 32bit, Linux 64bit and Windows 32bit. You can follow our progress by trying our experimental viewers if you’d like, but buyer beware, these are alpha viewers and you should read the warning label carefully before use. You’ll find the link to our experimental viewers page on our wiki below…

There follows a link to the Kokua wiki and links to the Windows and Linux release 3.0.0 downloads. However, before you get too excited, it should be pointed out that while the blog post refers to V3.2, the release available on the wiki, and the one immediately prior to it (0.1.1) are not based on the current V3.2 code, but rather on V3.0 code. Those installing and running either experimental will notice, for example, that the log-in splash screen still has the BASIC / ADVANCED mode toggle button.

Kokua *will* be moving to V3.2, but for now it is still based on V3.

I raised this point with ZATZAI, who was able to confirm after checking that, “The current Experimentals are indeed based on v3 … future ones (I don’t know how soon) will be based on 3.2+.” A clarification on the releases has since been posted on the blog entry itself.

So for those wishing to see a release of Kokua based on V3.2 code will have to wait just a little longer – and should keep an eye on both the blog and the wiki page!

How to Get Involved

For those who are further interested in the Viewer’s development, the team hold a weekly meeting every Wednesday at 20:00GMT on the Hoagie Sim in the 3rd Rock Grid. The meetings are for Dev and Project Contributor discussion and open to the public – although the meetings are not intended to deal with support issues. Transcripts of recent and past meetings cane be found on the wiki.

People can also join the Developer Mailing List (again: please note that this is not intended to deal with support issues).

Related Links