Oz discusses TPV Policy changes

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.

Pages: 1 2 3 4 5 6

TPVP changes – Oz provides further explanation, Tateru gets answers

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

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

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

1) What is meant by shared experience?

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

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

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

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

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

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

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.

Related Links

• My original TPV Policy changes article
• Tateru’s article on answers to questions
• SL forum thread on questions on the TPVP changes
• Recording of the TPV Developer meeting at which the changes were discussed.

LL update their TPV Policy

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

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

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

Privacy Clauses

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

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

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

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

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

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

Shared Experience

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

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

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

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

Thoughts on the Changes

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

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

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

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

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

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

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

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

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

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

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

Related Links

• Oz discusses TPV changes – March 10th
• TPV changes: Oz provides further explanation; Tateru gets answers – Feb 29th

Making an Ascent on Second Life

While Phoenix remains by far the most popular of the Third Party Viewers on offer for use with Second Life, a new arrival in the last couple of months is beginning to show some promise – particularly when it comes to implementing features from the Viewer 2.x stable – and which again, like Phoenix and Imprudence, does not require the initial installation of either the “official” 1.23.5 or Snowglobe Viewers as a prerequisite to its use.

Ascent has probably caused some eyebrows to rise, given it is apparently based on the Inertia Viewer code base. Inertia was a non-TPV compliant Viewer that was developed by the infamous “Hazim Gazov” – who was by turns, banned from Second Life by Linden Lab, the “whistle-blower” who first started to “reveal” genuine concerns around the Emerald Viewer (while also sharing in the rumour-building) and who was the target of Phox’s failed (and idiotically suicidal as well as moronically childish) DDoS attack which was in part responsible for Emerald being “banned” as a Second Life Viewer. Ascent is now maintained by one Charley Levenque, aka Charlotte Wirtanen, an unknown quantity in both cases, although in the latter guise, has been around since 2006.

Now to the Viewer itself. The setup EXE downloaded smoothly. It did cause a raised eyebrow, however, as it came in at almost twice the size of the likes of the Phoenix, Imprudence and other 1.23.5 Viewers – although I’ve been informed this is often the case with Viewers based on the Snowglobe code, which apparently forms the foundations for Ascent. An anti-virus scan revealed nothing untoward in the EXE (not entirely unsurprisingly) so I went ahead and ran it. As one would expect from a TPV of this nature, the overall installation was quick and clean, ending with an option to run Ascent at once.

The splash screen showed the Ascent download page, and was in the “official” blue skin display. Logging-in revealed the familiar 1.23.5 UI – but with the ADVANCED menu already listed on the menu bar, so no need to press CTRL-ALT-D.

At first glance, Ascent looks little different to the likes of Phoenix, Imprudence and others: the menu bar and toolbars along the bottom of the screen are largely unchanged, the in-world View is obviously the same – but just a little digging reveals that thought has been put into making Ascent not only different to other TPVs – but potentially more useful.

Clicking on COMMUNICATE, for example reveals several new features. At the top of the CONTACTS list is a CONTACT SEARCH box. Enter the first few characters of a name here, and a list of matching contacts is displayed. Type in a full name, and just display that avatar. Above this is a CONTACT GROUP drop-down, although functionality for this appears to be awaiting implementation. Replacing the Import / Export buttons found in the CONTACTS list of some Viewers is a count of the number of Contacts one has (and the number actually online), and a count of the number currently highlighted within the list. The Search function I can see being very handy for those with massively long Contacts lists – such as store owners – who need to contact someone quickly.

The RADAR (Avatar List) window offers the same functionality as most of the TPV’s that now include this function ported originally from Meerkat. However, unlike Phoenix, Ascent still includes the majority of avatar functions as a series of buttons at the bottom of the display, rather than moving them to a context menu displayed when right-clicking an avatar’s name in the list. When originally introduced into Emerald, this latter functionality caused divisions among users: people either accepted it, or demanded the return of all the buttons. Phoenix has something of a compromise, in that some of the buttons are back at the bottom of the screen; however, I find the context menu just fine, and personally think that Ascent has taken a step backwards here: the Avatar List is a useful tool in many ways, but Ascent’s simply takes up too much screen real estate.

BUILD incorporates functionality found in other TPVs, albeit relabelled. For example: the ability to OPEN the Group profile for a selected object is called VIEW. A nice touch on the Build menu is that when editing linked parts of an object, the “Selected Objects” count common to some other TPVs is replaced by a “Link number” display, as shown on the left. This functionality can be found in “Experimental” releases of Imprudence, but of the standalone installation TPVs, Ascent is the first to offer it in a “full” release.

For people utilising scripts that handle primitive counts to set a specific prim to a specific display (say, lettering on a scrolling prim notice), this strikes me as a useful little feature, and one I’d like to see pop up in other viewers.

INVENTORY offers pretty much the standard fayre for good TPVs, including the ever-handy RESTORE TO LAST POSITION option in the event you TAKE a linkset back to inventory, only to find you’ve missed linking a couple of prims. God knows, *I’ve* needed it enough!

Preferences

As with the majority of TPVs it is in the Viewer Preferences that Ascent shows clear differences. All the usual tabs are there: General, Input & Camera, Network, Web, Graphics… and so on. Two two unique tabs here are ASCENT SYSTEM and ASCENT VANITY.

ASCENT SYSTEM offers a number of additional tabs – less than the likes of Phoenix – each with either a less confusing array of options, or with options that have been better-organised. In summary:

