Tag: SL Issues

SL project updates 7/3: viewer updates, AIS and misc items

Posted on by Inara Pey

The following notes are taken from the TPV Developer meeting of Friday February 14th, a video of which is included below. My thanks, as ever, to North for the latter. Timestamps relative to the recording are given in braces both at the start of each section and within the text where appropriate.

SL Viewer

Release Viewer Update

[01:20] The Facebook Hotfix RC (version 3.7.1.286557) released on February 12th was promoted to the de facto release viewer on Friday February 14th. Based on the Fitted Mesh viewer code, this viewer has a single fix for a  problem in the in-viewer web browser that made it impossible to login correctly into Facebook. The rapid promotion was made because the issue was seen as obnoxious by those people who have connected their SL and Facebook accounts, and it was felt those who do may want to post Valentines-related messages and images to their Facebook accounts.

HTTP RC

Robbie Monty Linden sports new look
Robbie Monty Linden sports new look

[02:32 and 36:56] As noted in part 2 of this report, the HTTP viewer has been rebuilt using the Facebook Hotfix / Fitted Mesh viewer code to version  3.7.1.286567.

However, it has suffered from the number of RCs currently in the queue, or as poor Monty put it, getting “stuck behind everyone”.  This  viewer has one of the lowest crash rates on record as an RC, and given this, the expectation is that it will be promoted to release status “pretty soon”.

One of the major issues Monty faced with the viewer-side updates was directly related to mesh, and thread race conditions, and he admits that not all of these have been resolved. This is partially due to some of them being  infrastructure-related Heisenbugs, which are time and labour-intensive to resolve. However, they shouldn’t impact the stability of the updates made to date.

Remaining RC viewers

[03:54] The three remaining RC viewers  – the Maintenance RC (3.6.14.285499), Interest List RC (3.6.14.285213) and Google Breakpad RC (3.6.14.285686) are in the process of being rebuilt to the 3.7.1 release code, so updated versions should be appearing in the release channel in the next week (ish).

Project Viewers

[04:23]

  • It is unclear whether the Merchant Outbox project viewer (3.6.13.284731) will move forward or pulled back to have some more work done on it, and it is unlikely to move towards viewer release “any time soon”
  • The Sunshine / AIS v3 project viewer was rebuilt to the 3.7.1 code (Fitted Mesh and the Facebook Hotfix), with a new version (3.7.1.286565) appearing on February 14th. It is anticipated that this viewer will move forward to a release candidate status fairly quickly now that the Facebook Hotfix has been promoted, reducing the number of viewer RC cohorts currently in the release channel.

AIS v3

[05:16 and 14:50] A surprising piece of news passed-on in the meeting was that the AIS v3 server-side code has been deployed across all channels on the Main grid. This initially caused some confusion during the meeting , as there has been no mention of this in any server-side release notes. Nyx Linden queried the situation with the ops tem and received a confirmation that the new AIS capabilities had been deployed to Agni [21:40, via text], but are currently disabled [22:29 via text]. It would seem likely that the capabilities will be enabled once the Sunshine / AIS v3 project viewer moves to release candidate status.

Voice

vivox[07:35] There have been a number of issues with regards to voice in SL, particularly of late. As noted in my week 6 report, there was some recent back-end work carried out which should improve things for those using viewers running with the most recent versions of the voice SDK (SLvoice.exe).

Discussing the matter at the TPV Developer meeting, Oz Linden revealed that Vivox had reached out to the Lab to assist with issues being experienced, and as a result of this underlined the issues with viewers using older versions of the SDK (and which will not see any real improvements to their voice performance as a result). Vivox have requested that TPVs provide details on any older versions of the SDK they are running, and details of specific issues they are encountering, as well as offering encouragement to update.

As a new version of the SDK is due to be released in the near future (hopefully within a couple of weeks), it may prove to be an opportunity for TPVs to update, given it has a number of audio quality fixes and Vivox have offered to assist in dealing with issues being experienced with voice in SL.

