New experience tools: details starting to emerge

LL have started releasing more information on the Advanced Experience Tools developed during the creation of Linden Realms and its predecessor game demonstrated at SLCC-2011.

The blog post (yay! BLOG post!) provides an overview of the new tools and permissions, with the video providing further information. Bear in mind when reading and watching that this is only an initial announcement and that as such, further information will be forthcoming…

The video delves a little deeper into the creation of the tools themselves and which includes some interesting factoids and tidbits of information.

One of the tidbits demonstrates the popularity of the Linden Realms game, which has 5,000 unique visits per day, for a total of 249,000 unique visits since the game opened in (I presume) Beta. Had the game relied upon a “traditional” means of HUD attachment via people’s inventories, the game would be generating 4 million new inventory items per month!

The tools discussed by both blog post and video are:

Teleport agent: this is a new LSL function that enables an agent (avatar) to be teleported automatically to a given location / destination. Within Linden Realms, this is used when people are “killed” by the various threats to their safety; within the video, the LL spokesperson suggests a further interesting use for the capability: the teleport “gun”…

The function supports both local and remote teleports and also respects teleport and access permissions.

Temporary Attachment: this functions is a similar manner to llAtach, but avoids the creation of an item within a user’s inventory. This has two benefits, the most obvious being that people’s inventories don’t get cluttered with items each time they visit a region where the function is in active use and the second, as an extension of this, the asset database itself isn’t overloaded with millions of requests (again, Linden Realms would be generating an estimated 4 million items a month if using llAttach). Attachments for both avatar and screen (HUD) are supported.

The blog and video indicate that temporary attachment is not  forced attachment, but a part of the overall Experience Permissions system.

LR Portal: a means of enabling the enhanced permissions system

Experience Permissions: this is a simplified version of the existing permissions system currently in use across the grid. Under the current system, permissions to control your avatar would need to be handled on a case-by-case basis. In something like the Linden Realms game, this means that rather than “dying” and being teleported on contact with a rock monster, the player would get a pop-up asking them if they wish to “die”.

Allowing these permissions to be granted requires action on the user’s part – such as walking through the Portals in the Linden Realms game, but they only need to be granted once, and can be applied across multiple regions (again, as with Linden Realms), allowing for large, continuous experiences to be built.

Permissions that can be granted (according to experience requirements) include:

  • Teleporting
  • Attaching objects to an avatar / screen
  • Control / track camera
  • Trigger animations

The permissions system is specifically geared to prevent more dangerous permissions such as inventory access, debit a user’s account and change links.

Potential Uses

The potential uses for these tools in terms of games and adventures are clear. However, there are wider applications for the tools, including:

  • Providing a means for guided tours within sims – providing avatars with HUDs that suggest directions around the sim, allow items of interest to be identified, information relating to those items to be displayed, and so on
  • Providing a means for store owners to enhance the in-world shopping experience  – including how demo items can be provisioned to users using the temporary attach option
  • The enhancement of more interactive experiences ranging across multiple regions.

Professional Creators Programme

In line with the new tools, LL will be launching a Professional Creators Program. Details on this are currently scant – the blog post simply states, “This program will provide members with helpful resources, such as tutorials and exclusive closed betas. More information will become available in the next few months”. However, Rodvik gave some pre-hints on this via Twitter a couple of months ago, and it seems likely the programme will, like mesh, require filing of some personal information with LL and perhaps taking some form or tutorial like the mesh status upload tutorial. From Rodvik’s comments, the requirements shouldn’t be that intrusive, but given the potential uses of the tools, are seen as precautionary against misuse.

For those wishing to be updated on news and information on the new tools, there is also an in-world Group  – the Advanced Creator Tools Notification Group  – which can be joined free-of-charge.

Appetites are bound to be whetted at this news (and there are already a fair few in the Advanced Creator Tools Notification Group already!) – and at the little teaser included in the blog post that LL have, “Produced a number of other tools and prototypes to support more rich content creation that we look forward to releasing”.

Beta Grid inventory issues

This comes by way of Nalates Urriah, who keeps a finger on the pulse of things technical on the servers-side of SL (as well as covering much else). Due to the nature of the problem, it’s worth repeating here.

