Day: October 19, 2012

SL project news: week 42 / 2: viewer, mesh, shining and more

Posted on by Inara Pey

SL Viewer

After hopes that the latest beta version of the viewer would prove stable enough for things to start flowing again, it turns out that its crash rate is hovering around the 14% mark, with Oz reporting that a substantial portion of the crashes, which still appear to be related to memory problems, occurring as users exit the viewer. While these may go unnoticed by users, LL still want to bring the rate down to something closer to the release viewer (which is currently 10%).

As such, further candidate version of the beta viewer is being built, which should be released on Monday 22nd October with the hope that the changes being made will do just that. However, it is fair to say that the level of optimism within the Lab that this will be the case is currently low. Until the problem is resolved, further releases of code for projects are likely to remain blocked.

This issue is now the primary delay in moving a number of projects forward, including the Baker Linden’s Group Service project, Monty Linden’s HTTP texture project, updates for the Steam link-up and a host of other internal and contributed elements.

Mesh Deformer

A revised version of Darien Caldwell’s proposed addition for arbitrary shapes in the mesh uploader for us with the deformer

Darien Caldwell has been continuing to work on getting the deformer to work with arbitrary human shapes, and has some success. She has also ben working to refine the new options on the mesh uploader to cater for custom shapes, indenting the options to make it clear that they are a part of the Deform to Avatar Shape check box item (see right). Also, and while awaiting feedback from LL, she has moved the option to export an avatar shape as an XML file from a sub-menu on the Develop Menu (DEVELOP -> AVATAR -> APPEARANCE TO XML) to the Advanced Menu on her version of the Mesh Deformer project viewer.

However, as she comments on the JIRA (STORM-1716) for the deformer, there is also a problem.

Essentially, there are certain sliders (eleven in all) associated with armature bone length, which already deform mesh without using the deformer (see her JIRA comment for the full list of sliders). When these are adjusted to create a custom shape for making mesh items, problems arise because they are then deformed by both the viewer and the deformer, leading to odd results under certain situations.

The issue appears most pronounced when working on individual body elements, such as the upper body (as defined by SL) when using a custom shape (such as when creating a jacket). However, in a “full body” mesh, the problem is somewhat less pronounced.

Deformation issue: on the left, an “upper body” flesh-tome mesh (analogous to, say, a jacket) built to a custom shape is worn on that custom shape (in black). Note the mis-match. On the right, the same mesh, but combined with lower body elements applied to the same custom avatar shape. A much closer fit

As the sliders are placed closer to their default values, the issues become less and less pronounced. Darien had suspected this might be an issue, but until she started working with shapes other than the default, she had no way of determining if a problem existed. She has also a nagging concern that a small adjustment made to the deformer code itself might be having an unforeseen impact. However, from his own understanding as to how the deformer works and when discussing the matter at a delayed OpenDev meeting on Thursday 18th October, Oz Linden agreed this was unlikely to be the case.

When using custom shapes with the “problem” armatures set closer to their defaults, the problem is still present in “upper body” meshes (l) but is somewhat less pronounced, and again is barely noticeable on a “full body” mesh (r)

Currently, and assuming I’m understanding the matter correctly, the “fix” for this problem seems to be to define a custom avatar shape in SL, then adjust the eleven “problem” sliders to their default values prior to exporting the shape data to an XML file which is used shape to create the required mesh items (body, clothing). Once the finished items has been uploaded to SL, it can be worn with the shape and the desired settings for the eleven affected sliders can then be restored with the result that the mesh should deform as expected.

Darien will be carrying out further tests on the issue prior to offering her version of the deformer for wider use.

HTTP Libraries

As a result of beta viewer issues, it’ll be a while before everyone benefits from faster texture rezzing – but work continues on related services

While the viewer side of the new texture fetch library is blocked from going further than a project viewer at the moment, Monty Linden has resumed work on the server-side of things. Commenting on this at the TPV/Dev meeting on Friday 19th October, Monty had this to say, “I’ve been working on server-side work … and as part of the next part of the HTTP work, there will be a server change, grid change. sim OS change. And I just want to let everyone know that at some point we’re going to have to put up some beta servers on the beta grid and start some testing … It will be an interesting change to the services.”

