Tag: SL Viewer

SL project updates week 15/1: server, viewer, HTTP Inventory reminder

Posted on by Inara Pey
... and don't miss out on the merfolk's beach, complete with pier and fun fair!
Don#t forget you can plunge into learning about SL’s extensive merfolk and undersea community this week, thanks to the folk at Fanci’s Deep and the Safe Waters Foundation. There’s undersea tours, dances, dolphin rides, shopping opportunities, freebies and a whole lot more. You can even visit the mer beach and fun fair (above)! To find out more, read the blog post on the event, which runs through until April 11th

Server Deployments Week 15

As always, please refer to the server deployment thread in the forums for the latest information and updates.

  • On Tuesday, April 7th the Main (SLS) channel will receive the server maintenance update previously deployed to the three RC channels. This is primarily focused on trying to prevent  inventory loss issues, and sees UDP inventory messaging deprecated (see HTTP Inventory, below, for more important information)
  • On Wednesday, April 8th all three RC channels should receive a new server maintenance package comprising:
    • A fix for a server crash when rezzing an object
    • A minor change for CDN configuration
    • Adjusted internal server configuration.

SL Viewer Updates

A new release candidate viewer was released towards the end of last week. The HeatWave viewer, version 3.7.27.300424. This is essentially the maintenance RC viewer with an additional URI parser fix to prevent a viewer crash bug, but has retained a project name to differentiate the two RCs from one another.

 HTTP Inventory

With the Tuesday deployment (noted above), the main grid now only supports HTTP Inventory fetching. This means you must have the HTTP Inventory option enabled in the viewer (it can be found under the Develop(er) menu).

Should you disable it for any reason, you will encounter two issues:

  • Your avatar will not render, but will remain a cloud
  • Should you refresh your inventory for any reason (clear cache), your viewer will never complete the process of inventory fetching.

Unfortunately, and coincidentally, the Main channel deployment on Tuesday, April 7th came at a time when asset server / inventory issues were being experienced across the grid, and inventory database maintenance was carried out as a result.

Note that from Tuesday, April 6th, you must ensure HTTP Inventory is enabled in the Develop menu (sometimes called the Developer menu in TPVs) in order to help avoid inventory and / or avatar rendering problems
Note that from Tuesday, April 6th, you must ensure HTTP Inventory is enabled in the Develop menu (sometimes called the Developer menu in TPVs) in order to help avoid inventory and / or avatar rendering problems

These issues and the maintenance may have masked any problems some people may have been having purely as a result of HTTP Inventory being disabled in their viewer.

Therefore, if you are encountering problems with your avatar remaining a cloud, or your inventory failing to load, please try the following steps to see if they resolve your situation:

  1. Make sure you have the Develop(er) menu enabled in your menu bar at the top of the viewer. Press CTRL-ALT-Q if you cannot see it.
  2. Click on Develop(er) to list the menu options.
  3. Make sure there is a tick in front of the HTTP Inventory option.
  4. If HTTP Inventory does not have a tick in front of it, then it is disabled. Click on it to enable it (and display the tick).
  5. Closed the Develop menu and re-log.
  6. Hopefully, following your re-log, your avatar will render / your inventory load properly.

UDP Inventory Messaging Deprecated

The reason for this is that the Lab has now deprecated the “old” method of inventory messaging (referred to as UDP messaging). However, if you disable the HTTP Inventory option in your viewer, the viewer will still attempt to use the “old” method, and thus you’ll have problems.

There are plans in hand for the Lab to remove the HTTP Inventory option from the viewer, and some TPVs may opt to remove it ahead of any update from the Lab. Until that time, it is essential you keep the option enabled to assist with the smooth functioning of your inventory.

Experience Keys / Tools

Not a lot to report on this project. Simon Linden has been working on the Key Value (KVP) database store used by Experiences. This work appears to be related to the Lab working to ensure the when deployed Experience Keys / Tools can be properly scaled to meet the anticipated demand for them. Commenting in general terms on the work, Oz Linden said during the Simulator User Group meeting on Tuesday, April 7th, “if we are as successful as we’d like to be with Experiences being adopted, it would run into problems. So we’re trying to solve them before we get to that point.”

SL project updates week 14/2: server, viewer, CDN

Posted on by Inara Pey

The Trace Too; Inara Pey, March 2015, on Flickr The Trace Too (Flickr) – blog post

Server Deployments Week 14 – Recap

