Category: News-Opinion

Mesh upload patch enhancement for creators

Posted on by Inara Pey

Nalates Urriah drew my attention to a thread on SL Universe regarding the development of a new patch which should be of assistance to mesh creators making rigged mesh items. The patch is by Magus Freston and Gaia Clary, and is designed to solve a particular problem which exists between Collada file formats and Second Life. Magus describes the problem thus:

A limitation of the attachment points in the LL character is that many of them have names with spaces, like “Left Pec”. Collada 1.4 doesn’t handle bone names with spaces as space is used to delimit bone names. So the idea is to replace the spaces with an underscore for the collada file so you get “Left_Pec”, which of course SL doesn’t recognise. The patch just translates “Left_Pec” back to “Left Pec” at import time.

Posting initially to the Machinimatrix blog, where the raw code for the patch can be found, Magus and Gaia devised a test for the patch involving a mesh with two additional spheres which if imported successfully using skin weights, should appear hovering close to the hands and rotating as a result of an added animation.

Mesh uploader test item created by Magus Freston

The test files cane be obtained from the Machinimatrix blog thread, although they require registration / logging-in to the blog in order to see and download them.

Responding to Magus’ request for assistance, Darien Caldwell compiled a version of the Windows SL beta viewer incorporating the patch, and after a couple of bumpy starts, managed to import the mesh successfully and as expected. Since then several content creators have tried the patch and found it works, although a couple of warnings may be thrown up during the upload. The uploaded mesh can be correctly rendered in any mesh-capable viewer.

The test viewer is provided as a ZIP file for windows, not an installer. On unpacking, the contents should save to a default folder (at the time of writing “Test Build 341” – although you can obviously rename this). Once unpacked, open the folder and double-click on LINDENDEVELOPER.EXE to launch the viewer.

The uploaded mesh, with animation running, showing the expected result: the two spheres orbiting in front of my hands

Related Links

Rod Humble reveals more on LL’s upcoming new products

Posted on by Inara Pey

Talking to Giant Bomb, Rod Humble has revealed more about the Lab’s upcoming new products, all of which appear set for launch in October.

We already know about Patterns, which is already available in its Genesis Release, and which has had something of a positive response among those in the gaming community who have tried it.

Patterns: generally positive reception to initial Genesis Release

We also know that Creatorverse will also be appearing shortly, and will initially be aimed at the iPad (but is currently still awaiting Apple’s approval), although it appears it will eventually be available for the PC and Mac as well going by comments in the article. The description of a demonstration of Creatorverse given by Humble is somewhat amusing:

Humble loaded up the app, which starts with a white screen. First, he drew a box, colored it in and tried to convince me it was a car. He made a better argument when two circles were underneath it, but when he clicked “play,” everything fell apart. By tapping the left side of the screen and pulling up his toolbox, Humble added joints that merged the “wheels” with the “car,” and gave the wheels a movement ability. Finally, he added a squiggly green line beneath everything, and clicked play again. The car roared to life…and then quickly fell off, tumbling into oblivion.

Probably not the intended result, but it does raise a smile. However, the really interesting part of the news about Creatorverse is in the paragraph which follows:

Each creation can be uploaded into the cloud, and both played and edited by anybody. The goal is to bring some Second Life sensibilities to Creatorverse eventually, too, such as giving users the ability to charge for them. (That can’t happen on iOS, though.) One of the more ambitious toys created by pre-release users was a pinball machine.

So not only would shared creative spaces appear to be a concept being carried forward from SL into their new endeavours by LL, but also the opportunity for users to monetize their creations…

Creatorverse: shared creative space and monetization? (copyright Linden Lab)

Of the remaining two products up for launch, one is Dio, which has been known about in essence, if not in content for a while. It is described as a “room creator, in which players can do everything from construct a choose-your-own adventure to develop an interactive wedding album.” This had been thought to be a product arising from the acquisition of Little Text People earlier this year. However, the fruits of that collaboration would appear to be in the fourth product in the lie-up.

Dio: to appear in October as well

This fourth product is to be called Versu, and is described as a storytelling toolset, in which players assign characters a set of motivations. The characters react to the actions of the player based on these motivations, and the story is procedurally generated. The first release is aimed at murder mystery and romance stories.