This work is related to the number of connection an agent can have open to a given service – essentially the development of a “fairness policy” with regards to service connections. The changes and the policy itself are liable to be fairly dynamic as they come into effect and LL monitor use and potential abuse and start to focus down on ensuring a reasonable balance is met. This will require extensive testing from TPVs to ensure their viewers are handling the new services correctly, whether they can operate within the policy in terms of number of retries or back-offs on a failed connection, etc., and whether they need to limit the number of connections users can manually open (where this is the case).

Other Bits

Viewer and FMOD

No major news on this since reporting it in week 41. It is still LL’s intention to do something about it, however no resource has been allocated to it as yet  – with emphasis on the “yet” from Oz Linden. One of the hold-ups here is (again) the ongoing problems with the beta viewer, which require resources and effort to resolve.

Mountain Lion Support

The the TPV/Dev meeting on Friday 19th October, Oz reported that the Lab were making “great strides” on updating their Mac support for OSX 10.8 Mountain Lion, including gatekeeper support, and that the information should be available “quite shortly”.

64-bit Builds of the Official Viewer

The subject of 64-bit one that frequently arises in relation to the official viewer, particularly when mentions is made of memory leaks and the like, and it comes up not only among users. Remarking on it in the TPV/Dev meeting, Oz Linden said, “It is a bullet we have not yet decided to bite, but at some point we’re going to have to.”

He went on to point out that LL are already approaching a point where they’ll have to build OSX versions of the viewer in both 32-, and 64-bit, and that, “At some point the cost/benefit will tip the other way.” As such, he stated that any help LL can get from TPV developers in getting the code “64-bit clean”, etc., would be welcomed. In the meantime LAA support for the viewer has been merged into the development viewer (viewer dev) and is locked behind the current issues with the beta viewer.

Patterns gets its first update

Posted on by Inara Pey

Update, October 9th, 2014: Linden Lab announced that development work on Patterns has been discontinued.

In keeping with Rod Humble’s promise of rapid iterative cycles, Patterns received its first update on the 18th October.

Looking at Reactions to Date

Before getting down the the update, I thought I’d take a look at reactions to date. It is fair to say that overall, Patterns has been generally well-received in the “gaming community”, with positive comments appearing in response to articles about it, on the Patterns forum and forums elsewhere, together with a host of largely positive videos and tutorials being promoted to You Tube.

Within the SL community, the reaction has been somewhat more mixed. While many (myself included) have been willing to give it a chance and are happy – for now at least – to see where it leads and forgiving current shortfalls and bugs, others aren’t and have written it off before even the first update has arrived. Still others are loudly remonstrating that Rod Humble is pushing LL into something “it isn’t”, a “games company” with the subtext that it can only end in failure. Perhaps it will; my own view at this point in time is that it’s just too early to tell, although I remain of the opinion that diversification could be beneficial to the company and SL over time.

But to come back to Patterns. Many of those who have been working with it have been flexing the overall building capabilities – and this has in some ways mirrored early usage of Second Life. While Those at linden Lab expected their world to be filled with the unusual, bizarre and unthought-of, most early adopters worked with prims in remarkably familiar ways: houses were very much based of real-world designs, etc.

Of course, Patterns is a much harder world to go directly to the fantastic as the physics engine isn’t so obliging to turn a blind eye to a stately mansion sitting atop a tree or floating over a mountain (not unless they are part of a protoworld to start with, anyway). Even so, people have been playing with recognisable builds – such as Damien Fate, and his lighthearted look at building a house.

Others have been looking at the question of vehicles in Patterns – and while axles per se are lacking at present, some have been having fun nonetheless…

Rtan Slattery’s “SWAGON”, as seen in the Patterns community forum

I’ve been playing Patterns since it came out two weeks ago, and have to say I’ve found it buggy (not unexpected with an alpha release), very limited in terms of things to do (ditto for an alpha release), frequently repetitive (if only because for the last couple of days I’ve been reduced to vacuuming-up everything in sight….) – and oddly compelling and absorbing. The workbench / forge (or to give it its proper name, the Shaping Stone) has had me beavering away at what is / isn’t possible to build, and I’ve enjoyed experimented with different means of building bridges, ramps, stairways, etc while exploring in-world. More recently, I’ve been enjoying simply blowing this up (although I admit, creating “starene” bombs passed right over my head until Nalates Urriah pointed out one is built in the original promo video. Doh!).

So… what about the update?

A Word About Savesets

Before we get to that, a word about Patterns savesets – one I wish I’d read before launching into the update and building things :).

