Oz Linden

Bad effects on scripts may be relevant (or may be bugs in the scripts... hard to say), so it's fine to include it. Subsequent login attempts, regardless of where they are, are not part of the base problem we're most interested in right now.

We are very interested in hearing about TP problems, but it will be far far more useful if you report all of the following: When it happened; this doesn't have to be exact - within a few minutes is plenty accurate. Tell us what time zone you're using (SLT is easiest for us) Where were you when you tried to TP? Where were you trying to go? (region names is all we normally need for start and end locations) If you ended up somewhere else, where was it? Were you disconnected or did you crash? If the viewer window disappears with no message, you crashed; if not, you were disconnected. What viewer were you using? (copy the information from Help > About Second Life) It's easiest for us if you report those in jira, but contrary to what some people think we do watch the forums. This issue is a very very high priority for us right now, so we really will use reports we get, but none of the above is enough for us to learn anything from. If what you want to do is just vent your frustration by all means go ahead, but if you'd like to contribute to solving the problem we need the information above.

That is incorrect. The term 'process credit' means withdrawing your US Dollars (transferring them to PayPal, Skrill, or any other outside institution). Please see this thread for official clarifications.

I have not tried to measure it, but it's not free.

This is quite a bit more involved and expensive than it needs to be. You're essentially using the SHA1 value as an expensive index into a list; if both scripts have the same list of textures in the same order, just passing the index into the list is just as secure and much cheaper.

What that message actually means is that the simulator has determined that messages from your viewer are frequently arriving out of order. Some out of order messages are expected and ok, but if it's happening too much it probably indicates a faulty network path between your viewer and the simulator. Because this can cause problems, certain messages are disabled when this is detected, which is why we suggest relogging somewhere else for a while. I have no idea why that would be related to landmarks or any other part of inventory, but it's possible ...

Last I heard, we fixed that some time ago.

There was a minor glitch in rolling out that change ... should be fixed now, but you may need to relog to see the correct number.

What you're doing is essentially manually crashing the viewer; that can result in problems such as corrupted caches and failure to save settings changes. There's no need to wait for a fix; the link Whirly posted is the fix, and that viewer has no other changes compared to the current default viewer - it's as specific as can be.

This would be far better to handle as a Support ticket or a Jira. In either of those, you could more comfortably have included the details we would need to investigate the problem (such as the names of the users that are not blocked but should be, and where you are seeing the incorrect status).

The latter. We will not delete any of your groups; you just won't be able to join new ones until you're under your limit.

IMs via email have never been limited, and are not affected by this change at all. If you have a verified address, we'll send the IMs you are sent as email. The limit is only the number of messages we'll store and deliver in a batch when you log in. If you have IM to email enabled, they'll all be old news by then...

This is not a thing. We don't delete accounts when you miss a payment - we don't even limit access until after a considerable grace period.

The documented limits are correct, but as others have pointed out even getting close to them can cause throttling events, and once throttled it will take quite a while for the condition to completely clear (twice the period that triggered the throttle initially, typically). Yesterday I posted an example script to show how to employ a fuzzy exponential backoff to deal with remote server failures; it would work equally well for throttling. http://wiki.secondlife.com/wiki/HTTP_Server_URL_Registration

This is true only after a fairly long grace period (during which Billing will be reaching out to you to get it corrected). It does not happen automatically when a payment fails.

In general, we won't be discussing dates or milestones for our migration to the cloud, only any user visible changes that result from that migration. Initially, we hope that there won't be many of those - it should be more or less invisible to you (digging into the hostnames or IP addresses may provide clues, but not always). We've moved a few things, and are finding and fixing a few problems that crop up with the changes. As noted above, we're also upgrading the OS version for simulators and other things; again, that should be mostly a no-op for users. It's also true that none of the above has anything to do with streaming viewers. We've been monitoring the cost/benefit of streaming viewers for years, and will continue to do so. If/when we think that the cost we can offer a streaming viewer is reasonable, we'll do it. There is https://brightcanopy.com/ now (not a LL product).

That was broken by Facebook, I'm afraid, and it's not clear how we can fix it.

It's sort of a problem with the installer. We went through a few changes in updater strategy over the last few months, partly to be able to protect users who still need 32bit viewers and partly for some other reasons. I think we've ended up at a good solution, but there were some problems with some of the intermediate steps. I think that if you'll delete any shortcuts that you've been using to launch the viewer, and then reinstall one more time, you'll be ok from now on. (The problem is that the shortcut you're using is still pointing to a leftover component from an earlier version) If that doesn't solve it, please zip up all the log files in your log directory and file a bug report on jira. My apologies for the inconvenience.

In order to allow for meaningful testing, yes we do. Everything is very very close to ready, so we're in the home stretch.

Any testing you do with a non-EEP viewer is only testing the temporary attempts to convert the new EEP settings to some approximation of them for non-EEP viewers. These are not perfect and are not really meant to be. Once EEP is promoted to the default viewer we expect that it will be quickly adopted by all actively maintained Third Party Viewers, and we'll all once again be in sync. The only way to see what things will look like with EEP is to use an EEP viewer on an EEP region; the project has made major changes on both the server and viewer side, and we can't make the non-EEP viewers show the same results that an EEP viewer would. Making assertions about how it looks or behaves based on testing with anything other combination is meaningless. If you don't want to test, that's fine (Project viewers are always opt-in), but please don't confuse others by doing invalid tests and making assertions based on them.

Mainland parcel owners have the ability to set the environment for their parcels, so yes, adjacent parcels may have very different environments.

That message usually means that the server is not getting messages from your viewer reliably (too many lost). Check any firewall on your system, and reboot your router and cable or dsl modem (usually it's best to turn both off, turn on the modem and wait for it to come up to normal lights, then turn on your router).

Without commenting now on whether or not we have the specific cost correct (the people that chose that value know much more about it than I do), it is not correct that Land Impact exists only to protect or account for server side resources. Viewers lag too, and objects that produce unnecessary viewer lag have a large negative impact on the experience of Second Life. Land Impact exists not only to limit what you can put out, but to encourage efficient content. Animesh objects are more work for a viewer to process; the increment to LI exists to reflect that cost.

Check what your system sees as the IP address for www.bhr.vivox.com (that's the voice service for the main grid). In a terminal window, type: nslookup www.bhr.vivox.com The correct answer is 74.201.103.238 If you do not get that answer, it means that your system is trying to contact the wrong service. Rebooting your system may fix it; if not, it should correct itself eventually (the actual problem has already been fixed, but some DNS servers are incorrectly still giving out old addresses or otherwise failing to provide the correct one above).

Auctions have started again. See the status update