arabellajones

Kuula was very bad on Sunday, the server apparently crashing rather often, though restarting quickly. One very obvious check would be to take if off the Snack RC. That wouldn't tell you if the problem was the Snack RC code, or the overloaded hardware that Maestro only reported in the BUG-7444 Jira entry. Or is that too obvious?

So, when I ask about possible changes to what Linden Lab is doing, which appear to be, at best, unreliably documented, you ignore all I ask about, dismiss it as a rant, and dump a load of hlepy answers on me that blame somebody else for everything. I can only assume you don't have an answer.

"more options for support" turned out to be pretty damn useless. And, while the stipend does fill a lot of the gap, does it really make sense to buy L$, by any means, when general SL performance has slumped as much as it has appeared to from here.

Second Life seems to have gone badly downhill since the summer, particularly with sim-crossing problems. But very little is said about the changes. I know my ISP, in the UK, makes special provision for games traffic, trying to provide a clean connection. Second Life has been on their list for several years. But, if I have problems, they expect me to use one of those rather frightening traffic logging tools, something called <i>Wireshark</i>, which I admit I find pretty intimidating. They will check and interpret the results, not me, and they can tell what packets are being missed by their high-priority system. But has anything actually changed? Well, there's this CDN malarkey. They'll be seeing a lot of traffic coming from different servers, and I am not sure which domain names, or URLs, might be missed by their filters. I've been trying to find out when the testing started, but it looks as though my problems started some time before that. Another claim I have seen, with zero mention from anyone else, is that all the SL servers are now in Phoenix. It was something TPV developers were told about at one of those meetings, or so they say. All I can say is that over the last six months I started seeing some odd behaviour on connections to Phoenix. My ISP seems to have a fairly direct connection, but Speedtest reports some rather slow speeds and ping times. There were a couple of times when SL servers in Phoenix seemed to vanish. Which is one reason why I am a little reluctant to believe it. Again, no date, though I infer from one or two things that this happened no earlier than the second half of September. The only definite source I have is http://wiki.phoenixviewer.com/fs_speedtest which describes how to test connection speed to set the capacity limit in the viewer. The only date is when that page was edited, which is very recent. But it tells people to use a test server in Tucson. For a while, back in August, there wasn't a test server in Phoenix. It was one of those bad times. So it could have happened long before that page was edited. Of course, it could be the Viewer I am using. But everybody seems to want to blame somebody else. "No, there are no bugs in Firestorm", and now most of the problems I asked about are on the Firestorm bug list. I only found out about that because somebody happened to report them being mentioned at a TPV Developer meeting. I am still a Premium member for a few days. I don't plan to renew. Just what was I paying for? And this really is your best effort? I feel I wasted my money.

Oh I checked that domain name for ping time. Varied between 35ms and 65ms, depending on time of day, which suggests a CDN node in London rather than some other part of the UK. Tests I've done to other major UK cities don't show that pattern. I don't know how you can get the 12ms you claim. The Stats window in my viewer is consistently showing 190ms to 220ms ping times, but that's not strictly comparable since the data packet sizes will make a difference. So CDN should improve things but, as a fancy caching system, there's some potential for it to interact badly with the texture caching done by the viewer. It's a multi-level caching system, and with the cache search times coming into it, the optimum cache size for the viewer cache may be different. The Lindens may be doing something rather new and clever: SL has so much user-provided content that experience with CDN tech in other "games" may be misleading. And, over the years, the idea of a Linden doing something new and clever has lost its appeal.

I think Wolf was pointing out how amazingly low a 12ms ping time is to anything. I think I'd rather have a stable 200ms ping time when I enter a new region over over the sort of behavior he reports. I can work with it when I'm flying a plane in SL. An unpredictable multi-second delay is scary-bad. And now I am wondering if my viewer has been deciding it has lost connection with SL because of that. Is the burst of fast traffic messing up other necessary traffic, such as command-and-control signalling? And I need to check if my ISP knows about this CDN stuff. They makes specific QOS provision for Second Life as something that depends on a high-priority connection. But if they're using IP address blocks, are they seeing the CDN traffic as part of SL?

