Category Archives: News

Meet the Lindens, Wednesday, March 25th

Back in November 2014, the Lab held a get-together with residents at  Meauxle Bureaux, the official home of the Linden Department of Public Works (LDPW) moles. It proved to be the first of a growing number of social events, which have also included the return of the Lab / residents  winter snowball fight.

On tuesday, March 24th, Xiola Linden posted a Twitter message offering a further invitation for residents to get together with Lindens. This will again take place at Meauxle Bureaux, this time on Wednesday, March 25th, between 12:30-13:30 SLT.

The next meet-up with Linden folk will take place on Wednesday, March 25th, between 12:30 and 13:30 SLT at Meauxle Bureaux

The next meet-up with Linden folk will take place on Wednesday, March 25th, between 12:30 and 13:30 SLT at Meauxle Bureaux

So, if you’ve missed previous get-togethers, make a note of the time and place!

Meauxle Bureaux Ye Olde Abner Mole Pub could be seeing some heavy custom (Lindens are said to like their rum, rum, rum, rum, rum ...!)

Meauxle Bureaux: Ye Olde Abner Mole Pub could be seeing some heavy custom (Lindens are said to like their rum, rum, rum, rum, rum …!)

Related Links

Avatar Hover Height reaches release viewer

secondlifeOn Tuesday, March 24th, the Lab promoted the Avatar Hover Height release candidate viewer to the de facto release viewer, meaning it is now available to everyone receiving official viewer updates / downloading the official viewer directly.

As I reported back towards the start of the year, prior to the arrival of server-side appearance (SSA), many TPVs included a capability commonly referred to as “z-axis height adjustment”. Simply put, this allowed the height of an avatar to be adjusted up or down, relative to the ground or to an object they were sitting on, which allowed for a wide range of adjustments to be made (such as when sitting or kneeling on the ground, to prevent the appearance of hovering over it or to more finely tune the avatar’s pose on the ground, or to re-adjust an avatar’s height relative to the ground when using things like dancing posballs, etc, and so on).

However, with the introduction of SSA, the viewer / server messaging that made this kind of adjustment possible was removed. While the Lab attempted to offer an alternative capability – the Hover slider, available when editing your avatar’s appearance, its effectiveness has always been limited. You can’t for example, use it to adjust your avatar’s height when seated, for example, to prevent any appearance of sitting “inside” a chair or hovering above it; nor can you adjust your position above the ground when using poseballs, etc.

Avatar Hover Height, developed as a direct request of a proposal put to the Lab by members of the Firestorm team, addresses these shortfalls.

It allows “on-the-fly” adjustments to be made to your avatar’s height with the minimum of fuss and without having to use the Edit Appearance Hover slider.

A simple example: by default, my avatar (sized to a height of 5ft 10in, slightly taller than the in-the-flesh me!), appears to be hovering above the ground. With AHH, accessible through the right-click avatar context menu...

A simple example: by default, my avatar (sized to a height of 5ft 10in, slightly taller than the in-the-flesh me!), appears to be hovering above the ground. With AHH, accessible through the right-click avatar context menu…

It does this by providing a new right-click avatar context menu option  called, oddly enough, Avatar Hover Height. Right clicking on this displays a slider. Moving the slider to the right increases your graphical height above the ground, and to the left decreases it (you can also input values via the slider for additional control).

Overall, the slider allows for adjustments of +/- 2 metres relative to the default graphical position of your avatar. Note that this is a graphical (/visual) change – the slide does not make any associated change the avatar’s height in terms of platform physics.

I can use the slider or spinner to quickly adjust my height so I am standing "on" the ground . This can also be used for adjusting your apparent height when ground sitting, kneeling, sitting on unscripted furniture, using poseballs, etc.

I can use the slider or spinner to quickly adjust my height so I am standing “on” the ground . This can also be used for adjusting your apparent height when ground sitting, kneeling, sitting on unscripted furniture, using poseballs, etc.

Avatar Hover Height has been extensively tested while the viewer was both in a project status and was available as a release candidate viewer, and no significant issues or breakages were noted in that time.

Note that this capability does not replace the Edit appearance Hover option – than can still be accessed and used in circumstances where it might be more appropriate to use; rather it present a further, more convenient, means of adjusting your avatar’s height.

Related Links

 

AMD’s Catalyst™ 15.3 beta driver offers SL mesh fix

