Month: February 2012

LL update their TPV Policy

Posted on by Inara Pey

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

Received Items beta launch

Posted on by Inara Pey

This slipped in under the radar yesterday – I almost missed it, but for a Reddit post from “Finethanks”: the Received Items Beta Launch.

Considered a part of Direct Delivery (and therefore technically already in beta), the Received Items functionality will actually be used to receive all incoming items reaching your inventory – notecards, snapshots, gifts, even items returned under parcel auto-return – as well as items being delivered via the upcoming Marketplace Direct Delivery system.

The blog post reporting the beta launch reads in full:

Look for Received Item in your inventory (Beta Viewer)

The Received Items Beta launches on Aditi today. Received Items is a new subsection of Inventory where all incoming items, including purchases, gifts, shared, and returned items, will be placed. Received Items is displayed in a separate section of your inventory panel in the Second Life Viewer, making it easier for Residents to see and manage incoming objects.

This Beta is a chance for Residents to try out these new capabilities. It also provides Second Life business owners with advance notice so they can plan for any additional communication or customer support around this upcoming change.  The production deploy is currently planned for mid to late March, so please help to spread the word!

Because Received Items and Direct Delivery will use the new Received Items folder, both systems will launch together.If you would like to try out Received Items, please see the Received Items Beta instructions on the wiki. These instructions include pointers to Knowledge Base articles and ways to provide feedback.

You’ll need the latest SL Beta Viewer for testing, and may want to look at the Knowledge Base page as well. Aditi regions were testing is enabled are:

Additionally, there are a number of “special testing” regions that have been created for specific tests:

To access any of these regions, you’ll most likely need to log-in to Aditi first and then cut & paste he SLurls into your address bar, or use the World Map to reach them.

JIRA reports on the new functionality should be raised under the SVC project and categorised as “inventory”.

Related Links

with thanks to “Finethanks” on Reddit.

A Hazardous journey brings its own reward

Posted on by Inara Pey

In January I visited Wendy Xeno’s Humanoid, which I found to be an evocative and photogenic experience. So when I heard she’s been commissioned by Dirk Talamasca to produce another piece, I knew I’d have to pay it a visit.

Hazardous, the result of the commission, is located on Misali, a Homestead sim owned by Mandingo Quan, who was also involved in the design process. The byline for the installation is Dream infinitely….. remain fearless…..seek Hazardous adventures, and for those familiar with Wendy’s work, it carries many of her trademark touches.

Your arrival receives a musical greeting, this time from a piano which features covers of Linkin Park’s “Numb” and “Beth” by Kiss, a rather eclectic mix of instrument and music that works very well within the theme and tone of the installation.

The eclectic piano

Around you lies a muted landscape with dark, dusk-laden skies (assuming you accept the local Windlight settings – and I recommend you do!). For those visiting with a partner / loved one and who have a romantic inclination, a bottle floating in the water alongside the guest book pedestal offers dances. For the adventurous, the silhouettes of a nearby landmass beckon – but be careful you don’t mess the balloons tethered closer to hand, which offer a fun way to see the sim…

The balloons allow you to ride around the installation, guiding yourself via the arrow keys and PAGE UP and PAGE DOWN, and make reaching various part of the piece a lot more fun than simply flying. If you decided to stop off anywhere, then your balloon doesn’t instantly vanish, giving you the option of grabbing hold and floating onwards if your visit to a particular spot isn’t too long.

Towards the centre of the sim lay a number of tor-like outcrops, the larger two of which are linked by a rope walk and offer visitors places to simply sit and observe or enjoy one another’s company.

To the north-east of the region sits a tangle of trees, denuded of leaves, and from which a stone path rises, angling gently upwards and inviting you to walk it, following the trail of lanterns to the top. As you climb, so the wind blows, carrying the sound of surf, as waves sweep against the tall tor you are approaching. At the top sits another symbol familiar to Wendy’s work: a birdcage, this one containing a music box. Dances are available nearby, but I’ll leave you to find the giver :).

Make sure you drop down to the graveyard below…the tombstones are a delightful read…

Like Humanoid, Hazardous extends its reach into the sky via three teleports located near the arrival point. These lead to various scenes contained within spheres high overhead, of which my favourite is the “ghost ship”.