Finally got through it: the problem seems to be a badly-scripted pop-up window which blocks scrolling and zooms in so that the bottom half of the pop-up is invisible and the lack of scrolling makes it inaccessible. Summarising what was going wrong, the Snack RC is a small-scale server-beta test channel, and Kuula was one of a number of very busy regions all put on the same physical hardware, overloading it and leading to problems apparently unrelated to what Snack RC is trying to test: how is something like "About Land" related to texture fetches? When you cannot get onto the region, there seems to be no way to find out the server version involved. The Wiki page on the Snack RC is badly out of date: http://wiki.secondlife.com/wiki/Beta/Snack This web page tells us what the Lindens are doing: http://wiki.secondlife.com/wiki/Server_Beta_User_Group The Snack RC info describes it as an ongoing test, with no start date given, making it difficult to decide if an ongoing problem of the sort that Kuula has been having is related to the Snack problem. It looks like several of the commonplace Linden Lab problems, including... Inadequate documentation maintenance, leading to misinformed users and support staff, all wasting effort on irrelevant dead-end problem solving A test sample which is clearly unrepresentative of the Grid as a whole, suggesting a wider-scale inadequacy of testing. The use of a programmer time management system as the primary method for users to report problems. Depending on certain info about problems which certain problems make it impossible for users to provide. The general problem of helpdesk systems that it is a temptation to blame any new problem on somebody else. For SL, it always seems to be the "connection", and since my viewer has been reporting sometimes horrible ping times when in a Snack RC region, it can be plausible. (But people were screaming "connection" without even asking what the ping time was reported as.)

There's something really broken about that link. I can see the JIRA page is there, but most is covered by apparently unclosable pop-up windows. It may be a browser-related problem, but it looks as though something wants to install software on my computer. New JIRA version seems to be part of it, but my AV software doesn't like it, whatever is going on.

So that's what "capabilities" are? Is there some place I can find out what the various error-messages mean? They look about as useful as Cold-War era weapon codenames. "Support, I have had a Red Flag error message with the code WE177."

Since this is the first I have heard of this, I remain unconvinced. If it needs special settings from my hardware or software, either viewer or firewall, nobody has bothered to tell me. This is either more Linden incompetence, or another "not our problem" response. Why should I trust you?

I have decided to stop paying for Premium Membership. I get nothing of value from it.

I have just been bouncing off the sim boundary when trying to enter Kuula region Error Message: "Second Life: Failed to grant capabilities" All contents of the region are visible. Map indicates 10AVs are in the region Teleport attempts fail with a similar message (in a form I cannot cut-and-paste). Sim crossings at nearby boundaries succeed with no problems. Since I cannot get into the sim I cannot tell you which code version it is running on. Kuula contains the main NCI facility, one of the places which new residents are invited to go to when they complete orientation. And according to all the tests I can run, I have a very good connection. I have rebooted my modem. I don't use wifi. I figure it's time for somebody at Linden Lab to do their job.

That is one of the things I tried. It doesn't seem to exclude anything. But thanks for trying.

I am struggling with the marletplace search. I was looking for free or cheap Skins to help a newcomer to SL. Is there any way you can exclude Demo items from the search? It doesn't help that the search apparently looks at both the title and the description.

The Lindens already keep track of Stipend so it can't be directly converted to real money. It has to be done through a distinct account. So a chunk of extra L$ as a Premium Benefit wouldn't break things. I'm still trying to figure how to get the thing to move. I can fire the cannot, but nothing sets it moving. Is that a side effect of it being so big? It's a stupid design. All it can do is drift downwind. Real sailing ships depend on water and wind acting differently.

Sorry, Mr. Linden, but I already know a guy in Second Life. He's polite and well-behaved in public, and what happens in private is a lot of fun. It helps that our local clocks are compatible.

