Voice RC viewer, version 5.0.8.329250, dated September 29.
Maintenance RC viewer, version 5.0.8.329115, dated September 22nd.
Wolfpack RC viewer,version 5.0.8.329128, dated September 22nd – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 1st
Obsolete platform viewer version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Touch, Camming, Experiences, Avatars and Feedback
Note: the following is not indicative that the Lab is considering behavioural changes in Second Life at this time. The topics were simply raised with a view to generating discussion and feedback.
There are a lot of things we can do in a region which might not always be in the spirit of what is intended by the region owner, particularly if the region is designed for a specific purpose, such as an experience or game. We can, for example, cam ahead, seek out secrets, identify traps or hazards and find ways to avoid them. We can also reach across a region to touch things when perhaps it would be better if we could only do so up close.
There are various ways to limit some of this – scripts can be used to limit touch, as can RLV, for example. But for things like experiences and games, it might be better if the region owner had the option to perhaps enforce limits on how far away from their avatars people can cam or touch.
However, this has to be balanced against those situations where camera and “long-distance” touch can be essential. Shopping at a crowded event, for example can be made much less of a fight against crowds and lag by using Area Search, the camera, and far touch to obtain specific items (even flycamming and far touch can make shopping a lot easier in any situation). Ergo, there’s a risk that imposing limits on either could have a more detrimental effect on people’s willingness to shop in popular locations.
Given that crowds themselves are a problem, would it be worthwhile limiting the number of avatars seen within a region in some way? Perhaps a limit set through the estate controls, or by some method within the viewer such that avatars / imposters beyond a certain radius aren’t rendered / have updates ignored by the Interest List until they come within the specified distance – just like people can move in and out of view in a real crowd.
Again, how something like this might work – should it really be a control at estate level, or would it be better as an option users could tweak (which would get my vote) – would have to be thought through in detail. Particularly given we already do have some control over the rendering, at least, of the avatars around us through various methods (e.g. render friends only, derender selected avatars, CTRL-ALT-SHIFT-4, avatar rendering, etc.); while although each of them might not be perfect, they can give flexibility of control to individual users.
As noted, the Lab aren’t planning any changes specific to any of the above – but by throwing questions out and listening to feedback, concerns, alternative ideas, they are perhaps pulling ideas and thoughts into the melting pot on how SL might be refined and offer better controls and means to improve people’s individual and joint experiences.
The majority of these notes are taken from the TPV Developer meeting held on Friday, October 6th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it. time stamps in the text below will open the video in a separate tab for ease for reference to the relevant points of discussion in the meeting.
The meeting was chaired by Rider Linden, who was filling in for Oz, and was somewhat foreshortened.
SL Viewer
There were no updates to the current crop of official viewers during the week, leaving the pipeline as:
Current Release version 5.0.7.328060, dated August 9th, promoted August 23rd – formerly the Maintenance RC
Release channel cohorts:
Voice RC viewer, version 5.0.8.329250 on Friday, September 29th
Maintenance RC viewer, version 5.0.8.329115, dated September 22nd.
Wolfpack RC viewer,version 5.0.8.329128, dated September 22nd – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 1st
Obsolete platform viewer version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Quick notes:
[4:35-4:52] Work is continuing to fix the texture crashes in the 64-bit Alex Ivy RC.
[5:25-5:40] There is a reference to Voice changes, however, the question is non-specific, and it is unclear if it refers to the current Voice RC (updated at the end of week #39) or to further updates, the question is deferred to Oz (who is directly involved in the Voice project).
E-mail Verification
[2:56-4:00] As noted in part 1 of this week’s report, the Main channel deployment saw an update to IMs-to-e-mail as part of the Lab’s move to only handling verified e-mail addresses.
The sending / forwarding of messages to unverified addresses is not blocked – as yet. However, once a viewer-side changed has been deployed, accounts with unverified emails will no longer be able to request that IMs be forwarded to e-mail; attempts to enable the viewer-side setting will fail, and result in a message advising the account holder to verify their e-mail address.
Potential Interest List Change
[15:52-18:40] (with a lengthy silence)] There is a potential simhost change to the Interest List under discussion at the Lab. This will in essence reduce some of the aggressive culling of updates from objects behind an avatar (particularly useful in the case of light sources, moving objects, etc). If it goes ahead, this update could also benefit the 360-snapshot viewer.
Other Items
Estate Tools Update
[6:07-10:40 (ish) and 13:10-14:20] There is a lengthy on-off exchange, in Voice and text (with some long pauses in both) regarding the Estate Tools updates in the viewer. In short: updates to the estate ban lists (see BUG-8883 and BUG-40676 as examples of requested changes), have resumed. however, as Alexa Linden, who is running this project, was unavailable for the meeting, no detailed update was possible.
Viewer Build Issue
[10:50-12:00] There is “progress” in fixing an incorrect viewer build update involving a change to the Cmake files which results in a forced rebuild of the Windows version of the viewer (the “-z0” issue).
In-world Posing
[20:48-end of meeting] NiranV Dean has been experimenting with a means of in-world posing an avatar through the viewer (e.g. for things like photography), which would be visible to the person posing their avatar (as it would require server-side support to be visible in all viewers). There may be interest from the Lab in accepting as a proposal / contribution, if the details of what is required can be agreed between the Lab and Niran.
There were concerns among those attending the meeting (and raised largely in text) on what Niran is trying to achieve and how it might related to content ripping. If nothing else, the conversation underlines the need for a clearly thought-out proposal outlining the idea, its purpose, how it might be implemented, potential issues which will need to be considered and addressed, etc., rather than requesting people “try” the idea and give feedback.
Date of Next Meeting
The next Third-Party Viewer Developer meeting will not be until Friday, November 3rd, 2017.
As always, please refer to the server release thread for updates and the latest news.
On Tuesday, October 3rd the Main (SLS) received the server maintenance package previously deployed to the Magnum RC channel. 17#17.09.22.508905 comprises improvements to e-mail verification logic (IM to e-mail) which sees the system checking whether the receiving e-mail address is verified or not.
With regards to the e-mail verification update, note that the sending / forwarding of messages to unverified addresses is not blocked – as yet. However, once a viewer-side changed has been deployed, accounts with unverified emails will no longer be able to request that IMs be forwarded to e-mail; attempts to enable the viewer-side setting will fail, and result in a message advising the account holder to verify their e-mail address.
SL Viewer
The Voice RC viewer updated to version 5.0.8.329250 on Friday, September 29th. This viewer:
Adds support for a higher quality voice using SLVoice version 4.9.
Fixes the apparent position of the speaker in nearby voice.
Improves retry behaviour when there are problems connecting or during temporary connection problems.
Logs more detailed information to the Lab for quantifying connection issues.
Improves security of the communication between the viewer and SLVoice.
Unrelated to voice, improves the validation of TLS certificates (security improvement).
It should also be noted:
Local teleports will cause a short (a few seconds) voice interruption because the viewer now detaches from voice a little earlier in the teleport sequence.
With some SLVoice changes, the SLVoice executable can be copied into another viewer – that will not work with this one. There are changes to the connection between the viewer and SLVoice that are required. Talking to any viewer version should work.
The remainder of the viewer pipeline remains unchanged from the end of week #39:
Current Release version 5.0.7.328060, dated August 9th, promoted August 23rd – formerly the Maintenance RC
Maintenance RC viewer, version 5.0.8.329115, dated September 22nd.
Wolfpack RC viewer,version 5.0.8.329128, dated September 22nd – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 1st
Obsolete platform viewer version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Environment Enhancement Project (EEP)
“You will be able to add water settings to the day cycle,” Rider commented at the Simulator User Group meeting on Tuesday, October 3rd, when discussing the EEP project. “So calm seas in the morning and choppy at night.”
Once he’s got the settings working as inventory assets, allowing people to exchange / sell Windlight settings, Rider aims to get the project viewer sorted and available. No time frame on this, but he’s willing to discuss it as people start testing the new environment capabilities, either at the Simulator User Group meetings (noon SLT, Tuesdays) or the Content Creation User Group meetings (13:00 SLT, most Thursdays).
The following notes are taken from the Content Creation User Group meeting, held on Thursday, September 28th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article, with key points of discussion noted below. Time stamps to the recording are included below, and clicking on any of them will launch the video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
Animesh (Animated Mesh)
“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.
Project Summary
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
In short, an Animesh object:
Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
Can use many existing animations.
Note that the focus of this project is not currently about providing fully-functional NPCs at this point in time, which is seen as a follow-on project.
Current Progress
[3:32-4:00] We are getting close to seeing a project viewer for Animesh. Vir is about to submit a build to the Lab’s QA team for testing, which should be done by the time of the next meeting (Thursday, October 12th, 2017). The outcome of the testing will help determine when we might see the project viewer made publicly available.
[4:00-4:37] Most recently, Vir has been working on issues with the transform matrices when handling Animesh attachments. He’s now got these to a point where things can be edited and positioned where they are needed. There may be some further iterations on this work, but it appears to be working well enough for testing now, once the project viewer is available.
Constraints
This discussion on constraints, and triangle limits in particular ran throughout most of the meeting in chat, with a large portion of the meeting from around the 50 minutes to the end of the hour being almost exclusively personal viewpoints chat. I’ve attempted to highlight the key points of the discussion below.
[6:05-7:25] As noted in previous CCUG meeting notes, some constraints on Animesh are required to prevent undue impact at either the simulator or (particularly) viewer end of the system. These constraints will be in addition to any already in place in SL, and include:
Limiting the overall complexity of an Animesh object
A land impact surcharge for in-world Animesh objects (currently set to 200LI per region for testing purposes).
Limiting how many Animesh items an avatar can have attached at any one time (currently set to one for testing purposes).
Limiting the number of triangles an Animesh object (attached or in-world) can contain, the figure for this the topic of debate.
[8:21-9:08] The initial limits will be documented when the project viewer is released. Vir will be working on this and other related Animesh documentation when the viewer goes to QA for testing.
[12:30-13:30] The limit will come into play when converting an object (or linkset) to Animesh in-world (note there is no check at upload, as a) the uploader has no way of knowing if a rigged mesh item is specifically Animesh or not without changes; and b) an in-world check allows existing in-world mesh to be used as / with Animesh without the need to re-upload). It will be triggered through the viewer, enforced by the server.
[15:04-15:58, [16:02-18:35] There is doubt is the 20K tri limit is high enough – even Vir is not sure, and may raise it before the project viewer is made available.
[18:39-19:22] Concern was raised about the impact of the servers decompressing mesh objects in order to calculate the number of tris the number of objects in an item in order to check if the Animesh limit is exceeded. Vir explains this isn’t how it’s done. Rather the server has a estimation for the likely tri count based on the size of the data objects which store the triangles – which is essentially the same figure used in the rendering / streaming cost calculations, and gives a close enough estimate to be reliable.
[20:40-28:58] Some would like to see it raised “just for testing”. however, Vir’s concern is that once the project viewer is available, the Aditi test regions are liable to be inundated with Animesh objects, resulting in them being overloaded with no meaningful data collected. The flips side to this is that an initial limit of 35K or 50K would mean that more existing content could be “flipped” to Animesh status, without the need necessarily for creators to have to create models specifically for Animesh testing.
[31:47-32:47] As the tri limit is managed server-side, it may be possible to have different regions set with different limits to offer a variety of testing environments.
[20:01-20:30] Animesh will increase the server load in other ways. Whereas the tri count was only affected by in-world objects, it will now have to account for worn Animesh as well.
[34:54-35:42] The important thing to note with these constraints is that they are preliminary and for the purposes of testing. Depending on the results obtained, some of them might well be relaxed both as testing progresses and prior to Animesh being formally released. As Vir notes, it is potentially much easier – and less upsetting – to start with very tight constraints and then loosen them as data is gathered, rather than start with very broad constraints and then try to restrict them over time. so, the intent is with the testing is to lay the grounds for a more informed discussion on limits – tri counts, LI, and everything else. Nothing, at this point in time or with the arrival of the project viewer in due course, is set in stone.
[47:21-50:23] Could the number of tris in an Animesh be tied to land impact, rather than a basic surcharge regardless? Possibly; again, the 200 LI surcharge is purely for initially region-based testing. This is already how land impact works elsewhere. However, there is always a basic cost associated with an avatar skeleton, so this needed to be factored-in as well, however minimal it might be for a single skeleton.
Test Content
[4:50-5:42] The idea for the Lab to provide more in the way of test content to help those wanting to get started with Animesh has been passed to the Linden Department of Public Works (LPDW) team. They’ve in turn assigned someone to produce some test content which will be made available through the Library (and so will appear in people’s inventory under Library when available).
How Will Animesh Attachments Work?
[9:10-12:10] Essentially the same as any other attachment, using an avatar attachment point. The Animesh item is attached via its root joint, and then can be edited to fit (translation / rotation). Animesh can also currently be attached to HUD point, but this is liable to be disabled, particularly as it is will require more work to get it to function reliably, and there aren’t any obvious use cases.
Bakes on Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:
The current work to update the baking service to support 1024×1024 textures.
An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
This work does not include normal or specular map support, as these are not part of the existing baking service.
Current Status
[7:40-8:04] The updates to the service to manage 1024×1024 textures and compositing has been in testing with LL’s QA team, and it has been reported that the higher resolution texture capability (the baking service only supports 512×512) has the potential to impact the performance of the bake service, so a load test is being planned.
[14:17-14:37] The first part of the bakes on mesh project will not include any kind of API for injecting layers into the bake stack (e.g. to ensure that layers from the likes of appliers are stacked correctly (e.g. underwear, shirt, top), by the baking service. The might be added in the future.
[29:00-29:40] Essentially, the project currently breaks down into two core activities:
First stage: just to increase the maximum resolution the baking service can support (1024×1024, as noted above)
First (and larger) stage: to get the bakes on mesh to help with baking to mesh bodies. This work is “further down the line”.
[38:00-41:10] Once Animesh is released, the plan would be to also extend bakes on mesh to support Animesh objects as a part of the Animesh follow-on project, which would see Animesh objects have a notion of a shape, plus wearables in their object inventory.
Other Items
[14:39-15:03] As a ploy count will be used for Animesh constraints, can llGetObjectDetails() have a parameter to return the count is a scripted enquiry? Possibly, but not as part of the Animesh project.
There is no Content Creation meeting in week #40 (commencing, Monday, October 2nd). As noted above, the next meeting will be Thursday, October 12th, 2017.
As always, please refer to the server release thread for updates and the latest news.
On Tuesday, September 26th the Main (SLS) received the server maintenance package previously deployed to the BlueSteel and LeTigre channels. 17#17.09.14.508549 comprises improvements to address some problems that could degrade simulator performance in rare cases.
On Wednesday, September 27th, the RC channels should be updated as follows:
BlueSteel and leTigre were still “TBD” at the time of writing.
Magnum should receive a new server maintenance package, 17#17.09.22.508905, containing improvements to e-mail verification logic (IM to e-mail) which sees the system checking whether the receiving e-mail address is verified or not. Sending to unverified addresses is not blocked – as yet.
In light of the Magnum change, those who have not verified their e-mail address, should seriously consider doing so.
SL Viewer
The Wolfpack and Maintenance RC viewers were updated on Friday, September 22nd; however the updates were pulled to allow time for Microsoft to assist with resolving an issue with Windows SmartScreen flagging new releases of the SL viewer as possibly “unsafe”. This matter (due to the expiry of a code-signing key) was resolved over the weekend, and the two updated RCs were once again made available through the Alternate Viewers wiki page on Monday, September 26th.
This leaves the current viewer release pipeline as follows:
Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
Maintenance RC viewer, version 5.0.8.329115, dated September 22.
Wolfpack RC viewer,version 5.0.8.329128, dated September 22 – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 5
Voice RC viewer, version 5.0.8.328552, dated September 1
Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
Updated, September 25th: As indicated to me by Grumpity Linden, the cause for the Wolfpack and Maintenance RCs to be withdrawn as noted in this article (and which was as a result of this issue), has now been resolved and the two updated versions of these viewers are once again available. As a result, the links to their release notes and download options have been restored.
The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, September 22nd 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it. Timestamps in the text below will open the video in a separate window at the relevant point for those wishing to listen to the discussions.
Server Deployments Week #38 – Recap
There was no deployment / restart on the Main (SLS) channel on Tuesday, September 18th, leaving that channel running on 17#17.09.01.508236.
On Wednesday, September 19th, the RC channels were updated as follows:
BlueSteel and LeTigre received a new server maintenance package, 17#17.09.14.508549, comprising improvements to address some problems that could degrade simulator performance in rare cases.
Magnum received a new server maintenance package, 17#17.09.14.508533, containing a fix for BUG-100505 “llGetEnv (“agent_limit”) is returning an empty string in Magnum, LeTigre and Blue Steel regions.”
SL Viewers
Alex Ivy 64-Bit
[0:54 and 6:00] The Alex Ivy 64-bit viewer is due an update, possibly in the early part of week #39 (commencing Monday, September 25th). This may not have all the fixes required for the viewer to get promoted to de facto release status. Before this happens, the Lab wants to tackle the problem with pipeline stalls in this viewer, and are working on an experimental branch of the viewer to try to resolve the issue. This branch will be made available as a test viewer to those who have reported the issue and can reliably repro it. Depending on the outcome of this testing, a decision will be made on folding it into the RC branch for the viewer.
The wiki instructions for the viewer should now be updated to the 64-bit build requirements, nd Oz indicates that a new 64-bit Havok library should follow the release of the viewer.
Voice Viewer
[1:33,2:13, and 34:02-37:14] There will be a new Voice SDK arriving for the Voice RC viewer in the near future, which will include an updated SDK that includes a fix for some long-standing problems. There are still some problems to be fixed, so it is unlikely this viewer will be promoted until the new SDK has spent time in RC and the remaining major issues have been resolved.
This viewer already fixes the high number of failures to connect to the Voice service when logging-in; however, there is an issue where manually killing the Voice process will not restart (as it used to), and so Voice won’t work. The Lab would like to fix this so the process does restart the process, but this is not seen as a critical issue to be resolved before the viewer is promoted.
The new SDK does not alter the Voice protocols, but is not compatible with previous versions, requiring the supporting updates in the viewer to work. This means the new SDK cannot work with older viewer versions, and older SDKs cannot be used with viewers incorporating the code updates to support this new SDK.
Maintenance and Wolfpack RCs
[2:04 and 4:15] The meeting references updates to the Maintenance RC viewer (to 5.0.8.329115) and the Wolfpack RC (to 5.0.8.39128). While both updates were available at the time of the meeting and shortly thereafter, the Alternate Viewers wiki page now references the previous RC releases for both (5.0.8.329065 and 5.0.8.328990 respectively). It is not clear whether this is an error with the wiki page, or if the updated RCs have been withdrawn (both still appear on the viewer release notes list). Resolved.
Snapshot Viewer
[5:14] There may be a new updated to the 360 snapshot viewer in the next week to two weeks. Work has also started on providing better support for using 360-degree images in Second Life Place Pages (see here and here for more on Place Pages).
Pipeline Status
Keeping the above in mind, the current viewer pipeline comprises:
Current Release version 5.0.7.328060, dated August 9th, promoted August 23rd – formerly the Maintenance RC
Release channel cohorts:
Maintenance RC viewer, version 5.0.8.329065, dated September 18th.
Wolfpack RC viewer,version 5.0.8.328990, dated September 12th – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 5th
Voice RC viewer, version 5.0.8.328552, dated September 1st
Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
New Viewer Splash / Log-in Screen
[7:12-7:42] As noted in my week #36 TPV meeting notes, Phronimos Linden is updating the viewer splash screen which will see a different look and feel to the screen, including how information is displayed (such as making grid status info more prominent), and will see updates to some of the widgets providing information in the splash screen. This work is now with the QA team, and information on the updates will be available for TPVs soon.
Windows Viewer Installation Warning
[7:47-8:48] The Lab’s code-signing key used to verify the viewer with Windows (notably Windows 10) has expired. The Lab have a new key, but for an interim period, it means users installing the Windows version of the official viewer may find Windows SmartScreen reports the viewer as unverified.
You can read more here, on via my own blog post, which includes steps on clearing the warning and installing the viewer.
Server Version Updates and Move to the Cloud
[12:13-12:53] A number of server version updates are advancing. these don’t always have user-visible changes, but they are nevertheless important to Second Life. Among other things, they are part of the preparatory work for moving SL capabilities to the cloud (see my week #36 TPV notes for more on this).
[15:08-19:06] There is no time line for moving things to the cloud, simply because the Lab does not know at this point how long it will take. There are some significant changes which must be made to both the way things are built and the way they are run, and there need to be assorted updates to various components that go into building and running SL services.
Some SL services are already being tested in the cloud, and some are performing well – such as the process for determining if a user requires a viewer update. Others have been tested and revealed problems which must be addressed if they are to be run from the cloud – or should be addressed even when not running in the cloud.
It is unlikely the Lab will be providing specifics on services which have moved to the cloud / are being tested, and which are still based within their data centre until things reach a point where simulators are running in the cloud, simply because where many SL services run makes absolutely no difference to the user experience, as long as they are running. Moving and testing simulators in the cloud is likely to be one of the last things to be tackled, simply because of the complexities involved.
The first goal is to get everything working pretty much “as is” from the cloud. Only after this has been done, will work start on leveraging the benefits of having everything in the cloud be explored and exploited.
[19:06-21:49] This could include giving – and to use Oz’s words, the option of having their regions hosted in specific geographical locations. So, for example, the various communities located in South America could have their regions all hosted in South America, potentially improving response times between viewer and server. However, whether this will in fact be possible is dependent on the Lab reaching that point at which they can start leveraging the benefits of the cloud.
Obviously there are trade-offs in this kind of shift, should it occur; relocating a simulator to better serve a community may not improve things for others access the region on that simulator. However, in potentially supplying the option, the Lab is providing land owners with a choice of what they would like to do.
[21:56-22:38] If nothing else, this work should be a demonstration that the Lab really is continuing to invest in Second Life and its future. Were they seriously thinking of letting it go (i.e. in favour of Sansar), then none of this work – and the associated expenditure – would be taking place.
[29:26-31:16] There is a “fair amount” of back-end work that is being worked through, and the work is approaching the point of internal testing within the Lab. Once this has reached a suitable point, the server-side / simulator changes will be deployed (e.g. to Aditi) for wider testing, alongside of a project viewer to handled the client-side application of the capabilities.
Recent Grid Issues
[37:51-39:20] As most are aware, there have been some recent grid issues. While not the cause of these issues, but which has been a contributing factor to their duration, is some low-level code within the viewer which handles log-in retries far too aggressively. When this happens en masse (such as when there is a grid issue), it results in the log-in servers being swamped, adding to the woes for people trying to log-in.
A recent Maintenance update to the SL viewer addresses this issue (see my week #30 TPV update), and the request for TPVs to pick these code changes up was re-iterated at the meeting. In addition, the log-in servers have themselves been made more robust when facing large number of attempted / repeated log-in attempts.
Other Items
Estate Tool Ban List Improvements
[9:32-11:22] The Lab has resumed work on the region ban lists (layout / usability, etc), and the updates should be appearing soonTM. The specifics of what is being done will hopefully be available for the next TPV Developer meeting.
Premium Member Benefits
[13:13-14:53] There is apparently at least one Premium member benefit that will be appearing real soonTM which the Lab believe people will like, and some further ideas are being considered. Oz declined to comment on what any of these might be, citing it being more fun to find out when they are announced. He also indicated that appropriate and considered suggestions / ideas for benefits (e.g. not things that persist after a Premium subscription has been cancelled) are also welcome.
Group Notice Failures
[28:00-28:55] Still no work on group notices (on-line and off-line) sometimes not getting through for some people. It’s not on the “now / next” roadmap of things the Lab is / will be looking at. The focus on sever-side work is on dealing with instability issues which can cause crashes / offer exploits to griefers.
Asset HTTP Messaging and Asset HTTP Issues
[41:14] As noted in my week #36 TPV meeting update, the recent Asset HTTP updates are leading to the texture pipeline getting out of sync, and people experiencing texture load stalls. A JIRA for this has been filed (BUG-139123), and a possible fix has been submitted to the Lab by Sovereign Engineer.
[43:16] The Lab is also working on the texture caches in an attempt to make them faster and more effective.
Inara Pey: Living in a Modemworld 