Tag: Group Ban List

SL project updates: week 35 (1): server releases, group ban list, anti-griefing

Posted on by Inara Pey

Server Deployments Week 35

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

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

The Main channel received the update package which includes the “grey box” attachment fix, and which had seen previous deployment to some of the RCs. In all, the package comprises:

  • A fix for the “grey box attachment  issue” (non-public BUG-3547, see the details here)
  • An update to 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)
  • 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
  • Fixes for further simulator crash modes.

Release Candidate Channels – Wednesday August 28th

All three RC channel should receive the same maintenance package comprising:

  • An update to region restarts initiated by region owners or estate managers which will see the region restart after the last avatar leaves, rather than waiting for the full countdown period to complete
  • Preparatory work to support new estate and parcel access controls – these will require a upcoming viewer-side update in order to be visible to users
  • A fix for a physics-related griefing mode
  • A crash mode fix.

The release notes are here: Magnum, LeTigre, BlueSteel.

Commenting on the upcoming estate and parcel access controls at the Simulator User Group meeting on Tuesday 27th August, Simon Linden said, “I can’t get into details on the access change but it’s not a huge one, so don’t get too excited about it. We hope to have a project viewer out in a few weeks or so that will have the new code and we can discuss it then.”

SL Viewer Updates

Release Viewer Updated

Following the Monday review meeting, CHUIStorm Release Candidate viewer was promoted to the de facto release viewer 3.6.4.280048, dated August 20th) on the 26/27th August. This viewer includes the latest CHUI updates from the Lab and a number of Snowstorm code contributions from third-party developers, including:

  • STORM-1892 – Add Apply button to the edit content permission floater
  • STORM-1910 – Count of the number of groups a person has joined, and number of remaining group slots
  • STORM-1911 – Go-to line function for the internal LSL script editor
  • STORM-1918 – Part of the group notice attachment box does not allow dropping of assets
  • STORM-1952 – Clicking “Eject” needs a confirmation before execution when ejecting members from a group

The full list of updates are available in the release notes.

The move currently leaves two RC viewers in the release channel: the Cocoa updates for Mac builds, and the next round of updates for Materials Processing, which include goodies such as correct ALM rendering underwater.

Commenting on the removal of the Google Breakpad RC viewer from the list, Oz Linden confirmed that it had been removed as it had done its job, allowing the new reporting mechanism to be tested. As the viewer contains no user-facing changes or anything outside of the Breakpad updates, it has been withdrawn, and the new stats reporting code will be integrated into the viewer code base without requiring a dedicated release.

The mesh deformer project viewer has also been removed from the viewer test builds wiki page. There is not anything untoward about this; prior to the SSA deployment the viewer was already significantly behind the times in terms of merges. As SSA has now been deployed, and the view lacks SSA support, it is currently pointless having it as a publicly available download option.

Group Ban List

Baker Linden supplied a brief update to his work on creating a function to allow group owners to ban people (e.g. known troublemakers) from joining their open-enrollment groups. Speaking at the Simulator User Group meeting, he said:

I’ve still been hooking up the viewer to the server, and can now add people to the ban list. I’m currently working on getting the ban list, which will allow me to get deleting from the ban list working. After that, it’s code cleanup, reviews, and adding server-side verification checks!

To which Andrew Linden added, possibly wryly, “Baker banned me from some groups on the beta grid. I can attest that there is progress there”!

The question was again asked if the capability will allow for banning someone for a set period of time – such as for a week. Baker confirmed that while the ability to do so won’t be in the first release, there is a code stub included which will allow him to add the ability in the future. This is likely to be the case with the ability for a group moderator to add a reason for banning someone from the group if they so wish.

Anti-griefing

As he has now moved away from Interest List work for the time being, Andrew Linden is looking into griefing vectors and ways and means of circumventing them, particularly on mainland. Some of the areas he’s looking at and mulling over in terms of possible actions are:

Andrew Linden - now looking into anti-griefing options
Andrew Linden – now looking into anti-griefing options
  • Allowing estate owners to admin parcel properties (ban lists, object options, etc), without having to take ownership of the parcel
  • Altering the “allow public to build on this land” flag to default to FALSE rather than TRUE when a parcel transitions to a new owner – this is seen as a means of preventing griefers from buildings and hiding hide malicious objects in unattended parcels which can then be used to grief the region / people in the region.
  • Nerf the use of recursive rezzing to prevent griefers getting around autoreturn by creating an object which rezzes a copy of itself, then gives a copy to the rezzed object. The original is then autoreturned, but the copy carries on before creating a copy of itself, and so on.

