Tag Archives: SL Viewer Updates

SL project updates 16/1: server, teleports and other bits

The Incredible 4 blog post

Server Deployments

As always, please refer to the server deployment thread for the latest information.

  • On Tuesday, April 18th the Main (SLS) channel received the server maintenance package previously deployed to the RC channels in week #15. This includes:
    • Several internal fixes and two new internal logging modes
    • Another adjustment to fix issues with off-line IM and Group Notice delivery reliability
    • Fixes an issue where large numbers of objects could be returned after a rolling restart.
  • On Wednesday, April 19th, the RC channels should be updated as follows:
    • BlueSteel and LeTigre should receive the improved region capacity and access capabilities
    • Magnum looks set to receive a new “secret” update, which has been under testing on the Snack channel (and will likely have Snack reabsorbed into it).

SL Viewer

There have been no viewer updates thus far this week, leaving the viewer pipeline as:

  • Current Release version: 5.0.3.324435, dated March 13 – snapshots to e-mail hotfix
  • Release channel cohorts :
    • Project AssetHttp project viewer version 5.0.4.325368 dated April 12th – This viewer moves fetching of several types of assets to HTTP / CDN – overview
    • Maintenance RC viewer version 5.0.4.325124 dated April 3rd – avatar rendering and other updates
  • Project viewers:
    • Project Alex Ivy (LXIV), 64-bit project viewer version 5.1.0.503537 dated March 17th
    • 360-degree snapshot viewer version 4.1.3.321712 dated November 23, 2016 – ability to take 360-degree panoramic images – hands-on review
  • Obsolete platform viewer version 3.7.28.300847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Differences Between Teleporting and Physical Region Crossings

As we know, whether you teleport between one region and another or physically cross the boundary between two regions, you are performing a region crossing. However, there is a slight different in how they are handled. Rider and Simon Linden described the processes involved during the Simulator User Group meeting, which makes for interesting reading if you weren’t previously aware of the processes involved.

In referencing teleporting between regions, Rider said, “Teleport packs your avatar into a big ball of data and throws you at the destination.” It’s then left up to the destination region to determine whether or not you actually get in. Hence the teleport progress bar.

Simon then said of a physical region crossings, “They do a bit more pre-crossing checks to see if you go into the neighbour[ing] region than TPs do.” Rider Linden then added, “If the regions are adjacent, the sim you are on checks to see if it should smush you into that ball before it does.”

These pre-crossing checks are handled through your child agent on the neighbouring region, allowing the simulator running the region you’re currently in to “see” if you’re able to access the neighbouring region. If it believes you can’t, it won’t bother creating the ball of data about your avatar (and everything attached to it), reducing its workload.

When is a Region Not a Region?

A curious topic came up at the meeting: when is a region not a region? The simple answer is probably “when you can’t see it”. But what about if you can – apparently – see it, at least on the map, and it doesn’t appear to have a name.

The mystery island as it appeared for some people using both the LL viewer and Firestorm

Whirly Fizzle spotted this phenomenon on the World Map with a region apparently adjoining The Epiphany, although her curiosity was piqued as it was apparently without a name. The mystery deepened when most of those at the meeting reported they couldn’t see any such region on their maps – although two or three besides Whirly could, on both TPVs and the official viewer (ruling on an issue in how a specific viewer is handling the map data).

What was equally mysterious, was that those who were able to see the unnamed island on the World map could also see it on the web SL map – while those who couldn’t see it on the world map also couldn’t see it on the web SL map.

As other saw the same area on the map – regardless of viewer

Several theories were put forward for the phenomenon, including it being a  non-updated map texture; a potential error in map tiling and loading;  an  old texture loaded and stuck at the  wrong LOD; and so on.  Running a quick check, Simon Linden couldn’t find any evidence for a region ever having been placed in any of the eight grid areas surrounding The Epiphany. He did, however, offer a possible explanation of what might have happened:

I do know the support team will do some interesting tricks sometimes … they will move one of their regions next to another to do some sort of work, then move it away. Perhaps that got captured there.

Either way, a curious little anomaly.

Mesh UUID Flipping via Script / UUID

Back in the mists of time as mesh support was being added to Second Life, there was the ability to change mesh assets via UUID / LSL. However, the ability was used most frequently as a means of animating meshes  – putting considerable stress of the rendering system in the process. Because of this, a wiki page on the subject was raised, and the ability to change mesh UUIDs via script was eventually removed altogether.

The Lab is currently considering implementing a means to animation meshes (something routinely discussed at the Content Creator’s User Group meeting). This would be a far more efficient and less stressful means of animating meshes where it to be taken up as project, and completely negate the need for animation via UUID flipping.

