TPVP changes – Oz provides further explanation, Tateru gets answers

As concern over the latest TPVP changes continues, Oz has offered-up additional information on what section 2.k in particular means, and how it affects TPVs is terms of official Viewer releases, etc.

In a comment on the thread Questions about new TPV policy initiated by Cummere Mayo, Oz states:

Thanks for taking the time to pull your questions together, Cummere. I know a number of others have had similar questions, and I wanted to take a minute to address them here. I hope this will help clarify things.

1) What is meant by shared experience?

Making a simple statement that covers all possible cases is not easy … there is an unavoidable element of judgement in interpreting this rule; I’ll try to answer below, but that should not be taken as modifying the policy itself.  We will certainly help developers with proposals to understand whether or not a feature might fall under it.  It’s worth noting that the vast majority of all changes made by third-party viewers have certainly not been a problem.  The fact that there have been some problems in the past motivated our adding this rule so that in the future developers would work closely with us to prevent any more like them.

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

2) What counts as the latest released Linden Lab viewer?  Do the Snowstorm and Beta viewers count as released?

The Release viewer is the benchmark, but the difference in time is normally quite small (a few weeks).  If the relative release schedules of our viewer and that of some TPV are causing a problem, then we will discuss making allowances for that if the stability of the feature makes that a reasonable thing to do.  The whole point of the Development and Beta viewer builds is to test things – which implies that those tests may reveal the need to modify the feature, potentially including changes that would not be compatible with the earlier version, so the likelihood of this kind of problem would have to be taken into consideration.

3) Does this mean systems like RLV and integrated AO’s are no longer allowed?


4) Does this mean that third-party viewers may no longer experiment with and help test new features?

No – if the feature would fall under the 2.k rule, then it is faster and easier for everyone if the primary development and testing of it be done based on the common upstream code we make available to everyone, but parallel work by developers in test versions (not the default downloads) of TPVs will usually be ok as long as everyone (including the users of those test viewers) understands that the feature may change in incompatible ways, or even in an extreme case be withdrawn (such as if it is found to be harmful in some unresolvable way).

5) Does this mean that text only viewers or “voice only” viewers would no longer be allowed?

No – failing to provide a common feature is not the same as adding a new feature.   Users who choose to use such viewers are making a choice that is up to them. 

In terms of impact on TPV, the core paragraphs are:

A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.  

This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.

These give unequivocal clarification to a misunderstanding I’ve seen posted on a number of blog commentaries: that UI changes developed by TPV are unaffected by the policy update. To be fair to Oz, he made this very clear in the meeting last week when the changes were announced – but some commentators still seem to have the wrong end of the stick when it comes to UI changes.

To put it simply: the policy changed doesn’t impact on things like revised Build floaters, additions to the Snapshot floater (to upload to Flickr, for example) and improved Camera control floaters, etc. Similarly, things like object derenders are well outside the scope of the policy, as is the ability to audio or visually mute others (which is a concern I’ve seen raised elsewhere, despite the fact it is LL themselves who are introducing Visual Auto-mute), so people have no reason to worry on these scores.

I still find “shared experience” as defined in the policy itself to be far too vague – Oz’s clarifications notwithstanding; and it is the policy that will be used as a yardstick, not additional comments in a forum which may well be lost in archives over time. As such, it would be useful if wording such as Oz gives in the two paragraphs above were cited within the policy as examples as to where the line is drawn.

Better yet, I’d like to see the Lab take-up Tateru Nino’s suggestion. Over on her blog, she publishes the answers she has had to date on the policy changes (and if you’ve not read them, I urge you to do so). In particular Tateru suggests:

A well-documented baseline feature-set, that content-creators could refer to with confidence, would make a lot of sense, and probably be of broad utility and benefit…

Which is an excellent suggestion. Such a baseline document doesn’t have to be within the TPVP itself. LL have a wiki, and it could be placed there as a part of resources for TPV developers or those wishing to get into TPV development – as long as the policy provides a link to the baseline,then the needs of the policy are served and people get a clearer understanding as to what is “allowed”, etc.