In addition to this, Oz is looking to work with Vivox to try to get any new versions of the SDK used by the viewer made available to TPVs at the same time it is made available to the Lab, thus eliminating the need for TPVs having to wait for LL to QA and integrate the package into the LL code prior to being able to merge it into their own code, allowing them to test new SDK releases in parallel with the Lab. These will hopefully include 64-bit binaries of the SDK as well a 32-bit versions.

Group Ban Lists

[48:23] It had been hoped that Baker Linden might be providing an update on the overall status of his group ban list work. However, this was unfortunately not the case, although Oz provided a small update on things, stating that he has been able to sit down with Baker to review the updated viewer code, which is now with QA. Hopefully this means it will be appearing in at least a project viewer in the near future.

Continue reading “SL project updates 7/3: viewer updates, AIS and misc items” →

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.

SL projects update week 33 (2): server releases, group ban list, texture issues

Posted on by Inara Pey

Server Deployments Week 33

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

  • As noted in part 1 of this report, there was no deployment to the Main channel in week 33, as a result of the “grey box” attachment issue appearing in the week 32 BlueSteel deployment
  • The Magnum RC channel remained on SSA, with no other updates
  • The LeTigre RC received a new server maintenance package with “under the hood changes” which should not be visible / perceptible to users. This package saw the removal of SSA from LeTigre – Caleb Linden apologised at the Server Beta meeting for the confusion this caused as the forum thread & release notes did not initially make it clear
  • The BlueSteel RC received further updates to the fixes released in week 32 and the fix for the “grey box” attachment issue

Viewer Updates

The CHUI RC viewer updated to release 3.6.3.279849 on August 15th (download & release notes). The Materials project viewer also underwent a further update to release 3.6.3.279904 on August 16 (download & release notes).

Server-side Appearance

As noted above, SSA is currently only enabled on Magnum for the time being. A decision will be made on Monday August 19th on server-side updates and deployments, and until then the Lab is keeping quiet as to what may or may not happen in terms of SSA enabling. However, from comments passed in recent discussions and a hint in the forum deployment thread, it would appear that if the data obtained from Magnum during the week remains solid, SSA might be considered ready for “prime time” in week 34.

The removal of SSA from LeTigre did cause some confusion, with at least one JIRA (SUN-109) being raised as a result. Given the JIRA refers to the slowness of avatar rendering, rather than to any overall failures (which shouldn’t happen anyway, given the viewer code is currently backwards compatible with the “old” avatar baking service), this tends to point to the fact that the rapid nature of SSA baking is being appreciated.

Group Ban list

The obligatory Baker Linden shot :)
The obligatory Baker Linden shot 🙂

“Group bans are coming along pretty well,” Baker Linden informed his ‘Thursday after meeting class’.  He went on:

I chose to take the rest of this week to improve the code rather than continue progressing. I really hated copying an entire source file without trying to refactor it … So now it’s refactoring, cleaning up, and after that the viewer will be finished. Well, I need to add the functionality to some other subsystems and have it actually send an HTTP message but that stuff is all stubbed in anyway.

Some of the cleaning up work apparently involves  removing the, umm, colourful metaphors he used when first commenting on the code to highlight those bits he wanted to poke about at. These have apparently been causing a few giggles among those able to peek into the repository!

Given the work is still ongoing, there is no ETA for a project or beta viewer as yet, and this may be delayed a little more while Baker considers the problem of group chat.

Because of the way in which group chat works, anyone who is removed from a group while they have the group chat window open is actually able to continue chatting / spamming within the group until they close the group chat window, unless the group moderator remembers to block them from chat first. This hadn’t been on Baker’s radar, and he’s going to take a look around and see what can / needs to be done to try to make sure the group ban function won’t suffer this weakness, if possible.

Continue reading “SL projects update week 33 (2): server releases, group ban list, texture issues” →

SL projects news week 33 (1): server, “grey box attachment” issue, SSA, materials

Posted on by Inara Pey

Server Deployments Week 33

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

Second Life Server (SLS Main) Channel – Tuesday August 13th

There was no update to the Main channel. It had been anticipated that the package deployed to BlueSteel in week 32 would reach the Main channel this week, but this is not the case, for the reason given below (see the Grey Box Attachment issue notes, below),

