Category: Simulator User Group

SL projects update week 50 (2): Fitted mesh, deformer, viewer code contributions

Posted on by Inara Pey

Mesh Deformer and Fitted Mesh

The future of mesh garments / wearables created using the now SL-defunct mesh deformer was the subject of some discussion at the Open-source Contributions meeting on Wednesday 11th December. While the deformer was never officially adopted by the Lab for use within Second Life, it was available in various test and experimental viewers, and the code could also be included in self-compiled viewers if people knew how.

Fitted mesh is coming....what of the future for garments made for the deformer?
Fitted mesh is coming….what of the future for garments made for / via the deformer?

This means that there are garments within Second Life that were created and uploaded for / with the deformer code, and which can resize with viewers using that code. However, as is the case with Fitted Mesh, the clothing would not deform when using a viewer without the requisite code. The same will be true once the Fitted Mesh updates reach a release candidate status and start to be more widely adopted: while Fitted Mesh (and Liquid Mesh) garments, etc. will deform to an avatar’s shape, items created using the mesh deformer will not; they will continue to behave like any other rigged mesh item.

This likely means that as the Fitted Mesh code does become more widely adopted, people will stop using any garments / attachables created using the deformer code, and the availability of such items in SL and on the SL marketplace will decline over time.

Whether or not this means deformer-based items will vanish from people’s inventories is something only time will tell. From the Lab’s perspective, the work involved in trying to pro-actively determine a method of identifying assets using the deformer code and removing them from the asset servers / inventories isn’t likely to be worth the end result. Therefore anyone with “old” mesh deformer garments and attachables will probably retain them until they opt to delete them from their inventory.

It appears unlikely that viewers using the deformer code will be pro-actively blocked from SL. What is likely to happen is that the code simply will not be formally adopted by those variants of TPVs which do not connect to any other grid than Second Life. However, this does leave a further interesting question as to the future of the mesh deformer, which has potentially seen far wider use in OpenSim communities than Second Life. While it would seem likely OpenSim will adopt the viewer-side changes required to enable Fitted Mesh (at least in the majority of cases), at this point in time, it is not clear whether the mesh deformer will be entirely abandoned. Whether there will be sufficient pressure within OpenSim for the deformer code to remain in use, and whether TPVs will feel obliged to incorporate the deformer into their viewers / OpenSim variants of their viewers as a result, remains to be seen. Currently, the only grid which has any kind of significant investment in the deformer is InWorldz, which provided funds for the code to be further enhanced and adopted it into their dedicated viewer in July 2013.

Materials and Numbers

Statistics are always a hard thing to determine. Back in the day, there was much controversy over figures released as to the adoption of mesh within SL following its deployment. The figures offered-up by the Lab at the time were vague enough that they could be taken to mean that mesh was either being rapidly adopted, or was seeing very slow growth (with the reality lying somewhere in between). This was not an attempt by the Lab to fudge issues at the time; it simply underlined the fact that numbers aren’t always the best means of trying to quantify something, so it’s perhaps better to allow the passage of time to speak for itself.

The most recent figures for materials suggest that over half of the regions in SL now have at least one materials-enabled item within them, and around 10% of avatars apparently utilise at least one materials-enabled item.  Again, these are figures that are likely to be interpreted either way, depending on how people look upon materials as a whole. Certainly, the term “object” is sufficiently vague so as to be pretty worthless as am objective yardstick, as it likely covers everything from an individual prim through to entire linksets, which leads to a huge variance in the visibility of objects using materials. On a personal note, I can only say I’ve made extensive use of materials in my house, and am more than pleased with the results.

I've used materials on my house; particularly on the stonework and stucco textures to prevoide added depth. Materials on the whole appears to be slowly gainly momentum
I’ve used materials on my house; particularly on the stonework and stucco textures to provide added depth. Materials on the whole appears to be slowly gaining momentum

Upcoming Code Contributions

There are a number of third-party code contributions in development for the SL viewer, some of which I’ve previously reported upon, and which are now progressing towards a point where they may well have public visibility through the likes of a release candidate in the new year.

STORM-1981 and STORM-1831