Andrew is particularly concerned that the third proposal might be damaging to content which may legitimately self-replicate itself (such as items placed by the parcel owner or members of the group the land has been deeded to). In order to prevent this, he plans to apply the nerfing only to objects to which the auto return would otherwise apply.

At the moment these ideas are still musings – although Andrew admitted the code for nerfing recursive rezzing has already been written – and he’ll be having further discussions at the Lab as well as looking at various alternatives / additions (one he mentioned himself was to perhaps have two auto return functions – one for objects whose owners in the region, and one for those lacking owners).

One of the problems here is that in planning to create any additional restrictions on land use, etc., is that people can always raise apparently legitimate reasons why things shouldn’t be done, or offer up ways and means of how changes can be circumvented. However, the fact remains that griefing – particularly on mainland – is once again a growing issue (as those of us have experienced only too well at recent in-world LL meetings). Therefore, change is needed. The skill in the work will be how that change is managed.

SL projects update week 34 (2): Server, viewer, group ban list, HTTP

Posted on by Inara Pey

Note: with the exception of the server deployment review, the majority of this update has been taken from the TPV Developer meeting held on Friday 21st August. A video of the meeting, recorded by panterapolnocy, is available at the end of this article

Server Deployments Week 34

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

  • On Tuesday August 20th the Main channel had Server-side Appearance (SSA) enabled, as per this blog post from the Lab.
  • On Wednesday 21st August, the Magnum RC received a new maintenance package with “under the hood” changes which should be invisible to residents, while BlueSteel and LeTigre received an update to the package deployed to BlueSteel in week 33. This includes a fix for the “grey box” attachment issue which affected multiple avatars riding an object over BlueSteel region crossings. Additionally, these channels also saw SSA enabled, meaning the entire main grid is now running SSA.

SSA Update

For information on the Server-side Appearance deployment, please see my separate report.

SL Viewer Updates

A new release candidate debuted on August 20th with the name “CHUIStorm” (3.6.4.280048). This is a merging of the CHUI and Snowstorm RC viewers with the latest de facto release code base. The reason for merging the two RCs is because the Lab felt there were “too many RCs in flight”, making it difficult to determine which one should be promoted to the release viewer if several appeared ready simultaneously. In future, the Lab hopes to keep the total number of RCs in the channel to around two or three.

Interestingly, the Google Breakpad RC has vanished from the list of RC viewers in the Release channel.

The Materials project viewer was promoted to the Release channel on August 21st (RC 3.6.4.280083), leaving the current total number of RC viewers in the channel at three (CHUIStorm, Cocoa (Mac) and Materials).

Next in the Pipeline

While the order in which they appear or the overall time frame for their release is not clear, there are a number of project viewers which will be appearing in the near future. These include:

  • A further Snowstorm project viewer (third-party developer contributions) – currently with LL’s QA team
  • A new Interest List project viewer (which has had trouble passing QA – see below)
  • A further SSA project viewer – for details see my SSA Update
  • A Group Bans project viewer (see below)
  • An HTTP project viewer (see the HTTP update below)

In addition, Oz Linden hinted that he may have a surprise announcement at the next TPV Developer meeting in two weeks. While he said absolutely nothing further on the subject, the resultant speculation was that he might have been referring to the arrival of an Experience Tools project viewer. Linden Lab accidentally exposed such a viewer a few weeks ago, but quickly moved it back to a private status, so there is an awareness that a viewer is in development. Whether the speculation is right or wrong will be revealed in the fullness of time!

Interest List Update

As noted above, the viewer-side updates to the Interest list project continue to evade a project viewer release, but are expected to appear “soon”. While the code does not contain any mandatory changes TPVs must adopt, there are obviously optimisations within the code which will be beneficial for TPVs to pick-up once the repository is public.

Group Ban List

Baker Linden continues to make good progress with the group ban list project. He is currently working on what he sees as the last major part of the initial work: getting the viewer connected to the server. After that, he reports he has “a lot of security checks, and some minor additions”. There’s still no date for a project viewer, but it would appear that it is not that far from reaching a status of “real soon now”.

HTTP Update

Monty Linden is continuing to work on his HTTP updates, although he has most recently been trying to get the ” bureaucratic details” sorted and getting a QA pass on both the server-side and the viewer side work. He’s also trying to get a DNS fix in as well, which he describes as the “great DNS look-up failures problem” which the Lab has had for a number of years. He thinks he has a fix for the issue, but he’s not 100% certain.