AMD have release a new set of Catalyst™ drivers for windows which, according the release notes, includes a fix intended to resolve the  rigged mesh issues  which, since the deployment of the 14.9.2 drivers by the company, have caused rigged mesh to be invisible unless hardware skinning is disabled (see BUG-7653 and my report here).

The  AMD Catalyst™ drivers (1.4.9.2 onwards) rigged mesh rendering problems as a result of changing openGL support within the drivers (image courtesy of Maestro Linden, click for full-size)

The AMD Catalyst™ drivers (1.4.9.2 onwards) rigged mesh rendering problems as a result of changing openGL support within the drivers (image courtesy of Maestro Linden, click for full-size)

In the release notes accompanying the new drivers, AMD note the following under Resolved Issues:

[413076] Second Life : Rigged mesh objects are not rendered correctly when hardware skinning is enabled in the in game setting

The update was spotted by SL user Liffento Eldritch, who posted the news on the Firestorm Preview Group, prompting Miro Collas of the Firestorm team to poke a few people, and Whirly Fizzle to drop me a line on the update.

The AMD Catalyst™ 15.3 beta drivers offer a fix for the SL mesh rendering issue

The AMD Catalyst™ 15.3 beta drivers offer a fix for the SL mesh rendering issue

As regular readers of these pages know, I’ve followed the situation with the AMD drivers, and have posted on the matter a few times. In turn, as a result of these posts, Yoho Waco wrote-up a workaround for the problem, which appeared in a comment on a blog post here, and which I later reproduced as an article in its own right.

The workaround involves using .DLL files from either the 14.9.1 or 14.2 Catalyst™ drivers, and placing them  in the viewer’s installation folder.

If you are one of those who have employed this workaround yourself, please not that you must remove the relevant .DLLs files from your viewer’s installation folder, or the viewer will revert to using them, rather than the drivers for the newer .DLLs.

I’m an Nvidia user, and so cannot test things for myself, so should you give the new beta driver a go, please do drop a note in the comments on whether or not the fix works for you.

Firestorm seek feedback on “restore to last position”

Restore To Last Position (RTLP) was a joint server / viewer capability that presented uses with the ability to right-click on an object in inventory and return it to its last recorded in-world position, relative to the region in which the user is standing. However, due to an exploit used be griefers to rez objects on regions where they otherwise had no rezzing rights, the Lab made changes to the simulator code, which also impacted how this capability worked. As a result, the viewer-side code was removed from the official viewer.

Restore to Last Position as found in Firestorm's inventory context menu

Restore to Last Position as found in Firestorm’s inventory context menu

Nevertheless, TPVs have continued to provide RTLP to users. Unfortunately, the the capability has been long been known to cause a range of genuine inventory issues, and since the changes made to the simulator code to prevent griefing, the shortfalls with RTLP have been somewhat exacerbated (such as with No Copy items, which is why some TPVs have blocked the capability from being used with No Copy objects).

However, as I reported In my last SL projects update, as a result of the recent survey the issued in respect of inventory loss issues, the Lab is considering deprecating the last of the server-side messaging which allows RTLP to work.

This has understandably given rise to concern among some TPV teams, simply because they are aware many users do find the capability useful, despite its limitations, and communicated this to Oz Linden at the TPV Developer meeting on Friday, March 13th.

As no final decision on the future of simulator-side messaging for RTLP has been made, Oz suggested to TPVs that they provide reasoned arguments as to how and why it, or a function like it, should continue to be supported by the Lab, which can then be considered when the time comes to determined the future of the current capability.

To this end, the Firestorm team have issued a blog post asking users to offer their own clear, concise explanations as to how they use RTLP and why they find it beneficial. The aim is to take  the submitted examples and build them into a reasoned argument that can be presented to the Lab and hopefully encourage them to either reconsider deprecating the RTLP messaging or to provide functionality that might help meet some of the more common use cases supplied to the Lab.

So, if you do have a clear use case for wanting to see RTLP, or some similar type of functionality to continue to be offered, and regardless of whether you are a Firestorm user or not, you should consider helping to build a reasoned argument for retaining RTLP by adding your use case to the comments following the Firestorm post (please do not add them to this post, as I am not directly involved in compiling the information).

This doesn’t men RTLP will be saved, but at least the opportunity to present user feedback to the Lab has been provided; if that feedback is sufficiently constructive and consistent, it may influence future thinking on and around RTLP.