STORM-1981, contributed by Jonathan Yap, is intended to change the behaviour of tracking beacons to help make locating items in a region somewhat easier (e.g. locating lost items or scripted objects which are causing issues, etc.).  Under these changes:

  • Beacons would begin at a height of 0 metres and extend up to the maximum unassisted flight ceiling (5,020 metres)
  • The beacon colour will be blue from 0 metres to the base height of the object being tracked, and red from 5,020 metres down to the height of the object being tracked
  • Users can optionally set the beacon to pulse towards the target object using the CheesyBeacon debug setting (Advanced->Highlighting). The blue beacon will pulse up towards the object, the red beacon will pulse down towards the object.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.
Tracking beacons will be changing under STORM-1981, making it easier to locate objects, etc.

STORM-1831 covers the work being undertaken by Ima Mechanic, with assistance from Oz Linden, to improve syntax highlighting in the viewer’s LSL editor by allowing the viewer to obtain the information required for syntax highlighting directly from the simulator the viewer is connected to. This should eliminate issues with the current manually updated files used to manage syntax highlighting falling out-of-synch with new LSL syntax as new functions and parameters, etc., are added. Folded-in to this work should also be a change to the source code text allowance in the viewer’s LSL editor, increasing it from the current 65,000 characters to around 256,000.

The server-side cap updates required for both STORM-68 and STORM-1831 have been combined and passed into the simulator release stream, and while it is unclear as to when the cap updates will reach a server-side release candidate package, their progress is being tracked. Obviously, both STORM-1981 and STORM-1831 require viewer-side updates as well, and these will hopefully appear in viewer release candidate form once the server-side updates are sufficiently deployed.

STORM-68

A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. STORM-68 aims to add a similar capability to the LL viewer (and which will quite possibly supersede the capability in TPVs once implemented). This work is again coming from Jonathan Yap, although it requires server-side updates, which Andrew Linden has been taking care of. However,  this work has hit some problems in viewer / server interactions, which may be down to timing issues between requests and acknowledgements being sent between the viewer and  the simulator and vice-versa. As such, further testing is required, so it’s possible this work might take a little longer to appear in the new year.

SL projects update week 50 (1): server and viewer updates

Posted on by Inara Pey
A typical Simulator UG meeting (stock)
A typical Simulator UG meeting (stock)

Server Deployments week 50

As always, please refer to the week’s forum deployment thread for the latest news and updates.

Second Life Server (main channel) – Tuesday December 10th, 2013

The main channel was updates with the server maintenance project that was on the RC channels in week 49.  This project includes a few miscellaneous bug fixes. These include a fix for BUG-4431, which Maestro Linden, speaking at the Server Beta meeting on Thursday December 5th, described as:

A fix for avatars with crouch / crouchwalk animation overrides. Previously, the llGetAgentInfo() LSL function would only return AGENT_CROUCHING if the avatar was playing the default crouch or crouchwalk animations, so if your avatar had an AO which replaced those animations, (either with llSetAnimationOverride() or possibly with classic AOs too), scripts couldn’t tell when you’re crouching. But with the fix, the function is looking at whether you’re actually crouching, regardless of which animations are playing.

This should be the only “visible” fix within the package.

Second Life Release Candidate Channels – Wednesday December 11th, 2013

All three RC channels should receive a new server maintenance project containing a single bug fix related to vehicles becoming stuck in the ‘sat upon’ state (which prevents parcel auto return).

This issue is related to vehicles getting into a “bad” state if they lose the passenger right at region crossing. The vehicle is left with what is effectively a “ghost rider” sitting in it, which defeats parcel auto return, leaving the vehicle in-world.

SL Viewer

The SL release viewer was updated on Tuesday December 10th to version 3.6.12.284506, formerly the NameUpdater release candidate. This release does not contain any updates to the viewer’s functionality, but does change installer naming and fixes an updater issue.

Code Freeze / No Change Window

Week 50 marks the last week for deployments to release, main and RC channels by the Lab for both the viewer and the servers prior to the Christmas / New Year code freeze / no change window commencing on Monday December 16th. The no change window extends through until the start of January, and will see no significant releases (other than possible emergency updates, if they are required), although there may still be updates to project viewers.

The main reason for the no change window is to allow Linden staff, notably support personnel, have a decent break over the holiday period without the risk of having to deal with significant issues as a result of a change or update immediately prior to the actual holiday period. To ensure this is the case, the code freeze starts ahead of the actual holiday period so that the Lab can ensure those final releases for the year which are made are robust and stable and unlikely to give a major cause for concern while still having staff available to deal with matters should things get a little higgledy-piggledy*.

