Oz Linden

We retired those mailing lists in April; I sent a message to the lists on April 7th announcing the upcoming change and suggesting that this forum be used instead.

This should be fixed on most regions now, and all regions after todays RC roll has finished.

It'll be back pretty soon as a normal RC viewer

I messed up the quoting on that reply... I meant the 4 corners region setup for large events. No, you can't run your own server, sorry.

We do this all the time; it works well.

I suggest just adding a line that shows you what you're passing as the url. My guess would be that one of those values you're using to construct it has a bad character in it.

The build that the group date problem was found in was the same one that made name changes possible. I don't recall whether or not we discussed blocking that release because of the group notice date problem, but I suspect that if we did we'd have decided that getting the name changes out was more important. We do normally weigh regressions fairly heavily, but everything is a tradeoff - there are few hard-and-fast rules. In general, even a fairly important problem normally takes a couple of weeks to get from the developer to the main channel on the grid. Even after the fix is coded and tested by the developer (the time for which can vary quite a lot), it has to go to QA to be tested and the build has to get a general QA pass to look for regressions; depending on what else is in the queue (more crowded than usual lately due to uplift-related work) that can take from a day to a few days. After that, it goes into an RC channel on a Wednesday. Depending on the level of risk we think the build has (based on what changes are in it), that might be a tiny channel with only a few regions in it to one that's a substantial part of the grid. If it's a riskier change, then after a week in a small channel it will normally be bumped up to one or more of the larger channels and will spend at least a week there. Normally, only a release that's been in at least one of the larger RC channels is eligible to be promoted to the main channel (at the same time, those changes are merged into the builds for all the RC channels, so at that point the change is everywhere). The decisions about what builds should go on which channels is handled by a team composed of representatives from Product, Development, QA, Operations, and Support; it's never any one person.

One of the current Release Candidate viewers is specifically focused on an improved set of camera controls, including a way to save and quickly switch between multiple settings. Try it out

The problem has nothing to do with how SL scales; it's that we have only so many server boxes and so much space in our datacenter to put them in (our servers are located in a facility in Phoenix; none of them are in corridors or under desks 🙂. In theory, we could buy or lease more, but we'd have to find new space to put them in (our current space is full), get the network set up to that space, etc. Since we expect to complete our migration off of our own servers onto cloud systems in a relatively short time, it just doesn't make sense. The sharp rise in demand for regions we've seen recently wasn't something we could have reasonably anticipated. Moving to cloud servers will, among other benefits, mean that should we have similar fast increases in demand in the future we'll be able to just sign up for more systems and we'll have them almost immediately.

We have enough to have spares to replace any that develop problems. With as many systems as we use, that’s sure to happen from time to time.

I imagine that one could do that now by projecting the stars from a RL source onto the interior of a big sphere rather than on the sky itself. But maybe if some educational institution that wanted a bunch of regions put that on their list of requirements, I could get the project prioritized 🙂

You might want to try a couple of things: Have your friend who hears static check the volume specifically for you and make sure it is not turned up very high Try running the current official viewer (it may have a more recent version of the voice software than what you're running)

Magic 8 Ball says Ask Again Later

Many of the Firestorm windlights were converted for you and can be found in the Settings folder of the Library in your inventory.

Download from https://secondlife.com/support/downloads/ or from its release notes page. The reason you have not gotten the update automatically yet is that you happen to have been randomly selected to be in the test cohort for a different Release Candidate viewer (in your case this one); within a few days the EEP features will have been merged into that candidate and you would get an update that includes them.

The new opensource-dev list (now reincarnated as a Google Group) is operational. Invitations were sent last week to all past subscribers. To subscribe, either find the invitation (in your spam folder?) and accept it, or send an email to opensource-dev+subscribe@lists.secondlife.com The new archive is available, and the archives of past incarnations of the list are at list-archives.secondlife.com.

Unless you describe in detail exactly what the problem was and how it affected your Second Life, there's little chance that we will even be aware of it much less fix it. The best place to do that would be to submit a Jira issue.

Not at present. The recent increase in load (a good problem to have) has probably caused some of the performance changes you've seen. We're aware of this issue and working on it.

We believe we've provided all the capability that a merchant, script, or external system needs to be able to determine whether or not a given account is the same as one that previously used another name (for Marketplace there is literally nothing they need to do). Doing that does not require that we give everyone the ability to read your name change history, which is otherwise no one elses business.

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Custom_Name_Program#Custom_surnames

No it isn't; it's exactly the same.

What you're looking for is the Community Gateway program. There's much more to it than just adding a link or a form to your site, though.

What you did was create a redirect. There's a much simpler way to do that; see the documentation for the RedirectSSL directive. If your request was a GET (you didn't say), your request might have worked (your redirect did not include any query string), but it won't work for any other method; see the wiki: It's also possible that the redirect you created was not to a valid url; impossible to say without specific detail or a complete log.

Not sure I understand what you're saying there ... it is not true that if the server responds to http that it will always respond to https. Have you looked at the server logs to see that it is getting the request and thinks it's responding?

There is no defined ordering between the changed event and the timer event; they can happen in either order. I recently made a small script specifically to record how long a region is inactive during a restart and ran into this same issue. I solved it by recording the last restart time in a global variable from the changed event handler: lastRestartTime = (integer)llGetEnv("region_start_time"); and then in my timer event handler I ignore timer events if the last restart time doesn't match: timer() { // when we're coming back up, the timer may fire before the changed event // so don't record the tick if the last restart time doesn't match // this will be fixed in the changed event handler if (lastRestartTime == getRestartTime()) { recordLastTick(); } }