Tag: SL Viewer

Server Deployments Week #29

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

• There was no Main (SLS) channel deployment on Tuesday, July 14th.
• On Wednesday, July 15th all three RC channels should receive the same server maintenance package, comprising internal simulator fixes.

There were some issues with poor region performance following the week #28 Main channel deployment (see BUG-9647), but the majority of these appear to have been corrected with a region restart.

SL Viewer

On Tuesday, July 14th, the attachment fixes viewer (project Big Bird) was promoted to the de facto release viewer. Version 3.8.1.303130 has fixes for some attachment-related issues, particularly when multiple attachments are added or removed at the same time. Allegedly, no birds were harmed during the making of this viewer, although a parrot may have bitten an engineer’s finger…

Region Performance

While things may appear to be quiet in terms of new deployments, etc., the Lab are working on Second Life in a number of areas. One of these is in finding ways to improve region performance – such as through finding the means for a region to support more avatars, something Simon Linden was recently looking into.

During the Simulator user group meeting on July 14th, Simon indicated he was also looking at the abilities provided to region owners which might allow them to better specify what can and cannot be done within their regions in turns of things like object rezzing. in order to improve people’s experiences. “I’m looking at the balances we keep on regions between being permissive and locked down, and how that relates to the land usage,” he said during the meeting, before continuing:

So combat regions want fast and free rezzing, but that’s not appropriate for a music venue … venues don’t want free rezzing of objects, so someone can’t drop their griefer bombs. The big fuzzy goal is to make SL better.   More specifically, it’s to make different types of regions run better. For example, there’s a bug now where rezzing can get backed up and delayed.   This is really bad for combat rezzing arrows or whatever projectile. Part of the reason that happens is throttles and limits on rezzing … So maybe we should be able to set up combat region settings tweaked for that kind of performance, and an event venue might be tweaked to handle crowds best, and really lock down free rezzing and object entry. 

This sparked a discussion on a range of performance issues and cases, including issues such as BUG-8974 and BUG-8946, as well as matters such as the inefficiencies evident in the asset handling system in general (this has also come into sharper focus with the arrival of Experiences, where KVP operations are handled by the same thread as asset handling), and the issues of agent script usage (script management doesn’t balance out and prevent someone from using far more than their share of script time). Ironically, during the meeting, a demonstration of this problem was given with the arrival of a griefer loaded with  >9999 scripts – with the result that the region crashed.

Simon emphasised the discussion was just that – a discussion intended to explore ideas and options, rather than any firm commitment on his or the Lab’s part to make changes. With this in mind, some of the suggestions put forward were:

• Land owner resource control for both rezzing and scripts for all region types (see BUG-3854)
• An option to block rezzing an object over a certain draw weight to help stop people being able to rez graphics crashers
• Possibly altering settings on mainland so that when purchased, it is not completely permissive and the new owner failing to understand what that can mean
• A re-submission of BUG-2467 as a feature request, amended to “visible attachments”, so the Lab might re-evaluate the idea
• The Lab to reconsider requests such as BUG-4153 and BUG-4182.

One of the problems here is that there are a lot of settings which might be exposed in order to help land holders better protect / optimise their land, such that it could become a complex issue in user understanding if too many controls are made available. However, it will be interesting to see what might transpire in the future as the Lab continued to consider options.

Other Items

Receipt of illegitimate L$ and Account Locking

An old issue of individual harassment has started to re-surface in Second Life of late, which can lead to people’s accounts being locked. With it, someone pays another avatar in-world using fraudulently created Linden Dollars. This results in an automatic account lock being applied, and the recipient, even though they are an innocent party, finds they are unable to use the account while investigations proceed.

The problem here is that there is currently no way to prevent the receipt of any L$ payment; not even blocking an avatar can prevent them from making a payment to you.

As a result of the recent increase in this problem occurring (there have been numerous reports to the Lab’s support team on the matter), a request has been made for the Lab to consider adding an “accept” button for all incoming payments. This would allow people to review all such unsolicited incoming payments ahead of accepting them, allowing them to judge whether the payment is valid or not.

Umbral Photography, July 2015 (Flickr) – blog post

Server Deployments

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

On Tuesday, July 7th, the Main (SLS) channel received the same server maintenance package deployed to the three RC channels in week #27.

As noted in my project update for week #27, BUG-197 referred to in the package release notes relates to an issue whereby a user can’t see any of their local chat on a region or parcel, and nor can anyone else, due to a scripted object which is spamming chat so badly, the chat throttle kicks in, but no warning would be provided to inform the user this was the case. with the deployed change, the user will now get a message about the chat throttle being hit, but unfortunately, the system will not identify the spammy object (so it might be removed / returned, if possible).

There will be no RC deployments to the RC channels on Wednesday, July 8th, leaving all of the main grid on the same release. A new RC deployment, described as a “minor update” is in preparation for deployment to the RC channels in week #29.

SL Viewer

On Tuesday, July 7th, The Maintenance RC viewer was updated to version 3.8.1.303166, bringing it into line with the attachments RC viewer updated in week #27, and just leaving the Viewer Managed Marketplace viewer to be updated in the release channel, which will likely happen later this week.

Chromium Embedded Framework

At the Monday Open source Developer’ meeting, Oz Linden indicated that an anticipated project viewer,  the Chromium Embedded Framework (CEF) viewer which will provide media support via HMTL 5, should be appearing “Pretty Soon”™.  While Quicktime and Flash  may work on this viewer for some users, given the age / status of both, the Lab does not plan to support either going forward, and recommends media creators migrate to HTML 5.