I've seen it claimed that Mesh skills will still be usable. because the importing is in an industry standard format. Even if the rigged meshes have to use a different skeleton, this skills won't change. But I have also see reports of other ways of doing 3D rendering, whih don't use anything Mesh-like. There are reaspns for a change. There are different ways of doing things. Other providers have shown that. There are limits in SL which come from the original design decisions. And is the SL Viewer really Open Source, with things like the physics library? This is a bit more than what hapened when the Viewer changes major version number. But, struggling to get around SL11B though the lag, I have wondered if SL has reached the upper reaches of a signoid curve. We've had big changes in my time here, but the rate of obvious change has slowed. I doubt anyone can reallyget anywhere by throwing hardware at the problems. SL might have become a little too complicated. I am sceptical whether Linden Labs can innovate and come up with something that succeeds as SL has. But they know more than most about how user-created content and the people interact. And in the end, all the innovation from LL, or whoever steals their lunch, is nothing without us. SL exploded across the world on the back of broadband internet. We've had big changes that are nothing to do with Linden Labs, and which have been exploited in sometimes crude ways. What comes next has to match the visual quality of SL, and of the consale games, while still having room to develop. SL has succeeded partly because the developing technology was able to give us the room. I am not sure that the next ten years will give us the improvements we have been able to use. I cannot expect my connection to increase its capacity a thousandfold. I cannot expect the increases in processor speed I experienced. LL are going to have to do some smart stuff. Can they?

Almost midnight, SLT, and the Status page still reports the Main Channel server maintenance as in progress. Either something has gone sadly wrong, or somebody is careless about reporting. There's the usual announcement of a planned start at 3am, an actual starting message at just after 7am, and nothing since. And in-world there is some laggy behavious affecting mesh objects and textures in general.

A lot depends on the operating system your computer is using. For example, there is Windows Firewall, which is accessed through the Control Panel list in the Start Menu for Windows 7. You would need to check that the correct version of SLvoice is allowed access, so you need to know where your viewer program is. That seems to be something that no firewall software handles well: yopu have to look for yourself and take notes. It's all a bit intimidating. It doesn't help that some changes are being made, a new version of SLvoice and all the hassles that can bring. I'm having some more general problems this morning, what looks like a bad connection, and it needs a bit more knowledge and experience just to check things. But I am getting the same error message as you, and a few others.

The new Mesh AVs for the new residents to choose are a real curates egg. But the No Mod shapes are solidly in the badly proportioned mould of all newbie AVs since SL Year Zero. Not everybody in the real world is a supermodel shape, but the Lindens can't even manage to get that standard right. They need lessons. Time for a Kickstarter?

Fitted mesh, so the clothing components should work with an ordinary non-Mesh AV, and they do come with component specific Alpha Layers to make that possible. I am seeing something seriously weird with the UI processes needed to use Alpha Layers from these new Library components. Try figuring out how to "Add" those Alpha Layers from the inventory window If this is how screwed up the UI is for working with other Fitted Mesh, no wonder the customers hate it.

A couple of things to think about, based on my own experience: 1: Cooling fans You don't mention the CPU heatsink/fan, and it may be included. My case has a vent in the side, which delivers air direct to the CPU fan. I also use an outlet fan just below the PSU. Whatever size the ports in the case, use the largest diameter that will fit. If you have to fit the CPU heatsink/fan remember the thermal grease. A thin smear, no more, to bridge the gaps left by slight surface unevenness. 2: Expansion slots Apart from the graphics slot, you may not need to add anything else. But adding a graphics card often blocks both the PCIe slots. The usual two PCI slots can be useful, perhaps an add-on sound card, but they are looking slow for some purposes.

Sorry, I cannot quite figure what this bugfix on Magnum is for. I have been seeing some horrible sim-behaviour at some events. with plummetting sim/physics frame rates, bursts of packet loss, and extended ping times all reported by the viewer, and I suppose this all could be the "networking-related issue" of the bugfix. But I am not the highly paid computer professional that some people in these parts are. Reading a JIRA makes my brain hurt, I read and write English, not BASIC, or whatever it is you guys use. Just what is going on?

Thanks, that looks useful. I know that many of the sliders will affect a rigged mesh without the hassles of going for a fitted mesh. Things such as limb lengths.

I know that, before fitted mesh, there was a standard set of mesh sizes. and there's still a lot of these on the Marketplace. The available help seems to have dropped all mention of this system. I've also seen on the Marketplace some sample shapes, but can I trust them? Is there a reliable source for the shape settings, so that I can tweak my avatar shape to suit them. It's fairly easy to manually copy the body shape details, although the volme of head/face data is intimidating. I would take the shape I usually use, leave the head/face unchanged, and shift the rest of the shape-sliders to match a standard shape. But where can I find the numbers? (Slight grumpiness: The Knowledge Base is horribly confusing to me on the problem of finding mesh clothes that fit.)