Carol Darkthief

I measure distances in Light Fortnights. What are you people wittering about?

Summary from Europe: internet speed a little down, internet ping good, similar speeds to SL, other US locations, and Europe. Reported log-in number was lower than the recent usual by about 10% but has started to rise again. Was able to log in OK, SL stats are looking good. In my experience, systems are a bit sluggish when they get over 45,000 total logins.

There's truth there, but how do you tell who is a "regular group member"? Even in long-standing help groups, that's difficult. On what I have seen of this year's SL17B groups, even the "official" post warning of events have been spammy in style: multiple lines of uninformative "decoration", and little or no information about about what style of music the DJ or Live Performer is presenting. They have not done a good job. The only event which piqued my curiousity enough to lure me into one of those overcrowded, viewer-crashing, lag-fests was almost invisible in the published calendar, and I would have missed it if one of the performers hadn't done his own promotion elsewhere. Two more days... If I want music I can watch recordings from Glastonbury on the BBC

That's worth knowing, but the big textures quadruple the download, add to the cost of locally generating the mipmaps, and hit local storage and caching. It wouldn't encourage me to buy a product (and too many have permissions settings that block access to the pixel-size info, so even Demos are of little use). Not all the textures even need to be 512s. How close do you have to get your camera to an eye before you see a 512, never mind a 1024? We don't all have super powerful modern computers, but too many creators and pundits assume we do. Would it be so hard to supply a low-power version of a BoM wearable.

I have a mesh body that has that neck feature, and a few other features that may be problematic. I was using your Cool VL Viewer, which I keep on my system as a sanity check, and I think I shall wait and see if experienced Creators can get Bakes-on-Mesh working. Seeing some of the things they do, I don't feel optimistic. The particular mesh body also has overlapping sections. They map OK to the class UV map, but there are panels which are distinct, such as the front, sides, and back of the upper body, which overlap. It's one row of quads (which each comprise two triangles), I suspect it avoids problems with gaps at extreme shape settings, and the body looks fine with the pre-Bakes-on-Mesh tech. But go Bakes-on-Mesh and you get all the seams showing, internal to the upper body and at the upper-lower boundary. I do wonder if the Lindens responsible really knew what they were doing. Or was it whoever set the test criteria? Another reason I wonder about the Lindens is the 1024 textures on those freebie outfits for SL16B.

I have a feeling that a lot of connection-related problems could need different answers now that so much has moved from UDP to HTTP, and there is the CDN. What does the "Bandwidth" setting actually control? What effect does the CDN have at my end of the connection? Can that traffic mess up the mostly UDP command and control traffic from the Server? That's certainly consistent with the horrible warnings I find else-net, but I don't know the details of just what you did. (You personally and the Lab as a whole) I sometimes find myself wondering if I am even asking sensible questions.

I just tried checking that page. I could tell it was bug SVC-22 which must be really really old, but the JIRA system seems to be unusually hostile this morning, throwing unclosable pop-up windows at me like a cheap porn site.

I see you got things sorted. That error message looks odd. I think I would have tried a reboot of my system, to clear up any lingering elements that might not have closed. And that might be behind your problems. If the program wasn't properly closed, the update could have fallen over. Rebooting your system is one of those catch-all fixes. And, like all of them, it tends to dodge "what went wrong" questions. There are other ways of fixing a program that didn't close properly, involving Task Manager and such, but the details get hard to explain.

Anti-virus software varies in things like false alarms, but don't remove what you have. I'd disable it after downloading the installer, manually run a scan on the installer, and see if anything is flagged. A Linden Lab download should be safe, but if anything turns up in the file, let us all know. There are false positives, but the Lab might have slipped up. Then install without the anti-virus active. I'll go along with the other commenters about installing from scratch. You shouldn't really need to but sometimes it can make a big difference. And it is one of the standard problem-cures which can work without having to know what is wrong. I know the Firestorm crowd have a web page on doing a Clean Install which tells you where things such as chat logs might be, and how you can keep such things safe. There may be something on the SL Wiki too. Folder names will differ for different viewers—a quick check suggests "SecondLife" can be substituted for "Firestorm". In my experience, a Clean Install isn't as vital as some would say, but when things get like this it makes a huge amount of sense. It's like rebooting your ADSL-router, an easy no-thought answer that can make a difference. And at times like this, why not? (And a part of me says you don't try every fix-it trick at the same time, because you never know what really fixed it.)

I know you're correct about the cache clear option, but "bake fail" is starting to look like another catch-all problem answer. Some of the standard answers even look as though they could fix a range of problems that have nothing to do with the SSA system. Reboot the router-modem, Log-out and log-in again. How many other things will those fix, but it means the problem is confirmed as a bake-fail, and so "resolved".

Firestorm uses RLVa. So do most other viewers that are RLV-compatible. The differences are slight, when you look them up, and Firestorm is reckoned the most widely-used Viewer. One I noticed was a restriction on channel numbers used, to avoid an LSL restriction on message length. I think if I were writing code, I wouldn't want to be caught by the difference. The combination of slight changes and widespread use tips the balance towards RLVa.

I have sent you a Landmark in-world. There's a whole sim called "Lolas" with the in-world store. You may need to check the age-rating you have set for searches.

Even in California, it has stopped being Sunday, so I am not astonished that things have improved.

That sounds a little bit different from my experience; it seemed to be the SSA that was the chief problem, mesh attachments next, I didn't see any problems with prim attachments. I shall give things a try in a little while, I have one or two RL things to do first. I do recognise a couple of names here from the chat logs I have from Sunday. It's a long time since anyone threatened to pay me for my internet knowledge, but I have been known to get down and dirty with the internet protocols, especially DNS. This situation is easiest to explain through problems with the SSA servers or the Linden Lab network, rather than a wider ranging problem that was likely to be affecting other services sourced from the Phoenix area. But it isn't always easy to see the difference.

There seem to be a lot of reports of people in the UK having problems loading avatar textures. I has been affecting me. Nothing seemed to be wrong on the UDP side. Viewer-reported Ping times were normal and there was zero packet loss. Attachments and scenery in general were loading textures without problems, which means the CDN network could have been hiding any intermediate problems. A traceroute to community.secondlife.com confirms a Bay Area location for this server I am typing into, and very different routing. A traceroute to the sim server shows routing over the Level3 network between my ISP in London and Phoenix Ping times and a Speedtest to Phoenix give me results in the usual range. I am not sure how a network fault could be affecting just one sub-class of HTTP traffic between Phoenix and London. Some textures eventually loaded, but a wait of over an hour, with no changes from trying to force a texture rebake or from relogging, leaves me thinking that the problem is in the Linden Lab servers. But why does it seem to be only affecting one part of the world? I am badly out of date on this networking stuff, but I would urge you to check the SSA Servers. If it's a network problem I can't see how it would be blocking one particular texture every time, but with only four "baked" textures that still could be chance. If it is a network problem I would expect it to be affecting other traffic to the Phoenix area, but how can I check that? Ah, Flying Buffalo Games! Their website loads OK, but I am not sure if their server location is anywhere near their postal address. Can folk, if they have similar problems, do a traceroute to check which provider is carrying their data to Phoenix? It can take a little Googling to pin down the name, but there will be at least a clue in the server names involved. I'm not sure, I only read English, if anyone elsewhere in Europe is being affected. Likewise, if the problem is between Linden Lab and the transatlantic cable, it might be affecting some people in the USA. Also, from past experience, I know that ywo supposedly independent network providers can end up running their data along one small cable duct. There was one time when a flood took out a bridge, and two completely seperate connections to the USA went down.