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
- Oz discusses TPV changes – March 10th
- TPV changes: Oz provides further explanation; Tateru gets answers – Feb 29th
Inara Pey: Living in a Modemworld 
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 so broadly worded that it can be used to ban any viewer from access to Second Life. Let me give you an example (I’m sure they are never going to do this, but technically speaking it applies):
Radegast, the viewer that I develop, supports all sort of different ways to represent the world. For instance it has surround sound text-to-speech technology developed by Mojito Sorbet that reads out loud stuff happening around you. It places avatar chat in 3D sound space, uses male/female voices to paint audio image of the world, reads object names and provides hints of their location. This functionality is mostly developed to help the visually impaired users of Second Life. None of these features is “accessible to users of the latest released Linden Lab viewer” (not that organizations that support the disabled such as Virtual Ability have not been asking for them for years).
Again, I’m sure that Linden Lab will not invoke 2k to prevent Radegast from providing this functionality, but it’s highly questionable weather such functionality would have been developed in the first place if going in we were faced with such onerous policy language.
One curious thing to note is that the same issues have been brought up when the original TPVP was proposed. It had an identical article, but Joe Linden who was Vice President at the time agreed that the clause was too imprecise and agreed to take it out. It’s unfortunate that people like Joe Linden have since left Linden Lab.
LikeLike
Agreed on both points.
I had a comment on the fact the clause is so broad as to be open to interpretation – and there is no guarantee that the current benevolent administration would always be the ones doing the interpretation, but it got cut in editing for length….
LikeLike
I suppose it could be interpreted down the line as, “You can’t have anything in a TPV that’s not in the official viewer so … we’ll … just be taking that TPV from you, thank you.”
LikeLike
I’m kind of curious in which category something like Restrained Life would fall in. I mean, given how things have to be made to be ‘compatible’ with it, plus the explicit BDSM purpose of it to begin with, it seems it would come afoul of this new policy (and be the single biggest rage-inducer).
It wouldn’t affect me in the least, granted – while some of the additions made are neat and useful, the basic idea that you need to stop someone from detaching their virtual collar because they might not be able to resist the impulse to hit ‘detach’ has long been a source of hilarity for me – but I try to be friendly and understanding of kink in RL and SL both, and the *existence* of Restrained Life certainly never bothered me.
Still, it seems like it might directly be stomped by these additions to the TPV policy.
LikeLike
I’ve been told that RLV was explicitly mentioned at the meeting and the response was that it would be unaffected – it is an “opt-in” viewer where the user makes the choice to accept a degree of browser control by another user. Although I’m sure sections of the adult community would be pretty vociferous if its functionality was removed, it’s worth [pointing out that also used by sections of the game playing community too, which is something the Lab are currently building on.
LikeLike
That is correct. I’ve been listening to and taking notes from the recording, and that was clear in the meeting.
LikeLike
My bad… I managed to remove a bullet point that stated RLV was excluded as it is opt-in.
My apologies, entirely my fault for staying up half the night listing to the audio broadcast and then trying to put this piece together.
LikeLike
What is causing hollow laughter here is all the stress that is being placed on a shared experience … whereas the HUGE gap between Viewer experiences is not between TPVs and the official viewer, but between viewers that are mesh-enabled and those that are not – one of which is, of course, the Lindens’ own 1.23.
The difference between the mesh-enabled and the non-mesh enabled is a real source of frustration but it tends to come not from users’ determination to stay with the viewer they know at all costs (which was the case, I think, with the first Viewer 2) but because they may be having problems with newer viewers. I was in that camp for quite a while myself – it’s only the most recent iteration of Firestorm and Viewer 2 that I’ve been able to use for more than five minutes without crashing.
So virtuous comments on levelling the playing field for all users and ensuring they share the same experience seem a little wide of the mark.
LikeLike
This is the part that currently confuses me the most, the one glaring area of shared experiences is with regard to mesh and non mesh viewers, issues cited by Oz are parcel windlight settings and jiggly boobs, neither of which I can recall having an issue on the shared experience in the same way as Mesh or non Mesh viewers do.
LikeLike
I think the idea must be that if something’s going to be introduced that everyone can see, but which only looks right if you use a particular viewer, LL want to be sure that it’s easily adoptable for all viewers based on the official viewer, because otherwise you end up having to use one particular TPV for the shared visual environment to render properly.
For that to work, it’s got to be something that LL can support; it’s a far bigger deal for LL, for example, that something works properly on a Mac as well as Windows and Linux, than it maybe is for a TPV. And also it needs to be something scalable. I’m thinking of flexible sculpties, which people may remember from 3 or 4 years ago, when there was some experimental code to support them and Henri Beauchamp put them in his viewer very briefly. They were nice to have (if you were using Cool, otherwise they looked hideous) but they turned out to be very laggy, and LL rapidly decided that, if we were going to have flexible sculpties in widespread use, they’d have to implemented completely differently.
That worked out well, not least because Cool VL was not in widespread use (I don’t think it was even available for Windows then, in fact) so only very few people got a brief and tantalising look at flexible sculpties, and also because Henri is reasonable and responsible about such matters, but if Emerald had been around at the time and rolled them out for their far larger user base, it might have been a different story.
So I’m wondering if they don’t have half an eye, at least, on the possibility of someone coming up with — for example — a way of animating mesh that looks nice but is completely unsuitable for widespread use, and want to make sure that any work in that sort of area is done in collaboration with LL and other TPVs so new forms of content are widely supportable.
LikeLike
I can see their argument to a degree, you shouldn’t need to use a specific current viewer to utilise a feature such as Qarl’s mesh deformer, that can undermine the whole experience, but parcel windlight and avatar physics are more about optimising your Second Life, those who don’t use the TPV’s that supported those features didn’t really have their experience undermined. Attachment points is a different issue as people on viewers that didn’t support that did have odd experiences viewing those who did have that feature.
LikeLike
Parcel Windlight can affect the “shared experience” however.
Say I have an art exhibit, and I used Viewer X to establish my parcel Windlight to enhance the experience of my visitors. You come along to see the installation, and because you are using a Viewer that uses compatible code, you get to see my work exactly as I intended. Poor old Joe Schmoe, however (see my reply to Saffia 🙂 ) comes along with a Viewer that doesn’t support parcel Windlight. But he can’t see the work as I intended unless he swaps Viewer.
Therefore, it can be argued that both his any my “shared experience” is diminished.
LikeLike
To me the issue isn’t about “shared experience” per se. There are valid cases where things may well need to be – for want of a better word – policed. Innula cites a reasonable example. While it is now less relevant today than perhaps it once was, the Emerald multi-attach issue Oz referenced is also somewhat relevant – if also somewhat extreme.
What troubles me is how the clause is already being arbitrarily interpreted by LL.
Let’s take two cited examples: Emerald breast physics and mesh.
Suppose I go to a park and find a beautiful rendered mesh statue. However, a few metres away, Joe Schmoe is looking at the same statue, but on *his* screen, he’s seeing a deformed blob because he’s using a non-mesh Viewer.
As I admire the statue and move around it, I see my movements perfectly naturally – as does everyone else in the park *except* Joe Schmoe. He is using Emerald-style breast physics adjusted so that on *his* screen, I look like I have a pair of rampaging weasels down my blouse…
In both cases, it is *only* Joe Schmoe’s world-view that is affected: he can’t see the statue, but he can see my breasts leaping and bouncing around – so the net result is actually exactly the same.
Yet, according to Oz, the fact that Joe can’t see mesh on his Viewer is perfectly OK, clause 2.k isn’t contravened.
But the fact that he can see my boobs flolloping around (to use an Adams-ism) even tho no-one else can suddenly could be a violation of clause 2.k, and thus his Viewer is no longer allowed.
Contradictions such as this – and there are others in the audio, both around clause 2.k and with regards to 2.i and 2.j that tend to add an air of farce to the changes.
The sad part is that while there may well be valid reasons for implementing tighter controls over some aspects of Viewer functionality (again, Innula cites a good example, and a reasonable comment – as quoted in the article – was made by one of the TPV developers in the meeting) – when taken together, the contradictions evidenced in the discussion tend to underscore the view that some of these changes are less about better management of the “shared experience” and more about LL trying to capture some of the shiny that makes TPVs so popular and use it to promote their own Viewer.
Unless practical measures are put in place to prevent this – such as clear, consistent and documented guidelines to support the policy in terms of what is / isn’t allowed, coupled with clearly-documented guidelines on how LL will interact and assist / support TPVs in the development of “shared experience” features and provide a more balanced way of launching such features – then there is a risk that the net result of these changes will be a migration of TPVs into the OpenSim environment and to other walled gardens like InWorldz and Avination.
And while Oz might well view that as an acceptable risk – at least going by his comments in the audio – its something that could very well come back to haunt Linden Lab very quickly were it to happen.
LikeLike
I haven’t listened to the full audio yet, Inara. Did Oz actually give Emerald avatar physics as an example of something that wouldn’t now be permitted? It seems to me, too, that it was something that only affected the individual using it; as I recall, it affected how the individual using it saw things, like any other graphics setting. That was one of the complaints, as I recall — that I might not want my boobs to bounce up and down, but if someone else set his viewer to see them that way, then they would, for him and only for him.
LikeLike
The point was made that breast physics were developed independently of LL after LL refused to develop the feature – the argument being that the TPV solution more-or-less forced LL’s hand. If LL placed breast physics under this clause today, it wouldn’t happen.
LikeLike
“Work as fast as we can” – i.e. between 1-48 months before something is completed by LL. A handful of major updates a year, most of which are despised by the users/residents.
I like this plan a lot. Killing innovation/slowing progress to the very slow speed LL takes, and essentially putting the initial foot towards closing off TPV’s altogether <<
LikeLike
There first part of your comment is somewhat unfair.
Region Windlight settings have been the subject of rapid implementation by LL. Yes, there is an argument to state that they only came about as a direct result of TPV innovation – parcel Windlight (which LL are also now working on) – but even according to TPV Devs themselves, it only took LL 2-3 months to implement.
Furthermore, as even a casual glance at the Viewer download pages reveal, LL is constantly pushing out Viewer versions. The “release” version is updated almost monthly with bug fixes, etc., and Beta and Development versions used for testing fixes, patches, etc., are pushed out almost weekly.
They’ve also branched Viewer development to allow them to deal with specific major projects without impacting on other Viewer-related activities – hence project Viewers for the likes of Direct Delivery, Simplified Inventory and the recent Shining fixes.
Overall the company has made attempts to mend its ways, improve responsiveness, open-out development in terms of time frames and deliveries. They’ve clearly not got everything right and still have a way to go – but let’s not tar them with a brush that is a year old…
As to the rest – the jury is out as to how things develop from here – and it really does come down to two things: just how this policy clause works out in practice as TPVs attempt to put forward ideas to LL (i.e. how LL openly LL responses, how co-operatively they work with TPVs to bring functionality to fruition, etc.), and whether or not LL allow “scope creep” to enter the situation, with clause 2.k being used as a much wider catch-all for new functionality that might cause LL issues beyond that of the “shared experience”.
Will the clause stifle innovation – yes, there is a real risk that it will. TPV developers work for free and take pride in their work. Perhaps the one real satisfaction they get from their hours / days / weeks of toil and effort is being able to showcase functionality and capabilities within the Viewer that the community itself has been calling for. Clause 2.k now curtails at least some of that. That is bound to have an impact on motivation and desire to work on features and ideas with a resultant stifling of innovation.
But, it really depends upon how the clause is put into practice and how well LL and the TPVs work together – particularly in LL’s willingness to consider and adopt proposals for features and provide the technical support and input in order for a TPV to more readily develop that feature.
That really is the major question mark on the matter – and one that needs a lot of clarification in the next Developer meeting.
LikeLike
“Rapid implementation”? Region windlight was promised in 2008. It only took 3-4 years.
LikeLike
I’m simply re-iterating what many of you said at the meeting on the subject, Latif :).
LikeLike
As a coder, two things concern me about the change to llRequestAgentData(). I’ll prefix my comment by saying that I do actually appreciate people’s desire for extra privacy controls. However…
If (as it seems) the change to llRequestAgentData() in respect to online status is going to be blanket (as opposed to, say, a per-user switch to opt out of having their status revealed by the system) the proposed new working doesn’t really address the concerns about breakages at all. There are any number of cases where checking if an avatar is online or offline, and where the avatar who is being checked on isn’t the owner of the script, is a valid use case. The most obvious, of course, is any number of online/offline boards that are managed by a single person. Not impossible to work around, but it’s making work for lots of people (and forcing returns/updates/workarounds for those systems that were purchased).
But, beyond that: While I appreciate that it’ll get a “so what” shrug from some, using this to detect if an avatar has logged off, vs escaped, from equipment designed to hold them, is a very common use. Especially when you’re talking about code that makes use of the RLV API too, this request against the server data can be used to make decisions in code that affect the user.
Ultimately, while I appreciate that there can be no guarantees, what this seems to do is tell every coder in Second Life that you can never, ever, trust the documentation. I also think that people shouldn’t suggest that the proposed change doesn’t break it — it does. It’s interesting to note that http://wiki.secondlife.com/wiki/DATA_ONLINE still doesn’t seem to have a note to the effect that the operation of this call will change or that it should be treated as deprecated.
LikeLike
The only effective user input about features has been via. TPVs. Multiple attachments and Body physics were both created in their initial forms by Emerald and then basically *imposed* on LL, over their initial objections, by how popular they were with the residents!
Suggesting a new feature in the jira is a joke, you have to be very lucky to get any response at all, and then the best you can expect is “maybe someday”.
The “Our World – Our Way” like-it-or-leave it faction at LL is raising it’s ugly head again.
LikeLike
Firestorm does not include the true online status feature. Phoenix does.
LikeLike
Thanks, Tonya. Corrected!
LikeLike
That kind of confuses me then … why take a strong stand on this now, when Phoenix is most-likely not a viewer with a substantial future and Firestorm does not contain it?
LikeLike
Marx, you and I know Phoenix does not have that much of a future, but it’s still the most widely used viewer on the grid by a fairly wide margin, and many people out there want it to have a long future.
LikeLike
[audio src="http://lecs.opensource.secondlife.com/tpvd/meeting/2012-02-24.mp3" /]
DL first they play .. 1.45 hour
LikeLike
Parcel Windlight to me for an art exhibit would be like a website saying which browser and settings it’s best viewed in, I really don’t see this as upsetting the shared experience at all.
LikeLike
I’ll remind you of that the next time you take me on a date and I can see the glorious Windlight skies the venue creator has set-up and all you can see is the standard SL sky & are wondering what I’m cooing over… :).
LikeLike
Concerning my feeling about LL trying to get their viewer more popular by including what makes TPV so popular? Well. *my* main reasonS not to use LL’s viewer are the following:
-Rendering speed
-Rendering Quality
-Restrained Love API
-More exposed settings
-Client AO (even though it’s not really essential to me)
-General performance (rezzing speed, etc)
-Skins (viewer UI appearance)
-Phoenix/Firestorm’s Build floater, which contains more settings and greater decimal precision.
-Phoenix/Firestorm’s windlight. (The current Linden Lab’s implementation of region windlight is NOT acceptable for me. You can not change it unless you are the region admin/owner, and you can not allow renting residents to set their own windlight on their parcel. Sorry. That’s not working for me. Try again, LL.)
If Linden Labs can adress those issues and code a proper rendering pipeling, I would gladly use their viewer if I must.
About viewer tags: THANK YOU. <3!
About the true online status: Thank you. I put a lot of importance into Respect, and if I want my online status to be hidden from somebody, I like this desire to be respected. However, I would as well add a "Login as Invisible" function in the login screen.
That's all I can think about right now.
LikeLike
On two counts, you might be interested to know that LL are apparently working on parcel Windlight – and that the Phoenix / Firestorm system gets a “free pass” until the LL system arrives. Oz indicated during the meeting he’d like to talk to TPV devs regarding client-side AOs.
I think is fair that some of the performance issues you mention are sometimes down to the system the Viewer is running on. I personally find the later V3.2 releases, for example (from around 3.2.5 onwards) somewhat superior to one or two TPV offerings in terms of rezzing, world view quality and rezzing times, something I’ve commented on in a few on my Viewer reviews. But that is just my personal experience, based on my hardware…
LikeLike
I’m always confused by this ‘can’t do parcel windlight’ complaint.
Everytime I prep a snapshot I pull down the lighting effects and tweak all kinds of settings – am I doing something different than windlight?
LikeLike
“-Phoenix/Firestorm’s Build floater, which contains more settings and greater decimal precision.”
That greater “precision” is a false sense of security – the server only stores the resulting edit down to 0.01. It will thus cause items you edit at “more” precision to ‘move’ when it rounds off your value.
LikeLike
Great post! I’m completely in favour of the changes, the Emerald attachments were a classic example of irresponsible development. 3rd parties can now focus on enhancing the quality of the experience for the user, developing viewers that fit specific niches or groups and they will have to do so in a careful respobsible way that doesn’t mess up the experience for others.
LikeLike
@Emma The privacy changes are welcome, but you are mistaken about the rest.
Clause 2K makes it very hard for TPV’s to continue to shape and enrich your experience of Second Life in the way they have been so far.
Yes the emerald attachments were a hack and bad. But without them would the lab have recognised the demand for more flexible attachments and added multi wearables? The same with breast physics leading directly to avatar physics from the lab. Not to mention the very hacky parcel windlight leading to the labs own implementation.
TPV’s might have been doing it wrong, but when you can’t work on the server side quite often a mash up is the best you can do. If you look at what the TPV’s have been doing more as quickly prototyping ideas for the Lab then today, everyone looses.
As is often the case, an idea on paper is one thing, trying it out and experiencing it is quite another and the Lab will never be able to mash things up to see what we think of something in the hack and slap way a TPV could.
LikeLike
This has been percolating for a few days since your blog post – with some comments coming out about those clauses.
The privacy thing is a major concern. Ever since the malware viewer Emerald put in the ability to override privacy settings of others – and this for some reason was kept in Phoenix / Firestorm… its been a point of controversy.
That the TPVs have been unwilling to self-correct on this for so long means they need to lose some of their autonomy. When self-regulation fails, you lay out the smackdown and let em get hurt. They clearly lacked the ability to be responsible on their own.
TPVs brought that policing upon themselves.
That this breaks some scripts is unfortunate – but those can be re-coded to new methods.
On to 2k, the ‘sky is falling’ clause.
It appears that’s about being able to change the experience of other people through your viewer. I see that as a pro-active measure for the coming game features that got a preview in Linden Realms. Adding these features in will likely add code that could be cracked and retooled for a hostile purpose. And again the over-riding of privacy settings in the Emerald line shows that some will feel entitled to do this if not told outright that it is forbidden.
– So this section 2k is in my opinion a measure to prevent us going down the Emerald path -again- in a year, where we end up with a griefer viewer as a populat choice and masses of people demanding Linden Lab not ban it despite the risks it poses to the system.
LikeLike
Well, my position on this is clear.
There are more grids then Sl, so pls Tpv’s builders make sure you think on open sim and include a inbuild Ao! (Henry, i know you hate that idea, but most of open sim regions are scripts disabled and the only way to walk is using a inbuild ao;)
LikeLike
Inara said:
“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.”
Actually, you’ve hit on the central rationale for that rule… we want to focus on core issues, and that means things that affect what the world is, and how it behaves. We encourage third party Viewer
developers to innovate with user interfaces and controls (which is both what most TPV users cite as the reasons they use them, and the vast majority of all TPV changes). We want to be sure that development of features that can affect all users is done in such a way that they 1) don’t cause problems with the server systems (something TPV developers don’t have a good way to check on their own), 2) fit into Second Life as a whole, and 3) are available to all Viewers in an orderly way. We are already working with open source feature developers in this way, and look forward to more.
LikeLike
TBH, Oz, I understand and broadly agree.
The fear comes that – with due respect to yourself and Rodvik et al – that while you and the likes of Oskar (as two examples) work hard to talk things through with users and external devs, LL has had – and still has – something of a poor record where corporate-level communications / decisions are concerned. As such, I think it fair to say that (and without wishing to put words in any TPV developer’s mouth), people are worried about “scope creep” on these goals and that over time, Viewer developers will see what they can do be eroded. I know that is not what you intend, but these things can and do happen, particularly given the generally fuzziness around the concept of “shared experience” and what that actually constitutes / how it is presented solidly to people.
Another problem, potentially, is that so many people are passionately engaged in SL – through the likes of Viewer development, that however positively-motivated moves on LL’s part are, there is always the feeling – because of the passion involved – that doors are being closed. It’s not always a rational response, but it does happen.
LikeLike
If you could ask anyone who knows me in RL, you’d find out I’m every bit as passionate as anyone 🙂 I won’t hold that against anyone.
It’s not easy to write a rule shorter than a book that expresses clearly what you want it to express, and if you write a book you’ll still be asked about the chapters you didn’t include. We’re doing our best.
LikeLike
I emphasise totally on both counts.
As Hitomi suggests below, some concise examples that had been agreed upon within LL could very much help clarify matters greatly.
LikeLike
Oz, if a sentence is enough to express clearly what you want to express, then this sentence is all you need. But if it takes a book to express it clearly and without being misunderstood, then a book it’s what it takes.
While I personally think that 2a(iii) and 2i/2j are just exaggerated, I kind of understand the reasoning behind it:
1)For the “privacy” matter, it’ s like when you’re sitting with son and daughter in the kitchen, and your son answers the suddenly ringing phone first – with your daughter’s adorer on the other end of the line – and tells the caller that “she’s right here with me, but she doesn’t wish to talk with you right now.” – while she previously said “When that guy calls, tell him I’m not home.” Of course your son has to be punished for NOT lying… <.<
2) And for the viewer tags: There have been a few who bullied others, so the bullying will be disabled by breaking the functions behind. Just like when a school introduces school uniforms in order to stop a handful of students bullying others for wearing different brands of clothes or school bags or whatever.
And given how unclear 2.k is worded, I think it can and will stifle all kinds of innovation in a harsh way: "You implemented something we formerly thought not necessary or not possible? And lots of users have moved from our official viewer to yours in order to to have that feature? Bad luck. That feature's declared contrary to the new paragraph 2.k TPVP. Take it away or we'll ban you".
LikeLike
Oz – I think a full official explanation of what is meant by a “shared experience” with as many examples as possible would be helpful. At the moment there are so many interpretations that it is leading to a great deal of uncertainty
LikeLike