However, while allowing meshes to be changed through scripts / UUIDs has other potential uses, it is unlikely to be re-introduced even if animated meshes are introduced to SL, because anyone obtaining the UUID for a mesh could potentially download the “mesh” as a vnd.ll.mesh  file from the CDN, and could then theoretically reconstruct the original mesh item from that data (thus effectively stealing it).

Advertisements

SL project updates 2017 15/1: server, viewer

Sky Gardens, Holly Kai Park

Server Deployments

As always, please refer to the server deployment thread for the latest information.

  • The was no Main (SLS) channel deployment or re-start on Tuesday, April 11th.
  • On Wednesday, April 12th, the three RC channels should all receive a new server maintenance package which includes:
    • Several internal fixes and two new internal logging modes
    • Another adjustment to fix issues with off-line IM and Group Notice delivery reliability
    • Fixes an issue where large numbers of objects could be returned after a rolling restart.

It had been indicated that the new server OS build could be deployed to an RC this week. Whether this would be a “full” RC (BlueSteel, Magnum or LeTigre) or perhaps to a limited channel (as is the case with the increase avatar capacity updates, which are on McRib),  was made clear. More on this later in the week, maybe.

SL Viewer

The recent Voice RC, version 5.0.4.324770 was withdrawn some time on Monday, April 10th / Tuesday April 11th as a result of suffering a high crash rate.

The AssetHTTP project viewer was promoted to RC status with the release of version 5.0.4.325144 on Monday, April 10th.

This leaves the remainder of the current viewer list as:

  • Current Release version: 5.0.3.324435, dated March 13th – snapshots to e-mail hotfix download page, release notes
  • Release channel cohorts:
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847 dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

New region and parcel access controls coming to Second Life

(Copyright Linden Lab)

At both the Server beta meeting on Thursday, April 6th and the TPV Developer meeting on Friday April 7th, Grumpity Linden and Oz Linden revealed more about the upcoming changes to region and parcel access settings.

The server-side update for thee control are currently on the three RC channel (server maintenance package (17#17.03.31.325149) – but the changes as a whole will not come into effect until after there has been a significant UI update to the viewer.

So what is changing?

In short, the new controls – once they are available through the viewer – will mean that when a region is explicitly set to Public Access via the Region / Estate floater, parcel owners will no longer be able to unhceck Allow Public access or set other restrictive access (e.g. Group Only) in the About Land floater for their parcel – so no more ban lines on regions explicitly set to Public Access. However, parcel-level ban lists will still apply and if things like security orbs are allowed with the region in question, they will still work as well.

Note that no change will occur where Allow Public Access has not been explicitly set within the Region / Estate floater. In these instances, parcel owners will still be able to set their own access.

This change is being made for several reasons. For example, it is something many region owners (and those who sail / boat / fly  / drive through ostensibly public regions) have requested; it is also something many estates have in their covenant but cannot actually enforce; and so on.

With the upcoming changes, if an estate is set to Allow Public Access (top), parcel holders on that region will no longer be able to override the public access using the About Land access options (above). However,the parcel ban list and and installed security system will still apply

These changes mean that the viewer UI – as noted – will be undergoing some significant changes.  Exactly how extensive thee changes will be is unclear. However the Lab is conscious of the need to ensure there is no ambiguity in the controls, and that issues such as BUG-4994 which results in a parcel being set to Group access (and gaining ban lines) if both the Public and Group access options are checked, are also resolved as a part of the work.

At the Server Beta meeting on Thursday, April 6th, Grumpity Linden commented on the UI updates thus:

We are trying to find the best way to express the access sets most clearly … The UI is changing to better convey what your actual settings permit …

1) EO & EM can now force parcels to be no more restrictive than the Estate level setting.

2) UI for both Estate and Parcel access management is confusing. We’re making changes to make it less confusing. The weirdness where you check “Public access” and “Group access” and end up with group ONLY unless you also check “PIOF” and then you get group + public w/PIOF … that will not stand.

UI will grey out unavail options; also, estate level setting will include a warning dialogue to hopefully deter EM from messing with this override willy-nilly.

It is anticipated that a viewer (project or RC) with the required updates could be appearing in week #15 (week commencing Monday, April 10th).

The changes and the upcoming viewer UI updates were also discussed at the TPV Developer meeting, from which the following audio excerpts were extracted and put together.

These comments can be heard in full on the video of the TPV Developer meeting, commencing at the 4:45 time stamp.

SL project updates 2017 13/2: server, viewer, Content Creation meeting

PeTOublog post

Server Deployments – Recap

  • There was no update to the Main (SLS) channel on Tuesday, March 28th.
  • On Wednesday, March 29th, the three RC channels received a new server maintenance package, primarily comprising a small update to asset metrics stats logging.

Week #14 (commencing Monday, April 3rd) should see a new RC update: “New estate setting allowing estate owners to override the parcel level allow public access settings”, which I assume will be awaiting a viewer-side update once deployed – but more on that next week.