There is a problem with inventory on the Beta (Aditi) grid. Essentially, the inventory you have on the Beta grid is a copy of your Main grid inventory. However, it only gets refreshed / updated when you carry out a change to your log-in password. Recently, people who have been changing their passwords to refresh their Beta grid inventories have subsequently had at least two problems:

  • Anything “new” in a refreshed inventory (i.e. was not there prior to the password reset) will not rez in-world the inventory
  • Things created following the password reset and saved to inventory may vanish at the next log-in to the Beta grid.

Additionally, people are reporting that after initially logging-out of Aditi, they are unable to re-log to the same region, as they get a “region unavailable” error, whereas the region in question appears perfectly OK post log-in.

Given people are being asked to try-out various elements of new SL capabilities on Aditi, this is causing some concern and tending to put a major hole in any ability to test such capabilities. For those logging-in to Aditi for the first time (or the first time in a very long time), this may mean that very little will rez from MY INVENTORY, depending upon how long a person has been involved in SL and how their inventory has matured over the years.

A JIRA has been raised on the issue – SVC-7727 – if you’ve experienced the issue for yourself, please make sure you Watch it – and if you have specific details of cases where you experienced the problem that aren’t already listed, please add details.

Viewer release summary 2012: week 9

Updates for week ending: 4 March, 2012

As per usual, a number of updates this week. LL released a new version of their Development Viewer and updated the Direct Delivery Project Viewer. Catznip went to release R6 and got a TPV Directory listing (congrats!), marking their “official” graduation to public Viewer. Lance issues his “Fujiyama” release of Dolphin (2.3.9.23177), so-called as it includes various photography updates. Niran’s Viewer hit release 1.28 and Zen 3.3.1.1, with releases of these Viewers averaging at one per week. Cool VL moved to 1.26.4.1, and appears to have seen the removal of the experimental versions (none listed on the blog when checked today).  All others remain unchanged.

Changes since the last round-up shown in green.

SL Official Viewers

Available for: Windows, Linux, Mac

V3.2-based TPVs

V1-based TPVs

This is intended to be a weekly round-up of current public SL viewers (of which I’m aware / for which I have information). As few Viewers are static, and releases are made according to individual development cycles, further versions of any given Viewer may well be released between these updates, and as such the information here may become out-of-date as the week progresses. Please check with the relevant download pages.

Related Links

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

Catznip R6: purring along

catznip logoJust as I pushed out the weekly Viewer round-up, Kitty and the gang slipped out Catznip R6, which nicely compliments (and perhaps complements!) R5. My timing sucketh.

R6, based on LL 3.2.7 code, is a maintenance release that fixes a range of bugs and gives Group management some love and attention and well as adding other nibbles to enjoy.

Changes to Group Notices

If you’re constantly pushing out Group Notices, you’re liable to like this. You can now create a Group Notice without having to open Group information first. Simply display your Group list (COMMUNICATE->GROUPS or CTRL-SHIFT-G), right-click on the name of the Group for which you wish to create a notice and select CREATE NOTICE. You can still create Notices in the usual way as well – via the Group information floater itself, but the menu option is liable to be a timesaver.

Nor does it end there. Rather than being confined to the Group floater, the Create Notice option now gets a floater of its own, meaning that when used with the new menu short cut, less screen real estate is used-up. All the functionality associated with raising a Group Notice is retained, and the floater can be resized to suit your needs while writing.

New Group Notice floater (shown here being opened the “conventional” way)

Viewing a Group’s archive of Notices is now also easier, thanks to another addition to the contact menu: simply right-click on a Group in your list and select VIEW NOTICES to immediately display the history of recent Notices for the Group in the Group floater.

Staying the Groups, the Group toast has been reworked for greater clarity with:

  • The details of the notice sender and Group are now displayed on separate lines and are clickable – clicking the Group name will open the Group’s profile; clicking the sender’s name will open their personal profile
  • The number of visible lines in the Notice has been increased from 7 to 10 for better readability
  • The date is displayed in a smaller font to provide better separation between it and the notice title and the main body of text.

Finally, Groups get a handful of bug fixes, as detailed in the release notes.

Windlight Updates

R6 brings with it additional Windlight options and a nicely cleaned-up list (WORD->ENVIRONMENT SETTINGS->CUSTOMIZE MY ENVIRONMENT->FIXED SKY) which includes creators’ attributions wherever possible, which is a nice acknowledgement to see. TBH, I can’t specify which of the list are new – as I’ve never actually looked at what was there to start with in Catznip (shame on me, I know), but the release notes refers to them as a “huge stack”, so there should be a lot for regulars to enjoy.