Tateru’s piece raises the spectre of enforcement – and Section 8 of the policy is somewhat vague to the point of unpredictability, as Tateru states. It was an issue back when the policy was first introduced, and these latest changes bring those concerns back into focus. Again, providing an outline set of exceptions (say, alongside the baseline feature-set mentioned above) would go some way to further focusing developer’s thoughts and people’s understanding.

That said, and in fairness to LL, where problems have occurred with TPVs over the past few years, they’ve made every effort to sit down and discuss issues with the developers concerned, and provided opportunity and time for ways to be mended rather than simply dropping the hammer. As such, I doubt that they are going to stop any such dialogue as a result of these policy changes which may be required in the future. Again, as I’ve said elsewhere, LL isn’t the malicious ogre as can sometimes be portrayed.

I still have concerns that section 2.k will have an adverse affect on broader Viewer innovation than perhaps the Lab anticipates – which is not so say I don’t understand the reasons for the Lab taking this step (which Oz also moved to clarify in part in a comment he made in reply to my original piece on the policy changes). Hence why I feel that were the Lab to take one or two additional steps in the matter and provide a baseline functionality document, together with some examples of  potential exceptions that might cause problems (with any required caveats about such a list not necessarily being  complete, etc.), would actually help the wider audience of concerned SL users understand what is happening and why, as well as providing TPV developers old and new with a more solid foundation for their work going forward.

Related Links

Catznip R6: purring along

catznip logoJust as I pushed out the weekly Viewer round-up, Kitty and the gang slipped out Catznip R6, which nicely compliments (and perhaps complements!) R5. My timing sucketh.

R6, based on LL 3.2.7 code, is a maintenance release that fixes a range of bugs and gives Group management some love and attention and well as adding other nibbles to enjoy.

Changes to Group Notices

If you’re constantly pushing out Group Notices, you’re liable to like this. You can now create a Group Notice without having to open Group information first. Simply display your Group list (COMMUNICATE->GROUPS or CTRL-SHIFT-G), right-click on the name of the Group for which you wish to create a notice and select CREATE NOTICE. You can still create Notices in the usual way as well – via the Group information floater itself, but the menu option is liable to be a timesaver.

Nor does it end there. Rather than being confined to the Group floater, the Create Notice option now gets a floater of its own, meaning that when used with the new menu short cut, less screen real estate is used-up. All the functionality associated with raising a Group Notice is retained, and the floater can be resized to suit your needs while writing.

New Group Notice floater (shown here being opened the “conventional” way)

Viewing a Group’s archive of Notices is now also easier, thanks to another addition to the contact menu: simply right-click on a Group in your list and select VIEW NOTICES to immediately display the history of recent Notices for the Group in the Group floater.

Staying the Groups, the Group toast has been reworked for greater clarity with:

  • The details of the notice sender and Group are now displayed on separate lines and are clickable – clicking the Group name will open the Group’s profile; clicking the sender’s name will open their personal profile
  • The number of visible lines in the Notice has been increased from 7 to 10 for better readability
  • The date is displayed in a smaller font to provide better separation between it and the notice title and the main body of text.

Finally, Groups get a handful of bug fixes, as detailed in the release notes.

Windlight Updates

R6 brings with it additional Windlight options and a nicely cleaned-up list (WORD->ENVIRONMENT SETTINGS->CUSTOMIZE MY ENVIRONMENT->FIXED SKY) which includes creators’ attributions wherever possible, which is a nice acknowledgement to see. TBH, I can’t specify which of the list are new – as I’ve never actually looked at what was there to start with in Catznip (shame on me, I know), but the release notes refers to them as a “huge stack”, so there should be a lot for regulars to enjoy.

Elsewhere there are nips and tucks – the delay that may be experienced when right-clicking and . or editing an object has gone, so menus, etc. immediately respond, issues around the multi-line chat freezing the word view have been corrected, etc.

Chat also sees any character opening the chat bar or focusing on Nearby Chat when WASD is set to start typing. All I can say on that is “Three cheers!” As someone who has her WASD set for typing rather than movement, the tendency for some Viewers to ignore various keys has been a source of considerable teeth-grinding…

As updates go, this may well appear to be a small one, but it again demonstrates that Catznip remains highly innovative in examining how people actually use the Viewer and its UI on a daily basis and in seeking ways and means to make common tasks easier to access and get on with.

Related Links

Help the Lab help you