The timing of the launches so close to one another is intentional, with Humble hoping that the close proximity of the launches to one another will change people’s perception of Linden Lab, and encourage those who wrote it off as “just the Second Life company” to come back and have another look.

Hopefully, if successful, this may encourage people to take a look at Second Life as well…

With thanks to Laetizia Coronet

Network Optimisation: LL seek assistance

Posted on by Inara Pey

Linden Lab are in the process of changing the manner in which network traffic is handled within Second Life, and require assistance in testing the changes made to date in order to ensure various services are functioning correctly prior to rolling-out the changes to the grid as a whole.

To this end, Oskar Linden posted the following request in the Server forum late on Wednesday 10th October:

Linden Lab has made some changes to the way regions handle network traffic. We need your help to test. This will help us insure that regions are communicating appropriately over the network. Mainly we are concerned with agents entering via direct login, teleport, and region crossing. As well as other functions such as IMs, Voice, and Group chat.

Tomorrow, October 11th, at 4PM Pacific time (right after the server beta user group) we will conduct these tests with as many people as we have. Testing will take place on ADITI and require out of world communication we will be coordinating via IRC. This will require an IRC client connected to EFNET in the channel #sltest. If you don’t know how to do that you have until tomorrow afternoon to figure it out. 🙂

The details on the tests are here:

 – https://wiki.secondlife.com/wiki/Networking_Optimization_Pile_On_Tests

I hope you can come and help us test these new changes.

__Oskar

The tests will comprise three parts:

  • Direct log-in test to a pre-determined location on the beta grid.
  • A group chat test via the Second Life Beta in-world group.
  • A teleport test to a pre-determined location.

Note that Voice is also indicated as one of the services to be tested, but no details on what this will entail have as yet been included in the test notes – please check both the note and Oskar’s forum thread for possible updates on this ahead of testing.

Those wishing to take part in the tests will need to:

  • Be members of the Second Life Beta in-world group
  • Be able to log-in to the Aditi beta grid

The tests will be coordinated on IRC using the EFnet channel #sltest, and those involved in the tests will need to be able to access this channel either via the EFnet website or through an IRC client.

Accessing the #sltest channel on the EFnet website – note you do not require a registered account; you can access the channel using any suitable nickname

The tests are due to commence at 16:00 SLT.

Note that these changes are not related to the region lag issue sudden and massive lag spikes, as reported in the Server forum threads, but rather appear to be part of ongoing network-related work.

The “LeTigre event” and seeking to safeguard deployments

Posted on by Inara Pey

As reported last week, Wednesday October 3rd saw a massive problem hit the LeTigre Release Candidate channel, which impacted over 1200 regions. This most visibly manifested itself as a large number of items (including partial builds) being returned to people’s inventories as a result of regions being seen as “full” by the software as a result of an error in the prim accounting code. This saw disruption across the grid throughout Wednesday and into Thursday, partially because those regions impacted by the error not only required a corrective deployment of RC code (from BlueSteel), but also had to be manually restored to a state prior to the LeTigre deployment occurring.

Since the problem occurred, Linden Lab has not only been looking into the bug within the prim accounting software, but also at their internal processes in terms of why the error wasn’t picked-up prior to the LeTigre deployment going ahead, and also in terms of what steps can be taken to curtail such a massive disruption in the future, should ever a similar problem occur, and how regions can be restored in a less manually intensive manner. Even so, sorting out a solution which fits every possible scenario by which a deployment may go wrong isn’t easy.

Speaking at the Sim  / Server User Group meeting, Simon Linden commented on the matter thus, “The tough thing with SL testing is running it on all those combinations – it’s just never possible to have complete test coverage. The RC channels are actually designed to be representative of the whole grid, so we try to keep a mix of the different types of regions like full, mainland, Linden Homes, etc. On one hand, the system worked … we found a problem before it got to the whole grid, which might have been how this would have happened before we started the Release Channels. But it really was so bad we definitely want to catch something like that even earlier. So … we’ve had a bunch of meetings discussing what and why it happened, and have some better tests added to the regular test pass so this specific problem won’t happen again.”