As always, please refer to the server deployment thread in the forums for the latest information and updates.

  • There was no deployment to the Main SLS channel on Tuesday, March 31st, due to the inventory issues arising from the week #13 RC deployment – see my update here for details.
  • On Wednesday, April 1st, all three RCs received the same update to the current server maintenance package to fix the issues with Trash failing to purge in non-AIS v3 viewers (see BUG-8877. and my coverage of the recent issues here). Those suffering from inventory fetch failures on RC regions are advised to re-enable HTTP Inventory in their viewers, if disabled (found under the Develop menu).

SL Viewer

Wednesday, April 1st saw the release of the Project BigBird viewer (yes, seriously!), version 3.7.27.300377, which contains the various fixes for attachment issues which the Vir Linden has been working on. Specific fixes offered are listed as (note the MAINT designations are for the Lab’s internal JIRA, and thus non-viewable):

  • MAINT-4351 HUDs and attachments intermittently and randomly detach after teleports, sometimes reattaching on their own shortly after, sometimes staying detached completely, or showing as “worn on Invalid Attachment Point” while still detached
  • MAINT-4653 [Attachment-RC] When using “Add” or “Attach to” to attach multiple attachments at the same time, some attachments fall off and some get attached to the wrong attachment point
  • MAINT-4917 Attaching multiple objects generates multiple bake requests
  • MAINT-4918 Removing multiple attachments generates redundant detach requests
  • MAINT-4919 Attempting to wear an outfit with more than 40 attachments will fail

UDP Paths: HTTP Inventory, Textures and More

As noted at the top of this report, the week #13 RC deployments have been causing some inventory-related issues, one of which –  the Trash purging problem – has been fixed with this week’s RC RC deployment.

The second issue  – failures in inventory fetching following clearing cache on RCs regions – has been caused by a combination of the Lab deprecating the UDP message path for inventory updates and users having the HTTP Inventory option in the viewer (found under the Develop menu – CTRL-ALT-Q) disabled (unchecked).

Given this path has been deprecated, it is essential you keep HTTP Inventory enabled (the Lab will be removing the option from the Develop menu in the future to prevent it being unwittingly disabled).

Speaking at the Server Beta Meeting on Thursday, April 2nd, Oz Linden indicated that the Lab would be taking steps in the future to deprecate UDP messaging is “high on the list” for being deprecated in the future, given that textures have now moved to the CDN.

The CDN and Switching Further Services

While discussing the issue of UDP messaging, Oz again re-iterated the desire to pivot things like fetching animations and sounds away from UDP and onto HTTP, with the aim of provisioning them through the CDN, further lifting the load the simulators currently carry. However, he caveated this with two important points:

  • While this is something he’d like to see done, and is in the plans for SL’s future, the work hasn’t actually be scheduled yet, must less started; therefore it is not something that will be happening in the short-term (or perhaps even the medium term)
  • The Lab is working on a further round of CDN improvements – again, no time scale is available for their implementation – but there won’t be any additions to the data delivered via the CDN until after such improvements have been deployed.

One aspect here is that, in terms of the simulator load and in terms of the vast majority of users, the switch-over to avatar, mesh and texture data to CDN-based services has been a success for the Lab. However, as we’ve also seen, it has resulted in issues for some users, up to and including what is a degraded service due to the actions of at least one ISP.  While the latter is not something the Lab or their CDN provider can directly tackle, it does point to the fact that while off-loading the heavy lifting from the Lab’s servers can make for improvements, it can affect users in other ways.

Hence why the Lab is being cautious in approach, and is continuing to work with its CDN providers to try to improve the service as far as can be done, in the hope of reducing the number of ways in which users might find SL a poorer experience as a result of the CDN implementation. However, exactly what can be achieved and issues mitigated, remains to be seen.

In the meantime, as as per part 1 of this week’s update, if you do feel mesh and texture rendering isn’t what it once was, try following Monty Linden’s interim ideas  for easing things.

SL project updates week 14/1: server and viewer updates, misc items

Posted on by Inara Pey

Piony Hideout, Lions Hill; Inara Pey, March 2015, on Flickr Piony Hideout, Lions Hill (Flickr) – blog post

Server Deployments

As always, please refer to the server deployment thread in the forums for the latest information and updates.

There was no deployment to the Main SLS channel on Tuesday, March 31st, due to the inventory issues arising from the week #13 RC deployment – see my update here for details.