Other Items

“Uniform Scaling” LSL Functions

Andrew Linden has been working on a set of “uniform scaling” LSL options which would allow an object / linsket to be rescaled via a single LSL call – such as uniformly increasing or decreasing its size by a factor of 2. The work is still experimental and won’t be deployed until 2014. However, commenting on the work at the Simulator User Group meeting on Tuesday December 10th, he said:

One problem with scaling by multiplicative factor is that the scale operation might fail for a number of reasons; there are four categories of failures: hit the “prim is too small” limit. (2) hit the “prim is too big” limit (3) violation of linkability rules for linked set (when making bigger) (4) misc failures because of navmesh or other things.

The current API includes three calls: (A) llGetMinScaleFactor(), (B) llGetMaxScaleFactor() ; (C) llScaleByFactor(float). I currently handle failures (1) through (3), and the llScaleByFactor() will return FALSE if it fails, but it won’t tell you why it failed. You can use llGetMaxScaleFactor() and friend to ask what the max/min multiplicative factors are possible for reasons (1) through (3). Needs some work, but it is in progress.

A further concern / failure point was raised at the meeting: rescaling an object containing mesh and hitting the land capacity for a region as a result of the LI value increasing. One suggestion for avoiding this would be to have a function which could determine how far an object can be scaled prior to hitting the capacity limit for a parcel (e.g. returns the potential LI for a given scale value before an object is rescaled; however how this might be accurately achieved is unclear, particularly as LI scaling with mesh objects can be subject to a range of factors.

It will be interesting to see how this progresses.

*For those unfamiliar with the term “higgledy-piggledy”, I offer the following explanation:

Higgledy-piggledy explained courtesy of Mr. Berke Breathed
Higgledy-piggledy explained courtesy of Mr. Berke Breathed

SL project updates: week 49 (3): Fitted Mesh, AIS v3, Oculus Rift and more

Posted on by Inara Pey

The following notes are taken from the TPV Developer meeting held on Friday December 6th. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.

TPV Developer meeting (stock)
TPV Developer meeting (stock)

Release Channel Viewers

Name Updater Release Candidate

[00:17-01:40]

The Name Updater RC viewer, also released on December 3rd, has been updated to version 3.6.12.284506. This contains no functional changes to the viewer itself but contains two sets updates, hence the odd name.

The first of these is a fix for the viewer updater where problems can occur if a new update to the viewer is downloaded by the updater but deleted somehow prior to  the installer itself being executed. The second set of updates cover:

  • Changes to how the viewer packaging is done and cleans-up how the viewer channel (used to recognise the viewer and allow it to connect to the SL servers when logging-in) is distributed and established
  • Makes some changes to the viewer start-up parameters
  • Changes the package names to a uniform format which is the same for all of the operating system platforms.

The aim of these changes is to further improve the viewer build process and reduce the number of places changes have to be made in order to change the viewer channel name when building different flavours of the viewer (LL’s own or a TPV).

The RC has been performing well in terms of low crash rates, etc., and looks set to be promoted to the de facto release viewer in week 50 (week commencing Monday 9th December), and so will see-out 2013 as such if this is in fact the case.

Google Breakpad

It is possible a further Google Breakpad RC may appear in week 50.

Maintenance Release Candidate

[02:00-02:16]

The Maintenance RC viewer 3.6.12.284430, released on December 3rd  suffered an abnormally high crash rate, prompting it to be withdrawn in order for it to be looked at and crash issues diagnosed / fixed. Once these issues have been dealt with, the viewer will be returned to the release pipe.

Project Interesting Viewer

[39:24-41:07]

The Project Interesting (aka “viewer-interesting”) RC viewer has been in RC for a while and is suffering a high number of crashes, which are currently being investigated by the Lab. Unlike the Maintenance RC viewer, it has been left as an RC simply because issues are being found with it, because of both the number of people using it and the broad range of systems on which it is being run and which the Lab couldn’t possibly account for in their own testing.

At the moment, the Lab are trying to put together an update for the viewer, but they still have a couple of “pretty serious” crash issues which have yet to be resolved. However, the hope is that this may actually make it out into the world before the no change / code freeze window comes into force  on Monday December 16th, which affects all server releases and all viewer release channel releases. This would allow the updates made to get further “in the field” testing during the code freeze / holiday period.

That both the Project Interesting and Maintenance RCs are experiencing issues is something of a validation of the new viewer release process introduced by the Lab earlier this year, in that the problems being encountered with both of these viewers are not blocking the viewer pipe, unlike the situation of just over a year ago, where a series of crash issues with the old beta viewer completely halted all significant viewer updates.

Fitted Mesh Project Viewer

[02:20-03:16 / 32:05-39:20]

As noted in part 2 of this week’s report, the Fitted Mesh project viewer received a set of updates (including new avatar skeleton files) in the form of release 3.6.12.284458. The project viewer has so far received a very low number of downloads – somewhat unsurprisingly – with the total number of people using the viewer thought to be under 2,000. This means that it hasn’t as yet been used widely enough to generate meaningful crash statistics.

The response to the skeleton changes within the viewer has been “good”, and the viewer has seen a reasonable number of JIRA issues raised under the FITMESH project, etc., although the Lab cautions against anyone using the changes contained in the viewer in anything other than an experimental version of their own viewer until such time as the code reaches a Release Candidate status. The latter will not happen before the end of 2013, although there may be a further project viewer update for Fitted Mesh before the end of the year.

One thing which may happen when the viewer is approaching a release status is that it will bring with it a “significant bump” to the viewer version number, not the least of which is because users on viewers without the code may see some bizarre, or at least oddly fitting clothing on avatars using garments weighted to use the new system, as noted in my launch preview of the Fitted Mesh project.

Overall, it appears that the Lab is “pretty happy” with the way the work is developing, although they would like to see more people involved in using / testing the viewer, particularly anyone proficient in rigging mesh garments, etc, especially given the nature and state of the project, as Oz Linden pointed-out:

This is one of those times when things are in flux and can be changed… We have never made changes to the avatar skeleton casually, and we’re making a round of changes now; we’re wildly unlikely to make another round of changes for years. So if there is feedback to be had, this is the time to have it.

So if you are a creator and do have an opinion on how things might be better handled within the Fitted Mesh solution, now is the time to be involved and potentially influencing the Lab’s thinking. not every idea put forward may be taken-up; but on the other hand, waiting until the changes have been made and the viewer released will certainly mean that any ideas someone may have will have passed their sell-by date.

The Delay in Opting for this Solution

Part of the general feedback voiced when the Lab announced the Fitted Mesh viewer came in the form of questioning why it took the Lab so long to reach the decision to go with the approach. Part of the reason appears to be that mesh deformation and Server-side Appearance projects required the same expertise with the Lab to be applied to them, and so were vying with one another for manpower – and the decision was made to give the SSA project priority.

Oculus Rift Update

[24:46-26:26]

During the Server Beta meeting on Thursday December 5th, VoidPointer Linden indicated the work on making the viewer operate with the Oculus Rift headset was now “feature complete”, and that a (presumably project) viewer will be appearing “soon” with support for the headset. How soon is open to question, given VoidPointer had to be somewhat circumspect. However, following the TPV developer meeting, it appears that “soon” might actually be a little more in the realm of “later” than may be the case.

Oculus Rift viewer: "soon" probably not as close as either
Oculus Rift viewer: “soon” probably not as close as either “real soon (TM)” or “pretty soon (TM)”!

Continue reading “SL project updates: week 49 (3): Fitted Mesh, AIS v3, Oculus Rift and more” →

SL projects update: week 49 (2): Oculus Rift Support “soon”

Posted on by Inara Pey
Maestro Linden (foreground) leads the Server Beta meeting. The colony of bats to his left is Voidpointer Linden, who is working on the Oculus Rift project
Maestro Linden (foreground) leads the Server Beta meeting. The colony of bats to his left is VoidPointer Linden, who is working on the Oculus Rift project

Server Deployments week 48 – recap

As always, please refer to the week’s forum deployment thread for the latest news and updates.

  • Main channel, Tuesday December 3rd: received the maintenance package deployed to BlueSteel and LeTigre in week 47

Issues with Main channel deployment

Two issues were discovered post-deployment of the Main (SLS) channel  updates:

  • BUG-4637 “”Can’t rez object at { x, y, z } because the owner of this land does not allow it”when rezzing any object from Library”
  • BUG-4635 “”Selected / sat upon:” incorrectly shows objects that are not actually selected or sat upon. “

Maestro has verified a fix for the latter issue, which he described as occurring with vehicles which get into a “funky” state, ” The vehicle gets ‘bad’ if it loses the passenger right at region crossing,” he said by way of explanation, leaving them appearing to have somebody sitting on them per parcel accounting rules, but who is effectively a “ghost rider”.

It is hoped that these fixes will form a RC release together with some additional small updates prior to the no change window / code freeze kicking-in on Monday December 16th.

Animation fixes

Commenting on the llGetAgentInfo() update deployed to the RC channels at the Server Beta meeting on Thursday December 5th, Maestro Linden said:

The only change which should be visible normally is a fix for avatars with crouch / crouchwalk animation overrides. Previously, the llGetAgentInfo() LSL function would only return AGENT_CROUCHING if the avatar was playing the default crouch or crouchwalk animations, so if your avatar had an AO which replaced those animations, (either with llSetAnimationOverride() or possibly with classic AOs too), scripts couldn’t tell when you’re crouching. But with the fix, the function is looking at whether you’re actually crouching, regardless of which animations are playing.

He went on to note that there is a similar issue with ground sit, wherein if you sit on the ground, the viewer only presents the ‘stand’ button if your avatar is playing the default ground sit animation. Originally, llsetanimationoverride() allowed the ground sit animation to be replaced with something else, but this led to situations where a seated avatar could not stand up.

To fix this latter issue, Kelly Linden implemented a workaround for this problem by making “ground sit” play two animations, the default ground sit and any custom ground sit specified by the user, with the priority of the default ground sit hopefully being low enough not to clash with any custom animation also used. The change was viewed as a compromise to make the AO system compatible with viewer 2x/3x, and is why the SL wiki alludes to in ‘ State “Sit on Ground” will play the default animation in addition to any override set. This is required for correct viewer behaviour. ‘

SL Viewer

The Fitted Mesh project viewer was updated to version 3.6.12.284458 on December 5th.  The update addresses:

  • LL internal JIRA MAINT-3311 (Skinning to some collision volumes is broken)
  • STORM-1985 (Mesh garments don’t adapt to changes in avatar shape)

In addition, it includes the updated avatar_lad.xml and avatar_skeleton.xml  file developed by Jeremiah Linden in accordance with his notes on FITMESH-2 (notes dated December 2nd, 2013).

Oculus Rift Support

Oculus Rift: release of a "feature complete" viewer with Rift support "soon"
Oculus Rift: release of a “feature complete” viewer with Rift support “soon”

Also attending the Server Beta meeting, Voidpointer Linden reported that support for Oculus Rift is feature-complete and should be released “soon”.

There will be a formal announcement when a viewer with Rift support is released (no date as to when this will be as yet), however, a few clues were given out during the meeting:

  • The same viewer can be used in both a “normal mode” and a “Rift mode”
  • There will be no apparent changes to the viewer / UI when in “normal mode”
  • Frame rates when in “Rift look” will be very much down to the user’s own hardware  (unsurprisingly). Voidpointer apparently attended the meeting using a Rift headest and reported that he was getting frame rates ” pretty comparable to normal,” but also noted he has a good machine on which to run SL.

Details on the presentation of the UI, etc., were not provided, as these are apparently still under wraps. In the past, it had been indicated that the UI had been set to be floating “overhead”, just outside of your normal point-of-view, so you had to look up to see them. Whether this is still the case, remains to be seen.

There have been reports of people using the Rift (in general, not just with SL) suffering from nausea and motion sickness. Commenting on this, VoidPointer said, “I’ve been using it for a while now and I don’t really have problems with nausea at this point. [But] the Rift is very sensitive to frame rate, vsync, and other things.   Before the rendering was fully hooked up or optimized,it wasn’t as fun, I’ll say that.” He also revealed the Rift headset can be somewhat adjusted so it can be worn over glasses, if necessary.

As the Rift is not currently commercially available, those with the headset and SDK will be able to make use of the new viewer once released, and will require a DVI cable connected to the headset and their system for the video output and a USB connection for the head tracking capability (so the screen view follows the wearer’s head move to present them with the expected view). Commercial versions of the system will use HDMI for the video.

Rod Humble tries out Oculus Rift in a photo released on July 18th
Rod Humble tries out Oculus Rift in a photo released on July 18th

There was a lot of additional talk about possible future options for presenting in-world views with the Oculus Rift, however, as Voidpointer advised, “Heh, let’s get Rift support first, then talk about more :).”

