Darien Caldwell

After today's restart on LeTigre (sim of Borgbeef), HTTP-IN performance has dropped dramatically. Two prims talking to each other via HTTP-IN now takes 16-32 seconds to send a message from one to the other. Note that the HTTPRequest() timeout is 30 seconds so this often results in false failure results. Previous to the rollout, such a message would be transferred in 1 second or less nominally. This really breaks HTTP-IN.

I don't know if there's something wrong with this RC, or it's just that my sim is broken. But after Borgbeef (on LeTigre) rolled today, everything is broken. Mesh rezzed in the sim won't load, Friends list is stuck at (loading), It says I have 0 Groups, and I'm all grey. Can't Rez anything, etc etc.

Nika Talaj wrote: ObviousAltIsObvious wrote: .... thinknig more, are you using the linked prims set to different groups hack? maybe autoreturn still ages those linked prims in different groups, even if the root keeps them rezzed? Yes, I am! Thanks for the info about the change, that appears to be the problem. If I link two prims in this sim, the root set to group and the child not, wait 10 minutes, and unlink, the child disappears immediately. People have been using this trick for a long time. It seems to me that it would not defeat the intent of this anti-griefing change for script-rezzed objects to inherit the autoreturn timeout of the object rather than the individual prim, what do you think? I wasn't aware that linked prims HAD individual autoreturn timers! Can't think what use that serves. But thank you. The best solution is to put your rezzer in the land's group. Since you know the owner, and the object is allowed to be there (I assume), there shouldn't be a problem doing that.

This is a silly thread. A) you don't have to have land to enjoy SL. B) if you want land and are on a budget, get a premium membership. For 72 bucks a year you get 512m plot. If you need more, a Full sim on the mainland can be found for 100-300 bucks. (which is way cheaper than the 1200 bucks they used to go for). Land is actually cheaper than it's ever been in SL history.

I haven't seen anywhere that Maestro said there wouldn't be a roll. If you're going by the google calendar, it's probably that nobody has filled it in for the new year.

There's nothing more amusing than opening your daily digest to see two dueling threads: Server Side Baking Doesn't work: Period. Server Side Baking Works: Period. So I have to put a blanket statement in both. :matte-motes-big-grin-wink: For most people it works. I'm sure for some, it doesn't. But guess what is more likely to solve the problem if it doesn't work for you: A) complaining about it in a forum. B) actively working to modify your software, network, or hardware to solve whatever issue you have. The answer is B. However, I know, A is a whole lot easier. (and I guess i have to put something unique or it won't let me post again.)

There's nothing more amusing than opening your daily digest to see two dueling threads: Server Side Baking Doesn't work: Period. Server Side Baking Works: Period. So I have to put a blanket statement in both. :matte-motes-big-grin-wink: For most people it works. I'm sure for some, it doesn't. But guess what is more likely to solve the problem if it doesn't work for you: A) complaining about it in a forum. B) actively working to modify your software, network, or hardware to solve whatever issue you have. The answer is B. However, I know, A is a whole lot easier.

Cerise Sorbet wrote: For what it's worth, one of the biggest causes of group chat overload is being addressed. I dont' know what makes you think bots are the biggest source of "group chat overload". Nothing could be farther from the truth. They may be the biggest source of fraud and annoyance. But compared to all the real users of group chat that actually put 99% of the load on the group system, they are a drop in the bucket.

if you don't specify a physics shape for a mesh upload, a default convex 'shell' is used to approximate the shape. This shell is the smallest shape that can encompass the mesh. It's basically a sqished sphere. So for a 'floor' that is square, it would look like this: Already you can see where this is leading to a problem. If you tile several of these together you would get this: So for anything you're going to be walking on, or anything you need to have an exact physics representation rather than an approximation, you really need to specify your own physics shape at upload.

The viewer usese WEb for profiles, etc. and those are run in a sub-process called SLPlugin.exe. There should be 3 instances of SLPlugin.exe running after login. If there is not, likely something is blocking it. Be sure your antivirus/firewall allows SLPlugin.exe to access the internet, etc.