On Wednesday, April 1st, all three RCs will receive the same update to the current server maintenance package. This update is specifically aimed at correcting the trash purging issue reported with BUG-8877. However, the fix does not address the issue of inventory fetching hanging if HTTP Inventory has been disabled within the viewer.

This is because the Lab regards UDP inventory fetching as a deprecated protocol path, as indicated by the release notes, and non-HTTP based inventory fetching is now being phased out. As such, it is anticipated the option to disable HTTP Inventory within the viewer is likely to be hidden / removed at some point in the future.

SL Viewer Updates

The Tools update RC viewer updates to version 3.7.27.300242 on Monday, March 30th, bringing it into line with the current release viewer (3.7.26 with Avatar Hover Height).

The Maintenance RC viewer updated to version 3.7.27.300323 on Tuesday, March 31st. also bringing it into line with the current release viewer,  and includes fixes for many of the bugs and issues encountered with the initial release of the RC.

Other Items

Diagonal Region Rendering Issues

A fair while ago now (late 2012 / early 2013 in fact), I reported on issues that had been noted with regions seeming to be “missing” when seen from other regions.The problem was originally reported in SVC-8130, which is still marked as “unresolved”, and it had been hoped that fix for SVC-8019 would address the problem as well as dealing with other issues. However, the problem has continued intermittently ever since, with numerous issues marked as duplicates of SVC-8130 being reported, with the issue most recently being seen when looking at regions diagonally opposite Brocade on the Mainland.

The return of the missing regions issue (if it ever really went away): looking north-east from Brocade towards where Mullein isn't on the Mainland. Not, as well, the region kitty-corner beyond Mullein is also absent the view, although both appear on the map
The return of the missing regions issue (if it ever really went away): looking north-east from Brocade towards where Mullein isn’t on the Mainland. Not, as well, the region kitty-corner beyond Mullein is also absent the view, although both appear on the map

The problems are regarded as handshaking / communications issues between region, and are generally resolved through a region restart; although understandably, some holding regions on Mainland are reluctant to request a restart as this can affect multiple other region as well.

Multiple Calling Cards

Most of us are familiar with calling cards in the viewer. They can be obtained by friending someone, or by someone giving you their card (or you giving them your card, and are useful for things like  opening people’s profiles from inventory (particularly handy in cases where you haven’t friended someone, and so don’t have to use search to locate them), or initiating an IM conference call.

One of the many calling cards issues - spawning multiple copies of the same card (images via Jessica Lyon)
One of the many calling cards issues – spawning multiple copies of the same card (images via Jessica Lyon)

However, within v3-style viewer they can also be annoying, as they have a tendency to multiple for no readily apparent reason. People can often have a set of calling cards under the Calling Cards folder, which can be partially replicated in the Friends sub-folder, and then fully replicated in the All sub-folder beneath that, for example. Or individual cards can get spawned multiple times across one or more folders for no readily apparent reason.

The problem here is that having a high load of calling cards can generate problems logging-in to SL, where they run out of curl multihandles, causing log-in to hang or for them to disconnect on logging-in. This can usually be solved through … wait for it … disabling HTTP Inventory and then logging-in and deleting them, but this may not be an option in the future (see the notes at the start of this report). Given that calling cards get re-spawned following a re-log after deletion, and can start multiplying again, Oz noted in the SUG meeting that they are now an area “worthy of some study”.

Rendering / Rezzing Failures and the CDN

In week #13 I reported on rendering / rezzing issues being experienced by some people in the Florida / Alabama region of the USA. Since that time, the Lab’s investigations through the CDN provider have suggested the the ISP in question (Mediacom) has degraded the service, possibly due to the volume of traffic coming from the CDN. This was a concern voiced early-on during the CDN implementation, but this appears to be the first time such a move has been confirmed. In the forum thread on the matter, which has seen more input on the situation, Monty Linden has offered some interim ideas that may help users experiencing problems, while also emphasising the Lab is still working with the CDN providers to further refine the service.

SL project updates week 13/1: server, RTLP and misc news

Posted on by Inara Pey

Server Deployments Week 13

As always, please refer to the deployment thread in the forums for the latest updates / news.

  • On Tuesday, March 24th, the Main (SLS) channel received the server maintenance package deployed to the three RCs in week 12, comprising updates which allow the Lab to make various configuration changes without having to necessarily run a rolling restart when they have done so. It contains not actual functional changes to the simulator software
  • On Wednesday, March 25th, the three RC channels should all receive the same new server maintenance package, which is focused on inventory loss issues, and provides the Lab with better error detection and logging, improving their ability to look at some of the failure places and the removal of unused code.

SL Viewer

On Tuesday, March 24th the Avatar Hover Height (AHH) viewer, version 3.7.26.299635 became the de facto release viewer. Avatar Hover Height is a new feature that allows you to adjust the vertical position of your avatar within some preset limits. This is a purely graphical tweak that does not affect your position for physics purposes. For it to work properly, both you and observers watching you need to be running a supported viewer.

You can find out more information view the wiki page and / or via my overview of AHH.

Now in the release viewer: Avatar Hover Height provides a means of adjusting your avatar's graphical height above the ground / floor / objects, as seen by yourself and others
Now in the release viewer: Avatar Hover Height provides a means of adjusting your avatar’s graphical height above the ground / floor / objects, as seen by yourself and others, on-the-fly

A very slight peculiarity with AHH, which seems to work very well, that if you have camera angle moved to the “default” view looking out from behind your avatar by hitting ESC to reset your camera angle, and use the AHH function, it can also change your camera angle. However this doesn’t happen if you’re using any other camera position at the time you alter your height using AHH. This appears to be because there is some interact between the avatar’s height and the default camera position which might be expected behaviour, and may be looked at again in the future. In the meantime, it doesn’t impinge on the overall functionality of AHH.

Restore to Last Position

Note that the RC update is does not include any deprecation of the server-side message used by the restore to last position code (RLTP) used by TPVs.

Commenting on the status of any removal of the server-side support for RTLP (see here for background on this) during the Simulator User Group meeting on Tuesday, March 24th, Simon Linden said, “We haven’t done anything about RTLP  and it’s still officially unsupported.   There’s a long list of issues that would really make that feature work.   It would be really nice, but it’s not just fix-one-bug.”

Oz Linden then added, “We won’t disable it completely without fair warning at the TPV meeting. What I’ve done so far is just ask questions – it doesn’t count as fair warning :-).”

 Other Items

