Following-on from the announcement that Second Life will soon be available through Steam, it appears the viewer itself is going through some small changes in order for it to be better used with SL.
Yesterday, I downloaded the latest Development version of the viewer. As per usual, I performed a clean install, removing the older version & the associated user and log files. On starting the viewer, I was surprised to see the log-in screen displayed with an additional pop-up:
Clicking Create Account pops-up the familiar “Do you want to open your web browser” dialogue box, prior to taking you (on clicking OK) to the SL sign-up page. I confess I have not (as yet) run through th actual sign-up process to see if that has changed in preparation for the Steam tie-in, but I’ll be doing so around the time the tie-in is announced as being live, if only out of curiosity.
Clicking Continue from the prompt will allow you to log-in using an existing account, and the prompt to sign-up is not repeated the next time you launch the viewer.
Alongside the new pop-up message, the actual log-in area of the viewer splash screen has been tidied-up and made more presentable.
The cleaned-up log-in credentials area of the splash screen, completed with grid access option enabled (Main and Beta grids only)
Assuming these changes are a part of the preparations for the link-up with Steam, they would appear to answer how users coming to Second Life via Steam will be directed to the sign-up pages. As such, it will be interesting to see what, if anything, will be done to make at least the initial sign-up page more informative as to what Second Life is, or whether this will be handled directly through the SL page(s) on Steam itself (I personally suspect the latter).
Linden Lab has issued a blog post announcing that Second Life will be expanding to steam “in the next month or so”. The announcement reads in full:
As some sharp-eyed developers have speculated, we’re going to make Second Life available on Steam in the next month or so.
Many of us have friends who are avid Steam gamers, but if you’re not familiar, Steam is a very popular online game platform that offers a wide range of titles (and will soon also offer other software as well).
What does this news mean for Second Life? You’ll still be able to access Second Life just as you can today; there won’t be any change to that. But, the more than 40 million people who use Steam will also be able to get Second Life as easily as they can get games like Portal.
We’ll make an announcement on the blog when Second Life is actually available on Steam, but in the meantime, if you have friends who are Steam gamers, let ‘em know it’s coming!
Steam is a digital distribution platform developed by Valve Corporation. It is used to distribute games and related media online, from small independent developers to larger software houses. The primary service allows users to download games and other software stored in Steam’s virtual software library (some 1500 titles as of August 2012) to their local computers. In addition, Steam offers a range of other services, include the ability to purchase games in your local currency, some DRM protection for titles, and a comprehensive communications platform service that allows for direct contact between users, the ability for users to join in multi-player games, etc.
It is estimated that Steam has some 54 million users world-wide as of August 2012, with an average concurrency rate of some 5 million users.
Given the volume of users enjoyed by Steam, and the fact that many SL users are also engaged in games and may well use Steam already, this move is clearly aimed towards increasing SL’s visibility and increasing the potential influx of new – and retained – users. As such, it is no coincidence that this announcement comes almost hand-in-glove with the blog post about materials processing coming to SL.
With pathfinding now “released” on the main grid, the promise of much improved materials processing on the way which should, among other things, lead to a much more “realistic” looking in-world experience, and the roll-out of advanced experience tools, the move to make SL accessible to “hard-core” gaming community using Steam could be seen to be indicative of Linden Lab’s desire to have Second Life perceived more as a “games enabling platform” than perhaps as a “virtual world”.
We’re promised a follow-up blog piece when the service is launched, possibly some time in September. It will be interesting to see how the platform is promoted and what the potential response is from the world at large.
On July 24th, Toysoldier Thor posted about an idea he calls “virtual landmarks” in the Merchant’s forum. It’s a potential solution to an age-old problem most of us in SL face at one time or another: making sure all landmarks relating to your location in Second Life are always up-to-date.
Whenever we move in SL, we’re faced with the fact that every LM we’ve ever given out for our old place is now worthless, and we have no choice but to start issuing new ones. For some, this isn’t a problem – but for others it very much is.
Merchants, for example, are faced with the fact that every single landmark they’ve ever placed within a package contained in a vendor server or magic box or in a Marketplace folder or used within landmark givers they’ve placed around the grid (at malls, satellite stores and so on), now needs to be individually replaced (and in the case of Marketplace folders, each folder manually re-linked to the relevant listing). For some this can run into several hundred items and many hours of additional work. Nor are merchants alone – the likes of role-play groups, clubs, and so on, can face similar issues, both in terms of updating landmark givers, etc., and in terms of ensuring patrons get updated LMs.
In short – it’s a nightmare.
The issue: change your SL location and old LMs no longer work – click to enlarge (credit: Toysoldier Thor)
Toysoldier Thor’s idea is so elegant and (in some respects) obvious, one is tempted to ask why such a system wasn’t developed for Second Life from the outset. He calls it Virtual Landmarks (VLMs), and it essentially works in a similar manner to how we navigate the web. He describes the idea thus:
The concept of a VLM would be identical to the critically important Internet service of DNS (Domain Name Services) in that Internet users can create and use easy to understand HOST NAMES to access all Internet services where the HOST NAME actually masks the underlying required IP Address that is needed to actually route and connect their computer to that respective host.
Well the same would hold true with VLMs. A VLM would be the equivalent to a DNS HOST NAME and the LM that is configured to be associated to this VLM would be equivalent to an IP ADDRESS.
One Change
In his proposal, rather than creating and distributing a landmark, a store-owner (or whomever) would create a user-friendly VLM (e.g. “My Wonderful Store”) which is then associated with the actual landmark for the store itself. This association is stored in a new service Toysoldier calls the “VLM Mapping Service”, and it is instances of the VLM – not the original – which are given to people or placed product packages, landmark givers, etc. When someone uses the VLM, their viewer sends a request to the Mapping Service, which looks-up the physical landmark associated with the VLM and sends the information back to the viewer, enabling the user to be teleported to their desired destination.
The beauty here is that if the underlying landmark is subsequently changed (because the destination store moves, for example), all the creator of the VLM has to do is associate the VLM record stored in the Mapping Service with the new landmark – and every instance of the VLM in existence will automatically route people to the new location when used. There is no need to pass out new LMs, replace existing LMs or anything else; one change, and that’s it.
The solution: VLMs and the Mapping Service – click to enlarge (credit: Toysoldier Thor)
There are further benefits of the idea, as Toysoldier points out:
The system could be developed such that a single VLM could be associated with multiple landmarks (such as a primary store location, a secondary store location, etc.). Then, should the primary location be unavailable for any reason, the person using the VLM would be automatically routed to one of the alternate destinations
A round robin capability could be included, such that a single VLM is linked to a number of arrival points at the same destination (such as a club or an event that is liable to be popular, etc.). People using instances of the VLM are then automatically delivered to the different arrival points in turn, helping to prevent overcrowding at one particular point
Duplicate names could be supported for VLMs through the use of asset UUIDs (so there could be many VLMs called “My Beautiful Store”, and asset UUIDs could be used to ensure a VLM sends a user to the correct destination
As with LMs at present, VLMs held within peoples’ own inventories can be renamed without affecting their function
The system does not prevent the direct use of landmarks.
While there is some potential for griefing within the proposed system (people maliciously creating an VLM with the intention of flash-mobbing a venue or mis-directing people to a location, for example), the risk is probably no greater than is currently the case with the use of landmarks. Griefing via the use of VLMs might even be easier to limit, as LL would have control of the Mapping Service and so could effectively remove / disable VLMs shown to have been created with malicious intent.
The Content Creation Improvement Informal User Group has started work on putting together an exploratory proposal for consideration by Linden Lab on the subject of morph targets.
Morph targets (also known as shape targets, per-vertex animation, blend shapes, shape interpolation in some 3D applications) are generally used for complex animations that would otherwise be hard to accomplish with skeletal animation – such as facial animation and avatar customisation. In this latter respect, the SL viewer already uses morph targets to a degree. The proposal being drafted is aimed at the implementation of a more widespread use of morph targets, for use in such areas as:
Complex facial animations on rigged meshes
Additional ways for a user to customize the appearance of their avatar
Animating the surface of a prim without the need to use a custom skeleton
Fine grained control for content creators over how their clothing and avatars deform
Morph targets: animating facial features
It is with regards to this last bullet-point that morph targets are particularly interesting to content creators, as they are seen to have significant potential advantages for clothing deformation than might otherwise be offered by either the parametric deformer, or RedPoly’s alternative approach.
The proposal outlines some of the drawbacks in the latter two approaches, and covers some of the advantages and issues in adopting morph targets. One advantage in using morph targets is that they would allow a content creator to “sculpt” how a morph target should appear, directly within their 3D application of choice, thus giving them the ability to directly control over how a mesh deforms around an avatar (or how a rigged mesh replacement avatar deforms around the base avatar). A potential issue with the approach is that morph targets require additional information to be encoded either within a mesh, or within a texture. This means that additional bandwidth will be required to transmit any mesh which uses morph targets.
Morph targets: a better means of getting mesh clothing to deform?
As it stands, the proposal is in its early phase, although the intention is to complete it and submit it to LL for consideration and feedback as soon as it is felt enough information has been put together. Geenz Spad, co-chair of the CCIIUG, is aware that at the moment, much more input is required in order to get to that stage.
“There could be more input with regards to the content creator’s and the technical perspectives,” he commented to me in discussing the proposal, “The biggest bottleneck is just getting enough input to finish the proposal at this stage.” Of the two perspectives, Geenz feels that it is the technical side of things that is perhaps the more lacking of the two and he would like to see more input from those of a technical mind in terms of potential feature implementation, advantages, disadvantages, possible issues, and so on.
If you are in a position to provide input to the proposal itself, your views would be most welcome, as would your presence at the weekly CCIIUG meetings, which take place every Tuesday, from 15:00SLT at the Hippotropolis Auditorium.
On July 31st, The Commerce Team issued the most recent update in the ongoing saga of SL Marketplace issues. The update reads in full:
UPDATE: July 31, 2012
We continue to work on testing the next Marketplace update, which includes a required upgrade (for the Marketplace, not for Residents). One benefit of this work is that we are seeing performance increases with page load and purchase completion during our testing. We are working to get this update completed as soon as possible.
Last week, fixes to help with WEB-4600 were deployed with viewer 3.3.4. We have also been working with Third Party Viewers to make sure they are handling the Merchant Outbox correctly going forward. In addition, some Third Party Viewers now support the Merchant Outbox on Linux. Please see the following Third Party Viewers if you would like to use the Merchant Outbox on Linux:
If your Third Party Viewer is not on this list, and it supports the Merchant Outbox on Linux, please send a notecard to CommerceTeam Linden. Please include a link to the download location, and it will be added to the above list.
Below is the updated set of outstanding issues with Direct Delivery and the Marketplace.
Direct Delivery
Here are the outstanding Direct Delivery issues:
WEB-4600 (Merchant Outbox failures): There are still outstanding issues with the Merchant Outbox, in addition to the issues addressed above. We continue to investigate and address these issues as they come up.
WEB-4554 (Test delivery permissions incorrect): This is on hold while we work on other issues.
Limited Quantity Support (Merchant does not have rights to copy the items for sale): This is currently being worked on. Magic Box migration will not be required until this is supported. (Note that Merchants can sell items that have next owner rights set to “No Copy”.)
Overall Marketplace
There are also several issues that occurred around the time of the Direct Delivery launch that we are still working to address, but are not issues with Direct Delivery.
WEB-4587 (listings with the wrong images): This will be addressed after the next Marketplace update.
WEB-4441 (Orders stuck in “Being Delivered” state): We have been able decrease the number of orders getting stuck and continue to work on preventing all orders from getting stuck.
WEB-4592 (Orders marked as “Delivery Partially Failed” on success): This issue is currently being worked on.
WEB-4138 (Confirmation emails failing to deliver): We are currently working on a solution to this issue.
WEB-2974 (Listing enhancement stuck in “Charging, cannot edit right now” state): This issue is on hold while we work on the other items on this list.
WEB-4696 (Deleted listings appearing in search results): This issue is on hold while we work on the other items on this list.
WEB-4567 (Bulk delete fails for some merchants): We will evaluate the priority of this once we have completed the above Direct Delivery fixes and features.
In the meantime, the due date for Magic Box migration has again been extended (as of July 26th) to October 1st, 2012.
As I’ve previously reported, the informal Content Creation Improvement Group this week had its second meeting, the majority of which revolved around mesh deformation and the available / potential options.
While the current emphasis on mesh is understandable given all that is going on, the focus of the group shouldn’t be thought of as being “only” about mesh. As I commented in my piece announcing the group:
It is intended for developers and content creators alike, with the aim of providing a collaborative atmosphere which will allow members to discuss features, workflows, and modifications with the aim of enhancing content creation for everyone on SL. As such, the focus of the new group will be:
To provide a forum in which content creators can voice their ideas and / or concerns about the overall state of content creation in SL
Encourage the spread of knowledge about content creation methodologies and tools
Suggest / discuss new ways to facilitate content creation in SL (including the use of new tools or possible improvements to the viewer)
To provide a focal-point where content creators can have questions answered and issues highlighted that might otherwise go unanswered in other user groups.
This being the case, Geenz Spad, the CCIG’s chair is keen to see more participation in the group from TPV developers – to whom he put out a request in this week’s TPV/Developer’s Group meeting – and from content creators and builders from across the grid, “It would be nice to have some feed back on other content creation issues that don’t necessarily centre on mesh,” he commented to me immediately prior to the TPV/Developer’s meeting on Friday, “I’m sure there’s plenty of builders who’d like some progress in making their workflows easier as well.”
One potential area for discussion is that of the build floater. This has already received various degrees of attention within various TPVs, with some adding extra tools and capabilities (such as the prim alignment tool) others even giving it a complete overhaul in terms of presentation. Capabilities such as pathfinding, which sees an additional information panel added to the Build floater, stand to make it even more crowded. So there is a question to be asked as to what might be done to update / improve the floater in order to provide better access to tools and options – and this potentially falls into the remit of the CCIG.
The current official build floater (l) and the Pathfinding build floater (r)
Of course, TPVs are free to determine how they wish to develop floaters, etc., for their audience – and they do take a lot of feedback from users in doing so. But the CCIG offers an opportunity for developers and creators to work together on ideas and to develop proposals that can be fed back to Linden Lab and possibly influence their thinking on things – and even help them determine what needs to be done in order to make the tools and floaters with the viewer more accessible and user-friendly.
Given the CCIG is still formulating itself, now would be an ideal time for builders and creators who haven’t previously attended meetings to pop along and get a feel for what is going on.
There is a wiki page which contains the meeting agenda and links to meeting transcripts. If there is something specific you would like to see discussed, drop Geenz Spad a line in-world to have it added to the agenda. Meetings themselves take place every Tuesday at the Hippotropolis Auditorium in SL, commencing at 15:00 SLT. See the links below for more details.
Following-on from the announcement that Second Life will soon be available through Steam, it appears the viewer itself is going through some small changes in order for it to be better used with SL.
Inara Pey: Living in a Modemworld 