Release Candidate Channels – Wednesday August 14th

    • Magnum remains with SSA enabled, but otherwise received no further updates.
    • LeTigre should receive a new maintenance package which “only includes a few internal bug fixes which shouldn’t show any visible changes to the residents”. In describing this at the Simulator User Group meeting on Tuesday August 13th, Simon Linden said, “There’s one performance fix that you might see in the viewer … you shouldn’t get those situations where you see lots of ‘duplicate caps. messages”
    • Bluesteel should receive a new server maintenance package comprising:
      • A fix for the “grey box attachment  issue” (non-public BUG-3547, details below)
      • A (further?) update to for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*”, which was also listed in the BlueSteel release notes for week 32  (non-public JIRA BUG-3291)
      • The code to block avatars entering a region / objects being rezzed in a region during the last 60-seconds before a restart. In addition, restart warning pop-ups will include the region name. This was again in the release notes for week 32, so would appear to be a further update to that code
      • Fixes for further simulator crash modes.

“Grey Box” Attachment Issue

This is a problem whereby a grey prim appears around any passenger(s) sitting on a boat / vehicle when crossing from a BlueSteel region to any other region (including another BlueSteel region) – the driver / pilot is left unchanged. The affected avatar has no control and requires a relog, while the prim itself appears to be linked to vehicle when edited.

The "grey box attachment issue" (image courtesy of Jen Cuddihy via the SL forums)
The “grey box attachment issue” (image courtesy of Jen Cuddihy via the SL forums)

It is thought the bug was introduced during the week 32 BlueSteel deployment, and Simon Linden indicated it was the reason there was no Main channel deployment for week 33, saying:

We didn’t update the main channel today. There was a bug found involving vehicles and region crossings that needed to be fixed, so that update will go out tomorrow [the BlueSteel RC deployment].  Basically, don’t sit more than 1 person on a vehicle when leaving a BlueSteel region, otherwise it turns you into a box :P.  It happens to the 2nd (and probably more, if you had a crowd) person seated on the object.

Kelly Linden explained what was happening to cause this:

Every agent has a ‘task’ representation on the server that is the same as a prim. The bug is in sending the linked set w/ avatars to the other region: avatars after the first are losing the special avatar treatment and getting passed as a regular linked prim. So that prim is what the server thinks all avatars look like.

Simon added:

The region crossing code basically un-sits avatars from an object, sends both the avatars and object to the next region [as separate sets of data], which puts them back together. In this case, the 2nd avatar doesn’t get detached properly and things go south from there. So the 2nd avatar gets sent over bundled up with the object … which it’s not designed to do.

The additional avatars on the vehicle at the time of the region crossing essentially end-up in limbo, with data caught between the two simulators. “The regions are very confused about that avatar data by that point, I’m sure a relog would be needed,” Simon said.

An interesting side-effect of this is that the bug makes it possible to exceed the 256-prim linkset limit – sort-of. Enterprising individuals have realised that if you rez a 256-prim linkset, sit a number of avatars on it and move it across a region boundary, it will acquire an additional prim for each additional passenger over the first avatar to sit on it. However, the ability is of limited value; make any changes to the enlarged linkset, such as unlinking a child prim or trying to texture one of the greyprims, and the entire thing turns no modify / no copy – and the fix being deployed to BlueSteel should correct the problem anyway.

Server-side Appearance

Just as a reminder. There are no further SSA deployments planned for week 33. This is to allow for some back-end updates to be made to the SSA servers. These updates shouldn’t result in any visible difference to users on SSA-enabled regions, and are intended to fix a couple of scenarios where the viewer would have to re-try requests when it shouldn’t have to. The Lab wants to get these updates deployed to the SSA server prior to making any move to rolling-out SSA to the entire grid.

There have been comments on the forums that SSA “must” be encountering major problems as the deployment has been so protracted. This is not the case. Linden Lab (via Nyx Linden) have always stated that the deployment would proceed very, very cautiously because it is such a fundamental change in how Second Life functions. Even though the Lab has indicated that very, very few problems have been encountered with enabling the service so far, and the load testing on both Magnum and LeTigre (representing a little over 20% of the grid) has been very positive, they are sticking to their softly, softly approach.