I'd suggest you try the viewer found here: http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers The one labeled "Second Life GPUUpdate Viewer version 3.6.11.283787" Support added for the following gpu families: Newer NVIDIA GTX 700 series AMD R7/R9 Intel Iris Pro IT's less likely the problem is windows 8, and more likely the viewer isn't supporting your GPU driver. So this 'beta' viewer is meant to correct that. Worth a shot.

Too bad it turns out any alt can simply buy something with L$ and become PIOF. So now all they have to do is, give their throwaway alt 1 L$, buy a 1 L$ demo, and tada, they are PIOF and can open a store. This makes the new 'restriction' without any teeth whatsovever. Payment Info on File should mean just that: that they have a Credit card, Paypal or other form of identifiable payment associated with the account. Making PIOF just mean they spent an L$ someone gave them makes it useless as a protection.

Email is basically a relay service, the mail can jump from server to server until it reaches it's destination. LIkely some server along the line got backed up and held the messages. It's rare, usually emails reach their destination within 5 minutes, but it can happen, they get delayed for days because of some server along the line doing this.

I use Emails to SL almost daily, and they have been working fine for me. I can say, years ago, I had problems, and ended up finding out it was due to my email program. SL can only accept Emails in plain text format. If you're sending emails in a HMTL format, they will be rejected. So be sure to check what format your email program/service is using.

And probably compounded by the fact RCs didn't get a restart this time around.

Definitely not my experience. All/any changes to clothing layers etc, appear within seconds.

Bunderwahl Guisse wrote: I dont really think the only or best option is fixing the carriers.. that is just not likely to happen. What we know for the people with this problem is the following (these may vary a little from one to another): 1. Sl performed well before sunshine. 2. It may work again for brief periods 3. All other aspects of SL still function, most importantly downloading of other textures 4. Sunshine "broke" something for them and they do not receive the baked textures. What this seems to suggest is that it is not the texture or the connection causing the problems, it was a change in delivery introduced with sunshine. All sunshine does (correct me if I am wrong) is bake several textures and sends one, instead of sending all and having the users machine bake them. I would guess this helps performance by having the server send less information and people with older machines rez faster. What is different about the baked textures and "ordinary" textures that you can still get the latter? A texture is a texture right? Why can not the baked texture be sent like all the others? Well, that's not the only change that came about in this time period. There have also been a lot of work (by Monty, no conincidence) to streamline HTTP communications, like reducing the number of simultaneous connections, using proper HTTP headers, using Keep-Alive connections, etc, and that work is ongoing. While, it's probably good to make SL adhere to the strictest of HTTP standards, the reality probably is, most of the rest of the Internet doesn't always do so. So it's inevitable conflicts like this will arise. Personally, I have a feeling a balance will have to be struck between strict standardization and quirky compatibility. But it definitely sounds like in this case, wireless carriers are not playing nice.

Monty Linden wrote: @weetulow captured some packets which duplicated @Sarah's report. Capture shows a baked image coming back to the viewer with 'Content-Range' and 'Content-Length' headers in disagreement. If we were doing this consistently from the bake service, *every* viewer would be failing. This reeks of a buggy or misconfigured HTTP cache sitting between your viewers and our servers. So, first question of the reporters here: are any of you running a local HTTP cache (Squid, etc.)? With tethering, yes, it's unlikely you added one. We'll have to consider that your devices might insert one regardless. It may be the carriers doing this. Getting some action there may be interesting. Carriers for wireless services do a lot of strange, and sometimes improper things to traffic on their networks. It brings to mind the case when Nokia was found to be Decrypting HTTPS traffic to HTTP in order to 'improve service'. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799