Mesh Uploader

There is currently a mesh uploader project viewer (version 3.7.25.298441), which includes various improvements to the uploader, and which will most likely be progressing through to RC status and to a release status over time. However, there are still further requests for the uploader to be improved in terms of the information it displays, two of which are:

  • Better capabilities for zooming the model preview window after using the scale option, so that if the preview image is enlarged the user can zoom out further than is currently possible
  • The ability to provide an actual LI calculation while using the custom physics model upload, rather than just a convex hull measurement (see VWR-28177 “Enable Prim physics-shape-type physics weight display in upload floater”).

Both of these were raised at the Simulator User Group meeting on Tuesday March 24th; which doesn’t mean they’ll necessarily be acted upon, but while the Lab is tinkering with the uploader, it does bring both matters back to the Lab’s attention.

Avatar Hover Height reaches release viewer

Posted on by Inara Pey

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 option 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
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

SL projects update week 11/2: TPV Developer meeting + misc news

Posted on by Inara Pey

Armenelos, Calas Galadhon; Inara Pey, March 2015, on Flickr The Shire (Flickr) – blog post

The following notes are primarily taken from the TPV Developer meeting held on Friday, March 13th,  a video of which is included at the end of the article (my thanks as always to North for recording it and providing it for embedding), and any time stamps contained within the following text refer to it.

Server Deployments Week 11 – Recap

As always, please refer to the sever deployment thread for the latest updates and information.

  • There was no Main (SLS) channel deployment on Tuesday, March 10th
  • On Wednesday, March 11th, all three RC channels received the same new server maintenance package comprising “internal improvements for premium users”.

SL Viewer

The Avatar Hover Height viewer reached the release channel on March 10th, with the release of an RC version (3.7.26.299635). Avatar Hover Height allows you to adjust the vertical position of your avatar within some preset limits. See the wiki page and my overview.

This brings the total number of RC viewers in the viewer release channel to four, however:

  • [0:41] It is unlikely the Maintenance RC viewer (currently version 3.7.26.299610, released on March 6th) will be promoted without further update, as it has been found to contain a significant number of additional bugs which require fixing
  • [0:51] As the Avatar Hover Height RC viewer has only just been released, it is unlikely that the Lab will have enough stats on it to judge whether or not it can be promoted to the de facto release viewer in the immediate future; it is therefore likely to remain at RC status for at least another week, although initial reports suggest it is stable and doesn’t hide any unpleasantness
  • [01:07] The back-end support for Experience Keys / Tools still isn’t ready for the service to go live, although the Lab is making further progress with whatever needed to be done; it is therefore remains unlikely the that Experience Keys viewer (currently version 3.8.0.299338, released on March 9th) will be promoted to the de facto release viewer until such time as the remaining back-end work has been completed.

