LL update their TPV Policy

Posted on February 25, 2012August 18, 2013 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.

The Major Rule and Other Requirements

To quote from the press release on the Challenge:

Your machinima can be about whatever you choose, but there is one rule all entries must follow. The only requirement is that at least ONE of the 100 Treasures from UWA must form part of your story. These are actual treasures, however at least 17 of them exist on UWA land in Second Life. You may choose to include as many of the treasures as you like so long as there is at least ONE. Apart from this, feel free to film anything, anywhere. You may use props at the location, or maybe want to change the footage later during the post process, this is up to you… as long as the treasure or treasures you choose to be part of your Machinima can be recognised and form part of your storyline.

The recommended running time for entries is around 4 minutes 30 seconds in length. This isn’t a hard rule, but entries aiming for the UWA L$100,000 special prize, which will be awarded to the machinima that best captures the essence or spirit of 100 years of seeking wisdom at UWA, must fit within the recommended length.

Additionally, entrants are asked that they acknowledge the works featured in their submission and the lands in which the submission was filmed.

Completed entries should be uploaded to a suitable broadcast medium (e.g. Vimeo, YouTube, etc.), and links to the film sent to the UWA’s Jayjay Zifanwe and LaPiscean Liberty.

Closing Date for Entries

Midnight SLT, June 30th, 2012.

About the Theme

“Seek Wisdom” is the UWA’s own motto, found in its coat of arms, and was selected as the theme of the challenge to honour the new way education is delivered at UWA, “New Courses 2012.” The requirement to include at least one of the 100 treasures from the UWA in entries is to mark the university’s upcoming centenary in 2013.

Where to find 17 of the 100 UWA Treasures in SL

To help machinimatographers get started, the UWA press release for the Challenge lists the location of 17 of the treasures in SL, and entrants are encouraged to read about the 100 online treasures in the UWA book to gain a further feel for possible subject matter.

Prize List in Full

1st Prize: L$130,000
2nd Prize: L$105,000
3rd Prize: L$85,000
4th Prize: L$60,000
5th Prize: L$40,000
6th – 10th Prize: L$30,000
UWA Special Prize: L$100,000 (awarded by UWA members of the committee)
Best Machinima Poster: L$10,000 (awarded by SL Machinima Poster Archive; Glasz Decuir)
Machinima Audience Participation Prize: L$20,000

Links

Questions relating to the challenge should be sent directly to the UWA’s Jayjay Zifanwe. Seek wisdom poster by Eliza Wierwight.

Raise the (flight) limit!

Posted on February 8, 2012August 20, 2013 by Inara Pey

Update April 2012: The flight limit has been raised to 5,000m.

Nalates Urriah keeps her finger on the pulse where all things server and scripting are concerned, as well as keeping an eye on other technical aspects of SL. Today she reports on server scripting, and carries an interesting little nugget on flight limits.

Apparently the Lab is considering whether or not to raise the current flight “ceiling” for unassisted avatars. As we’re all aware, if you fly without any kind of scripted / client-side assistance, you’ll start slowing down from around 165m onwards, and come to a complete halt at about 180-190m. To go any further, scripted / Viewer assistance is required.

I’ve no idea why this limit was set – there has to be some solid reasoning for it in the depths of time. However, for as long as I’ve been involved in SL, build height has (I think, my memory is getting fuzzy in some areas) always been at least 768m (prior to being raised to the current 4096m), so the brake-point at 180-190 to “natural” flight does seem rather arbitrary.

Simon Linden apparently puts forward an argument that raising the limit will shoot people using flight assistance systems into orbit. I’m not entirely sure I follow his logic. There is a plethora of flight assistance alternatives available across SL, from the ubiquitous Flight Feather or Flight Ring of old, through to fancy backpack attachments to options built-in to a range of tools such as Em Dash and Mystitool. Many of these include accelerators which allow the rate of vertical ascent to be adjusted by the user – some of them quite ridiculously so. Yet none, so far as I’m aware, have resulted in people ending up in orbit on the click of a button / key, even when employed at altitude. So would the removal of the current limit suddenly cause these tools to behave any differently?

It’s not even as if flight assistance tools are required, either. Firestorm bypasses the current limit by adding flight assistance to the LSL bridge. Milkshake (prior to being withdrawn from public use) demonstrated that it is possible to override the flight limit directly from within the Viewer without even resorting to any form of bridge attachment. Both of these capabilities tend to make the current limit somewhat pointless.