Qwalyphi Korpov wrote: Perrie Juran wrote: Qwalyphi Korpov wrote: With the problems of group chat continuing year after year it certainly is irritating. I tried to review the LL efforts to fix things. Some parts I just couldn't find. Here's what I think has happened: 2008 LL acknowledges group chat problems and commits to fixing them 2009 LL makes some changes and while they can measure improvements problems continue. Here's a link to an amazingly detailed technical explanation http://community.secondlife.com/t5/Technology-General/Improving-the-quality-of-group-chat/ba-p/645117 2010 LL says fixing group chat is a top priority 2011 LL announces new group chat will launch by March 31st http://community.secondlife.com/t5/Tools-and-Technology/Technology-Improvements-for-Q1-Including-Raising-Group-Limit-to/ba-p/673513 2011 LL delays new group chat due to licensing issues. Then quietly never launches new group chat 2011/2012 (?) LL announces they have largely resolved all group chat issues. They are now rarely seen. I remember the announcement. However I can't find it now. Clean up of premature declaration of victory or poor search skills on my part? Are you perhaps thinking of The Large Group Issue in your 2011/2012 comment? That was related to the group members list never loading. It had side effects such as not being able to change group preferences (recieve notices, show in profile) and sometimes if I recall correctly made starting or participating in a group chat difficult. That problem has been fixed. No that isn't what I was thinking I remembered. That is a nice example of a problem that got fixed though. I am remember a blog post... I think it must have been one of those - that gushed about how work had been completed on the group chat issues. It claimed that the problems were almost never seen anymore. Not that they had been completely eliminated. Found it... Pasted below & here's a link: http://community.secondlife.com/t5/Featured-News/July-Update/ba-p/964435 ------------------------------------------------------------------------------------------ Group Chat Lag Here’s a little something about that right royal pain, Group Chat Lag. You know how it is: you’re inworld, having a ball chatting with a group of friends, but the chat shows up with words missing or in the wrong order. It’s like a bad roommate, always hanging around and making a mess, interrupting your conversations and ruining your jokes! Some of your friends won’t even try talking while that loser’s around, knowing that their impeccable comic timing will come out looking like free-form poetry. Except, for some reason, we don’t see that dude around much these days. Was it something we did? We’d say that we’ll miss the old Group Chat Lag, but that would be a total lie. Instead, as the saying used to go: “door Don’t let the hit you in the butt on the way out.” ------------------------------------------------------------ Whoever said that clearly never spends time inworld chatting. The out of order stuff still happens, all the time. So does everything else, including chat never appearing, chats closing due to failure to initialize, and every other issuse since I started in 2006. Every so often LL will do something, and it will improve, breifly. But over time it just goes right back to being as bad as it was.

Amethyst Jetaime wrote: When something goes wrong they may not know what the problem is at first. Personally I'd rather they fix it than worry about having to give explanations when they do find out. When something goes out in RL, the utility company doesn't call me up and explain the technicalities. LL is under no obligation to tell you squat other than what they have. Quoted for Truth.

Or go to Oz Linden's office hours inworld and bring it up. Times and locations can be found here: http://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups

Ayesha Askham wrote: Dezy One thing that jumps out at me straight away about your settings is the bandwidth: 1600 is quite high. If you are optical fibre hard-wired, the maximum recommended is 1500. If copper wire 1000 and if wireless, regardless of what is downstream of the router, 500. Now that may not make much of a change but it will almost certainly reduce your packet-loss, which might reduce your perceived lag and building issues. I don't know who started that superstition about Bandwidth, but it's pure nonsense. You should set your Bandwidth as high as your connection will allow, with some buffer for other applications. If you have a 1,500 kps connection, then sure, setting it to 1,000 is probably ideal. But if you're like most with a 3,000 to 25,000 kbps connection, 1,500 is fine, and even 3,000 is recommended for the high end. Sadly LL used to allow as high as 10000 for bandwith (which was great for us ppl with 25,000 to 45,000 kpbs conenctions), but no loger allows that high. The generic formula is connection Speed X 0.66 = Bandwidth Setting. And in case you need to convert, 1 MBPS = 1000 kbps. So if it's a 1.5 Mbps connection, that's 1500 kbps. In short, go as high as you possibly can, but don't choke your connection. You may have to play with the setting to find what is best for you.

Thanks for the explanation, because it was really confusing to me as well. I guess this is a small part of the coming group banlist changes.

CoolVL has supported SSB since version 1.26.4 which came out back in july. However, it's best to get the latest verssion, as many bug fixes have been added since then.

You can always count on people to **bleep** and moan, no matter what.