By default when starting the update, a player is starting over; this is a new version with a new world, so you’re essentially starting from scratch, which is a bit of a pain if you’ve collected a few tonnes of substances in your inventory or created a slew of custom shapes.

However, all is not lost. Providing you’re not too heavily into the update, you can re-load various elements from earlier sessions with Patterns (providing you saved your games) into the new version. This not only means you can revert back to just playing within the 0.01a world – you can load your inventory and shapes! The process for doing this is currently a bit complicated, but the indications are that future versions will included the ability to load data from previous versions etc.

In order to load-up data, you’ll need to access the savesets for the game. These are located in the following folders:

  • Windows: C:\Users\[user name]\Appdata\LocalLow\FreeRange\Patterns\SAVEDATA|
  • Mac: \\Library\caches\FreeRange\Patterns

The savesets themselves are called:

  • character_ProtoWorld_0
  • data_ProtoWorld_0
  • inventory_ProtoWorld_0
  • patterns_ProtoWorld_0
  • shapes_ProtoWorld_0

Note that if you have already played the update, you may also have savesets from version 0.01b. These are differentiated from version0.01a savesets by having a “2” in the filename.

To use a saveset file from 0.01a in your updated Patterns, all you need to do is add a “2” to the name so, for example: “data_ProtoWorld_0” (the world file) would be renamed “data_ProtoWorld2_0”. Note that this may overwrite any existing 0.01b file with the same name.

Continue reading “Patterns gets its first update” →

Commerce Team: upping the tempo with more of the same

Posted on by Inara Pey

Following Rod Humble’s entry into the ongoing Marketplace issues discussion, the Commerce Team have posted an update. At the time of Rod’s entry into the situation, I commented that overall, more than just a stepping up of forum posts is really needed if issues are to be sorted with any degree of satisfaction (and I didn’t just mean the technical issues – I was referring to the entire loss of trust many merchants have with the Commerce Team), then more pro-active steps are need.

Sadly, if the latest update is anything to go by, rather than moving to build bridges, the Commerce Team is simply going to give more of the same.

The update opens with a report on Direct Delivery delivering items “2.3 times faster” than Magic Boxes and at “2.5 times” the success rate. This might be taken as significant but for two things.

  • Many of those hit by the problems remain unable to use Direct Delivery
  • Many of the issues impacting merchants at the moment are occurring regardless as to whether they are using Direct Delivery, Magic Boxes  – or both. Issues such as WEB-4441, for example, which was originally raised in relation to Magic Boxes, but which was opened-out by the Commerce Team to include a number of Direct Delivery issues (WEB-4559, WEB-4570, and WEB-4595) as well (which also served to confuse the purpose of the JIRA).

As such, talk of the “success rate” and “speed” of Direct Delivery is pretty much pointless.

Direct Delivery stats: irrelevant for those experiencing the ongoing Marketplace failures – such as not being able to use Direct Delivery, or facing mechanisms within the Marketplace which are broken regardless of whether or not Direct Delivery is used. (Also: spot the missing line in the comparison)

The rest of the update is, frankly, bland. It offers no more information than previous updates; in fact in some respects it is less informative. At least the previous updates (which appear to have been removed from the forum with the publication of this update) recorded a consistent list of JIRA, allowing merchants to properly identify issues and look them up (all the relevant JIRA remained public access after the switch-over to the Bug Tracker mode in the JIRA system).

The one ray of sunshine in the update is that it would appear that the overcharging for listing enhancements has finally been resolved some 10 days after it was originally reported as fixed. While this is indeed welcome (if correct), it really is overshadowed by the lack of genuine information being provided by the rest of the update.

Of course, keeping people more informed is to be welcomed. However, the key point here is keeping people more informed. That implies passing on meaningful information and making some effort to explain what is going on: what are the priorities, where are the possible bottlenecks in dealing with maters, what has been done to date in order to understand the issues, and so on.  As it stands, it would appear that the Commerce Team’s response to Rod’s comment on “upping the tempo” appears to be “more of the same” in terms of bland summaries – only possibly more frequently.

So far, the update has been met with a deafening silence, which may reflect the fact that it really doesn’t say that much more about core issues than merchants already knew from previous updates.

And while not entirely unexpected, it is nevertheless disappointing. Again withe respect Rod, and to precis my previous post on Marketplace communications:

It’s not just the tempo, Rod, it’s the quality of the information supplied.