Jump to content

Oz Linden

  • Content Count

  • Joined

  • Days Won


Everything posted by Oz Linden

  1. They will once EEP is integrated into the viewer they are using. If what you did was edit a local file on your system to set the parcel windlight, then only people who have that file (with the same name) are seeing that now (this is how the Firestorm parcel windlight works; everyone must have a copy on their own system).
  2. Not completely, no. We want to unambiguously identify what is being done with LSL so that it's more difficult for bad actors to use it inappropriately.
  3. Maybe they don't want you doing that? If they really are blocking requests from LSL, they most likely are matching on the presence of the LSL version, which is included automatically and you cannot remove; see the wiki page : Have you tried asking them?
  4. Why are you trying to set that elaborate User Agent header?
  5. As much fun as it might be to watch the continuing speculation, I'm afraid there's a simple explanation.... We're in the process of upgrading some of our inventory database servers, which means moving each users inventory data from an older server to a newer one. We can of course only do that when the user is not logged in, and before we start the copy we lock the account to prevent them logging in while the move is in progress. You just happened to try to log in while your data was being moved. The lock lasts for 6 minutes, so if you happen to get that message go make a sandwich or your favorite hot beverage and you should be able to log in when you're done. If you happen to get that message separated by more than 6 minutes, file a ticket with support and we'll look into it promptly.
  6. Good point - my mistake. Fixed. It will of course be moved back if/when the 3D view is in production.
  7. The functions will not change; the values returned by them will, since we won't be using the 'lindenlab.com' domain for simhosts in the cloud (they'll probably be in 'secondlife.io'). They will most likely still have the grid level in the name, but I strongly recommend not counting on any particular structure or content in the value.
  8. For future reference; if anything in your infrastructure relies on simulator IP addresses being in a particular range or having a particular domain name, you should reconsider it - when the simulators are in the cloud (none you can see are, yet) both of those will change.
  9. No one told me I needed to pick a name until the Thursday night before my Monday start date, and the first 4 or 5 I came up with were rejected for one reason or another (most because they'd been used... we normally require that no Linden has ever used a name before). By Saturday night I was getting desperate and enlisted a bunch of my friends to come up with suggestions; one came up with Oz, and I texted the HR person and my soon-to-be boss and they said it was ok. I was coming in as the Open Source Director, and already had an 'Open Sourcerer' t-shirt (still do, but it's getting pretty ratty now), so the wizard angle was attractive (setting aside that the character was something of a fraud). I won't deny that the fact that the then most popular of the third party viewers I'd be dealing with was 'Emerald' wasn't a factor (the friend who suggested it had no idea)... and one more little bit of Linden lore... at work, nearly everyone is known primarily by their Linden name; there are plenty of people I've worked with here for years that I'd have a very hard time coming up with RL names for (makes creating LinkedIn connections a bit more difficult). I rather like being called "Oz" and it feels as natural to me as the name my parents gave me.
  10. A change is a change and will cost the same (and require a Premium status) whether to a new name or back to a previous one.
  11. Inventory size does not affect lag in any way that I know of (where in this case 'lag' means impact on movement and visual updates). If your inventory has more than a few thousand items in the same folder (where an item is either an object or a sub-folder), it can affect the time it takes you to log in; if that effect becomes large enough it can cause your login to time out.
  12. See Channel and Version Requirements You can, within limits as described there, choose your own.
  13. Nope. I queried the URL you posted and got back reasonable looking XML, so I suspect the public/private setting is the real issue.
  14. 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.
  15. 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.
  16. Incorrect I'm afraid. New accounts will not select last names - they will continue to be created as 'Resident'.
  17. A change of either or both is just one charge; it is not per name.
  18. 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.
  19. 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.
  20. 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.
  21. Jira issue creation can be used for creating either bug reports or new feature requests.
  22. LSL does do automatic redirection for GET (and HEAD) requests, but not for other HTTP methods.
  23. 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.
  24. 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.
  25. 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.
  • Create New...