Jump to content

Oz Linden

Lindens
  • Content Count

    241
  • Joined

  • Days Won

    1

Oz Linden last won the day on April 25 2018

Oz Linden had the most liked content!

Community Reputation

456 Excellent

About Oz Linden

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. 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.
  2. 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).
  3. 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.
  4. 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...
  5. 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.
  6. 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
  7. 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.
  8. 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).
  9. That was broken by Facebook, I'm afraid, and it's not clear how we can fix it.
  10. 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.
  11. In order to allow for meaningful testing, yes we do. Everything is very very close to ready, so we're in the home stretch.
  12. 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.
  13. Mainland parcel owners have the ability to set the environment for their parcels, so yes, adjacent parcels may have very different environments.
  14. 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).
  15. 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.
×
×
  • Create New...