Elsewhere there are nips and tucks – the delay that may be experienced when right-clicking and . or editing an object has gone, so menus, etc. immediately respond, issues around the multi-line chat freezing the word view have been corrected, etc.

Chat also sees any character opening the chat bar or focusing on Nearby Chat when WASD is set to start typing. All I can say on that is “Three cheers!” As someone who has her WASD set for typing rather than movement, the tendency for some Viewers to ignore various keys has been a source of considerable teeth-grinding…

As updates go, this may well appear to be a small one, but it again demonstrates that Catznip remains highly innovative in examining how people actually use the Viewer and its UI on a daily basis and in seeking ways and means to make common tasks easier to access and get on with.

Related Links

Received Items: the good, the bad and the “$%^&*!”

So, as I was updating the Viewer Round-up for this week, I thought I’d have a run with the new Received Items Beta launched last week.

Those familiar with Direct Delivery testing will already be somewhat familiar with Received Items – it is a section of the Inventory floater wherein anything purchased from the Marketplace will show up. However, the overall functionality has now been extended so that anything you obtain or receive by way of a “new” inventory item will pop-up within it.

To test the new functionality, you’ll need to run one of the following versions of the official Viewer: the Beta (3.2.9.249510 or later), Development (3.3.0.248913 or later) or the Direct Delivery Project Viewer (3.3.0.249395 or later). For testing, I used the latest Beta, 3.2.9.249510, which has been available since before the Received Items Beta was announced, but which has the Received Items capability available within it.

You’ll need to be on the Beta grid (Aditi) to carry out the tests, and will need to visit one or more test regions, as detailed in the Received Items Beta wiki page and my original blog post on the subject.

Where to Find the Panel

I’ve read reports of people having problems finding Received Items. It should appear as a “button” at the bottom of your Inventory floater. Clicking the “button” will open-out the panel.

Opening Received Items

If, for any reason, the button is not apparent within your inventory floater, try this (with thanks to Innula Zenovka):

  • Go to the Fast Return test region on Aditi (this is the LIGHTER GREEN area within the GC Test 9 region)
  • Rez a prim and wait for the auto-return to send it back to you – it’ll take around a minute
  • Open your inventory floater and the Receive Items “button” should now be visible – click on it to open it as described above, and your prim should be sitting inside it

I spent an hour or so playing in the test regions to see what Received Items does / does do, and here’s a summary of my findings, together with some broader observations and feedback.

Situations where there is no change to current behaviour

  • Rezzing an item from inventory – the item will still return to its originating folder when you TAKE it back
  • Taking a copy of a rezzed object you own will still return it to your Objects system folder
  • Trying to rez / build in a no rez area will generate the usual warning without anything being rezzed / returned
  • Trying to move an in-world object into a parcel with NO OBJECT ENTRY set: item will be blocked and the usual pop-up displayed