Whether support for the Rift will be announced before or after the end-of-year break remains to be seen.

SL project news week 49 (1): server and viewer updates

Posted on by Inara Pey

Server Deployments week 49

As always, please refer to the week’s forum deployment thread for the latest news and updates.

Main channel: Tuesday December 3rd

The Main channel received the maintenance package deployed to BlueSteel and LeTigre in week 47. This project includes:

  • Bug Fixes
  • New Features
  • Fixed “Sim crossing on vehicle fails when parcel at opposite sim border is full.” (BUG-4152[c])
  • Fixed a case in which a viewer with a high draw distance would not connect to distant regions which are within the draw distance area
  • Fixed some crash modes
  • Fixed “Vehicles containing a mesh are returned to the owner upon region crossing when destination parcel is full”
  • Fixed “Temp Attachments are sometimes not removed on the viewer when detached from a region change event.”
  • Fixed “Avatars inside a private parcel can see other avatars 2 regions away” (BUG-4356[c])
  • Fixed an issue with object return to inventory on test grids
  • Objects which are rezzed by sat-upon or attached scripts no longer inherit the temp-on-rez or auto-return timer of the parent object
  • Estate managers and region owners are now prevented from being teleported by llTeleportAgentHome()
  • Estate managers and region owners are no longer affected by scripts which use ESTATE_ACCESS_BANNED_AGENT_ADD
  • The grey goo fence is now stricter for large physical object rezzes
  • More robust handling of inventory management within objects
  • Cleanup of controls-grabbing in LSL scripts (no functional changes)
  • Parcel owners are now prevented from being teleported by llTeleportAgentHome()