Viewer Updates

As the Vivox updates became the de facto release viewer in week 32, the remaining five release candidate viewers in the viewer release channel have been underground rebuilding using the updated release viewer code base. On Monday August 12th, updates for both the Cocoa Viewer for Mac (version 3.6.3.279554 – download and release notes) and the Maintenance Viewer (version 3.6.3.279564 – download and release notes) were released.

Materials Project

The Materials Project viewer was updated to version 3.6.3.279651 on August 8th. This release lists a large number of fixes, perhaps most notably those related to problems with the appearance of alpha textures under both local lights and sunlight, and numerous issues with mesh rendering and lighting within the materials viewer. Please refer to the full list of JIRA items in the release notes linked-to above.

ALM Concerns

Concerns have been raised about performance issues as a result of having the Advanced Lighting Model (ALM) enabled by default (as is now frequently the case for most graphics cards, as is a requirement in order to see materials in use in-world).

The amount by which ALM can affect the user experience is variable, and subject to a lot of influences, not just the graphics cards / computer system the viewer is running on. Some people with systems similar to my own (see the panel on the right for my system spec), have noted “significant” impact when running with ALM enabled on a materials-capable viewer.

Part of the problem is the “ALM” is a very broad term, and other options within the viewer can influence performance, but will not impact the ability to see materials even if they are turned off – such as having shadows set to None, for example, or having water reflections set to Minimal and turning off local lights (via debug or Phototools, for example). So part of the problem is that of communicating what can be done from within the viewer to help offset performance impacts should they occur, but which don’t limit their ability to see materials in use.

Quick ways to improve performance when running in ALM to see materials. Top left: you can uncheck Ambient Occulsion, keep Shadows set to None and drop water reflections to Minimal. Bottom Left: Using Debug Settings from the Advanced Menu, set RenderLocalLights to FALSE. Right: Firestorm / Phototools, ambient occulsion, hadows, local lights and facelights can all be disabled from the Light tab and water reflections lowered from the WL tab
Quick ways to improve performance when running in ALM to see materials. Top left: you can uncheck Ambient Occlusion, keep Shadows set to None and drop water reflections to Minimal. Bottom Left: Using Debug Settings from the Advanced Menu, set RenderLocalLights to FALSE. Right: Firestorm / Phototools, ambient occlusion, shadows, local lights and facelights can all be disabled from the Light tab and water reflections lowered from the WL tab

Related Links

SL projects update week 32 (1): Server, viewer

Posted on by Inara Pey

Server Deployments Week 32

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

Second Life Server (SLS Main) Channel

There was no update to the Main channel on Tuesday August 6th. This is primarily because the SSA project is not being further deployed during week 32, and BlueSteel was not updated in week 31 (other than to be brought up to a par with the Main channel), so there is nothing from the RC channels to promote to the Main channel.

Release Candidate Channels – Wednesday August 7th

Magnum and LeTigre will remain SSA enabled, and apparently without any further updates.

Bluesteel should receive a new server maintenance package comprising:

  • A new feature which will see regions block rezzing and entering during the final 60-seconds before a shutdown / restart (see notes below)
  • Code to help fix an exploit whereby a scripted object can surreptitiously obtain permissions from an unsuspecting avatar, allowing the object owner to later use the object against the avatar in s griefing attack (e.g. by tracking camera movements in a deform attack, and so on – see publicly viewable JIRA VWR-13228 and the notes below)
  • A fix for “llListen in linked objects is listening at root instead of linked object local position *after re-rezzing the linkset*.” (non-public JIRA BUG-3291)
  • Fixes for further simulator crash modes.

Region Restart Blocks

Referring to the new feature allowing regions to block rezzing and entering during the last 60 seconds before a restart at the Simulator User Group meeting on Tuesday August 6th, Simon Linden said, “this is just trying to stop adding stuff to the region’s workload when it shuts down. Let’s say you TP into a region in the last second before it shuts down … you’re still going to be loading when it boots you out [and changes made to attachments could be lost after the resultant relog]. [It’s] the same possibly with rezzing an expensive no-copy item … it’s just not a good idea to start a complicated process right before shutdown. So those last 60 seconds are going to block entering and rezzing.”

