Jump to content

Carol Darkthief

Resident
  • Content Count

    51
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Carol Darkthief

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.)
  7. 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".
  8. 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.
  9. 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.
  10. Even in California, it has stopped being Sunday, so I am not astonished that things have improved.
  11. 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.
  12. 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.
  13. It's probably a coincidence, but I'm seeing a better connection now. There are still bursts of high Ping Sim, but they are much smaller than they were. They may be related to events such as the arrival of a new Avatar in the region, but I wouldn't lay a bet on that. I am seeing some of the same when I teleport, and maybe a very short burst of packet loss.
  14. Thanks, Oz. That clears things up a lot. Knowing that Ping Sim is UDP to the region server does eliminate a lot of my guesswork about the high Ping Sim readings I see. May I suggest a revised wording for the description in http://wiki.secondlife.com/wiki/Viewerhelp:Statistics Ping Sim: How long it takes data to go from your computer to the region sim server you're currently using. This does not reflect texture and mesh loading through the CDN service but measures UDP communication to the sim server itself and is affected by both by the internet connection and the load on the server hardware. It will normally be higher than an internet ping or traceroute time to the same address. I have seen claims, some rather old, that combinations of UDP and TCP traffic on the same link can lead to problems. It doesn't matter where the CDN server is, it's all going to converge on my broadband connection, but the telco engineer vans are exhibiting breeding behaviour in my part of the world, Maybe something will suddenly improve.
  15. And the DNS problem did get fixed by using a different DNS server. That still doesn't sound like the ISP messing with the modem the customer is using. There's a chain of DNS servers between the ISP's DNS server and whatever server is "authoritative" for a domain. And I've known that chain get a "bad" mapping between domain name and IP address when something has changed at the authoritative server. It takes time for the change to propagate. Maybe an ISP is running a DNS server with too long a TTL on the DNS entries. A quick check on the Wikipedia entry on DNS shows a link to a report on Slashdot but it was ten years ago. That old claim does seem to linger in Google searches, and it would explain some things. But, unless Linden Lab are changing IP addresses very frequently it wouldn't explain anything I see. That sort of thing would cause a lengthy total fail, and I've never seen that for Second Life. It is something I have seen in the past for other services. And the fix of trying the Google or OpenDNS servers makes a very obvious difference if the ISP's DNS server were doing something weird. It's not the place for solutions, but I do know what the scary devil monastery is. And sometimes Second Life and Linden Lab do seem to need a LART.
×
×
  • Create New...