Tools Update Viewer and XP Users

[01:20] This potentially means that the Tools Update RC viewer (currently version 3.7.26.299443, released on March 4th) may be promoted to the de facto release viewer in week #12.

When this happens, it will obviously mean that all future builds of the official viewer will be made using the new tool chain and autobuild process. This in turn means that any Windows version of the viewer built using the new tools set (which includes MS visual Studio 2013)  will not run on any version (32-, or 64-bit) version of Windows XP. To this end, the installer is being set so that it requires a minimum of Windows Vista with Service Pack 2 installed, in order for it to successfully install the viewer.

Note that this is not a deliberate attempt to block XP users from Second Life; it is purely the result of the Lab moving towards the use of up-to-date tools for building the viewer (and which will yield positive benefits elsewhere, such as with greater tool commonality between the Lab and TPVs), and some of these tools do not support windows XP due to its age and it no longer being actively supported by Microsoft.

[16:54] Some TPVs may investigate / opt to build the viewer somewhat manually using the new tool chain in such a way that it can be used on XP, but this is reportedly requires a “very large amount of work” to achieve, requires a lot of command line input, an avoidance of VS 2013, and is “really hacky”.

Project Viewers

    • [03:28] The Viewer-Managed Marketplace project viewer (currently version 3.7.25.298865, released on February 13th) is liable to be updated in week #12 as a result of further fixes and updates that came out of the last round of testing
    • [04:20] The Mesh Importer project viewer (currently version 3.7.25.298441, released on February 3rd), is currently undergoing further update with new fixes and will be updated as a project viewer in the near future.

 

Avatar Layers Global Limit

Vir Linden - working on the new wearable layers code
Vir Linden – working on the new wearable layers code

[04:41] In response to  BUG-6258, “Popularity of Mesh Attachments Facilitates Need For More Alpha Layers”,  the Lab is working to implement a new “global” limit to the number of system clothing layers an avatar can wear.

Under the current system, there are 12 types of clothing layers or wearables (alpha, tattoo, undershirt, shirt, jacket, underpants, pants, gloves, socks,  skirts, shoes, and physics), with (generally) up to 5 of each type of wearable able to be worn at the same time, giving a maximum of 60 wearables that can worn simultaneously.

Under the new code being developed by Vir Linden, a new “global” limit of 60 wearable layers is being set per avatar, and users will be able to wear any number / combination of layers up to that limit (so you could opt to wear 60 jacket layers if you wanted, or 10 each of alpha, shirt, pants, gloves, jacket and socks, for example).

This update requires changes to both the viewer and to the server-side Appearance (SSA) service. The viewer-side changes are updates to the viewer’s logic, so it is purely checking the number of worn layers against the global limit of 60, rather than limits set for individual layers. The SSA changes will similarly support the new “global” use of clothing layers, but will also continue to support the 5-per-layer limit for viewers that do not adopt the newer code, or require a longer lead time in order to adopt the new viewer code, once it is available, thus providing a measure of “back compatibility”. The viewer code is expected to appear in a project viewer once it, and the back-end changes have cleared the Lab’s QA team.

Group Chat

[09:29]  As noted in my recent updates, changes made to the group change service in the last two weeks unexpectedly resulted in up to 20% of messages failing to be delivered correctly. Simon Linden spent a fair amount of time during week #10 stabilising things and delivering further updates to try to correct the problem. As a result, in what has been called an “educational” two weeks for the Lab, the situation has been largely reversed, although some problems still remain.

The Server Beta User Group meeting on Thursday, March 12th, saw a further set of updates from Simon undergo testing on the Beta grid, and during the TPV Developer meeting on Friday, March 13th, Oz indicated that the Lab will probably undertake a further round of “serious” upgrading of all the technology associated with group chat before they declare the project in any way “finished”. This will likely involve putting the back-end service support group chat on more up-to-date hardware and OS environments.

Continue reading “SL projects update week 11/2: TPV Developer meeting + misc news” →