I’ve always loved dancing in Second Life; I especially loved going out to a really good ballroom and spending the evening with friends and loved ones, begowned, bejewelled and dancing under the stars.
For a good while, my spiritual home in this regard within Second Life was Birdland, a beautiful build by Alma Fushikizoh. This was a wonderful place to pass the time, dance, converse, and have fun – and it was an awesome build as well. Sadly, as with many things in Second Life, Birdland was lost to us, and I’ve never really found anywhere to replace it.
Until now.
Now there is a new venue for romantics to enjoy. Set in formal gardens, surrounded by trees and offering quiet love seats and water-side benches, Secrets is one of those rare finds and an absolute delight.
Secrets Ballroom
The ballroom is a wonderful piece of architecture, graceful in its simplicity and providing the opportunity to dance under a glass dome etched with stars; tables and seating are provided around the edges of the main dance floor and open doors invite those so minded to take a walk through the gardens and admire the water feature by Followmeimthe Piedpiper and marvellous sculpture of a dancing couple by Pumpkin Tripsa.
In the wake of the arrival of mesh, and in the hope of alleviating confusion / making things a little more understandable, there are changes coming down the road for Viewer 3. Some of these will undoubtedly make their way into TPVs as well, so here’s a quick overview.
The changes described below can be seen in the latest Mesh Development Viewer from Linden Lab (3.0.5 (240741)+), which can be obtained from the alternate viewer wiki download page. note that as this is a development Viewer, some elements may change in relation to descriptions provided here.
Prim Equivalence and Land Impact
For a general user perspective, this is probably going to be the most obvious change.
Prim Equivalence, or PE has been an issue on many levels, not the least of which, for consumers, is that it tends to be bracketed with a prim count value – and is frequently greater than the associated prim count (although there are items where the reverse is true). People therefore get confused as to which is the key value: prim count (which everyone is familiar with) or PE.
In order to try to solve these issues, the terms “Prim Equivalence” and “prim count” are set to be replaced by a single value: “Land Impact”. How this will work takes a little explaining on two fronts, as it relates to a couple of changes within the Viewer and how we need to view things. So bear with me while I attempt to explain.
The first of these changes is that land will no longer be referred to in terms of prim counts and usage, but rather in terms of its “capacity”. Essentially, this means that:
Full sims have a “capacity” of 15,000
Homestead sims have a “capacity” of 3,750
OpenSpace sims have a “capacity” of 1,875.
Land parcels will also be referred to in terms of their “capacity”:
About Land today: prim counts (l); As it will be: capacity (r) (click to enlarge)
This might all sound like unnecessary semantics – but it does have a point in that it allows everything to be thought of equally, regardless of its origin – as we’ll see below.
Note as well, that nothing is physically being “lost” from your land. A 4096 sq m parcel that had a prim count of 937 prims before the arrival of the new Viewer will simply have a “capacity” of 937 after the new Viewer has entered general use, as shown by the figures highlighted in green in the above images.
To align with this, objects need no longer be through of in terms of their prim count or their PE – but simply in terms of their Land Impact – that is, how much of the available “capacity” on a sim / parcel they take up. This is reflected in changes being made to the Build menu floater:
Build floater: As it is with Prim count & PE (l); The new Land Impact values (r)
As can be seen, the prim count / PE values are being replaced with two simple figures:
The impact the rezzed object has on the land
The remaining capacity that is available for rezzing further objects.
So if an object has a Land Impact of 15, it will reduce the land capacity by 15; if it has an impact of 150, it will reduce the land capacity by 150, regardless as to whether the object itself is made of prims or is a mesh object.
For people who want more detail on individual objects, the new Build menu also includes a MORE INFO link. This opens an additional floater which provides:
Information on the object itself (including the prim count for those missing it!)
If the object is a mesh creation, the “weights” applied to it in terms of the bandwidth required to download it, the server resources it uses, its physics weight, etc.
The overall land impact: impact of the object itself, impact of all objects rezzed, remaining free capacity and total capacity for the land itself.
MORE INFO: for a prim object (l) and mesh object (r) – note the weights for th mesh object
There will also be a WHAT IS ALL THIS? link which will open a Help page that explains the various figures.
Replacing both prim count and PE with a single, easily understood value (Land Impact) makes sense, and at a stroke makes the impact of rezzing any object in-world easy to understand, removing any confusion between prim count and PE.
Of course, there are going to be voices that proclaim the change is about further “hiding” the “real” cost of mesh objects from the user, with the underlying implication that the users are somehow being hoodwinked by Linden Lab. But, c’est la vie. People are wont to make waves come what may.
It will be interesting to see how merchants react to the change – given that all vendors, etc., refer to prim counts right now, and getting wording changed to “Land Impact” (or simply dropping the word “prim” from displays) is a nontrivial issue for many. Some may even opt to retain the use of “prim count” in their vendors for this reason.
And when considering merchants – one hopes that Linden Lab will actually remember to update the Marketplace so that listings also reflect the use of “Land Impact” (i.e rename Prim Count!).
Avatar Rendering Cost and Avatar Draw Weight
Alongside the changes around PE and Land Impact, the Viewer will also be losing another measure that has always caused controversy and angst: Avatar Rendering Cost, or ARC.
Always intended to be an indicative figure for the amount of potential Viewer-side lag avatars create, ARC quickly became viewed by some as the figure for determining whether or not an avatar was “creating lag”, which in turn lead to a lot of drama in some quarters – up to and including people being banned from venues / sims on the basis of their ARC count.
DWA: 197,484 – but don’t panic!
From 3.0.5, things will be totally revamped. ARC as a term is vanishing from the Viewer to be replaced by Draw Weight for Avatars (DWA). Furthermore, how DWA is calculated is radically different to how ARC has been calculated, as Nyx Linden explains.
DWA should be far more accurate than the old ARC system; and therein, one cannot help but feel, lies the rub.
If the figure is indeed more accurate, it is likely to be pounced upon within even greater zeal by those already obsessed with ARC. As such, I can’t help but hope this is one value that Linden Lab don’t make a song-and-dance about when these changes to the Viewer are formally released for general use.
Mesh Uploader
Another source of irritation for content creators has been the mesh upload floater. At SLCC 2011, Charlar Linden himself admitted the current floater is isn’t overly user-friendly. As such, it is also being overhauled, as can again be seen in the current Mesh Development Viewer.
The current upload floater presents a basic set of modifiers that can be applied to a mesh object prior to uploading in order to optimise it. These tend to encourage a lot of trial and error / guesswork on the part of the creator in order to arrive at a desired result.
The current mesh object upload floater
The new upload floater offers a greater range of modifiers and the ability to better define the model itself in terms of what it represents (avatar shape, avatar attachment, moving vehicle, etc – see the drop down in the image below), which presumably apply suitable algorithms that help optimise the object and calculate its overall weight.
The new mesh upload floater as it appears in the Mesh Development Viewer
I understand that several of the changes in the new upload floater are as a result of consultations with / requests from mesh content creators, so hopefully they will go some way to easing the process of importing objects into Second Life.
More to Come
These are by no means the only changes coming to Second Life and the Viewer as a result of the arrival of mesh object support. For one thing, more needs to be done in the area of mesh clothing in order to make it easier to adjust clothing to fit the avatar, rather than the other way around as is currently largely the case. Therefore we can expect to see further changes in relation to this in the future (indeed, those interested in the issue should check Maxwell Graf’s JIRA relating to a parametric deformer).
In the meantime, the above should hopefully give insight into what is waiting just around the corner.
The server roll-out of the 13th September introduced a new and unexpected bug into the grid, as defined in JIRA SVC-7283:
“Attempting to issue llRemoteLoadScriptPin() on a non-full perm script to a worn/attached object fails with “Unable to add item” error message. If there was an existing script with the same name in the destination object, that script is deleted, often resulting in the items being made completely useless.
“A similar error occurs when using llGiveInventory() on a no-transfer item to a worn/attached object. In this case, the error message is “Unable to give inventory: ‘Destination did not accept'”.”
Simply put, this means that at present, attempting to update worn objects runs the risk of breaking them completely.
The JIRA is currently assigned to WorkingOnIt Linden, which means it is being investigated – indeed, Maestro Linden has commented on the JIRA, and has confirmed the bugs. He’s even offered some well-meaning advice:
“The workaround for updaters that affect attachments such as HUDs is to first drop the attachment or detach it and rez it on the ground before using the updater.”
However, this doesn’t help in all cases – particularly those using RLV items which they may not be able to remove; there are also those update systems that rely on the object being worn.
What is more worrying, however, is the seemingly casual response from Linden Lab to the issue. There has been no official indication to content creators that there is a potentially major bug impacting their items – people are being left to hear about things via word-of mouth.
Nor does the Lab – via Oskar Linden – seem all that concerned about getting a fix for the problem out sooner rather than later. Commenting on the JIRA, Oskar Linden states:
“We have traced the cause of SVC-7283 to a security fix around permissions. Due to the urgency of the security issue, we deployed the fix to all channels of the grid at once. Unfortunately, we cannot ‘roll back’ the change at this point, since doing so would compromise permissions across the grid. We are working on a fix for SVC-7283 – we hope to deploy the fix to an RC channel next week. We apologize for the inconvenience and problems with update scripts which are caused by this bug.”
So a potentially significant bug has been introduced right across the grid – and Linden Lab hope to get a fix out to 10% of the grid next week. Does this mean that if successful, the fix will be held over a further week prior to being rolled out to the remaining RC channels and the rest of the grid?
If so, it is wholly unacceptable.
The bug was apparently introduced as a result of a fix being pushed out without sufficient regression testing. Fair enough; however, if this can be done with a security fix – and given Linden Lab have successfully recreated the bugs through Maestro Linden’s tests – then frankly the normal release cycle should be foreshortened as far as possible:
The fix should be coded
The code should be tested for potential impact
The code should be *immediately* release to an RC channel and baked for 24 hours on that channel
If no significant impacts / bugs found as a result of the RC test, the code should immediately be rolled out to the rest of the grid.
And I sincerely hope that this is what Linden Lab will be aiming for. If they are – then we need a clearer statement of intent than Oskar is giving.
In the meantime, one would hope Linden Lab would at least take the issue by the horns and for once communicate the problem with their users, rather than leaving it to people to stumble upon it through either word-of-mouth or through actually encountering an update failure.
Updates
15th September
Maestro Linden reports on SVC-7283:
“We have a fix for this bug that looks promising, which is currently on Aditi (the ‘Beta grid’). The fix version right now is thermonuclear 11.09.14.240803. You can find this version on a handful of Aditi regions; I’ve been testing in the region ‘Pixelpark’, which has a large sandbox area.
“With this fixed version, llGiveInventory() and llRemoteLoadScriptPin() should be able to deliver (no-copy or no-trans) items to worn attachments as long as the attachment’s owner permissions (in terms of copy and transfer) don’t exceed the owner permissions of the item.
“The following 2 cases are still blocked, however, for security reasons:
“Adding a no-transfer item to a worn attachment which is transferable
“Adding a no-copy item to a worn attachment which is copyable
“These cases might be fixed in a future project, but first the server will need to support dynamic updating of worn attachments’ permissions.”
17th September
The fix developed by Maestro Linden is receiving some positive feedback from those testing it on the Beta grid; as such, it is to be rolled out to an RC channel (no details on which as yet) on Wednesday 21st September.
This probably means that the fix will not be implemented across the entire Grid for a further week.
Additionally, a further issue was uncovered relating to permissions restrictions that impact content creators (but not necessarily their customers), wherein NO TRANS items cannot be moved between root and child prims in a full permissions item. Maestro Linden has opened a JIRA related specifically to this issue, SVC-7294.
19th September: The bug fix is confirmed for a roll-out on an RC channel this Wednesday (21st Sept). Those wishing to have their regions included int eh release should submit region names to JIRA SVC-7291.
21st September: The bug fix was apparently rolled out to all RC channels today (it seems the release notes for the RC channels don’t expressly refer to the JIRA), and appears to have corrected a part of the problem for some content creators impacted by the issue, but not for others. Further updates expected.
In addition, there are still issues beyond this JIRA that need addressing – hopefully through SVC-7294, although no roll-out date is available for this yet.
Yesterday Linden Lab rolled out an update to the SL Marketplace – and in the process managed to break several things:
When editing any listed item, merchants found themselves faced with both the item’s list name and all permissions set for it being wiped from listing details, thus requiring the info to be added again
Loss of information appearing in Merchant’s Transaction Histories following sales (such as the actual customer’s name…)
Loss of data from the Automatic Notification of Sale (ANS) e-mail merchants receive when a sale is made (such the actual amounts involved, pre- and post-LL’s commission).
This has understandably lead to a lot of consternation and anger both on the commerce forum and on individuals blogs. Various assurances have been given over aspects of the above errors, together with excuses made (such as the zeroing of balances in ANS being “A bug that was missed” in testing) – but the fact remains that issues have still not been fixed, nor have the changes been rolled back until such time as the code can be made fit-for-purpose. As a result, merchants are still – quite rightly – feeling hurt and betrayed.
I do not classify myself as a merchant in the same was as Darrius Gothly, Dartagan Shepherd or Pamela Galli – but I do feel their pain. Second Life is promoted on a number of unique attributes – one of which is the ability for people to “make real money”. If this is to be true, then the systems Linden Lab put before their customers to enable them to do so must be robust and capable of providing information people need in order not to fall afoul of legal requirements vis-a-vis earnings, etc.
But in reality, they’re not – not through and direct flaw in the software, but simply as a result of how things are being managed. This is perhaps where the philosophy of “put it out, test, polish, test, polish”, as described by Rodvik at SLCC 2011, falls down. Simply put, such a philosophy cannot work well where it impacts in people’s ability to generate income. As Blaze Nielsen comments:
“Brooke et al, I believe the great frustration we feel as merchants here is the methodology of using us as beta testers for your “upgrades”. Many of us have our livelihoods on the line. The money we use to buy food and gas and pay mortgages. For many this is far far [sic] more than a hobby. We see again and again and again sloppy code disrupting our businesses here while the bugs are ironed out. From the server, the client and the marketplace you obviously feel your tinkering can be done with the general population instead of in an isolated testing environment. This needs to be discussed at the highest level of management and the policy changed.”
An added issue here is that Linden Lab are introducing a new Direct Delivery system which could be exceptionally beneficial to merchants and customers alike. But this latest situation does little to inspire merchants with any sense of trust in LL’s ability to do so without causing further confusion and upset.
Update, September 16
Darrius Gothly reports that the majority of the issues encountered in the Marketplace update og the 13th have noew been fixed. He also gives considered thought on what went wrong – and is in all probability pretty close to the mark – and what needs to be done in the future to avoid similar cock-ups. It’s a recommended read for all those involved in content creation and sale, whether for business or as a hobby.
The talk is scheduled for 16:30 SLT, and will feature a simulcast in Second Life at the University’s in-world sim, and Ms. Crowley will answering questions from both the live and virtual audiences.
Given we’re into the run-up to the next year’s US Presidential election, this could be a challenging and thought-provoking presentation.
US Vice President Joe Biden
On Friday 16th September, US Vice President Joe Biden will also be speaking at the University of Delaware. As a former alumnus of the University, he will be delivering the inaugural James. R. Soles Lecture on the Constitution and Citizenship, and gifting his three decades of US Senate papers to the University’s library.
His talk will take place at 13:00 SLT, and will be simulcast to the University’s Imagination sim in Second Life.
Questions on the Vice President’s presentation should be directed either to the University of Delaware’s website, or in-world to Firery Broome.
With thanks to Betterverse and the University of Delaware
Torley Linden, rightly one of the most popular Linden Lab employees, famous for his infectious good-humour, his love of watermelons and talent for music, is to be the focus of the 4th resident-run Saint Torley’s Day, organised by the First Church of Rosedale and the Four Kittens of the Apocalypse.
The many faces of Torley Linden
The event will take place this Sunday, the 18th September, 2011, commencing at 12:00 SLT. Celebrations will comprise:
12:00-14:00: a party featuring Second Life artist Kaklick Martin and Torley’s own compositions, hosted by Alchemy Epstein and Nakira Tennen; to be held at the Four Kittens of the Apocalypse, Penning
14:00: a “special service” at the Rheta Shan Memorial Chapel of the First Church of Rosedale, Rhianna, wherein Torley’s story will be recounted (participants will need to be adult-verified or have payment information on file).
The press release announcing the event reads in part:
“Torley Linden has written innumerable posts on the company’s official blog and created hundreds of video tutorials. He listens and responds to residents, holding weekly office hours and keeping tabs on Second Life content all over the Web, including blogs, Flickr, Twitter, Vimeo, and YouTube. His Saint Day is the Sunday closest to his “rezday” (the day he first entered Second Life), September 15; 2011 will mark the end of his seventh year ‘in-world.'”
The event is intended to be a warm celebration of Torley’s work as Resident Enlightenment Manager, as such those attending the party are encouraged to “wear the most pleasingly garish shades of neon pink and green they can find”, and expect the “‘melon-go-round’, the grid’s most heavily armed watermelon piñata, and more surprises”.
So get your shades, grab a watermelon and join the festivities!
Watermelon Wine by Torley Linden
For further information, contact Samantha Poindexter in-world.
The organisers stress this event is not affiliated with or sponsored by Linden Lab.
Inara Pey: Living in a Modemworld 