The following notes have been taken from the Open-Source Developer meeting held on Wednesday, March 23rd, the Server Beta User Group meeting held on Thursday, March 24th, and the Third-Party Viewer Developer (TPVD) meeting held on Friday, March 25th (for which audio extracts are included). My thanks to Yuzuru Jewell for sending me the notes from the Open-Source Developer meeting.
SL Server Deployments – Recap
On Tuesday, March 22nd, the Main (SLS) channel was updated with the improved server maintenance project previously deployed to the three RC channels. This comprises server script fixes (not LSL changes) and internal improvements. There were no planned deployments to the RC channels.
SL Viewer
There have been no further updates to any of the official viewers since the recent promotion of the former Maintenance RC viewer to release status. This viewer has already demonstrated a much lower crash rate than previous release viewers, thanks in part to the contributions made to the Lab by TPV / open-source developers.
HTTP / Vivox Viewer
It is anticipated that the HTTP / Vivox RC viewer, version 4.0.3.312816 dated March 23rd, 2016 at the time of writing, will be the next RC to be promoted to the de facto release viewer.
Quick Graphics RC Viewer
The Quick Graphics RC viewer, version 4.0.2.312297 dated March 11th, 2016 at the time of writing, further testing has been going on with a hard limit on the number of avatars rendered: anyone outside the closest N will simply be invisible./
64-Bit Viewer Builds
The 64-bit official viewer project is continuing. As a part of this work, the Havok sub-library will be updated to 64-bit as well (allowing 64-bit versions of TPVs to including the sub-libraries, and will see CEF updated to that Mac users can utilise PPAPI should they wish to continue to use Flash driven devices for in-world media (currently, Mac users must use the less secure NPAPI – see here for more on installation requirements).
Inventory Updates
Once the HTTP viewer has reached release status, the Lab will be shifting viewer focus back on the inventory improvements work Aura linden has been working on. This includes switching all of the old UDP inventory messaging paths over to HTTP, and to deprecate old inventory messages and the removal of server-side support for such messaging.
Once live, this means that older versions of viewers which still rely on the old inventory messaging paths will no longer have functional inventories.
Aditi Inventory Syncing
As I’ve previously noted, there is a new system in place for synchronising Aditi (Beta) grid and Agni (main) grid inventories for avatars. Rather than requiring a password update in order to force your Aditi inventory to be overwritten with the contents of your Agni inventory (generally around 24 hours after the password change), the new process simply requires you to log into Aditi.
Whenever you do so, your inventory is flagged so that the contents of your Angi (main) grid inventory is merged with your existing Aditi inventory (in theory preserving most of your Aditi inventory, rather than simply overwriting / deleting it) the next time an update process is run (at around 06:00 SLT daily). This process works one way: the contents of your Agni inventory is merged into your Aditi inventory – it doesn’t merge anything you have on Aditi into your Agni inventory.
The “in theory” statement above is important, as some issues / potential confusion has arisen with the way the process operates.
Syncing, Cache Clearance and Slow Inventory Load
Whirly Fizzle reports that following an inventory sync, items created on Aditi (and therefore unique to it) prior to the sync may seem to be missing from your Aditi inventory the first time you log-in to Aditi following the sync process. As the viewer uses the shame cache location regardless of which grid you log-in to, logging off and clearing cache corrects the problem (fresh inventory download from the correct grid asset servers) but it can lead to exceptionally log log-in times when trying to get back into Aditi (Whirly indicated in her case, it took two hours for her to log back into Aditi after clearing cache).
“Shared” Asset UUIDs and Agni Precedence
A further issue appears to be that worn items are essentially treated as “shared” assets between Agni and Aditi. This can led to problems on Aditi when editing the contents of a worn object there.
For example: Lucia Nightfire had her Agni inventory merged into Aditi. She then modified a script for a HUD which originally came from Agni. This was fine until the next time her Agni and Aditi inventories were synchronised (remembering that your Aditi inventory is flagged for update each time you log-in to the beta grid, unless it is flagged already). following this further merge, she discovered that the changes she’d made to the script on Aditi had been reverted due to the Agni data relating to the HUD and its contents overwriting the Aditi information.
The issue appears to be the result of the respective Aditi and Agni versions of the asset having the same UUID, with the Agni version of the asset taking precedence over the Aditi version during an inventory merge. It’s currently not clear if the same issue will occur with the contents of objects which are rezzed in-world as well; further tests are being carried out to check on this.
Two-Factor Account Authentication
As recently indicated by the Lab, phishing issues are still a problem in Second Life. These issues led to a request during the TPVD meeting that the Lab look to implement two-factor authentication on accounts.
The lab has been carrying out back-end infrastructure work, which has involved some changes – transparent to users – in the log-in and authentication process, and going forward, further work is to be carried out, which may include a move to two-factor authentication, although the Lab is still looking at options and time frames.
RegAPI
The back-end accounts management work being carried out by the Lab mentioned above is in part related to updating the new user account registration process, and the RegAPI associated with it. The latter is intended to by used by those involved in the upcoming Gateways trial programme, but has been subject to some issues (please see my week #10 TPVD update and to my Gateway trial programme update for specifics on the problem).
The first phase of the work to improve the RegAPI (referred to in my week #10 update licked to above) is now live, and the additional update with new features is currently with the Lab’s QA team and about to undergo testing. The hope is that this will be available in the very near future, allowing the Gateway trial programme to finally ramp up.
TLS 1.2 Update
There is some confusion over precisely what impact the implementation of TLS 1.2 will have on people’s ability to use Linden Dollars in the viewer. When originally announcing the switch-over would be coming, at the end of 2015, Oz Linden commented:
Anything that does not support TLS 1.2, will not be able to do any interactions with cashier or anything that involves money. This isn’t optional on our part or just an arbitrary choice on our part, this is a compliance requirement.
While the emphasis is mine, this seemed to indicate that it would involve both cashier interactions (e.g. buyig L$ through the viewer) and money transfers (e.g. in-world shopping). However, it has been taken by some to mean that only cashier interactions will be affected. Asked to provide a clarification at the TPVD meeting, Oz responded:
I believe it’s basically going to break anything that has to do with transferring money, including Linden Dollars …. it’s not going to happen all at one time, but we are going to change all the secure connections to be TLS 1.2.
To which Grumpity Linden added:
The immediate change is only going to be to cashier, which is buying Linden Dollars right now, not transferring Linden Dollars … So that’s what’s going to change right away. Later changes will come, and we’ll certainly tell you about them.
TLS 1.2 is one of a number of changes which will gradually further eliminate the use of older viewers with Second Life.
Other Items
Your Trash Can and You
I’ve covered a lot in the past about issues such as long log-in times and failures, etc., which can be a direct result of having a large, relatively “flat” inventory (e.g. tens of thousands of items all under a single folder level), and the inventory transform process the Lab introduced to help deal with such issues.
However, id you know that keep very large numbers of items in your inventory trash can have the same impact (it is, after all, effectively a single folder / level within your inventory)? The advice is, if you are moving items to Trash, don’t let them accumulate there into the 10s of thousands, but purge Trash regularly.
Longer Sound Loops for SL?
Currently, sound loops in Second Life are limited to just under 10 seconds in length at upload. The rationale for this appears to have been to allow for playback over slow internet connections. If this is indeed the reason, the Lab may not be averse to testing whether longer sound playback times could be implemented.
Were this to be done, the work would likely be undertaken as a project viewer initially, so that it could be thoroughly tested. However, this is unlikely to happen until after additional assets (including sounds) have been moved to being handled by the CDN, rather than through the simulator. While this latter move is very much something the Lab wants to do, there is currently no definitive time frame on when it will happen (although it will likely involve any assets which are acted upon purely by the viewer, and which the server needs not be aware).
Inara Pey: Living in a Modemworld 