Release Candidate Channels, Wednesday December 4th

All three RC channels should receive a new maintenance package comprising:

The will be one more week of releases (week 50), prior to the Christmas / New Year code freeze / no change window commencing, which is due to start on Monday December 16th, 2013.

SL Viewer

Two new release candidate viewers arrived in the release channel on Tuesday December 3rd:

  • Maintenance RC version 3.6.12.284430 comprises a number of fixes, including a fix for the issue of FPS dropping when the Expanded Chat option is enabled in CHUI (MAINT-3375) – download and release notes
  • Namefix RC version 3.6.12.284383 changes installer naming without modifying channel or application names, but contains no functional changes to the viewer code – download and release notes.

SL projects update week 48: region crossings, scripted camera and region restarts

Posted on by Inara Pey

Server Deployments week 48

As this is Thanksgiving week in the USA, it is a code freeze week with no scheduled deployments for the grid. Deployments will resume in 49.

It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)
It was a quite Simulator UG meeting in terms of news from LL due to this being Thanksgiving week (image: stock)

SL Viewer

There are no planned RC releases or updates  for week 48, again because of the Thanksgiving code freeze.

Oz Linden is, however, working on getting another maintenance RC together in the near future, although it’s not clear exactly what this will contain at this point in time.

There have also been reports of issues with test versions of viewers built using the latest Sunshine External repository (the SSA “polish” code and AIS v3). The exact cause of the problems is not known, but it is leading to a high number of Current Outfit Folder mismatch issues on Windows. A request has been passed to the Lab to check the automated build process in order to help ascertain if there is a problem in the code, or whether an issue in merging the code is causing problems. These issues don’t affect any released versions of viewers, only those using the latest SAA / AIS v3 code for testing purposes.