• General: offers a subset of functionality found in the TP/Login tab from Phoenix and others (double-click teleport, always allow fly, always rez under land group when available, as well as several Ascent-specific functions:
  • Enable Power User functionality: “unlocks” the ability to set an animation priority up to 7, rather than the usual limit of 4. How this is reflected when said animations are used in other Viewers is unclear.
  • Destroy Objects: anything you have the power to DELETE is deleted permanently, bypassing the Trash can.
  • Explode Objects: temporarily renders an object physical and then delinks it.
• Chat/IM: neatly combines the more welcome elements of the IM and CHAT tabs again found in other TPVs, providing access to options such as allow MU* poses and auto OOC actions in chat; turning off the typing sound for chat, use vertical IM tabs, toggle the announcement of incoming IMs. This tab also includes the very useful Auto-response option for IMs, and (for some reason) includes options to display the time in either 12- or 24-hour notation and the date in US or European formats.
• Performance: captures the progressive draw distance option from other TPVs, although without the slider bar to adjust. It also includes:
  • An option to turn off the annoying wind howl, pulled up from the Windlight settings and made easily accessible
  • The ability to turn off the Classic Cloud layer (the one that exists at around the 200m level) at log in, rather than having to twit around and find the option in your Windlight settings. I’m very in favour of this, as it does lead to a nice little performance boost.
• Command Line: sees a subset of the text short cut commands available through the likes of Phoenix continued in Ascent.
• Security: gathers together the more innocuous options from Emerald’s infamous “shield” options, presenting the user with a degree of privacy without going too far in the direction of impinging on the privacy of others.
• Building: offers a subset of options originally found in the Emerald Build tab.

ASCENT VANITY gathers together the kind of settings one might like to set for one’s various avatars (if you happen to have more than one), and includes options to set tag and map colours to highlight friends, etc., as well as turn things like the teleport screens on/off or set breast and other dynamics.

Ascent does away which much that has in the past been looked at as controversial in some Viewers: IM encryption, for example is not present, nor are some of the more intrusive options to bounce in on people. It does have a couple that some may yet object to, although in the scheme of things, they are trivial. The first is the ability to fake your AWAY status – when active, AWAY will say visible in your tag even while you are camming around or engaging in IMs with others, etc. The second is the ability to see how long the people around you have been inactive.

Elsewhere, the pie menus have been reordered somewhat. Imprudence did this as well, with the aim of rationalising the pie menus and making them flow more logically – and it succeeded. It also offers the option of reverting to the more familiar pie menus if people have trouble getting their heads around the reordered versions. Ascent both reorders and adds functionality. I had no problems with the pie menus, but I can see those who want “all the latest but leave it as it is” bemoaning the pie menus at times.

Viewer 2.x Functions

As one would expect, Ascent includes Viewer 2.x’s Alpha Mask and Tattoo layer support – so no surprises there. What is a very pleasant surprise, however, is the inclusion of the Viewer 2.x multi-attachment support for prim attachments. This means that you can now wear multiple items on the same attach point (multiple rings on one HAND, for example)  - and have them render correctly in all Viewers. This is a major step forward when compared to the likes of Phoenix and Imprudence – and the work in getting it into Ascent is largely down the Henri Beauchamp. With multiple clothing layer support also promised (i.e. wear 2 jacket layers at the same time), this puts Ascent head-and-shoulders above other TPVs of its kind.

Beyond this, Ascent has the welcome inclusion of a client-side AO, the ever-useful Area Search functionality, and just about everything else that has proven useful in other TPVs. If it lacks anything at all, it is potentially that the Radar / Avatar List doesn’t include the additional listing fields found in Henri’s CL Viewer and, more to the point for many within SL, RLV/a support is lacking at the moment (although it is on the “to do” list) – which seems to be an odd feature to miss out.

There are a couple of functions I don’t entirely understand – such as using the “Ascent System Inventory”, which adds a couple of additional folders to the Inventory window whose precise function is unclear to me. Are they intermediary way points for uploads, located on Ascent’s own servers? The option to upload temporary textures suggests this – in which case, I have to admit to being leery of the functionality. I’ve searched the Ascent wiki for further information here, but have drawn a blank. ”Downloading Inventory in the background” also seems to be an odd option. How is this different to the usual inventory caching, which is already dynamic and a background task?

Performance-wise Ascent feels a lot more stable than the likes of Phoenix, and certainly comparable to the “full” release of Imprudence. For me, it scores over the latter in having a wider range of skin options, and also retaining the more usable “large” Avatar List. Although it does miss out in not having a spell checker.

Ascent also appears to run somewhat faster (for me) than the official 1.23.5 Viewer, Imprudence and Phoenix. In comparison with the latter, my preferred Viewer at the moment, Ascent runs at around 10-12 fps faster on a “busy” sim and about 15 fps faster on a “quiet” sim. I have no idea if Ascent is SSE optimised, but overall the performance is good.

I have noted a couple of very minor issues, and given I’ve only been fiddling with it for 24 hours will doubtless find things that will niggle me – but currently, the fact that the Tp screen still momentarily flashes up, despite my setting the option to disable it and relogging after – does cause a frown, if nothing else.

Overall, Ascent is a commendable effort; I’m not qualified to look under the bonnet, so to speak, but from a pure user perspective, I have to say that it has the potential to become a Viewer of choice when certain other functionality has been added. That said, I would prefer to see higher visibility where the developers are concerned before I committed to a full jump to Ascent – and again, kudos to Jessica over at Phoenix in this regard. Nevertheless, providing no unpleasantness emerges around Ascent (one feels there should not be any, but the pedigree of  the Inertia viewer hovers in the background), Ascent could come to easily rival Phoenix in the TPV environment. It is already off to a very good start.