Overall, Hazardous has much in common with Humanoid, but is also very different; together they complement one another and form pieces that work both individually and together. Both are evocative, but in very different ways. While Humanoid caused me to the think very much of Eliot’s The Four Quartets, Hazardous resonated with me in terms of fantasy, the colours and forms lending themselves naturally to images of strange and distant worlds, or perhaps other versions of this world where the fantastic is possible.

Like Humanoid, Hazardous offers SL photographers a great environment in which to work – both the Windlight settings and colour tones work very well whether or not you have deferred rendering active, making it possible to play around a lot with images and effects when using a Viewer such as Exodus or Niran’s.

Well worth a visit.

Related Links

Call for Imprudence volunteers – meeting this weekend

Posted on by Inara Pey

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.

ISM: Alpha and Bravo back after snag

Posted on by Inara Pey

I reported recently on the status of the International Spaceflight Museum and the issues it has suffered of late – some of which are internal, others not so. However, tier due was raised, and the ISM team were planning on making a return with Spaceport Alpha and Spaceport Bravo.

At the weekend, Kat Lemieux received a message from Linden Lab stating that the account had been delinquent for so long, the ISM group would have to purchase new sims from Linden Lab.

The sims themselves went off-line in mid-January, with unpaid tier amounted to around $1180 (two sims at $295 for two months, presumably December and January). Since then, the ISM team have been working to get payments made following donations – and have experienced around two weeks in delays due to issues related to Paypal / LL.

The initial reaction to the news when made public was one of stunned disbelief, and for Kat and the team, a concern that the regions may have in fact been deleted with a loss of content.

While the tier had been in arrears for two months – the sims themselves had only been offline for a little over a month, so had the content been lost, this would have been a cruel blow.

BUT: during an e-mail exchange with Kat, I received this message:

The islands are back, with content!!!

Now we have to find out what are the conditions — is this a temporary restoration just to let us get the content, or are they back in the same terms as before? We’ll find out, and I’ll let you know when we do.

So – well done, Linden Lab!

As Kat’s e-mail states, there is still work to be done, but following a rapid-fire visit to Spaceport Alpha, things do appear to be back and in good condition.

Spaceport Alpha (centre front) and Spaceport Bravo (centre rear) back: 21st Feb, 19:00 SLT

Doubtless more to come as the situation becomes clearer.

Return to Fallingwater 4: the video

Posted on by Inara Pey

Note: The build has now been taken down from Eagle Acres. A “replacement” build is now available on a region of its own in Kitely. 

Well, I had to go and do it. Temptation got the better of me. After putting in all the effort on the build…and no-doubt causing many rolled eyes with my obsession, I managed to secure 1/4 of a homestead region for a week at a reasonable cost – just so I could try to fit the build together sort-of in-situ.

The result isn’t perfect – even with some adjustments to the build, a 1/4 sim in terms of land size is actually too small for all of it (it really does need an entire homestead size-wise. Primarily, I had to lose a parking bay in the garage (from 4 to 3) and reduce the size of the arc of the footpath linking guest wing to main house (which actually improves the build, I think).  I’ve also compromised a little on the positioning: as there are others on the sim, I didn’t want them to feel disturbed as part of the build suddenly appeared over the tops of the hills dividing the parcels and thinking they had some kind of pixel voyeur on their doorstep. I also had to do with phantom sculpts to represent the “far bank” of the Bear Run, and Linden Water is representing the stretch of river directly below the first set of falls. Sadly, compromises left me with no room for the rest…

Other than that, however, the house fitted fine… :), so I thought I’d share a little video and a couple of images:

(You might want to view it on the YouTube page given the way WordPress squishes things in this page layout.)

As the house is up until March 2nd, it can be seen at Eagle Acres Ranch (SLurl), if anyone is interested.

Fallingwater in-situ (sort-of). Perhaps a full Homestead. One day…
From the access bridge by night

(As an aside, I was asked the other day when I use stills rather than “pure” machinima. The answers are simple: I’ve not mastered camera manipulation to achieve the effects I want (no space navigator or anything like it), and when I’ve tried to run SL and capture video, I end up with something that is jumpier than a cat stoned on catnip…)

Related Links