Jump to content

Oz Linden

  • Content Count

  • Joined

  • Days Won


Everything posted by Oz Linden

  1. See Channel and Version Requirements You can, within limits as described there, choose your own.
  2. Nope. I queried the URL you posted and got back reasonable looking XML, so I suspect the public/private setting is the real issue.
  3. What you describe is what happens when UDP is blocked - this is common in free public access networks. Second Life can't work under those conditions, so you'll need to find somewhere else to connect.
  4. That is incorrect. New accounts will always be Resident whether Premium or not. New Premium accounts will have the same ability to change the last name that an existing Premium account has, and will pay the same fee.
  5. Incorrect I'm afraid. New accounts will not select last names - they will continue to be created as 'Resident'.
  6. A change of either or both is just one charge; it is not per name.
  7. The services we were providing interfaces to via SLShare (Facebook, Twitter, Flicker) have not maintained stable interfaces; each of them has repeatedly changed the interface in an incompatible way (sometimes with very little notice). None has been used very heavily by the user base as a whole, and because of the interface instability we have decided that they are not worth the high maintenance cost so we're removing those features from the viewer code and shutting down the backend service. We're very sorry that this will inconvenience those who were successfully using the service.
  8. You remember it slightly incorrectly. The Legacy Profiles project restores the in-viewer version of the profile floater; most of that floater will be in the native viewer UI rather than an embedded web window as in the current default release, but it will still have a tab that will be a web interface just to the feed. You can get the Project viewer for this and try it out for yourself.
  9. We simplified and consolidated bug reporting and feature requests into the BUG project quite a while ago for almost everything. Internally, we triage that project a few times a week and clone the accepted issues into the appropriate internal project (most of which you can't see). This reduces mis-filed reports and requests and makes it easier for us to do cross-functional triage. We are regularly doing work on Marketplace - a batch of fixes and changes that prepare the way for others was deployed today.
  10. Jira issue creation can be used for creating either bug reports or new feature requests.
  11. LSL does do automatic redirection for GET (and HEAD) requests, but not for other HTTP methods.
  12. It isn't in an XML file - it's compiled into the code. It is also available in a file named build_data.json in the "Version" element. On a Mac, build_data.json is in /Applications/Second\ Life\ Viewer.app/Contents/Resources; I don't have the Windows location in front of me, but it's there somewhere.
  13. The symptoms match what would happen if you had a firewall on your system or your router that is blocking the UDP traffic to the simulator.
  14. Forgive me for using your post as an example @MBeatrix; I don't want to pick on you at all. We do rely on user problem reports for detecting many kinds of problems, but the quality of the reports make a huge difference in how effective they can be. This report doesn't have enough information in it for us to even begin to investigate. What inventory operations are "slow"? Quantify "slow" What viewer? What regions are you in when they are "slow"? When is "for weeks"? Specifics might allow us to correlate the problem report with changes we've made to the deployed services, including changes to backend systems that may be made at times other then when simulators are updated. Note that if you fill in a BUG report in Jira, and just copy into the Environment for the bug all the information in your viewers About Second Life floater, you'll have provided much of that. This comment illustrates a common communication problem; this gets a bit geeky, but the better we all understand the same vocabulary, the better we'll be able to help each other to identify and solve problems... "Inventory" is a database of items either owned by an agent or inside an object. When you open the inventory floater or the content pane of the build floater, you're looking at that list. But the list does not contain the actual objects - it's essentially just a set of named pointers to the objects. "Assets" are the actual objects. They're not stored in the inventory database, they're in a completely different (very large) data store of every object in all of Second Life. The Inventory database is manipulated by talking to that database through the simulator. If you move an item from your personal inventory to the contents of an object, for example, you're removing a row from your inventory and adding a row to the inventory of the object, but you're not actually moving any of the data for the object those rows point to. Most Assets are accessed through the CDN (there are a few exceptions that are managed through the simulator for security reasons). This is why it's important to understand what operations are "slow" (or have some other problem); some operations are just interacting with the Inventory database, some are interacting just with the Asset store, and others are doing both.
  15. We're making a series of changes that I hope/believe will result in rolls that will reduce downtime and solve some other roll-related problems (some of which are purely internal). Those changes are being made slowly so that we can measure the effect of each change carefully. The roll this week was deliberately slightly slower than normal (I don't have the numbers yet, but we're collecting data); future changes should reduce the downtime for each region during the roll, but those changes will be made one at a time over the next several weeks. I don't think that any of those intermediate steps will increase the roll time further, but stay tuned...
  16. Yes, there are limits. Depending on circumstances you may get a debug channel notice when a limit is reached, or you may get this error. Yes, competing with other scripts that are making large numbers of requests can cause this error. As @animats said, a backoff and retry is the appropriate way to handle this. There's an example in the wiki of a simple structure for doing these retries (it's written in terms of an initial registration of your script with an external server, but the method used is general and can be applied to any outgoing request).
  17. https://community.secondlife.com/knowledgebase/english/how-to-report-a-bug-r224/Section_.3#Section__3_1
  18. Most likely your problem is actually something wrong with the connectivity between you and the servers (if you have a Windows or third party firewall active on your system that may be contributing). I suggest that the next time you experience a problem, save your viewer log file and contact Support to help diagnose the problem.
  19. The latter ... that last component is an identifier produced by our build system
  20. I'm not in Support, so whatever I say must be taken with a grain of salt. My understanding is that the request must come from the region owner. I don't know how they handle mainland and other Linden-owned regions. We will continue to post release notes, and link to them from the About Second Life floater; you'll be able to tell what version you're on. If some behavior changes that's causing you a problem then Support will be able to move you off of it, but please file a bug report first so that we can fix it. Really, all we're doing so far is to hide the name of the RC; whether or not you're in an RC is not really hidden if you just click through to the release notes. It's just one part of a much larger effort to make our simulator evolution more stable. Right now, the RC channels are not very good models of the grid as a whole. Some recent problems got to main channel because they didn't happen (or didn't happen much) in the RCs, or weren't detected when they did. Other parts of this project include much better reporting on what's happening, including things we have not monitored closely before. We're also developing ways of making the RCs more representative of the grid as a whole, but doing that will require being able to change their populations. Our objective is to find problems more quickly and reliably.
  21. We fully appreciate that predictable roll days are important, and that will continue to be a design constraint. Nothing is changing about when rolls happen for some time, and we'll provide ample notice and time for feedback when/if we make any change to that. For a region owner, all that is required to move on to or off of an RC (or any RC) is a support ticket. That will continue to be true. Sometimes being on an RC is more stable than on the main channel; when we're fixing bugs, that's certainly our objective. We're going to try to provide more useful information on what is changing in each new server release, but sometimes we just can't - for example, it wouldn't be a good idea for us to describe that we've disabled a particular griefing vector if it's only disabled on one RC.
  22. Customized stars was considered, and didn't make the cut this time around. It's still on my personal watch list, so maybe next time.
  23. That's true only for direct person to person voice calls. Any group/local/conference voice is anonymous because you are connected through a mixer.
  24. Nope, just dumb luck. When we have a viewer in a nearly-releasable state (in this case, that turned out to be a little optimistic), the last phase of the release process is to offer it as an upgrade to a cohort of randomly selected users. Second Life is so large and complex that it's just not possible for us to test as much as giving to real users will. Normally, once you're on a Release Candidate like this, you'll keep getting those updates, but by manually downloading the default release you removed yourself from the test. For details, see http://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes#Release_Candidate
  • Create New...