Default Object Permissions

A number of TPVs include the ability to specify the default permissions applied to a new prim object (cube, cylinder, torus, etc.) on creation. A similar capability is being developed for the LL viewer (STORM-68) by Jonathan Yap, a long-time contributor to the viewer. However, this work also requires updates to server-side  capabilities, and Andrew Linden is now looking into this, and at the moment is specifically trying to figure out how to propagate the default perms through teleports and region crossings.

Other Items

Region Crossing Issues

The three RC channels are all running the same simulator version, which includes a fix for “Sim crossing on vehicle fails when parcel at opposite sim border is full.” (BUG-4152). Describing the issue at the Simulator User Group meeting on Tuesday November 26th, Simon Linden said, “The server was doing a parcel check at the wrong location … you’d cross, and at one point it would check a parcel based on the new region coordinates in the first region.   If that happened to be a full parcel, it failed.” This issue has been reported as occurring on Main channel regions as well, under a variety of  reports including SVC-8007. As such, it is hoped that when the package currently on the RCs is promoted to the Main channel in week 49, these issues may also be rectified.

In the meantime, and to test whether the fix may work for SVC-8007, the mainland region of Epirrhoe has been moved to the Magnum RC to allow vehicle crossings to be tested between it and the neighbouring region of Jodis, which has been a crossing which has experienced repeated issues with SVC-8007 for the SLRR.