In addition to the new blocks, Simon has also added the region name to the pop-up warnings which are displayed during the 5-minute countdown to a restart shutdown / restart.

Animation Griefing

The fix for scripted objects surreptitiously obtaining permissions from an unsuspecting avatar (per JIRA VWR-13228) will require a viewer-side update as well to be effective, which will utilise the Stop Animating Me function in the viewer.

Currently, Stop Animating Me is purely viewer-side. When activated, it will stop all animations running on your avatar within your view, with an update (ANIM_REQUEST_STOP) sent to the simulator which gets relayed to everyone in the same sim to tell their viewers to also stop animating you. The system isn’t perfect, but generally works.  However, it is important to note that no actual permissions are revoked by the process, allowing griefing objects such as Soul Seize to retain control over an avatar.

Under the new system, and once the viewer-side update is available in viewers, Stop Animating Me will send a message to the simulator so it revokes all animation permissions for all objects in the region (other than those worn by the avatar issuing the command, such as AO HUDs, etc.), with the result that they are no longer animating the avatar (legitimate objects can re-animate via an explicit request, as per normal).  While there were concerns expressed at the Simulator User Group meeting that a griefer may be able to work around the approach (although most workarounds appear to be somewhat labour-intensive), the new capability should be enough to stop griefing objects such as Soul Seize within a region from retaining control of an avatar.

Commenting on the viewer side of the fix, Simon Linden indicated that the viewer with the change is undergoing QA testing, but because of the number of updates it contains, it is unclear as to when it will make a public appearance.

Simulator UG meeting, August 6th
Simulator UG meeting, August 6th

SL Viewer Updates

The Vivox release candidate viewer was promoted to the de facto release viewer (version number 3.6.2.279258) on Monday August 5th, which can be obtained via the main viewer download page or will be offered as an automatic update to those using the previous release and who have updates enabled. The release notes summarise changes.

As a result of this, the Google Breakpad release candidate updated to version 3.6.2.279364, on August 5th (download / release notes) and the Maintenance Viewer RC updated to 3.6.2.279427 on August 6 (download & release notes).

In the meantime, the Cocoa viewer updates (Mac only) moved from a project viewer to a release candidate (3.6.2.278960, download & release notes) on August 6th, bringing the number of active RCs back up to five.

The latest CHUI updates (now in release candidate 3.6.2.279321, released on August 1st) still contain the issue of highlighted text in scripts  / notecards being deleted if somewhere else in the script editor / notecard is clicked, requiring a CTRL-Z to undo (see publicly viewable CHUIBUG-210 and the associated forum thread).

As a small aside, apparently the (or perhaps only one of the) meeting(s) to decide on the status of the current viewers and determine which (if any) is ready to go to release status is held around late morning SLT on Mondays.

Group Ban List

Baker Linden - old style (stock)
Baker Linden – old style (stock)

There has been some confusion over the group ban function, which lead Baker Linden to clarify that anyone banned from a group under the new capability will be automatically ejected as well (hence the ban), and will not be able to re-join the group until such time as the ban is lifted. Group owners will automatically be blocked from the ban function, to prevent them being accidentally banned by other group officers.

Baker has been considering who can actually be banned by a group member granted the ability to ban others.

His initial idea is to allow anyone given the authority to ban group members to be able to ban anyone else (other than the group owners), so one officer with the ability to ban people could ban another officer, for example. “My reasoning is that if you can’t trust an officer with banning, don’t let that person be an officer,” he explained.

Descibing the other option he was considering, he said, “The other route I can go is anyone with the ban ability can [only] ban anyone that doesn’t have that ability.”

This second option appeared to gain more support than the first, although Baker himself sees it as somewhat limiting, “But I don’t see the point in that,” he said, “Since we already have a problem with eject not being able to eject anyone belonging to any role other than ‘Everyone’ which seems pointless to me.”