As it stands, and with maximum build height sitting at 4096m, it would make sense for LL to lift the limit to that altitude (as I’m sure they are only too aware). This would not only make mobility at altitude easier for all (especially around the more expansive higher-altitude builds where flying is allowed), it might even lessen people’s dependency on attachments, be they wearable or HUDs (not that this is a critical issue, given the threatened script limits project is now apparently shelved).

It’s not what I’d call a priority in any way shape or form, but it would potentially make people lives a little bit easier in-world; so if LL are considering the move – I for one say, “go for it – and push it to 4096!”

With thanks to Nalates Urriah

Visual Auto-mute: a farewell to ARC/ADW upsets?

Posted on January 30, 2012August 19, 2013 by Inara Pey

A new set of functions has been released by LL as a changeset, and is starting to find its way into SL Viewers.

Essentially, this functionality allows you to set thresholds above which avatars with a very heavy load (high-res textures, complex attachments (multiple prims, flexi prims, sculpts, and what have you), etc., – but not scripts, which are a completely different kettle of fish) will not be rendered by your Viewer. Instead, such avatars will appear as “grey ghosts”, similar to when they’ve been muted; however, IMs and chat can still be exchanged. This should theoretically reduce the load placed on the Viewer and a your system in terms of rendering, and lead to an improved SL experience.

It’s important to note that the functions only affect how such avatars are rendered in your world-view; they will still render normally in their own view, and for anyone who hasn’t set thresholds / has higher thresholds than you. Also, your avatar will remain visible in your view, no matter how you set the limits.

The thresholds are governed by two functions, initially released by LL as a set of debug settings:

RenderAutoMuteByteLimit – Maximum bytes of attachments before an avatar is automatically visually muted (0 for no limit)

RenderAutoMuteSurfaceAreaLimit – Maximum surface area of attachments before an avatar is automatically visually muted (0 for no limit)

These currently require numerical values to be entered. However, it is possible that they’ll find their way into at least some Viewers as Preferences options, possibly using sliders. Zena Juran has already opted for this approach with the latest release of the Zen Viewer (below).

Zen3287-4 — Visual Auto-mute as presented in the Zen Viewer

The functions are supported by a new addition to the Develop menu: Render MetaData->Attachment Bytes. When active, This displays a set of figures over / near avatars, which can be used to help you to determine the byte and area thresholds you should set.

VAM — Rendering Metadata->Attachment Bytes display enabled

The approach has already come in for considerable discussion on the SLU forum, where opinion seems to be weighted towards the favourable.

Certainly, it can’t be denied that avatars can impact Viewer performance enormously, so any moves that enable the user to have a greater degree of control over what is hurting their SL experience is potentially a good thing. But lag is a very sensitive subject – as anyone who has encountered upsets in the past due to people using ARC as a Big Stick can testify.

This approach would appear to be a lot more beneficial than something like ARC and its successor, Avatar Draw Weight (or ADW) are concerned, as it should hopefully reduce the amount of finger-pointing and hostility that goes on when people have arbitrary figures in red floating over their heads like a glaring accusation of wrong-doing.

It’s also somewhat friendlier than the other alternative to “blocking” “overloaded” avatars: that of audio mute, which denies any communications capabilities where some might be preferred and which can, if done on a group basis, leave a poor soul ostracised in silence with no idea why.

There are, however, some drawbacks. On the minor side, it is possible that setting the options when entering a popular venue may well result in you finding one or more friends around you turn into grey ghosts – or that you end-up greyed-out in their view. This might in turn result in strained relations, but shouldn’t really be anything reasonable people can get past – and even joke about privately.

This isn’t necessarily a “one size fits all” solution as well; it is possible that, depending on the type of venues a person visits (in terms of popularity popularity, nature of the activities carried out, etc.), the thresholds may need adjusting from time-to-time in order to gain the best benefits / compromise in terms of performance benefits and visual appeal. This may limit the scope to which the new functions are used, as people are not always willing to fiddle around with sliders as they teleport around SL.

It also needs to be remembered that avatars aren’t the only load placed on the Viewer, and using functions like these might not help tremendously when moving around an environment that has dozens upon dozens of high-resolution textures all over the place (such as a store or mall). In this regard, the effectiveness of the system needs to be balanced against alternative approaches (such as the use of avatar imposters, or by simply turning-down your draw distance and turning down / off various options within the Viewer Preferences) in order to improve one’s in-world experience.

The biggest question-mark over the new controls, however, is that of effectiveness. If the results of playing with the new options is an improvement of a couple of fps in overall performance and/or a very slight improvement in rendering time, then it is unlikely that they are going to gain a lot of traction. But if people see a demonstrable improvement in their overall experience, then it is liable that the functions are going to prove more popular.

