A quiet week – only the Usual Suspects 🙂 updating in the TPV arena – Dolphin, Niran’s, Zen and Cool VL LL have updated their Beta Viewer, dated March 1st – although I swear that wasn’t the one I got in my weekly download / check for the March 5th Round-up. The Development Viewer has also been updated, with all others remaining as-is.
Changes since the last Round-up shown in green.
SL Official Viewers
Available for: Windows, Linux, Mac
Current Release version: 3.2.6.248931 (download page)
Beta version: 3.3.0.250306 (released: March 1st) (download page)
Development version: 3.3.1.250772 (released: March 8th) (wiki page)
Simplified Inventory Project version 3.2.8.248008 (wiki page)
This is intended to be a weekly round-up of current public SL viewers (of which I’m aware / for which I have information). 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.
On Wednesday March 7th, Jessica Lyon of the Firestorm team sat down with Oz Linden to discuss the recent TPV Policy (TPVP) changes. Originally Oz had asked to appear with Jessica on the last Phoenix Hour, which is normally co-presented by Jessica and Phaylen Fairchild, but it was decided to hold-off on any appearance for a more focused presentation.
That Oz made the offer again speaks highly of his desire to engage openly with the community on what has become something of a sensitive (and in some cases incorrectly viewed, given the way it has been wrongly portrayed as stopping “any” innovation within TPVs) issue, and his willingness to try to provide further clarification on the changes and the reasoning behind them.
I’ve included a summary of the discussion on the following pages. As it is somewhat lengthy and potentially subject to “tl;dr” (shame on you!), I felt it better to provide my own thoughts on the discussion up-front.
Oz in conversation
While listening to the discussion I was also seeing Twitter comments appear on my screen relating to the posting of the interview video and was – to be honest – surprised at the negative tone of some of the comments being made. Overall, I felt the Oz was open and direct in dealing with the questions and statements directed at him, and he did much to fill-in the blanks. And before anyone starts on the, “But he’s only an employee” tack, I very much doubt that he was in any way speaking in isolation or sans the support for his management. As such, this is precisely the kind of engagement we should be applauding, even if the message may not be entirely what we want to hear, and which LL should be seeking to undertake more regularly.
Some have complained that we “don’t know” any more following the discussion than we knew at the start. To them I’d actually ask, “What more do you want to know?” The boundaries of the TPVP changes have been given better definition – indeed, Oz has provided clearer definitions here, and prior to this meeting. Unless LL produces a set of stone tablets detailing every case, it’s hard to see what more can be said – and it should be remembered that tablets of stone can be as dangerous as having a broad definition. Things do cut both ways.
Sure, what has been said previously, and is said in this discussion, doesn’t provide any safeguards against any fear of how LL might at some point in the future choose to interpret the TPVP – but really, this is an unreasonable expectation. No-one can predict what tomorrow may bring much less a time eighteen months or two years hence, and it is unreasonable to expect any company to give guarantees where the security and growth of their business is concerned. At the end of the day, SL is LL’s business first and foremost – and I applaud Oz for being so frank on the matter of the business / platform relationship – and as such they can change the rules howsoever they like; as such the hammer could be dropped on TPV activities with or without the use of such a policy.
However, I think it fair to say Oz is being sincere both on a personal level and as a representative of the company when he says that LL is not looking to end TPVs, but wants to enhance and grow their working relationship with TPV developers. While it is clear from the phrasing of some of his answers that LL would like to see their effective market-share of users increase in terms of Viewer use, it would be a mistake to attribute the TPVP changes to purely that motivation. It’s fair to say that if that was the goal, LL could conceivably achieve it simply by removing the majority of their Viewer development back behind the curtain, leaving TPVs forever in a catch-up situation.
Nevertheless, the risk of stifling innovation is still there, howsoever small a part the “shared experience” has played in TPV development, simply because of the concerns TPV developers have around the whole aspect of having ideas and proposals accepted by LL as Jessica expresses in the video. This is something that LL need to remain attuned to and seek to demonstrate they will help and support TPV developers when and where they do see an opportunity for developing a shared experience capability that isn’t on LL’s radar or to-do list.
Some will most likely remain dissatisfied with the results of the discussion, which is a shame. While the proof of LL’s commitment to developing and evolving the TPV / LL relationship can only be judged on whatever occurs going forward, there is currently no reason to take what has been said at anything less than face value.
For my part, I would say that Oz’s openness and his candour in dealing with the questions and concerns relating to the TPVP changes is to be welcomed. I hope he does take Jessica up on her suggestion of future discussions of this kind, and that we may yet see LL encouraged to participate in other such opportunities to address user concerns on various matters as openly and directly in the future.
As per usual, a number of updates this week. LL released a new version of their Development Viewer and updated the Direct Delivery Project Viewer. Catznip went to release R6 and got a TPV Directory listing (congrats!), marking their “official” graduation to public Viewer. Lance issues his “Fujiyama” release of Dolphin (2.3.9.23177), so-called as it includes various photography updates. Niran’s Viewer hit release 1.28 and Zen 3.3.1.1, with releases of these Viewers averaging at one per week. Cool VL moved to 1.26.4.1, and appears to have seen the removal of the experimental versions (none listed on the blog when checked today). All others remain unchanged.
Changes since the last round-up shown in green.
SL Official Viewers
Available for: Windows, Linux, Mac
Current Release version: 3.2.6.248931 (download page)
Beta version: 3.2.9.249510 (released: Feb 6th) (download page)
Development version: 3.3.1.250315 (released: Feb 29th) (wiki page)
Simplified Inventory Project version 3.2.8.248008 (wiki page)
This is intended to be a weekly round-up of current public SL viewers (of which I’m aware / for which I have information). 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.
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.
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?
No.
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.
Just 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.
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.
Inara Pey: Living in a Modemworld 