Situations where Received Items IS used

  • Creating a new object or linkset and taking it to inventory
  • Taking a copy of an object belonging to someone else (permissions allowing
  • Purchasing / taking anything from an in-world object (prims set to give / sell, Vendor systems, etc.)
  • Anything returned to you manually by someone else, or via parcel auto-return
  • Anything someone else gives you in-world
  • Items sent to you while off-line
  • Multiple items in a single delivery (e.g. items from a suitably scripted giver or passed to you via folder)
  • Anything you purchase via SLM or which is brought for you as a gift.

Other points of note

  • When receiving items via a transfer when on-line, you will still receive a pop-up notification – but without the ACCEPT button, which has been replaced by SHOW – clicking this will open your inventory floater and the Received Items panel. The remaining options, DISCARD and BLOCK remain unchanged
  • If you are offline when an item is sent, you’ll still get a notification sent (which will appear when you log-in and get sent to your e-mail, if you have IM forwarding set-up) as per current behaviour
  • Recently received items tagged as “New” (click to enlarge)

    Recently received items will be tagged as “New” in Received Items, helping with identification (right)

  • Received Items provides almost the same degree of functionality for items it contains as the rest of your inventory. However:
    • You cannot directly rename items (i.e. right-click and select RENAME from the menu), although you can select the item’s Properties and rename it from there, if permitted
    • You cannot paste a copy of an object into Received Items (but you can obviously paste it into your main inventory panel wherever you like)
  • If you delete items from Received Items and they will go to your Trash, as usual. However, if you subsequently restore an item from Trash that was in Received Items – it will go to the most appropriate folder in your inventory (so a notecard will be restored to Notecards, a landmark to Landmarks, etc.)

Received Items as a Folder

Received Items seen as a folder in the RECENT tab (click to enlarge)

For those that like to use the RECENT tab in inventory, it is worthwhile pointing out that Received Items also appears here as a folder (although there is no corresponding folder in the main inventory view). The folder view has the same functionality as the panel, but offers an alternative way of viewing incoming items. The major difference between the two is, when viewed as a folder in the RECENT tab, Received Items does not display “New” against recently received items.

However, this will only last during your current SL session – as soon as you log-out from SL, the “Received Items” folder will vanish from RECENT, just like everything else, leaving you with just the Received Items panel to peruse the next time you log-in.

On the good side

Providing a single “point-of-entry” for new items coming into inventory may well ease the process of understanding how works inventory and getting newcomers started on good inventory husbandry and may encourage those who don’t engage in inventory  housekeeping to do so… Which is not to say this new approach is without issues or necessarily preferable. Right now, it has to be said the negatives outweigh the positives.

On the poor side

There is no hierarchy to Received Items: Outside of items that are received into folders via their delivery mechanism (e.g. SLM or a scripted object), Received Items presents a “flat” view of incoming goods. This is liable to create a headache for some.

For example, many in the rental business put-out “for rent / sale” signs on their vacant parcel, and may add trees and other bits and pieces – up to and including houses and sim extenders on the parcel as well. Some or all of these get returned by the new tenant when the parcel is rented – and until now have gone to the Lost and Found folder, where they can be easily identified and disposed of.

But under the new system, all this now gets lumped-in with everything else the Estate Owner / Manager is receiving as well. This could get very onerous in terms of sorting through stuff and separating the wheat from the chaff.

There is no capability to sort / order / filter items: Obviously, the intention is for Received Items to be routinely cleared-down by users on receipt of incoming goods, no matter what the source. However, there are going to be times when – even with the best intent in the world, the Received Items panel is going to run the risk of getting choked  – such as in the case of estate management as mentioned above, or where information is specifically requested via notecard (such as requests for product help) and so on. Even someone being away from SL on vacation for a week or to could come back to find their Received Items brimming. As such, it would be nice to offer people the ability to sort / order / filter contents.

Creates an artificial divide in inventory: The Received Items panel does tend to split inventory into two, and unless it is clearly and properly explained to the likes of new users, it could end up creating as main problems as it is intended to solve, particularly if new users are no encouraged to use it as intended, but simply allow incoming items to reside in the panel. Communication is the key here – and that’s not really LL’s strongest suit.

(Currently) does not appear to solve the capped IM problem: I have read from feedback elsewhere, but have been unable to verify myself, that this new approach doesn’t presently overcome the problem of goods failing to be delivered if IMs are capped. Whether this is because the code itself doesn’t contain a “fix” for doing so, or whether it’s actually not working as hoped, I can’t say. However, this is causing concern, and may still need to be addressed.

Opinion

There has been a lot of negative feedback from users on this new approach. Whereas Received Items was accepted for the forthcoming Direct Delivery system, people are questioning why everything now has to go into Received Items, rather than the more intuitive approach we currently have.

I personally can see both sides of the coin: as an established user, I’m very familiar and comfortable with the current behaviour – notecards coming in go to Notecards, landmarks to Landmarks, and so on. As such, I can only see this approach as being something of a step backwards – and I’m someone who is pretty obsessive about keeping my inventory sorted.

However, for new users, then the system – again with the caveat of “as long as it is properly explained” – offers a much easier-to-understand approach to the receipt of goods and items. At least initially. There is also the fact that it does present (or should eventually present) one consistent mode of behaviour for new items entering inventory – and consistent can be often be good.

The problem really is that this approach is one in which – yet again – established users appear are being faced with something that is definitely less intuitive and potentially useful than the current system in order to “improve” matters for the ever-elusive new user. Even for those (like me) who are obsessive about keeping inventory sorted, this approach adds an irritating additional level of management, simply because we do now have to faff around moving various received items around that once pretty much took care of themselves in the first instance.

As such, Received Items does run the risk of leaving people with the impression that the existing user community simply doesn’t figure in LL’s thinking, and how we use SL on a daily basis simply isn’t really understood. I could say more on that topic, but Saffia Widdershins already has, and very eloquently.

Related Links