That said, anything tha moves us further away from the finger-pointing extremism that has been the plague of ARC /ADW, has to be a step in the right direction, doesn’t it? One possible benefit from this approach is a greater awareness and consideration of just how one’s own avatar might be impacting other people’s experience within SL, simply by seeing that it exceeds the thresholds one is setting against other avatars.

Well, one can hope, can’t one?

Taking stock of Inventory: LL ask for feedback

Posted on January 22, 2012April 24, 2021 by Inara Pey

ProductTeam Linden (who he/she? is it Rhett in disguise?) has posted to the Technology Forum about a new option for presenting Inventory within the Viewer. Apparently, when the Viewer was split between the Basic and Advanced modes, moves were made to try to improve / simplify inventory presentation, but they never made it to a final cut of the Viewer.

Now they have, and Linden Lab is asking for feedback. The announcement reads in part:

For new users, managing and understanding inventory is often challenging. Drag and drop over large inventories can be problematic and daunting. New users are often confused about the meaning of certain system folders.

Today we have released a Project Viewer beta that includes this simplified presentation of inventory as an option. Before we consider any widespread changes to inventory, we want to know what you think about the Simple Inventory UI, noting that the target user is someone just starting out.

The Simple Inventory UI offers new users:

A simple display presenting only one folder at a time
Improved wayfinding and findability
Faster load of inventory items

The article then invites users to download a Project Viewer which includes the new Inventory presentation, and to provide feedback (via the SL forum), with any bugs that are found logged in the SINV Project JIRA. In doing to, the article notes:

It’s important to note that Simple Inventory was intended for Basic mode before Basic and Advanced modes were merged. It is still experimental and so it is unclear how it will function with extremely large Inventories, so if you have a large Inventory we don’t recommend using Simple Inventory as your only view.

There are also some incomplete features and some known issues, again as LL note.

So, what is it like? As I have a fairly extensive inventory that (if I say so myself) is well-managed and ordered that I’m in no mood to mess with, I tapped my CTA (Crash Test Alt) on the shoulder and took the Project Viewer for a spin.

Quick Tour

The Viewer has an initial release number of 3.2.8 (248008), and installs into is own folder but shares the standard cache and user folder locations as all other SL installations. Once started, the Viewer has the same funky blue/teal UI as the DD Project Viewer – so I assume this is to provide a simple means of recognising that you’re running a Project Viewer. Otherwise, the Viewer looks and behaves like a “normal” release.

Opening Inventory initially reveals a familiar panel (for those that use the official Viewer), but one with a new SWITCH TO FOLDER VIEW link in the top right corner (below left). Clicking this brings-up the revised layout (below, right).

SInv-4 — Inventory: from hierarchical view to folder view

Key points of the new layout:

Inventory is divided into clear sections: MY INVENTORY, LIBRARY, RECEIVED ITEMS (for the forthcoming Direct Delivery) and TRASH
You can have more than one section open at a time
Sections can be resized by hovering the mouse at the bottom of an open section so the cursor changes to a double-headed arrow. Click and hold the left mouse button to drag the sections beneath the open section up/down
Within a section, folders and contents are listed alphabetically (so system folders do not appear at the top of MY INVENTORY by default, and folders are not sorted to the top when mixed with objects)

As the view is not intended to be hierarchical, there are no arrowheads to the left of folders or any ability to open them within the displayed panel. Instead, opening a folder is now achieved in one of two ways:

You can hover the mouse over a folder to highlight it with an ACTIONS option. Clicking this will displays context menu from which you can select OPEN IN NEW WINDOW (below, left)
You can double-click on the folder and have a new view of the contents slide neatly into the existing panel, replacing what was already there.

Note that to prevent accidents, system folders automatically have the options to move, rename or delete them disabled.

Whether you opt to open folders in a new window, or display them in the existing panel, the end result is the same in terms of what you see (below, right).

SInv-6 — Opening folders: either hover the mouse over the folder and Click ACTIONS for a menu (l) or double-click a folder. The contacts will be displayed (r)

If you opt to drill down through your folders by opening each in a new window, then navigating back and forth is a relatively simple matter of swapping between windows and closing those you’ve finished with.

However, the system also makes it possible you to navigate up / down a set of nested folders within a single panel by adding breadcrumbs to the top of the panel (right) as you open each successive folder, allowing you to navigate back up the tree. At the same time, hovering the mouse over MY INVENTORY will reveal another ACTIONS option from which you can elect to go BACK TO TOP FOLDER.

