Oz Linden

Improved region crossings is one of our active projects right now; it may take a little time to get out to most of the grid, but we've got some promising-looking changes coming.

Yes, we'll continue to add to LSL. llName2Key is being tested now on parts of the Beta grid. Permanent storage is already available for scripts that are part of an Experience. Most likely, really powerful new additions (anything that imposes a significant cost to provide or that has high griefing potential) will also require an Experience. Bigger scripts are a personal favorite feature of mine... but I can't be sure when we'll be able to get them on the roadmap.

That is usually the result of one of a couple of bugs in media handling, but a request that any sounds at all from outside the parcel would make a good Feature Request.

I would personally love to do two-factor authentication. At the moment we've got some architectural challenges that we've got to work through to make that possible, but we're working on them. I hope that when we do it that most people will use it.

Open Source... we continue to solicit features and fixes from open source developers, and don't plan to stop. Sansar tech back to SL... the way the two are built are pretty different, so bringing improvements from one to the other is usually more a case of reimplementing than just copying. We did recently poach an ex-SL Sansar developer to come back, and he brought some pretty cool rendering ideas back with him... High hardware demands vs user hardware... well, we're just trying to be really clever about it. We're committed to supporting as wide a range of hardware as we can, but getting a good video card and a lot of memory are certainly good ideas. What SL content are we surprised hasn't been created ... I expect that if I named any, someone would point out that we've had it for years (I know - it's happened many times).

There are not at the moment, but it's a Feature Request we might do - please submit it.

That would make a good Feature Request jira (and one we could probably do without too much trouble).

We'd like to fix that. We've got some simulator changes in the development pipeline now that might help, but they're not quite ready for testing. In any event, they probably are not a complete solution, but we'll try to keep at it.

Adding substantial data structure support to LSL at this point isn't a very high priority; I think we've got ample existence proof that people can do pretty amazing things without out them. That having been said, there are other things we'd like to do to make LSL more powerful, but other than a few new functions we don't have anything big on the road map for this year. Access to Avatar Complexity would be relatively easy - please file a Feature Request. Some support for redelivery is among the things we'd like to do for Marketplace - we're trying to hire a developer for that - tell your friends.

I'd be interested in hearing what specific changes would make a "real" first person mode. Submit them as Feature Requests in Jira, please. We're working on a number of improvements that we are optimistic will improve framerate for most users. I'm not familiar with "vector copy" - another good candidate for a Feature Request. The chat window does support "compact" mode, and can also be set to be largely transparent. Moving it (and other floaters) outside the main viewer frame is something we've discussed many times. It's a big job; while we have some ideas on how to do it, at the moment it would mean not doing a great many other things. We'll try to get to it eventually though.

I'm not sure I buy the 95% number, given how many people run it... but in any event, we have an active effort working with open source developers to bring the Linux viewer up to date. Grid scope experiences are on the road map for this year. Unless we are very very close, we prefer not to set expectations for release dates of anything - SL is so large and complex, and the number of unexpected events that can occupy developers for a time so large, that we have not found that we can accurately predict very far in advance.

At present, there's no way to read any HTTP headers from an http_response event. The header value is useful if your request is from an outside web request, though. The throttle allows many requests per second (no, I won't tell you exactly how many because it may change and we don't want people trying to see if they can get in just under the limit) to the scripts owned by the same owner in the same region. A good general strategy is to wait a few seconds (possibly with a little randomness added in) before retrying, and if that fails increase how long you wait by multiplying by a small number before retrying again. If all your requestors follow some method like this, eventually they'll get through.

I don't recognize the exact text, but it probably means that the rate of inbound HTTP requests to objects in the region has been exceeded. We don't document the exact value because we don't want people to try to "get the most we can without hitting it". The 503 response has a Retry-After header that tells you how many seconds to wait before your next request. However... right now, the throttle is applied to all scripts in the region. We are looking into two changes (which are currently scheduled to roll to a small RC this week): The limit will apply to all scripts in the region owned by the same user. This should prevent your scripts from being throttled because of requests to someone elses scripts. The limit will be raised slightly for Skilled Gaming regions (because of the first change, the increase may in practice be quite large). We have baseline stats on how frequently this error is occurring now, and will measure how that changes as it goes through the release channel process.

It should already have increased. It's possible you'll need to relog to see it in your viewer...

That happens if some part of your current avatar was not valid or failed to load. It's possible (but should be very rare) that could happen because something took a very long time to load. It's possible that something had changed while you were away. If it happens again, save your SecondLife.log file and post it in a bug report.

I've been doing that for most of 8 years... feel free to come by Open Development User Group and we've got other User Groups

I'm delighted to hear that it's working again, for whatever reason. I really wish I (or even Linden Lab) could take the credit. I certainly hadn't made any changes yet (though I had contemplated some). Maybe someone else did something, or maybe not... Here's hoping that it continues to work. Thank you for your patience, and for your 13 years in Second Life!

Contrary to popular opinion, we do read these. I flagged this for attention yesterday (a Linden Lab holiday), but am just getting to it. I'll make an effort to help sort this out, but let's please eliminate the counterproductive finger pointing and hostility in all directions. We've made a number of changes to how and when we send email, including changes to some of the software used for postcards. These changes are motivated primarily by the fact that email from SL has in the past often been filtered and discarded or rejected because it was sent incorrectly or to bad addresses. We are trying to make it as reliable as email ever is by upgrading nearly everything about how we do it (and by the way, our internal data shows that that is having a very positive effect). The changes will continue for some time. If something we changed broke Typepad posting (and I have no reason to doubt it), then we'll have to find out from them (presumably through you, Prokofy) why they are not using it. It is said above that Support claimed that our mail sending is now more standards compliant; this is true, but it's still possible that we could do something to help Typepad understand it if we knew what was giving them trouble. We make strenuous efforts to test our changes for backward compatibility, but the universe of things that Residents do with our product is far far too large for that testing to be comprehensive.

The "Darn, you have been logged out..." message usually means that some part of the communication between your viewer and the simulator has been blocked. If you're not having problems with other programs, then the most likely culprit is that some firewall feature on your system is blocking the viewer.

Thanks for the detail, Prokofy. It isn't our intention that SLURLs would trigger the update check; we'll fix that. Some of the other cases you mention are harder to explain, especially When crossing sims When teleporting between sims (after you arrive) from a landmark or someone's sent TP When you are just flying around inworld on one sim. but I'll alert our QA people to be watching for those. If you can narrow down a specific circumstance, by all means let us know.

Our viewer doesn't have that message anywhere. It would help if you described the problem very precisely. One of the changes we made with the new updater is that it is only supposed to check for new viewers when you first launch, and for any optional upgrade it silently does the download in the background so that you're not bothered by the option until the new viewer is ready to be installed. If what you're seeing is the new updater, then it's running when it shouldn't.

From the System Requirements page: if for some reason you really can't upgrade your OS, for some time there is a viewer available from the Alternate Viewers Obsolete Platforms page on the wiki that may work for you, but it will get no updates for new features or even for bug fixes.

Please create a Jira bug report for this Create a bug How to report a bug In particular, please include the SL_Launcher.log file from your log directory with your report.

Please file a Jira for this: https://jira.secondlife.com/ Look in your logs directory and see if there is an SL_Launcher.log file and/or and SL_Launcher.old file; if they are there, please attach them to the Jira.

A jira would be welcome. Be sure to specify the site that you're having a problem with. It may be that we need to update the Certificate Authority roots in the simulator.