Server Deployments – week 22
The server channel deployments were delayed 24 hours this week due to Monday May 27th being Memorial Day in the USA. This being the case:
- On Wednesday 29th May, the Main channel received the server maintenance project previously on Magnum. This includes bug fixes, comprising two for crash modes and one for BUG-2424 (Overriding “Sitting on Ground” animation while sitting on the ground makes “stand up” button disappear). This deployment also included the LSL support to create and parse JSON-formatted strings, which also included the bug fixes for this capability deployed to Magnum in week 21 (see my SL projects update report from week 21). Release notes
- On Thursday 30th May, the three Release Candidate (RC) channels received the interest list improvement project deployed to LeTigre in week 21. The core change in this update should reduce scene loading time when entering a new region (again, please refer to my week 21 report for background information). Release notes (BlueSteel, but applicable to all three RCs).
Server-side Baking / Appearance
As noted in these pages, the Lab formally announced the forthcoming arrival of SSB/A on May 29th. This has prompted questions of “when?” Again, as I’ve previously reported, the Lab is proceeding cautiously towards a server-side deployment, even though they are encouraging people to swap to a version of their preferred viewer which is SSB/A-enabled sooner rather than later.
Currently, the two regions for TPV testing have been enabled with the new service and TPVs are putting the new capability through its places – and this has already revealed a reason for the Lab’s understandable reluctance to give out firm dates, as a potentially major issue has been identified.
SUN-74, raised on May 29th, shows that if you are wearing a MOD skin, hairbase or eyes and you enter an SSB/A-enabled region using a non-SSB/A enabled viewer, an alert will appear on your screen which, on clearing, is followed by an innocuous-looking prompt.
Clicking YES in reply to the prompt can result in the currently worn skin / eyes / hairbase to become irreparably corrupted, with a skin turning a mixture of black / invisible and eyes turning white. Rebaking will not fix the issue. Relogging to an SSB/A-enabled viewer seems to result in the avatar rendering as a cloud, and / or ending up with a default skin and ruthed. Replacing the affected items (skin and/or eyes and/or hairbase, depending on which has / have been corrupted) with others from you inventory will fix the issue, but re-wearing the corrupted item(s) results in the avatar once more appearing corrupted (and again ruthed, if running an SSB/A-enabled viewer).
Again, this problem will only manifest itself when:
- Using a non-SSB/A enabled viewer AND
- Wearing one (or more) of: a MOD skin, a MOD hairbase or MOD eyes AND
- Entering an SSB-enabled region.
Nevertheless, the issue is liable to be considered serious enough to prevent any public enabling of the server-side SSB/A code until such time as the issue has been investigated further.
Materials Processing
I asked Oz Linden on the status of the Materials Processing project viewer, which it had been hoped would reach a beta release status in week 21. He indicated that while progress was being made, the viewer was still with LL’s QA team, who were still pointing to bugs with the code which require addressing. As are other people at the Lab, as Maestro Linden again commented at the Server Beta meeting, “I found a materials viewer bug last night (fixed today), where my swimsuit wouldn’t render to people with certain graphics settings. That was considered a blocker for sure :).”
So we’re going to have to wait a little longer for the viewer to appear in a beta release.
Other Items
Apparent Region Crashes
Speaking at the Server Beta User Group meeting on Thursday May 30th, Maestro commented on an issue which is affecting Agni.
There is one medium-hot issue on the grid, recently which isn’t a crash, but disconnects multiple avatars from the sim suddenly (which looks very similar to a crash from the viewer’s perspective). I found out this morning that it can also cause http-in LSL scripts to lose their URLs. The viewer disconnection happens because the viewer suddenly gets a 404 when it reaches the EventPoll cap.
When this happens, the affected user(s) is/are disconnected from SL as if the region has crashed, although no actual simulator crash has occurred.
The issue has been reported in the forums, and takes th form of the user receiving the message: “You have been logged out of Second Life: This region may be experiencing trouble. Please check your connection to the Internet”. Checking the viewer log file will reveal 404 messages.
Whirly Fizzle indicated that Kadah Coba has produced a chart showing simulator crash and viewer disconnect rates over a 2.5 year period, and the sudden increase in disconnects since the start of May 2013 is readily apparent.
The good news on this is that a fix has been developed for the issue, and Caleb Linden has been testing it.
Inara Pey: Living in a Modemworld 
So what does “MOD” mean?
What makes it so special that skins and such with that label have never been tested until now?
LikeLike
Modify as in COPY / MOD / TRANS
LikeLike
First time I’ve seen it abbreviated that way.
..
That makes it even more of a William Tare Fox question. It’s not quite the same as write-enabled but testing that it is safe for such files is a rather obvious check.
LikeLike
Sorry about that.
I’ve always tended to refer to permissions in terms of Copy / Mod or COPY / MOD, together with either No Trans or Trans (or in uppercase for the latter). The only time I’ve encountered confusion being expressed until now is when I’ve used “Xfer” or “XFER” or “transfer”.
LikeLike
Glad they are being so cautious and making sure that assets would not be lost (probably most of mod skins are no copy so losses would be terrible!)
And now i understand why in so many concerts lately we all got disconnected form the region, hope that the fix will not screw sim crossings that seems to handle much better since yesterday’s deployment!
LikeLike
Answering your question, most brands only sell copy skins, so a mod skin is one that you created for yourself (imported the textures and so on) and/or some custom work that a creator sold (can be mod/transfer or whatever they agree with!).
I do believe in SL not to many use mod skins.
Eyes i think the same!
Now, mod hair is very common, its the only way to recize it and adjust to your shape and so on!
Why only with mod items and only those ones?
That i hope the fix will explain!
LikeLike
You can re-size No-Mod with scripts.
Wild guess here, but if the data can be modified, it can be written to. The way things work, it might not be quite the same in Second Life, there might be a new file with a new UUID since there is likely to be more than one Resident with the original file, but I really hope somebody checks that the corruption doesn’t spread from one Inventory to another.
LikeLike
I didn’t fully answer your last question, as I was on the move (now at computer).
The most likely reason that this issue wasn’t spotted before is that the majority of testing carried out on Aditi was with the new SSB/A viewer-side code – so only SSB/A-enabled viewers were given an in-depth test against both the new service and the existing service. Where non-SSB/A viewers were used, they probably weren’t exposed to any in-depth testing, the skin / eyes / hairbase being used was / were NO MOD(ify), and thus didn’t trigger the alert (for example, I used a non-SSB/A version of Firestorm and Dolphin to obtain images for my various blog posts – however, I wasn’t using a MOD(ify) skin, etc., at the time and didn’t really test the non-SSB/A viewer to see what would happen when bouncing around SSB/A / non-SSB/A regions.
The issue is still being examined, but it appears that there is no risk of the problem propagating between inventories – it occurs only with the copy of the skin / eyes / hairbase worn, and does not impact the “original”. The issue was first noticed on library skins, and there has been no sign of it propagating elsewhere as a result.
LikeLike
Modifiable skin, hairbases and eye textures are very rare species of virtual fauna. In fact virtual historians and scientists everywhere should rejoice that pending changes to avatar rendering have quite by accident uncovered the existence of creatures long thought extinct. To think that if someone hadn’t been on an obsolete and by its own admission no longer supported viewer, many people might have remained unaware that such things as modifiable skin or eyes ever existed just boggles the mind. It stands as a sober reminder to us all that no tool, no technology and certainly no amount of warnings to update, or pleadings to update (from any source) or attempts to educate the public are ever going to be enough to protect humans from themselves.
LikeLike
Reblogged this on The Lionheart Times.
LikeLike