SL Viewer

The new AssetHttp Project viewer,  version 5.0.4.324828, appeared on Thursday, March 30th. This contains code for handling the delivery of landmarks, wearables (system layer clothing and body parts), sounds and animations via HTTP and through the Content Delivery Networks the Lab leverages. I have a separate report on it available here, and Vir Linden – who has been leading the viewer-side work for the project – had this to say at the Content Creation User Group meeting on March 30th:

Outside of this, the various LL viewer channels remain as follows:

  • Current Release version: 5.0.3.324435, dated March 13th – snapshots to e-mail hotfix
  • Release channel cohorts:
    • Maintenance RC viewer version 5.0.4.324882 released on March 23rd – avatar rendering and other updates – overview
    • Voice RC viewer version 5.0.4.324770 released on March 20th – several improvements to voice
  • Project viewers:
    • Project Alex Ivy (LXIV), 64-bit project viewer updated to version 5.1.0.503537 on March 17th
    • 360-degree snapshot viewer updated to version 4.1.3.321712 on November 23rd, 2016 – ability to take 360-degree panoramic images – hands-on review
  • Obsolete platform viewer version 3.7.28.300847 dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

New Simulator Build Testing

DRTSIM-323 is the channel on Aditi (the beta grid) which is carrying the a new version of the simulator code using the Lab’s latest build of the server operating system. In includes the regions: Fire Ants, Bug Island and Mauve (again, these are on the beta grid). It’s still under test, and will remain that way for a while yet, although there is some limited testing occurring on the Snack channel on the main grid.

Content Creation Group Notes

Animation Transitions

Vir is still looking at the issue of animations becoming “stuck” between transitions when using  llSetAnimationOverride – an avatar freezing when it should transition from standing to walking, for example, or getting stuck in a pre- or post-jump mode (see  BUG-7488 as an example of the kind of problem). As llSetAnimationOverride is a server-side function, it would appear that something is going awry there, but pinning it down is proving difficult.

Mesh Upload Physics Type

This goes back to a very old Mesh beta (when mesh model support was being introduced to SL), and feature request CTS-571, and also related to BUG-40694. In sort, the original request was to allow the physics shape for an object to be set at upload time, rather than as is currently the case, after the upload. Allowing this is seen as a potential fix for a wide range of issues associated with mesh modelling, and could also overcome lot of the “failed to rez” inventory loss is due to the use of the lowest LOD auto-generated shape preventing a ray trace hit on the server-side when trying to place objects, as defined in BUG-40694.

While cautioning that changes to the mesh uploader aren’t currently on the roadmap, Vir listened to the discussion of the issues, and indicated he’d take a look at the upload and the problems, and possibly suggest a re-visit to the uploader might be in order depending on what he finds.

Object Permissions – Derivative Permission Discussion

Note that while the following was discussed during the Content Creation User Group meeting, it does not mean anything is about to be changed with the Second Life permissions system.

There have been a number of long-standing pricing issues with selling full permission items, such as kits to help people build content they can sell, or mesh templates for clothing and accessories which allow non-mesh modellers to enhance (via texturing, scripted options etc.) to enhance and then re-sell. So of these discussions can be seen as far back as with feature request SVC-2622.

Touching on these issues from the perspective of diminishing returns for creators of full permission kits and templates, Cathy Foil enquired whether a “derivative” permissions flag, similar to that seen within IMVU might be added to SL. This would still allow those wishing to sell full permission Copy, Modify, Transfer items to do so, but it would also allow kit and template makers to set the Derivative flag against a product (so it is Copy, Modify Derivative, for example).

This flag would allow others to buy the item, enhance it, resell it, etc., but with the caveat that the minimum they could re-sell it for would be the original purchase price. Thus, they would naturally be encouraged to sell it for more (with the potential for the original creator of the item effectively getting a “royalty” type payment of each item sold).

This sparked a lengthy discussion on a range of topics – such as adding derivative chains to the system (allowing all changes to an item by various resellers to be tracked), through the idea that such a system would encourage people to add value to the products they create using fell perm kits / templates in the knowledge their work would be rewarded, etc.

However, as Vir pointed out, changing the permissions system itself is complicated and not easy to update. Adding some kind of derivative tacking  system would as well makes any such update, even were it to be considered, vastly more complicated in scope. As such, it is not something the Lab is liable to consider.

Avastar,  MayaStar and Maya .ANIM Exporter

Avatar 2 is now at release candidate 7 for those with the product, MayaSatar has received an update covering bug-fixes and the like.

Aura Linden is still working on the .ANIM exporter for Maya (does not require MayaStar), but as she’s working on this in her own time, it’s taking a little longer than anticipated to finish off, having had to re-write the exporter using python rather than Maya’s own MEL scripting language.