As recently reported, Linden Lab have announced the first step in the retirement of Magic Boxes in order to encourage remaining merchants who have not done so to swap over to Direct Delivery.
At the time I posted that piece, I noted that a major stumbling block in the adoption of Direct Delivery was the fact that while it tended to work flawlessly for some (myself included), for others it has been at least as problematic as using Magic Boxes, and that Marketplace issues with DD were potentially as widespread as those for Magic Boxes.
To help overcome both reservations on the part of merchants who have not yet swapped over to Direct Delivery, and to help resolve any remaining issues with DD migration, the Lab has moved to do two things:
Launch a fresh Direct Delivery FAQ which attempts to answer some of the most common basic questions around Direct Delivery and also point towards other resources
Launch an updated Merchant Outbox project viewer. This viewer, built on 3.4.4 code, and so pre-CHUI, is designed to overcome all Merchant Outbox issues recorded in JIRA WEB-4600, and the advice for anyone still encountering migration problems is to give this viewer a run.
If you’ve been using a more recent (3.4.5 or 3.5.0 code base) LL viewer, note that you might find your toolbar buttons vanishing when you run this project viewer – it’s a known issue, and buttons can be restored from the Button Toolbar.
An updated Merchant Outbox project viewer has been issued to assist those encounter problems migrating to Direct Delivery
In addition, Dakota Linden has been responding to requests and questions regarding migration posted to the Merchant’s forum, and her responses may also be of assistance to those encountering problems.
Update March 4th: The main viewer download links on the Sunshine wiki page now all reference the updated viewer version (3.4.5.271118).
Update March 2nd: Just as a point of clarification, the update discussed here is not currently linked-to from the Sunshine wiki page. To obtain a version of the viewer with the updates, you will need to download version 3.4.5.271118 of the viewer (link repeated here for ease-of-refernce).
As I recently covered, a problem has emerged with Server-side Baking in that it “breaks” the Z-offset capability found in the majority of third-party viewers.
The Z-offset allows the vertical height of an avatar above the ground to be adjusted, such that sits and kneels don’t leave the avatar apparently floating in the air, and which allow those with very tall / giant avatars or very small / petite avatars and those wearing full body mesh to similarly adjust their vertical placement relative to the ground / floor.
The problem was reported to Nyx in week 8, and SUN-38 was subsequently raised by Henri Beauchamp on February 24th to officially log the matter.
On March 1st, Linden Lab issued an update to the Server-side Baking project viewer (release 3.4.5.271118) which is an attempt to address the issue.
The new capability is referred to as SH-3909 Support avatar height offset and is described as, “Adding a new visual param that allows users to manually adjust an offset for how far off the ground (+ or -) their avatar’s root bone is.Supports the +-2m range people are used to adjusting in their viewers, but new implementation should support server-generated appearances.”
It appears within the viewer as a new slider in the Body section of the Edit Shape floater, called “Hover”.
The new “Hover” option in the Edit Shape floater’s Body tab
Moving the slider to the right or increasing the displayed value will move your avatar upwards, much as increasing the Z-offset value in a TPV will. Moving the slider to the left or decreasing the displayed value will move your avatar down. As with all the shape sliders, any changes must be saved prior to exiting the editor, in order to be persistent beyond editing.
The slider offers a huge range of height adjustment compared to the z-offset slider in the likes of Firestorm, and is somewhat less accurate – with most TPV Z-offset options, height above ground can be precisely adjusted to 2 decimal points, whereas the Edit Shape floater only allows whole numbers in the range 0-99.
The “Hover” option presents a huge range of vertical motion when adjusting, which should accommodate the both the tallest avatars …
The vertical range of movement can be considerable, and lead to some interesting results when saved – your avatar can currently disappear entirely underground, for example. Also, adjustment made using the slider are not apparent in viewers which do not have the SSB code – something which shouldn’t be a major problem, given the need for people to be using SSB-enabled viewers once the server-side code starting deploying to the main grid anyway.
What might be of greater concern, however, is the fact that the control has been incorporated into the Edit Shape options means that it cannot be used on No Modify shapes, which could leave those using such shapes still feeling aggrieved if they are impacted by the height offset problems resulting from SSB.
…and the shortest.
It’s an interesting approach to solving the problem – and it would appear that LL consider the matter now resolved, Nyx Linden having issued an e-mail to the opensource dev list which reads in part:
Added a new parameter to shapes to replace the viewer-side height offset. Since it is stored in a wearable, the new back-end can read and use the value. Will send an email to third-party devs later today to let them know to pick up the patch.
Marking SUN-38 as resolved.
Given that earlier in the week – at the Content Creation User Group meeting on Monday February 25th, where the subject of SUN-38 was raised, Nyx commented, “It hasn’t escaped our notice. We’re considering a couple different approaches … we’re considering a few different options. Suggestions appreciated, but we haven’t officially settled on an approach we’re going to commit to publicly just yet”, it will be interesting to see the response is to this particular fix.
With thanks to Latif Khalifa, who both provided me with news of the arrival of this update, and provided the necessary links for me to have a play.
Linden Lab issued one of their (increasingly rare) blog updates on ongoing work with Second Life. The updates comes on the heels of the release of CHUI, the Communications Hub User Interface, which reached LL’s development and beta viewers on the 26th and 27th February respectively, and which I’ve briefly overviewed. Until now, the only official notice of CHUI’s arrival had been via a forum post which hasn’t been entirely visible, so the blog update include Torley Linden’s informative YouTube video on the release.
The update also references the e-mail preference changes made to the Marketplace at the start of February, as well as passing comment on region crossings, noting:
We have made several improvements to region crossing that allow a smoother transition between regions, instead of the jerky transition some users experienced in the past. This change also reduces the rate of teleport failure rate. This went out the full grid on January 25, 2013. Since that date, the number of reported teleport failures has dropped by 91%.
While teleport failures may have been reduced, many are still seeing continued issues with vehicle crossings …
The Cocoa project for the Mac builds of the viewer, which I made mention of in week 8, and offers a link to the Cocoa Project viewer for Mac users.
Finally, the post looks ahead to upcoming features and updates – but sadly, only makes passing mention of the materials processing project. One can hope that as CHUI is now in the beta viewer and there was, s of week 8, apparently only one remaining issue with materials to be dealt with, a project viewer will finally be appearing sooner rather than later …
Update February 24th: Henri Beauchamp has filed a SUN JIRA on the Z-offset issue mentioned in comments following this article. Z-offset is an opton found in many TPVs which allows the vertical height at which an avatar stands / kneels / sits / lays to be adjusted through the viewer, allowing users to compensate for their avatars appearing to float in mid-air. The SSB code effectively “breaks” this capability. The JIRA description carries a comprehensive description of the issue for those unfamiliar with the problem.
Update, February 23rd: The Catznip team (which includes Kitty Barnett, have added a post to their blog on the subject of RLVa and SSB. Be sure to read it!
Following the recent Server-side Baking (SSB) pile-on / load test, I took a little time out to try-out the various viewer versions which are starting to appear which provide SSB support. This was not intended to be an extensive break test or anything – just something to sate my own curiosity on a number of points.
As such, the tests I conducted were simple, and as they were performed on Aditi, they may have been influenced by some of the inventory issues being experienced there. For the tests, I used my main account, and my CTA – Crash Test Alt, which routinely gets used when testing experimental viewers, etc.
Testing covered the Cool VL experimental branch, Singularity Alpha release with SSB support and Radegast 2.8. Throughout the tests, my CTA was running the official Sunshine (SSB) project viewer 3.4.5.270409. Testing did not include Lumiya, which has SSB support implemented. The reason for this is that I remain unable to log-in to Aditi with Lumiya.
I started with a couple of baseline tests to remind people of what is going to happen once SSB is deployed to the main grid.
The three faces of SSB:On the left, what is seen when running a viewer which does not support SSB: the viewer user looks fine, but everyone else is a grey ghost. In the centre, what is seen when looking at someone who is using a viewer which does not support SSB: they are a cloud. Right: what is seen when both parties are using a viewer with SSB support: properly rendered and dressed avatars (remember: SSB does not affect prims / sculpts / mesh, hence why these render OK in the non-SSB viewer)
Following this, I switched to using Singularity first and then Cool VL.Results wer as expected – both accurately rendered outfits and outfit updates without any significant issues.
SSB on Singularity: Top: as I render in Singularity with SSB, as seen by myself (l) and with the official SSB viewer (r). Bottom: as I appear after an outfit change to both myself in Singularity (l) and the official SSB viewer (r).
Testing Radegast 2.8 also generated the expected results: outfits rendered correctly in both the Radegast 3D viewer, and in the SSB viewer, as did any outfit changes made via Radegast. Furthermore, and as expected, outfit changes made using one viewer were accurately reflected when logging into another viewer (so outfit changes made in Singularity were accurately rendered by Radegast, for example).The only issue I actually encountered was that footwear would not render correctly – which is not an SSB issue.
Baking on Radegast: (top) outfit changes on an SSB-enabled region render correctly in Radegast and (bottom) are also correctly rendered in other SSB-enabled viewers
SSB and RLVa
While carrying out these tests, I also took a look at RLVa on SSB, and confess to not finding any obvious issues when using Singularity or Cool VL (which uses RLV). All RLV/RLVa options functioned as expected:
Items “locked” as non-detachable remained undetachable until “unlocked”
Restrictions applied through RLV/a all functioned as expected (e.g. map restrictions prevented access to the World or Mini-Map; inventory denial prevented inventory access, etc.)
Remote access to #RLV Shared Folders worked as expected (i.e. remote changes of outfit worked and were accurately rendered)
Remote (HUD-based) access between avatars worked as expected
Control zone restrictions applied / released as anticipated.
This does not necessarily mean that RLVa is not “broken”. I actually have no idea if the Cool VL experimental or Singularity Alpha contain specific updates for RLV/RLVa outside of any work Kitty Barnett may be undertaking for RLVa and SSB.Aslo, just because the basic functionality of RLVa appears unaffected by SSB does not means that there are deeper, more subtle issues which need to be addressed in order to ensure all of RLVa continues to function correctly under SSB.
Summary
SSB is beginning to find its way into TPVs and appears to be working well – which is not to say that there are not bugs and issues still to be resolved with the service as a whole. Doubtless, we’ll find out more on this as LL continue to analyse the results of the initial pile-on test, and further tests are undertaken in the future. As a result of this quick-and-dirty play with the service over a number of viewers, I’m certainly curious to know if some of the issues encountered during the pile-on / load test (such as a noticeable slow-down in the time needed for outfits to render after a change) might be indicative that the system still needs tweaking in order to handle larger numbers of outfit changes, rather than all the problems being related to other issues on Aditi itself.
In terms of potential RLVa issues, I draw no conclusions; as mentioned above, the fact that the most obvious RLVa functions worked OK for me is not to say RLVa and SSB are without issues; there is much which goes on “under the hood” with RLVa which could very well be affected by the arrival of SSB which requires code refactoring but which does not result in outright / obvious breakages.
If you’d like to have a play with SSB for yourself, use the links below.
Not too long ago, I discussed the matter of tier and revenue. The main thrust of the piece was an attempt to point out why tier cuts, rather than being the magic bullet which will solve all of SL’s perceived woes, are actually likely to inflict a mortal wound.
As a part of that piece, I scratched the surface of other options open to LL for revenue generation – including the use of advertising. Now, to be fair, the idea wasn’t mine – it is something my dearest Lord of Dee, Ciaran Laval suggested in his blog (which, if not on your reading list, should be).
Indeed, outside of SL, the Lab have already dipped a toe into the use of web advertising as a potential source of revenue in launching dio – which is specifically geared towards revenue-through-ads.
dio: LL dipping a toe into the waters of revenue-through ads
Well, now it seems as though LL are taking Ciaran’s advice on board: advertising using Google AdSense / AdChoice is starting to filter into the SL webpages.
Again, Ciaran reported on this ahead of me, and a thread is up on the forums concerning the move – and the negativity is strong, sadly. The ads themselves comprise a banner at the top of some pages, together with a vertical ad space down the right side of a page. As such, they are not overly obtrusive, but they are noticeable.
Google AdSense / AdChoice ads starting to filter through the SL website
I could have sworn I actually had an ad appear on my dashboard earlier, but I was scootling around so much, I’m not sure – and repeated clicks on my browser’s BACK button failed to turn up anything.
As mentioned above, the reactions on the forum thread haven’t been overly positive to this move – but it is hard to fault it. Advertising is a fact of life on the web, and if LL can use it to generate a modest additional flow of revenue to their coffers, then all power to them – it’s not as if we can’t avoid the ads if we so wish; there are plenty of browser plug-ins available for those wo don’t wish to see ads popping-up hither and thither.
Currently, the ads have yet to hit the SL Marketplace, which would appear to be an ideal target for advertising, given the volume of traffic it receives, providing the page layout can be tweaked sufficiently enough so that real world ads aren’t getting confused for SL product ads. As I mentioned back in January, when discussing tier, the Marketplace would potentially be the ideal spot for LL to try-out Ciaran’s idea for strategic partnerships with other companies.
It has been suggested that perhaps the system could be extended to provide in-world businesses the opportunity to use the advertising space as well. I’m actually not convinced this would actually work, for a number of reasons. Which is not to say it shouldn’t be tried, is the software would allow for it in a meaningful way (i.e. links to in-world stores and / or SLMP listings. Certainly, it wouldn’t be the first time LL had offered direct advertising opportunities to users, as those of us who remember the MOTD promotional “opportunity” from 2010. However, were LL able to walk a similar path again, I would hope they’d avoid trying to charge people between $1,500 and $4,500 USD, as they did with that offer …
Overall, there is no real harm in LL seeking to generate money in this way – and it really shouldn’t be taken to mean the company is in “dire straits” financially. It may not generate a significantly large amount of revenue when compared to land, but that doesn’t invalidate the move as a means of removing at least a further small portion of reliance on tier as the company’s sole means of revenue generation.
While I’ve been buried in dio, working on an interactive guide to … something … Linden Lab slipped out another little surprise this week via the blog.
Reaching Out into Second Life looks at the use of Leap Motion for interacting with SL. The work is being carried out by Simon Linden, and is clearly tagged as experimental, but it shows the potential of Second Life as a platform for exploring gesture-based interactions with controllers like Leap Motion.
Nor are the Lab keeping matters to themselves. The blog post states:
If you have a Leap Motion controller and would like to experiment with the Second Life Viewer, you can find the source code for these experiments at http://bitbucket.org/simon_linden/viewer-rabbit. The indra/newview/llleapmotioncontroller.cpp file contains most new functionality. The Viewer is built to work in several different modes. These modes can be used to control the avatar while flying, send data into Second Life for scripts to intercept, detect hand motions that trigger avatar gestures, or control the camera and avatar movement. To switch between these modes use the “LeapMotionTestMode” value in the Debug Settings, accessible from the Advanced menu.
Commenting on his work, Simon Linden re-emphasised the experimental nature of the work and it’s possibilities, “It’s nowhere near a real feature. But it’s certainly fun to make things happen waving your hand around … I think we’ll see some very interesting stuff in the future.” He went on, “I think there’s potential there, along with touch screens, but it’s going to take a lot of work and experiments to see what really is good or not.”
The Leap Motion device for Windows / Mac (image courtesy of leapmotion.com)
If you’re wondering why Simon has his hand cocked sideways when firing the pop-gun in the video, he’s not trying to emulate any cool Hollywood or gangster-style of shooting, the Leap Motion device sensors demonstrated a blind spot when he was testing the unit, and would not register his thumb motion if he had his thumb pointing upwards.
For those wishing to try things out for themselves, Leap Motion can be ordered from the Leap Motion website, with prices starting from $69.99 + shipping (for the USA), which does not make it prohibitively expensive. It’s also capable of being put to a wide variety of uses as Leap Motion’s own promo video demonstrates.
Inara Pey: Living in a Modemworld 