It had been hoped that this viewer would have been out by now; however there appear to be one or two issues still to be resolved. “I heard the developer working on it today say he was deep in the middle of keyboard issues,” Simon Linden said during the Simulator User Group meeting on Tuesday, July 7th. “Getting frameworks like that to cooperate with OS events like keyboard, mouse and screen is always tough.”

Experience Keys / Tools

Simon is continuing to work on tweaks to the Experience Keys / Tools code, and in doing so passed an interesting comment at the Simulator User Group meeting.

“I’ve been working on updating the KVP code that runs on our server,” he said, “and had the most frustrating time integrating the newest version into our code … The code we have is dated and we should have better performance and stability with their latest.”

Quite what the difference is between “our” and “their” code might be isn’t entirely clear at this point in time – although the question was asked during the meeting, and may well be asked again in the future.

Simon also hopes to put some work into getting KVP access moved onto a separate thread to ordinary asset handling. As previously mentioned in these updates, that KVP access is currently on the same thread as asset handling can, at times, cause issues, as noted in BUG-8946.

Group Chat

The recent improvements made to group chat continue to make themselves felt, with many reporting that the old issues of lag with the chat on large groups has largely dissipated. Such are the improvements that Whirly Fizzle has suggested that http://isslgroupchatstillbroken.com/ should be updated. Even so, despite all the the improvements, Simon has indicated that there are still “a few things” he’d like to tweak a little more.

Flux Sur Mer (Flickr) – blog post

Server Deployments Week 25

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

• On Tuesday, June 16th, the Main (SLS) channel received the server maintenance package previously deployed to the three RC channels, comprising further Internal server logging changes.
• There will be no deployment or restart to the three RC channels on Wednesday, June 17th.

SL Viewer

On Friday, June 12th, the Lab issued a new viewer directly to release status. Version 3.7.29.302599 offers no functional changes to the the previous release viewer, but does include two DLL files – MSVCP100.DLL and MSVCR100.DLL which were missing from the Windows version of the viewer, and as a result causing problems for some users by their absence.

As a result of this release, the Attachment fixes RC viewer (Project Big Bird) RC viewer updated to version 3.7.31.302640 on Tuesday, June 16th, and the Experience Tools viewer updated to version 3.8.0.302622.

An “obsolete platform viewer” has also been issued by the Lab. Version 3.7.28.300847 of the viewer is a “static” release of the viewer which is aimed at providing users on Windows XP or versions of OS X below 10.7 to be able to continue to log-in to SL following the upgrade of the tools used to build the viewer. As I reported at the time, the key points to note about this viewer are:

• It will not receive new features or bug fixes
• It will not be promoted to release status
• It does not change the Lab’s support policy on Windows XP or versions of OS X below 10.7, and is purely – as noted – an interim offering to help people
• It will be provided for as long as is reasonable – but not indefinitely.

 Other Items

 Experience Keys  / Tools

As noted above, the Experience Tools RC viewer has been updated to match the current release version as the Lab continue to work on the back-end services. One issue that has been encountered  – albeit it in a single case so far – is that access to the KVP store used to hold information on the experience can be delayed in very permissive areas where there is a lot of natural in-world rezzing going on (e.g. public sandboxes) – see BUG-9027. This is because access to the store uses the same resources as used for rezzing objects.

The concern with the problem is that it could have an impact of grid wide experiences. However support for running experiences on a grid-wide basis is, in the Lab’s eyes, “still some time in the more distant future”, as they are focused on the region / parcel level and ensuring the capability works within these extremes first. As such, this issue is unlikely to prevent the initial deployment of the Experience Tools capability, although the Lab will look into this particular matter at a latter date.

Combat and Damage

During the Simulator User Group meeting on Tuesday, June 16th, the subject of damage, combat and protection within regions controls. Commenting on the matter Simon Linden said, “I’m beginning to think more and more we need regions set to different modes … something safe for general use, then raise the limits for combat (and the like) where you are freer to hurt yourself.  It’s just an idea at this point, but the one-setting-for-everything seems to always make someone unhappy.”

The problem here is that the existing Linden Damage system is seen as being somewhat inflexible, hence the development of various combat systems within SL. However, that there are so many systems now available, makes the Lab hesitant to change things, as Simon went on to explain:

We’ve talked before about working on the damage feature but I think that’s a case where everyone has their own usage, and so it would be better to have the features so others can make the damage systems they want. We probably can’t alter the current one. I’m sure somewhere somebody is using it and we can’t break their content. We could add to it, if it’s backwards compatible, but like I said, I think it would be better to hear what the CS and other system builders want to make their system nicer.

As Simon states, this doesn’t mean the Lab are about to make changes, or consider making changes where combat systems and damage are concerned; just that they are aware of the limitations within the current land settings.

That said, a recent change within the LL viewer has been noticed. Under it, damage cannot be set it the parcel level only; also, the viewer does not display the health meter on damage enabled parcels, but people can be “killed” and teleported home.  While Oz acknowledged this may be due to the Lab not fully following through on a set of changes to the viewer code, Simon also pointed out that the two-state on / off capabilities between regions and parcels has never really been fit for purpose:

Basically if you have any larger or high level setting, as well as a smaller scale (like regions vs parcels)  the higher one can’t just be “on” or “off”. It needs to be “on with override smaller settings” , “on without override”, “off override smaller settings” , “off without override” … It just doesn’t work with simple on/off settings.   You need more info about the intent on how it relates to the smaller areas

However, he again warned against anything being done on this in the near future, commenting, “if we want to fix this in SL, it means viewer UI changes, new data being passed back and forth to the simulator (which can be a hassle depending on the messages), new values in the database (which is another issue) and of course simulator changes.” In other words, were anything to be done, it would be a large-scale project, something which the Lab has yet to even consider taking on.