Monty's HTTP work is now focusing on mesh connections
Monty’s HTTP work is now focusing on mesh connections

In terms of the HTTP work, Monty is trying to get a project viewer lined-up, and describes the major feature within it as being the reduction of the number of connections used by mesh so that it will be possible to start using keepalives  with mesh as well.

As I’ve previously reported, Monty has already reduced the number of mesh connections from 32 to 8. Going forward, eight will be the new default (rather than 32), with the aim being to cap the total number of mesh connections used by the viewer, with adaptive throttling and two different re-try schemes. The hope is that this will further improve network utilisation by creating more effective viewer / server connections; it should also help less capable routers.

Continue reading “SL projects update week 34 (2): Server, viewer, group ban list, HTTP” →

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 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 update week 30 (2): Upcoming server & viewer releases, SSA, HTTP

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 should receive the server maintenance package previously deployed to BlueSteel in week 30. This project fixes some miscellaneous bugs, and also allows viewers to send requests for materials data more rapidly.

On Wednesday July 31st, the three main Release Candidate channels should be updated as follows:

  • BlueSteel should receive a new server maintenance project.  This project fixes some bugs related to LSL scripts in child prims of linksets, and also addresses some server crash modes
  • Magnum and LeTigre remain SSA enabled and both receive the updates deployed to the Main channel.

Server-side Appearance

As noted in the planned deployment summary above, it is currently not anticipated that SSA will be enabled on any additional channels in week 31.

Overall, the Lab think the initial phase of deployment is going well, and recognise the considerable contribution made by TPVs in enabling this to happen. A rough approximation from viewer statistics suggests that around three-quarters of users logging-in to SL are using viewers which are SSA-enabled, and that the overall figure may be higher.

A chart compiled by Kadah Koba showing the percentages of SSA-enabled and non-SSA viewer in use (excluding Firestorm 4.4.0)
A chart compiled by Kadah Coba showing the percentages of SSA-enabled and non-SSA viewer in use (excluding Firestorm 4.4.0)

Commenting on the state of play for the project during the TPV Developer meeting on Friday July 26th, Nyx Linden said:

The system is working pretty much as we expected … and even the scaling of how much load is being generated is pretty much right on par with what we’re expecting. But we want to make sure that a few other things are returning the right things and we’re getting the right statistics that we want before we roll it out to the [entire] grid. We’re trying to be extra-cautious.

Viewer-side Updates

In terms of viewer-side updates, the plan is to try to have one major post-SSA enabling release which should include the planned inventory updates noted in the first part of this report along with any additional viewer-side code tweaks to the viewer arising from SSA being enabled, and a final code clean-up to remove the “old” baking code.

However, this does depend on enabling SSA on the rest of the grid. If there is yet cause to delay this (due to an unexpected issue arising, for example), and the delay continues for a significant amount of time, then it is possible that there will be two viewer releases: one with the currently planned updates and one with the post-deployment code clean-up.

Either way, to assist TPVs prepare for the viewer-side update(s), Nyx plans to periodically push code from the Lab’s private repositories to their public repositories as and when code is in a suitable condition to be pushed.

Issues Update

SUN-98 (Bake fail resulting from partially broken alpha layer): this is thought to be the result of wearing a corrupted clothing layer, and if so is considered to be expected behaviour in order to avoid cases of “accidental nudity” (which might arise from wearing a corrupted clothing later, which the SSA system would ignore and just bake whatever was underneath it  – such as the avatar’s skin). However the matter is still being looked into in case the problem has another cause.

Nyx acknowledged that even if the problem is due to expected behaviour, it would be useful  “at some point in the future” to add some UI elements to actually show the user which clothing asset they’re wearing that is causing the problem. What form these UI elements / warning will take remains to be decided.

SUN-99 (Bakefail on SSA regions only. When entering into SSA region, skin and system clothes fail to bake): this issue only affects a very small number of users and appears to be related to them having multiple copies of the Current Outfit Folder (COF) in their inventories, probably as a result of having moved it  within their inventory (i.e. into another folder) at some point prior to the Lab introducing restrictions to prevent the COF being moved or deleted.

To prevent this happening in the future, the Lab is implementing further back-end restrictions and other improvements on the COF, and Nyx has e-mailed all TPVs with notes on how the COF should be implemented within the viewer in order to comply with these restrictions.

In the meantime it was mentioned at the Server Beta meeting on Thursday July 25th that LL’s support team can now assist users who find they are suffering from this particular issue.

