Sayrah Parx

Thanks for the screenshots, the ads never loaded for me but it was obvious what the new empty space was for. In the webpage source it's clear that they're legitimate google banner ads. Space is defined for an ad on the top that's 728x90 and an ad on the side that's 160x600. Whoever is working on the website just has no idea what they're doing apparently, and they're being careless by working on it in production.

It looks like someone is messing around with things in production instead of a test environment, and seemingly before they put much thought into it, which is normal unfortunately.

We need private islands to have no height limit when it comes to disabling scripts on a parcel. From what I understand, Mainland parcels only disable scripts under 50 meters above the land height so that people can use air vehicles on the mainland. We need scripts to be fully disabled on a parcel on private islands when we choose that option.

As far as maintenance restarts on estate regions, they don't seem to care at all about how it may impact the owner and what they're trying to accomplish in their region at the time. They don't seem to care at all about the complete lack of control over when the region will restart. They don't give more than 5 minutes notice when the region is going to be restarted, and they wonder why RL businesses and corporations are avoiding SL...

Looks like you were able to get it to work.

Can you explain how an estate owner or manager can disable pathfinding in the region, so that we don't have to worry about the navmash constantly needing to be rebaked? Pathfinding is an interesting concept but for my group's purposes we would rather wait for it to be more mature than to have to deal with it at all for now.

Are you going to be handling the deploy communication from now on Maestro?

Ordinal Malaprop may be listed as the creator of the object, but is not the creator of the scripts that are causing problems. Someone put scripts in a box from one of Ordinal's legitimate products, so Ordinal is also a victim of this. The script files may be reused from another creator as well, so the only ones who can track down the true creator are Lindens.

The phrase "unscheduled maintenance" is about as hilarious as a euphemism can be

It sounds like this is fundamentally flawed, if islands are loaded on the same servers as mainland regions. It would impact standalone islands a lot more than mainland because there would be no avatars in adjacent regions, yet an island costs $110 more than owning a whole mainland region. We get a lot more tools and flexibility with an island, but that is necessary because they must be managed without any help from Linden Lab. How is it possible to justify any reduced performance for islands under any circumstances?

ANS works great, we just need you to fix https://jira.secondlife.com/browse/WEB-4676 now.

Are you able to consider making the maintenance restart messages begin at least 10 minutes in advance instead of 5, as well as making the messages occur at most 1 minute apart instead of 2 minutes apart? Currently this is all the notification we get: [2012/03/06 06:40] Second Life: Your region will restart in 5 minutes and 0 seconds for maintenance. [2012/03/06 06:42] Second Life: Your region will restart in 3 minutes and 0 seconds for maintenance. [2012/03/06 06:44] Second Life: Your region will restart in 1 minutes and 0 seconds for maintenance. [2012/03/06 06:45] Second Life: Your region will restart in 0 minutes and 30 seconds for maintenance. Considering that the snapshot backup is already being taken when we get the 5 minute warning, it really is necessary for there to be more advance notice.

Would it be possible to make the countdown longer, like 30 minutes? This is what the current countdown looks like: Second Life: Your region will restart in 5 minutes and 0 seconds for maintenance. Second Life: Your region will restart in 3 minutes and 0 seconds for maintenance. Second Life: Your region will restart in 1 minutes and 0 seconds for maintenance. Second Life: Your region will restart in 0 minutes and 30 seconds for maintenance. Considering the unpredictable and disruptive nature of maintenance restarts, it would be helpful for the countdown to send a notice once a minute until the final 30-second notice (no matter how long the countdown is). The problem with the maintenence restart messages not popping up a dialog anymore would also be mitigated somewhat if the messages had a longer countdown. The larger issue is that the current queuing system for maintenance restarts doesn't allow for sufficiently advanced notice to landowners and estate owners, something which should be a priority for a stable platform.

Would you be able to include VWR-24513 in the scope of this project?

Philip Rosedale also stated in this interview from 2007 that they were already making preparations for it to become open source. However, they eventually decided to try making more money from businesses and institutions with licensed servers that could operate within the privacy and security of an intranet. Making the server code open source seemed to defeat that plan from their perspective, although the success of things like Red Hat Enterprise Linux should have suggested otherwise. They obviously need to start over from scratch and build something more scalable, based on the lessons they have learned over the past decade, so I'm not sure why anyone would want the current code anyway. A dedicated start-up team would be in a better position if they never saw any of the Linden Lab code, if only for the sake of their own ingenuity. The major failure of OpenSim is that they depend on compatibility with viewers based on the open source Linden Lab viewers, which rely on the fundamentally unscalable Linden Lab servers. The server can only be as good as the client, and vice-versa. At Linden Lab, a big part of the problem is that the server and viewer teams are completely different people. For a new grid to be successful, they would need to develop their own viewer and have every developer working on both the server and client.

Putting something that's no transfer and/or no copy into another prim already applies those restrictions to the prim, so it seems like there would be no problem with enforcing a new flag in the same way. One thing that people have brought up is that it would currently be possible for a script to give something away that's transferable but not resalable, like with a vendor that people pay rather than buy from. However, llMapDestination is able to determine whether someone besides the owner had touched the object first, so what I have brought up in response to that point is that it should also be possible for the llGiveInventory functions to determine if someone had paid the object. If it's determined that someone paid the object then it should be possible for the llGiveInventory functions to ignore sending non-resalable items just like it always ignores sending non-transferable items.

Pushing will still work if the object is set to the same group that the parcel is deeded to. Is it possible that the parcel's group was changed?

Are you able to make the maintainance restarts pop up a dialog message for the countdown, like they used to before the change about 6-8 weeks ago? After the change, it only shows countdown text in local chat which is easy to miss and doesn't flash the taskbar. Ideally it would show both.

Calling cards are now being created as "first.last" instead of "First Last" after accepting friendship. https://jira.secondlife.com/browse/SVC-7400

Thanks, llManageEstateAccess works great. I started working on a tool that will let group members ban griefers without having to be an estate manager. The only problem is that the only way to get a key from a name is to use a sensor, which requires someone to be within 96 meters. Sensors are also case-sensitive, unlike the "Choose Resident" name lookup window we have for various things in the viewer. Is there any progress on having a Name2Key function available to scripts?

I'll be able to switch from Snowglobe when I can get the same interface or better for my needs. Until then, I refuse to be forced into using a third-party viewer just to have a viewer that's usable for my needs. The biggest issue is web profiles in the viewer. I like the web profiles and they're a great bonus when used in an external browser, but they should not replace the original kind of profile in the viewer. Sometimes I consider switching and learning to deal with all the annoying things, but then I remember that there's no option for original profiles instead of web view profiles.

It's not a problem with Snowglobe.

There's been an intermittent problem the last few days, where everyone in a region gets disconnected about every 5-10 minutes, and the problem lasts for about an hour. Support doesn't know what's wrong because it's not something that can be reproduced. Maybe it's just network issues? It has started happening after 6 PM SL time.

Please make deploys pop up a "region will restart for maintenance" message again.

llCastRay works great. Can you make it pop up a dialog during restarts again?