Unfortunately, the meeting drew to a close before both options could be further explored, and so they may be a topic for further discussions at the next meeting. However, the idea of those with the ban ability only being able to ban those who don’t have the ability doesn’t actually seem to be as limiting as Baker suggests when citing the issue with group ejections (only those in the “Everyone” group can be ejected), so it will be interesting to see how much more discussion there is on this subject.

Andrew Linden: Interest List Work and Anti-Griefing Measures

Andrew Linden reports he has now all but finished his current work on interest list updates. While there is still no indication when the viewer-side changes might surface, he’s nevertheless freeing himself up to take a look at anti-Griefing measures. He’s already compiling a list of items he wants to look into, although his initial focus will be on general maintenance work to get him, as he puts it, “back in the groove”. One item in particular he’ll be looking at prior to delving more into anti-griefing measures is that of motion stops on region restarts.

Related Links

SL projects report week 31 (2): server and viewer

Posted on by Inara Pey

Server Deployments Week 31 (Week Commencing Monday July 29th)

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

Second Life Server (SLS Main) Channel

On Tuesday July 30th, the SLS Main channel received the server maintenance package previously deployed to BlueSteel in week 30 and LeTigre in week 29. This project includes:

  • A further fix for the issue of pathfinding characters using CHARACTER_STAY_WITHIN_PARCEL getting stuck if they somehow exited their home parcel
  • Fixes for objects failing to detect collisions after teleporting (BUG-969) and run time permissions failing to function correctly on attachments (BUG-2931)
  • New capabilities added to the materials system to control how quickly the viewer can set or query normal and specular maps on objects. The current maximum is once a second and the new capability will be 4 a second. However there will need to be a viewer-side update to make use of the new capability, which should be available soon.  Commenting on the capability, Maestro Linden said, “the difference will probably be most noticeable if you’re doing something like rotating the normal map on an object with the spinner control (holding down the button) it should update more quickly to observers in that case.”

Release Candidate Channels – Wednesday July 31st

  • Magnum and LeTigre will remain SSA enabled and both received the updates deployed to the Main channel.
  • BlueSteel should have received a new server maintenance project. However, as noted in the update to part 1 of this report, a last-minute bug was found in the code which meant the deployment didn’t go ahead with the result that it is currently running the same release as the Main channel.

Viewer Updates

There have been a number of viewer release candidate updates for the end of the week:

  • The Google Breakpad RC was updated on Tuesday, July 30th (2.6.2.279026 – download and release notes)
  • The Snowstorm  contributions appeared in a release candidate on Wednesday, July 31st (3.6.2.279119 – download and release notes)
  •  The Vivox RC was updated on Wednesday, July 31st (3.6.2.279258 – download and release notes)
  • The CHUI updates became the latest viewer release candidate on Thursday, August 1st  (3.6.2.279321– download and release notes)

The appearance of the CHUI and Snowstorm RCs brings the total number of cohorts in the release channel up to five.

Animation Syncing Issues

Speaking at the Server Beta meeting on Thursday August 1st, Maestro Linden said that he and Alexa has been looking into the animation syncing issue I noted in part 1 of this report. Their findings pointed to an issue going back to 2012, whereby someone who is dancing in sync with others can cams such that all of the group is out of the field-of-view and then cams back, their own avatar will be out of sync with the rest. As such, Maestro felt the issue might be related to JIRA VWR-10578.

Some saw people go out-of-sync almost as soon as dance sequences started, and without moving their camera position (image courtesy of Whirly Fizzle)
Some saw people go out-of-sync almost as soon as dance sequences started, and without moving their camera position (image courtesy of Whirly Fizzle)

Following the meeting, a number of us participated in a “group dance test” to see what would happen, and the experiences varied somewhat, with some reporting issues consistent with the long-standing problem, others seeing avatars slip out of sync without and camera movement, and some reporting the avatars on the very edge of their field of view appearing to be dancing slower than the rest, and starting to slide out of sync. This lead to a lot of speculation as to the possible causes, and also as to how much settings such as avatar imposters or message throttling might be influencing the viewers play-through of animations.  Maestro did suggest some of the issues may be down to some sort of message sorting behaviour based on where the avatars are, relative to camera view. As it was, no definitive outcome was reached, so it is liable that investigations may continue.

Related Links