Options to prevent a similar issue occurring again in the future which have apparently been discussed at these meetings include:

  • Improving the testing carried on Aditi. Part of the problem here is that as a representative testing environment, Aditi is very much smaller and much less diverse than the main grid, and as such it is harder to test for all possible failure conditions which may occur when deploying code to the main grid
  • Adding alarms to the deployment process so that when things do go wrong, such as a large number of object returns occurring, the process will automatically stop itself before the damage becomes widespread
  • Altering the deployment process so that code is initially rolled out to a subset of each Release Channel, prior to it being paused for a few hours to see if there are any reports from users of unexpected or undesirable results , and only resuming the deployments if it appears nothing untoward has happened
  • While it is the first time this particular problem has occurred in terms of selective region object returns, it has prompted the Lab into looking at ways and means to initiated an automated restore process in order to make the rollback of affected regions more time-efficient and less intensive.

It remains to be seen which of these – and any other ideas –  which have been discussed at the Lab are implemented. However, it should be remembered that even with the best will in the world, and given the dynamic nature of Second Life with all the user-created content and scripting, it is impossible for Linden Lab to take into account every single possible error which may occur with a server deployment, and provide a means of avoiding it. Even so, as a result of the LeTigre event, LL are looking to further improve how server code is both tested and deployed in the future, and provide the means to better flag any negative impact occurring during a deployment in order to allow remedial action to be determined and actioned in a more timely manner.

With thanks to Baz deSantis.

Lorca Linden provides data on pathfinding and simulator performance

Posted on by Inara Pey

It is fair to say that pathfinding has become one of the most controversial subjects in Second Life. While it has been the subject of a range of issues and problems, noticeably with vehicles, both before and after being deployed to the main grid, it has also become the most pointed-to bug-a-boo when people either are seeing, or believe they are seeing, simulator issues and problems.

Because of the levels of concern raised over pathfinding and its potential impact on simulator performance, Linden Lab has been carrying out comparative studies of simulator statistics recorded both before and after the pathfinding deployment. Speaking after the showing of a Designing Worlds special on pathfinding on Monday October 8th, Lorca Linden, the Pathfinding Producer at Linden Lab, gave the following high-level results of these comparisons:

Private Island simulator average sim fps:

  • Before pathfinding (Saturday, June 23, 2012): 44.43
  • After pathfiinding:
    • Dynamic pathfinding NOT enabled: 44.41
    • Dynamic pathfinding enabled, NO pathfinding objects: 44.29
    • Dynamic pathfinding enabled, at least 1 pathfinding object: 44.25
    • Dynamic pathfinding enabled, at least 10 pathfinding objects: 44.70

Mainland simulator average sim fps:

  • Before pathfinding (Saturday, June 23, 2012): 44.66
  • Dynamic pathfinding NOT enabled: 44.46
  • Dynamic pathfinding enabled, NO pathfinding objects: 44.44
  • Dynamic pathfinding enabled, at least 10 pathfinding objects: 44.79

These figures should not to be taken to mean there are no issues with pathfinding in terms of raised JIRAs relating to vehicles, etc.  However, as high-level as they are, and allowing for the size of the sample taken, they potentially show that pathfinding is not having as heavy an impact on simulators as many fear is the case. Commenting on them, Lorca said, “So in short, while there are certainly cases in which it’s possible for PF to have some performance impact, the data is showing that in the great majority of cases PF is not causing performance harm, since the grid-wide averages are within 1% pre and post PF.”

Also discussing the issue of perceived simulator performance during the Designing Worlds show itself, Falcon Linden acknowledged that part of concerns about simulator performance have been due to the way in which the Lab presented the potential for possible impact. “We didn’t communicate early on about the optimal performance of pathfinding,” he said. “We really wanted to take a conservative approach, so our communications, I think, were almost negative, in a way, where we were telling people what the worst case was, like we were making it seem that was what we expected to happen, but it wasn’t; and so people read from that that things could get bad.”

Lorca Linden (centre left) is joined by Maestro and Falcon Linden and Sandry Logan on a  Designing Worlds pathfinding special shown at the Designing Worlds studio on Monday October 8th (image courtesy of Designing Worlds / Wildstar Beaumont)