Once in a folder, items can be highlighted and the ACTIONS menu used to manipulate them (e.g. wear, move, rename, delete) – again displayed options are context-sensitive (so if you are wearing an item, that option is not displayed, for example).

You can move items around your inventory in several ways:

Use the ACTION menu to select MOVE for an item / folder. This opens an additional window in which you can navigate to your desired destination (double-click through the required folders), before clicking MOVE TO SELECTED FOLDER to finish the task
You can also simply drag-and-drop items / folders within a panel
You can drag-and-drop between inventory windows
You can drag-and-drop between sections (between RECEIVED ITEMS and MY INVENTORY, for example) – the destination section does not have to be expanded in order to do so.

A couple of things I did notice during testing were that a) worn items are not highlighted / indicated in any way and b) there is no option to remove / detach a worn item. There also appears to be a bug, as selecting WEAR appears to ADD the selected item to your avatar, rather than replacing anything already worn – my CTA ended up clumping around in two pairs of boots….

Feedback and Thoughts

I don’t really have any issues with the functionality presented here per se. It works OK, the overall layout within a panel is fine, and (known issues and bugs notwithstanding), it all works pretty much as expected. There do appear to be some issues that do need addressing, however, and as LL asked for feedback on the system as presented (and allowing for the fact it is only an initial iteration, here’s mine:

Add the ability to see what is actually being worn or is attached to the avatar within the Folder View
As most people are likely to be moving folders from RECEIVED ITEMS to MY INVENTORY, it would make sense to move RECEIVED ITEMS above LIBRARY, to reduce the chances of a mis-click dropping items into the Library section
As currently supplied, the functionality is perhaps a little too limited – no ability to create sub-folders, for example, so the ability to organise one’s inventory is restricted to drag-and-drop into whatever is already there
Don’t be afraid of using menu options at the top of the inventory panel (File, Create, Sort, etc.) – they are lot more intuitive for users new or established than having options buried behind obscure “+” symbols and cog-wheel icons.

Also, if it is intended provide both views (Hierarchy and Folder) within the inventory panel of the a release Viewer at some point in the future, then I’d also suggesting ensuring that the top-level folder presentation is consistent between them (i.e. scrap the “system folders to top” default in favour of an alphabetical listing for the Hierarchy View), as this will assist familiarity in switching between views.

Thoughts

Candidly speaking, this alternative presentation comes across as yet another Linden curate’s egg. On the one hand, it cannot be denied that there are issues around how the inventory panel functions (the “high-speed scrolling” that can occur when trying to move an item from one folder to another, for example), and that things could be improved in terms of presentation. On the other, this approach is perhaps a little too simplistic to make a valid judgement at this point; too much functionality has been stripped away. Looking at it in the form presented, it’s hard to see the direction in which it’s liable to grow (if any) – which I think may be the issue LL are having, hence the low-key call for assistance.

I also cannot help but think LL “misunderestimate” new users here. While people are new to SL, it’s doubtful they are new to computers and things such as file management tools like Windows Explorer and the Mac Finder. After all, they’ve managed to find their way online, navigated the web to the SL website, found the Viewer download link, downloaded the Viewer, found the installer on their computer and installed it… As such, is understanding the nuances of inventory management that big an issue for them? I’m not convinced.

That said, there are undoubted benefits in some aspects of what is presented here: a “flat file” view may well be more to some people’s liking (providing it is better integrated with a hierarchical view as well), and the use of a pop-up “move” window could be preferable to some than relying on drag-and-drop – and it’s good to provide alternatives. I just can’t escape the feeling the perhaps LL are missing an opportunity. Given most people are liable to be familiar with the likes of Explorer and Finder, why not grab the bull by the horns and make inventory more approachable by presenting it in a similar manner to those tools – perhaps a two-panel display, with scrollable hierarchical view to the left, open folder view to the right with the associated drag-and-drop capabilities?

I’m not saying it would be easy to do (or even necessarily a short-term development). but were it possible to achieve, I’d venture to suggest it would meet with significant approach from established and new users alike.

I’ll certainly be keeping my eye on this to see how things develop. In the meantime, and given feedback is being sought, if you’ve not already taken a look at the Project Viewer, I’d encourage you to do so & pass your thoughts / suggests to LL via the forum.

	Qie on April 2026 SL Mobile User Grou…
	Inara Pey on Space Sunday: Curiosity’s disc…
	Val Kendal on Space Sunday: Curiosity’s disc…
	Sparkie Hallard on Gaeta-1 and Zindra changes: To…
	Inara Pey on Gaeta-1 and Zindra changes: To…

Tag: SL News