Viewer Updates

Release Candidates

As noted in part one of this report, there are now three RC viewers in the viewer release channel (Beta Maintenance, Google Breakapad and Vivox). All three are performing well, although no decision has been made as to which will be going to release status first.

Beyond these, the Lab is looking at a number of further release candidate cohorts, including the Cocoa updates for the Mac version of the viewer, a series of open-source contributions to the viewer, and a further series of CHUI updates.

Commenting on the current situation with viewer updates at the TPV Developer meeting, Oz Linden said, ” It’s going to be some time before we get to the point where we’ve got the number of simultaneous things happening down to a reasonable number; lots of stuffing was sitting around waiting for the opportunity to get out, and it’s all coming at once now!”

Continue reading “SL projects update week 30 (2): Upcoming server & viewer releases, SSA, HTTP” →

SL projects update week 30 (1): server releases, viewer, SSB/A

Posted on by Inara Pey

Server Deployments – Week 30

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

Second Life Server (SLS Main) Channel

On Tuesday 23rd July, the SLS Main channel received the server maintenance package previously deployed to BlueSteel. This comprised a further package of under-the-hood changes related to the experience tools.

Release Candidate Channels

On Wednesday July 24th, the three main Release Candidate channels should receive the following updates:

  • BlueSteel should receive the same server maintenance project that was on LeTigre in week 29, and which additionally includes the experience tools updates deployed to the Main channel
  • Magnum and LeTigre should both see Server-side baking / appearance (SSB/A) enabled, and should both receive the experience tools updates deployed to the Main channel.

Viewer Updates and Release Process

The second release candidate viewer was made available on Friday July 19th. Version 3.6.2.278609 comprises the long-awaited Vivox updates. This was followed on Monday July 22nd by the third release candidate, version 3.6.2.278615, which contains Google Breakpad updates.

Commenting on the first two release candidates to be deployed (the Beta Maintenance RC and the Vivox RC), Oz Linden said at the Open-source Dev meeting on Monday July 22nd that, “they each got as many users as we asked for, and we’re getting good data on them.” However, this doesn’t mean that either one will is likely to become the de facto release viewer yet, as Oz went on to note, “we configured both of these for a relatively small number of users just in case… we might want to raise it before we make a release decision.” Given that the Google Breakpad RC has been added to the mix, any decision on which get promoted to release status may well be held over even longer as numbers are crunched.

Release candidates are now also listed on the Official Alternate Viewer wiki page, where they can be downloaded manually. In light of this, I’ve updated my overview of the new viewer release process to include notes on manually downloading and installing release candidate viewers.

Server-side Baking / Appearance

As noted above, following the RC channel restarts due on Wednesday July 24th, both Magnum and LeTigre should be running with SSB/A enabled. Overall, the response to SSB/A deployment both on LeTigre (week 28) and Magnum (week 29) has been good, with few issues being reported.

Of those which have, some may be tied to the way in which some TPVs have implemented the Current Outfit Folder (COF). To help determine whether this is the case, Nyx Linden issued an e-mail on Monday July 22nd, outlining how the Lab anticipates the COF should be set-up within a viewer, and has asked all TPVs to verify that they’ve met the requirements.

More on COF Mismatch Issues

In week 29, I referred to the issue of COF Mismatch Issues. These tend to occur when your viewer and the baking service disagree on the COF version number on which your appearance should be based, resulting in “COF version mismatch” errors appearing in the viewer. Part of the problem is due to the inventory protocol relying on both HTTP and UDP messages, some of which have failure callbacks and some which the viewer may wrongly assumes completes successfully – and the “COF version mismatch” results.

To eliminate this, the Lab is working to update the Agent Inventory Services (AIS), which will see the most error-prone operations related to the COF converted to use AIS rather than UDP. The hope is that this work will both remove the most prominent causes of COF mismatch errors and reduce the number of network calls needed to update the COF. This work has been ongoing for a while, and will form part of the next phase of SSB/A work once the current deployment has seen SSB/A go grid-wide. These updates will involve further viewer-side updates, and include a range of additional improvements, although as yet there is no time scale for their release (particularly as the Lab is only just starting discussing them with TPVs).

Group Ban List

There is not a lot to report here. Baker Linden is still working on the viewer-side code. Giving a brief update at the Simulator User Group meeting, he said, “I’m currently deciding on the format of the data coming into the viewer, and adding it to the group manager subsystem in the viewer. That’s about it :).”

Related Links