Also in the Designing Worlds programme, Lorca and Falcon, together with Maestro Linden, discuss Linden Lab’s thinking on pathfinding, why the Lab felt it to be a valuable resource to have in SL, and explain some of the additional features within it, such as the ability for pathfinding characters to navigate to a specific point in a region – or a point several regions away;  and a function which can be used both with pathfinding and independently of it (for example, it could be used within a HUD which can guide avatars to a specific store within a mall).

Overall, the programme helps to provide further insight into how pathfinding works and how it can be used, with a very practical demonstration by Sandry Logan of the Virtual Kennel Club. As such, for anyone who is curious / worried / may have a use for pathfinding, it is a recommended watch. Catch it on Designing Worlds at Tweet TV.

Related Links

Marketplace issues: not so much eroding trust as completely undermining it

Posted on by Inara Pey

Well, it seems news over the correction in one aspect of the ongoing SL Marketplace listing enhancements debacle (itself merely one part of the overall Marketplace debacle) was premature.

No sooner had the Commerce Team announced they were refunding people for the mess-up over payments, that automatic debiting for enhancements resumed, with the same level of confusion as to what is actually going on, and people unable to determine exactly what they have or have not been charged for. How this came to pass is unclear, although I do tend to agree with Darrius Gothly’s assessment of the situation, vis:

When your staff went through and refunded everyone, you should have AT THAT TIME tested to be sure your code modifications would not immediately undo everything just done. But did you? Nope. As a result it went through and lickety-split re-billed everyone .. not only for what they’d just been refunded but additional charges too. Pardon me but .. WTH?!? By dint of your lack of attention you have just completely undone everything your staff did .. by hand .. at great expense to your employer. You have WASTED a very large amount of money. Wasted because you could not or did not want to bother testing your changes. 

It is perhaps bad enough that people have seen refunds enter their accounts only to evaporate once more. But it would also appear that people are again getting charged for enhancements they cannot cancel due to WEB-2974 (an issue now some two years old, and resolution of which was “on hold” as of July 2012).

This state of play is, frankly, ridiculous. While mistakes can and do happen, what has been going on within the Marketplace and on the part of the Commerce Team long ago reached a point of farce. Even the simplest of tasks appears to be beyond their capabilities (or the capabilities of the software they manage). Remember the change to the sales notification e-mail address I mentioned as being rolled-out on September 26th as a part of my last general SLMP update? Guess what was rolled back just 48 hours later, only to be rolled-out once more on October 4th?

One has to question a) the level of competence within those responsible for managing and coding SLMP; and b) the overall condition of the Marketplace code itself, as it seems utterly incomprehensible that even the most basic issues within the system appear to be beyond LL’s grasp to fix.

In his comment on the matter of listing enhancements, Darrius concludes:

Communication from your team to us is a major issue. I’ve no doubt why this is the case. Most people have a very difficult time going to others with the need to say “We’re sorry, we screwed up.” With the number of times you must begin a blog post in that manner, it’s no wonder you don’t post very much at all. So here’s an idea … stop being lazy, stop short-cutting things and rushing changes into production, stop screwing up .. and STOP having to begin every post with an apology.

While I agree with his point of view, I’d go a step further.

It doesn’t matter as to whether or not these issues are only affecting a “small number” of merchants (as the Commerce Team have repeatedly stated); it also doesn’t matter as to whether LL regard L$ as “real money” or “tokens”.

What matters is that the company actively encourages people to get involved in their platform’s commerce engine, and to invest time and money in it – and they promote the Marketplace as a major means for people to do so. People have taken LL at their word, and for many of those affected by all the Marketplace screw-ups over the years, it very much is the case that real money is involved, and real stress and real upset.

As such, it is time for someone within Linden Lab to recognise this, take responsibility and step forward with a sincere apology for the manner in which the entire litany of mistakes, errors and mishaps going back as far as at least 2010 has been handled. They then need to go on to ensure issues are managed in such a way that people are kept properly informed on progress, and that issues are not exacerbated by what appears to be either flaws in internal processes – or carelessness.

Simply saying people are busy “crunching numbers” doesn’t really cut it any more.

As it is, a decent projection as to when LL will “have a fix” for Marketplace problems, would appear to be, “Around the 12th of Never”.

Related Posts