Linden Lab has issued a reminder / warning to users about buying and selling Linden Dollars and taking the appropriate precautions to prevent being scammed.
Second Life users do tend to be targeted by scammers periodically, so the reminder is timely as we approach what is for many the end-of-year holiday season, with both Christmas / winterfest and New Year looming.
The blog post reads in full:
As with any online service, Second Life users are targeted by scammers from time to time. One type of scam we’ve seen recently are websites that promise huge discounts on L$ sales and even offer to buy L$.
Often, these sites use these “too good to be true” discounts to lure you into entering your credit card information, which they then steal. Sometimes, they will use trusted payment systems, but sell you fraudulently obtained L$. When these fraudulent L$ are recovered by Linden Lab, you may then struggle to recover your payment from the anonymous strangers that sold them to you.
Not only does using these sites put your credit card information at risk, but it also constitutes a violation of the Terms of Service. Remember, you can buy L$ only on the LindeX or from an authorized L$ reseller; you can sell L$ only on the LindeX.
The good news is, keeping your credit card and your Second Life account safe is easy:
Remember that the only place to sell your L$ is the LindeX, the official exchange operated by Linden Lab
Be wary of any offer (which may be made via IM or direct message) that sounds too good to be true. If the site isn’t an authorized L$ reseller, ignore it.
There are currently 47 authorised L$ resellers available for the purchase of L$, including the likes of CasperTech, VirWox, ZoHa Islands, AnsheX, DXexchange, CrossWorlds, PodeX and others which will be familiar to SL users. Many will accept payments in a range of currencies via a range of credit / debit cards as well as accepting payments via PayPal, as such there would appear to be little reason to trust non-authorised sites for the purchase of L$.
Project Viewer 3.6.11.283899 is aimed squarely at resolving the thorny and oft-critiqued issue of making mesh clothing fit a wide variety of avatar shapes, as the blog post itself notes, reading in part:
Since the introduction of Mesh to Second Life, creators have faced challenges fitting Mesh garments to the Second Life avatar. Because mesh objects are not resizable in as many ways as the avatar itself is, it has been difficult for mesh garment creators to provide garments that adapt to the shape of the avatar in the way that the image-based clothing layers do. While many creators have made heroic efforts to provide products in a range of sizes, and some have collaborated to define a set of standard sizes that work reasonably well for much of the user population, many have found that mesh garments just don’t work well enough for their avatars. Mesh garments also don’t move with the body parts affected by avatar physics.
Users have developed two approaches to address these problems:
Rigging garments to the “collision bones” of the avatar skeleton (often marketed as “Liquid Mesh”). This works in current Viewers for some body parts, but there are some avatar shape parameters that do not have corresponding collision bones, so garments do not adapt to fit everywhere on the body.
The “Mesh Deformer” project added code to the Viewer to dynamically compute how to modify each garment shape by looking at how the vertices of the avatar were changed from that of the female and male base shapes.
The Linden Lab development team has studied both approaches, and compared their effectiveness, maintainability, and performance. Neither approach completely eliminates the occasional need for an alpha clothing layer to prevent small parts of the avatar skin from appearing through garments, but both work quite well at resizing garments so that they fit the avatar and move naturally with it. While the collision bones method requires the creator to do some additional rigging, we have decided that because it leverages more of the existing avatar shape system it is likely to be the more maintainable solution and to perform better for a wider range of users.
While the two current approaches to fitting mesh clothing are mentioned in the blog post (“Liquid Mesh” and the mesh deformer), it’s worth pointing out that the “Liquid Mesh” solution is actually based on an idea first demonstrated by RedPoly Inventor as far back as June 2012 – and it turns out that his approach is the one that the Lab, via Oz Linden, acknowledge as the one that first got them “started down the path of using collision bones to do this.”
At the time Liquid Mesh first appeared, there were concerns as to its impact on the market and the potential for content breakage should it prove popular only for something like the mesh deformer to eventually arrive in Second Life, prompting calls earlier in 2013 for the approach to be blocked by preventing mesh rigged to non-standard collision bones from being uploaded. At the time, the Lab remained silent on the matter, although many did blog on the potential pros and cons about the approach, including myself. Strawberry Singh not only blogged, but produced a video showing her testing a pair of boots she’d purchased which utilised the capability.
Prior to the launch of the Fitted Mesh project viewer, I was fortunate enough to be given the opportunity to preview it, and get to try out some sample clothing to see how it works. I don’t pretend this is a comprehensive review of the viewer, the new collision bones or skeleton; nor is it intended to compare / contrast the Lab’s approach to other methods. It is purely intended to provide an overview of the viewer and how suitably rigged mesh garments are handled.
The New Bones
As noted in the LL blog post, the project viewers includes an additional set of collision bones alongside the familiar set of bones. These are:
BUTT *
LEFT_PEC *
RIGHT_PEC *
LEFT_HANDLE
RIGHT_HANDLE
* These bones are affected by avatar physics.
All of these bones, and the original avatar bones, now affect mesh clothing when the avatar shape sliders (Edit Shape) are manipulated, thus giving mesh clothing which is rigged to the avatar skeleton the ability to adjust with the avatar shape as the sliders are adjusted, thus leading to a better “fit” for the clothing.
Content creators are invited to begin experimenting with creating garments rigged to the new skeleton. To assist creators in this, a Rigged Fitted Mesh wiki page is under construction, which includes information on the existing / new collision bones, links to the male and female .fbx, .ma and .dae files, and basic instructions on getting started with creating fitted mesh, including a link to downloading the avatar skeletons and to additional external resources.
Do be aware that this wiki page is a work-in-progress, as is the viewer, and liable to both update and change.
The Viewer and a Quick Series of Tests
There are a number of important things to note before going too much further. The first is highlighted in the Lab’s blog post, and is this:
At this time, the new skeleton should be considered provisional and subject to change; we do not yet recommend selling or buying garments rigged to it. Since we may find reasons to improve it during this testing process, and any change to the collision bones will likely break garments rigged before the change, we want to make sure that we have a set of bones that we can all live with into the indefinite future before it is widely used.
The second is that as with RedPoly’s original approach and Liquid Mesh, the approach will not entirely eliminate the need for alpha layers – but then again, it’s unlikely the mesh deformer would have entirely eliminated them, either.
The third is that the viewer obviously will not work with either unrigged mesh or rigged mesh which does not make use of the new collision bones (or additional bones intended to work with the appropriate sliders).
As the test clothing passed to me was for male avatars, and presented some of the usual problems when used with a female shape (and given I have very few mesh garments in my inventory, unrigged, rigged, liquid or otherwise), Oz kindly popped over and gave an initial demonstration. As he was already wearing a mesh jacket, he quickly played with the sliders to give himself a more portly shape – with the result that his mesh jacket (as expected) no longer fitted. However, when he swapped to the rigged t-shirt in the pack, it more-or-less fitted off-the-bat.
Oz, looking more portly than his usual self, demonstrates the new project viewer and collision bones. His mesh jacket (l) which is not rigged to the new bones, fails to adjust to his altered size. The t-shirt which has been rigged to the bones, however, does (r)
On Monday November 18th, Firestorm will commence blocking older versions of the viewer from accessing Second Life.
This is a move that has been coming for some time, and has been announced on a number of occasions through the Firestorm blog, through Firestorm user meetings and Q&A sessions, and which has been repeated through various blogs, including mine.
As it is, there are a good number of users still running versions of Firestorm that pre-date the introduction of Server-side Appearance (“avatar baking”) and some which even pre-date mesh rendering. Not only does running such versions lessen the user experience and increase the workload Firestorm support volunteers have in trying to assist people on older versions of the viewer.
Nor are the Firestorm team doing this entirely off their own backs. For obvious reasons, the Lab would like to see more users benefiting from the broad range of improvements which have already been rolled-out to SL (and those still being deployed in terms of further viewer-side updates), including SSA, interest list updates, improvements to the rendering pipe, improvements to viewer / server communications, and so on, all of which should improve the user experience, even for those on older hardware.
Given that Firestorm does have the lion’s user of active users, just under 65,000 of whom are still logging-in to Second Life on versions of the viewer pre-dating the more recent SL updates such as SSA, the easiest way to encourage them to update is to block older versions of the viewer.
Many Firestorm users are still on versions pre-dating SSB and mesh rendering
This being the case, once the block comes into force, it means only users on Firestorm 4.4.0 through to the current version(s) will be able to access Second Life. As such, from November 18th, the following versions of Firestorm will be blocked from Second Life (numbers of people still using each version given in brackets):
4.3.1.31155 (40,451)
4.2.2.29837 (14,120)
4.2.1.29803 (60)
4.1.1.28744 (3334)
4.0.1.27000 Beta (4585)
3.3.0.24882 maintenance release (606)
3.3.0.24880 hotfix release (571)
3.2.2.24336 (881)
3.2.1.24179 (166)
For those who feel they may be unable to run later versions of Firestorm, the recommendation is to give a later version a go and to contact Firestorm support teams for assistance or try the Firestorm troubleshooting wiki pages, as issues encountered may be fixable. For those who have genuine issues in trying to run later versions of Firestorm, Linden Lab’s Third-party Viewer Directory offers a list of self-certified alternative viewers you might want to try.
For further information, please refer to the Firestorm blog announcement.
Please note: I cannot address technical questions relating to Firestorm through this blog. Please contact the Firestorm support groups if you have specific technical questions.
On Monday November 11th, Linden Lab issued a Commerce blog post indicating that there were changing the requirements which much be met in order to sell goods via the Second Life Marketplace.
The move, clearly aimed at preventing the ease with which suspect accounts can create a Marketplace presence and start selling goods which may have been ripped from elsewhere was announced thus:
To increase security for Merchants and shoppers alike, all new Second Life Marketplace Merchant accounts will be required to enter payment information on file (PIOF). If you would like to check your account to see if this requirement has been met, please see the Mesh Upload Status page.
Only newly created accounts will be required to meet this requirement at this time, and existing Merchant accounts will not be affected. However, we strongly recommend that all merchants complete the steps necessary to meet this new requirement.
Unfortunately, the announcement was immediately followed by confusion and negative feedback, largely as a result of the system not appearing to work as advertised, and being relatively easy to circumvent.
I contacted Peter Gray, the Lab’s Director of Global Communications about the announcement and confusion, and received the following reply:
Hi Inara,
Thanks for your email. We’ll be adding the below to the blog post on this topic momentarily:
Thanks to reports from Merchants, we have discovered a bug in the system that determines whether an account has payment info on file. We are working now to resolve this issue as quickly as possible and expect to release a fix in the next couple of weeks.
In addition, we have had some questions about the 5-day age requirement for accounts trying to become Merchant accounts. This requirement is not new, and there are no current plans to change it.
best,
Peter
This update has now been appended to the original blog post, and will hopefully help alleviate immdediate concerns, although it may also lead to further questions as to why the update was not more thoroughly tested.
Update, November 26th 2013: The amount payable for virtual land held by claimants meeting the revised criteria of the settlement agreement is L$2 per square metre of land held held. The amount payable for inventory held by claimants meeting the revised criteria of the settlement agreement is $15 USD per account. Claimants may additionally be able to forego the payment if they wish, and attempt to sell their items via the SL Marketplace.
In June I reported on an out-of-court settlement reached between Linden Lab and a number of SL residents in the matter of a dispute over virtual Lab ownership.
At the time it broke, the Evans et al lawsuit against Linden Lab has strong echoes of the infamous Bragg vs. Linden Lab situation of 2007. The action was brought by the plaintiffs after having their accounts terminated and their assets (land, content, Linden dollars) seized, as was the case with Bragg. What’s more, the plaintiffs were represented by Jason Archinaco, who had represented Marc Bragg back in 2007. In a final twist of fate, the matter was initially set to be heard by Judge Eduardo Robreno, who presided over the Bragg case.
As it turned out, the matter eventually came before Magistrate Judge Donna M. Ryu. In November 2012, she published findings on the case, which granted Subclass A of the motion filed by Archinaco on behalf of the plaintiffs whilst also denying the Main Class of the action.
Judge Donna M. Ryu
As a result of this, an initial settlement agreement was executed by the two parties in May 2013. At the time, it appeared as if a settlement amounting to some $172,000 had been agreed, which would potentially be paid out to some 57,000 users who met the criteria of Subclass A, and that the payout would be made in Linden dollars.
However, according to a report published by Top Class Actions on Sunday November 3rd, following a request by Judge Ryu, the initial settlement agreement between Linden Lab and the plaintiffs passed through a series of revisions prior to the Judge granting preliminary approval to it on October 25th, 2013. Under this revised settlement agreement, the Class Members include:
All persons whose assets, including virtual items, virtual land, and/or currency in lindens and/or U.S. dollars, have been deliberately and intentionally converted by Defendant Linden’s suspension or closure of their Second Life accounts on or after April 16th, 2008.
This is slightly different to Judge Ryu’s original findings on the Subclass, which carried no limiting date when published.
Under the revised terms, Linden Lab has agreed to return up to 100 percent of the U.S. dollar balances in the Class Members’ accounts to their PayPal accounts within 10 days of establishing the validity of the claim, and to also return up to 100 percent of the balance of linden dollars by converting them to U.S. dollars and will waive all commissions on the currency exchange. Finally, Linden Lab has also agreed to pay for virtual property and virtual items once the validity of each claim is determined.
Precisely what this means in terms of overall payout is unclear. The next step in the process is for the Class Administrator to notify Class Members of settlement by email. A hearing on the final approval of the settlement has been scheduled for February 27th, 2014.
Back at the start of the year, Simon Linden revealed he’d done some preliminary work on using Leap Motion within Second Life, allowing the former to provide some limited control of in-world avatar actions.
Now none other that our own Draxtor Despres has been trying-out the Leap Motion, and has produced a video of his experiences and some notes on using the kit with Second Life. It’s an informative piece which includes playing Loki Elliot’s The Well.
Drax uses GameWAVE to configure his leap Motion device, and the video shows he gains a reasonable level of control over avatar movement, and GameWAVE has the potential to add control beyond that demonstrated within the video.
For those into compiling their own viewers, Simon’s code is still available in the viewer-rabbit repository, but please read his notes in his original blog post.
Linden Lab has issued a reminder / warning to users about buying and selling Linden Dollars and taking the appropriate precautions to prevent being scammed.
Inara Pey: Living in a Modemworld 