The recent TPV Policy changes brought with them the news that the functionality of llRequestAgentStatus, popularly used to obtain someone’s actual on-line status would be changed at some point in the near future as a matter related to users’ privacy.

The ability to determine someone’s on-line status has been the subject of debate for some time now, as evidenced by JIRA SVC-4823.  The JIRA itself has received a lot of attention since the news on the TPV Policy changes broke, which both highlights the level of concern where potentially legitimate uses of llRequestAgentStatus is concerned, but conversely doesn’t help the Lab clearly understand all cases where this is so.

Yesterday, Oz put on a request on the JIRA, thus:

Everyone…. I don’t know if this will help or not, but I’m going to give it a try and see….

We hear what you’ve all said, we understand the issues, and we’re going to discuss what we can and should do about them.

Nothing is final.

We appreciate that Phoenix is moving appropriately to remove the privacy violation from their next release, and hope that they’ll do that soon, but we understand that these things take time.

In order to help us to have a better understanding, I appeal to the many of you who are posting messages that essentially say “I agree – this will be bad for me too” as opposed to describing a specific use case not already described here (and thank you to the many posts that have done a good job describing use cases): please stop with these “me too” posts – they just make it harder to read the full stream (and yes, I at least am reading all of every comment). We know that for every use case there are many users… we don’t need each of them to post something

This is a fair and reasonable request, and while it is understandable the many want to add their name to one or more instances where the function does have a positive use, it’s also essential the LL get a fair chance to establish the how and where and what in terms of what needs to be done in order to avoid causing undue upset or pain in altering the functionality – if indeed this happens.

If you do have a potential user case that hasn’t been listed in the JIRA (or perhaps hasn’t been fully explained), then now is the time to help Linden Lab help you by providing a clear and concise explanation of how the function is used and how altering it could be detrimental to the SL experience. If you just want to add a “me too” comment, without specifics, I would encourage you to consider Oz’s plea and resist the temptation, so that LL stand more of a chance of sifting through the feedback and properly taking all they need to understand into account.

Again, you can reach the JIRA to add your examples by clicking here.

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 ( or later), Development ( or later) or the Direct Delivery Project Viewer ( or later). For testing, I used the latest Beta,, 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.


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 (stable) / (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
  • Singularity version

Related Links

Avination add vehicle sim crossing

With the SL-centric news on TPV policy changes, it was easy to miss the announcement that vehicle sim crossing capabilities have been rolled-out to the Avination Grid. I actually caught the new through Maria Korolov’s ever-excellent Hypergrid Business News.

The official press release reads in part:

Avination is the first Grid beside Second Life advanced to the point to offer cars, ships and other vehicles driving across sim borders.

“Breaking down the borders and crossing them!” Avination literally made just that possible for it’s residents. With the latest rollout of its server software Avination became the first grid beside Second Life to allow residents to explore their world using cars, ships, bikes or horse pulled carriages.

The days where one could only cross sim borders hiking or flying or needed a TP to get somewhere else are over.

Whether Avination was the first outside of SL is debatable. InWorldz may equally lay claim to that honour. However, sim-crossings are now available on Avination.

In discussing the roll-out with Hypergrid Business, Melanie Thielker, CEO of both Avination and hosting company 3D Hosting said, “We have worked continuously to improve vehicle physics and we have a good driving feel as it is,” she said. “However, we have also just started a complete revamp of vehicles with the aim to get even closer to Second Life behavior. At this time, Avination supports most of the API [application programming interface] and most values match or need only minor tweaks.” This essentially means that scripts that currently work in SL should work on Avination with minimal revision.

The capability will initially be proprietary to the Avination grid, but will eventually be released to the OpenSim community as a whole, in keeping with Avination’s policy of supporting the OpenSim community, in which it has its roots and strong ties (Thielker is one of the core OpenSim developers).

To mark the roll-out, Avination will be hosting a cross-sim race, sponsored by VirWox, the Austria-based virtual currency exchange and backer of the multi-grid Open Metaverse Currency (OMC), and organised by M Events, a Dutch marketing company which invested in Avination at the end of last year. Details of the race have yet to be announced, and I’ll endeavour to report them when known.

With thanks to Maria Korolov & Hypergrid Business