Jump to content

Oz Linden

  • Content Count

  • Joined

  • Days Won


Everything posted by Oz Linden

  1. We plan to modify/replace the ROOT_CREATOR function to be one less useful for spamming... stay tuned
  2. This is a great suggestion. For more information on how this problem occurs, google "buffer bloat". There's info on tests to see if this is your problem at https://www.bufferbloat.net/projects/bloat/wiki/Tests_for_Bufferbloat/
  3. What viewer version are you using? (it matters) For example, there are some alpha blending bugs in some viewers that show up there...
  4. This is a good illustration of the basic paradigm of LSL: a state machine. The owl has two states: hooting and silent. In each state, it's response to being touched and its response to the timer going off are different. Using states rather than a switch variable, you get a very simple set of event handlers in each state: float interval = 40.0; // how often the sound is triggered string hoot = "Owl"; // name of the sound in the object default { state_entry() { // you could do something here to let the user customize state hooting; } } hooting { state_entry() { llPlaySound(hoot, 1); // make it clear what state we're in llSetTimerEvent(interval); } timer() { llPlaySound(hoot, 1); // you could call llSetTimerEvent here to introduce some randomness } touch_start(integer total_number) { state silent; } } silent { state_entry() { llSetTimerEvent(0.0); // no need for the timer so stop it } // note that there is no timer() event handler touch_start(integer total_number) { state hooting; } }
  5. 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).
  6. 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.
  7. 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?
  8. Why are you trying to set that elaborate User Agent header?
  9. 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.
  10. Good point - my mistake. Fixed. It will of course be moved back if/when the 3D view is in production.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. See Channel and Version Requirements You can, within limits as described there, choose your own.
  17. Nope. I queried the URL you posted and got back reasonable looking XML, so I suspect the public/private setting is the real issue.
  18. 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.
  19. 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.
  20. Incorrect I'm afraid. New accounts will not select last names - they will continue to be created as 'Resident'.
  21. A change of either or both is just one charge; it is not per name.
  22. 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.
  23. 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.
  24. 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.
  25. Jira issue creation can be used for creating either bug reports or new feature requests.
  • Create New...