llSetCameraParams([CAMERA_DISTANCE, x])

Many vehicles of all types in SL use llSetCameraParams to establish a “follow camera” which allows the vehicle to be effectively guided by the driver / pilot.  However, there has been a long-standing issue the CAMERA_DISTANCE  rule, which is clamped to distances far shorter than draw distance. This can make it next to impossible to create a scripted follow camera for very large vehicles such as realistically sized spacecraft, airships and ships.

Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using
Clamping with CAMERA_DISTANCE can lead to issues when trying to script a follow cam for very large vehicles using llSetCameraParams

The original JIRA (SVC-3499) was closed as “Won’t finish”. However, commenting on the matter at the Simulator User Group meeting, Andrew Linden said:

If we were to expand the clamp limits then some poorly written scripts will change behaviour. How much do we care about breaking such poorly written scripts? And… I wonder why it was clamped so tight? It would be nice to ask around to see if anyone remembers why some limits were set … Well, it would be possible to expand the distance limit and test to see how it works with different limits. If nothing breaks too bad, then perhaps we could ship it.

A new BUG report has been filed as a feature request for this to be looked at (BUG-4594), which is likely to be looked-at the next time feature requests are sorted, and quite possibly passed to Maestro Linden.

Region Restart and Visibility Issues

An unusual issues has been reported which appears to be related to region restarts and visibility, but it only noticeable on regions which have multiple neighbours, all of which are restarted at more-or-less the same time (within about a minute of one another). The problem can be broken down into a number of related points:

  • Observers are standing in region A, which is surrounded by regions B, C, and D – all of which are restarted at pretty much the same time
  • Following the restart, there is a high probability that some or all of regions B, C, and D will not be visible to those observers on region A (which was not restarted), and they show-up as red on the mini-map – something which has been confirmed on both the SL viewer and Firestorm
  • However, anyone entering region A after the restart will see all of regions B, C, and D as expected. Similarly, anyone on region A at the time the other regions restarted can resolve problems by relogging
  • Those observers who were in region A at the time the surrounding regions were restarted are able to fly into any of them which are showing as red on the mini-map, and although nothing physically renders for them, they will experience object collisions. Furthermore, it is possible to exit the “red” regions on the mini-map and fly into the void where no regions actually exist.

In tests with a specific set of regions, the above issues occurred in 8 out of 12 tries. That there is a unique problem with the regions on which the tests were carried out has been pretty much discounted. Whirly Fizzle, who has been poking at the issue with a number of people, provided a screen capture show how her alt managed to fly through a “red” zone and into the void where no region exists.

Following a region restart, Droom is shown in red on the mini-map, to observers located in Mote (lower left on the mini-map) at the time of the restart. However, these observers were able to fly through Droom, although nothing would render for them (but collisions would occur), and then into the void space where no region exists (image courtesy of Whirly Fizzle, click to enlarge)

Commenting on the matter, Simon Linden said, “It sounds like it’s getting confused and not realizing the old connection went away …  I’d bet on the timing.”

Agreeing with this point of view, Andrew added: “If Region A thinks your viewer can already see into Region B, it wouldn’t initiate the connection,” hence why relogging would appear to fix the issue for those experiencing the problem and those arriving in the region after those around it have been restarted: as you arrive in the region, it (re-)initiates the connection between the  viewer and the surrounding regions. This is also why people encountering the situation can enter void areas where no regions exist, as Andrew also explained: “The region you’re on expects the other region to inherit your avatar, o it lets you walk beyond the region boundaries until the other region picks you up. But if the exchange never completes, you get to walk around outside of the region boundaries for a while.”

This can be seen in the image Whirly supplied: while she is clearly in a void space where no regions exist, the title bar of her viewer still reports her as being in Mote (her “region A” during the test), because the “hand-off” between Mote and Droom (shown in red on her mini-map) never completed.

Andrew recently fixed another issue related to connections to neighbouring regions, and has offered to look into the matter himself to find out what is going on and how it can be rectified.