Sayrah Parx

That's correct, it would technically be possible to change anywhere, but mainland is controlled by the Linden governance team and the mainland region settings are almost never changed from the defaults.

It means that the ranges for shout, say and whisper are getting turned into region settings like water level. Settings like that normally aren't changed from the default on mainland, but could be changed to custom values on any private region by an owner/manager. The ranges will probably stay at 100, 20 and 10 respectively on any mainland. It would allow any private region to not be consistent with the ranges in the rest of SL, so you would have to check what the ranges are every time you TP into a private region.

That's why any new larger ranges need to be on a new separate option that can be turned off, instead of creating the ability to change the current ranges. It would be great to be able to turn off the shout and say range in the viewer as separate options too. We don't want estates to come up with their own ranges for everything. Instead there should be viewer options to hear within the current estate, region, parcel, shout, say and whisper ranges. New options for estate, region and parcel should also obey vertical limits according to the viewer settings, i.e. max vertical range should be shout if people have shouts turned on.

You're right that the visibility in the viewer of who is in chat range, and what the chat ranges are, isn't going to be the issue. The issue will be having to check and memorize the local chat thresholds every time you enter a new region. That is what people will have to get into the habit of doing before anything else. It will be a nightmare to have that as a constant concern, and it will make people hesitant to communicate in local chat. I'm sure that's not the intention, so I hope you will reconsider making any of the chat ranges variable by region. It would also be good to know what problem it's meant to solve or what the benefit is meant to be. It certainly sounds like a good idea for making it easier to communicate, but the implementation will only make it more difficult to communicate consistently. What most people would really like is the ability to chat across an entire parcel/region/estate horizontally, with the vertical limit being the normal whisper/say/shout limits.

Making chat ranges for whisper, say and shout inconsistent across SL will only make things worse. People would not be able to trust local chat at all. It would be better to have new message range types for estate, parcel and region chat, and allow people to decide if they want to listen to any of those new three and choose which of the six ranges to send on by default. That way someone could send on estate, region or parcel, but if a listener has those off then it would still check if they were in shout, say, or whisper range.

It depends if the name is directly in a message from the script, or if it's in the footer of an offline message. The script probably gets the account name when it's rezzed and keeps it without checking again. So in that case you could just rez a new vote box. If it's a message from Linden Lab saying "Sent by Old Name", that could take about a day or two to switch to the new name.

It's good to see them trying. I recently had a friend request sent to me get dropped due to the cap and only found out about it from the offline e-mail. Group invites may also get capped and dropped. There's no way to accept either of those from the offline e-mails. The idea for group notices was to have it part of group settings and not from a script. Many of us have already posted our criticism of llTargetedEmail. But it's also good to see a new focus on using e-mail for messages, because communication is so important to the economy. Anything that can reduce reliance on the capped stored message system is a good thing. They said that the part that could be abused will no longer be functional. So if someone doesn't have a use case for it, its existence is not going to hurt them any more than something else almost no one uses like llOpenRemoteDataChannel.

It's great if you have a way to edit others' objects and have no other way to contact them. It's a great way to be sent offline messages and notices, after the offline message and notice cap was reduced 40% from 25 to 15. For most groups, it would be great to have the option of notices only being sent to e-mail when not logged in for that particular group, in the same way there are options for receiving chat and notices for each group. If sending e-mails is better for the SL infrastructure than storing offline messages and notices for the next login, then this seems like a great first step. I hope we can have that option for group notices sometime soon, because after the 40% cap reduction I've had to turn off notices completely in most groups that get sent notices frequently.

It's very strange because it's something I thought would be great for a long time, but it doesn't seem to be planned well at all. As a general concept, it's something we've needed for a long time to be able to reduce offline notices and IMs, but the implementation looks terrible and practically useless for most situations. Now that we're finally aware of the attempt to make something like this possible, I imagine that any feature request would be met with "we're not going to do _____ to make it actually worthwhile because we've painted ourselves into a corner with how we've already implemented it." But the good thing is that they picked one of the worst possible names for the function, so they could still make a better version with a new function name.

That's really interesting. It probably means that the new simulator support is to make it possible for real avatars to communicate with the mobile clients that are connected to some other service.

When you use something completely non-graphical like METAbolt or pikkubot, the avatar is the same and indistinguishable from someone using a graphical viewer. The avatar is whatever it was the last time you logged out.

I was able to confirm in all of these that object_rez doesn't occur with an object that has on_rez: Featherston Chapel Bolsena Clarabella Red Light Center Notteterna Creole Tranquil Dream II Animus City Rain Song Aladonia Island Raine Lake Epimetheus Envar I wasn't able to confirm or deny in Alexandria Falls due to not being able to rez anywhere. I was able to find that it worked in Playa dela Seduccion and Cape Hatteras. Maybe Playa dela Seduccion and Cape Hatteras have been restarted recently or something else happened that could be a clue.

I was able to get access to the six "_____ Sandbox 1" and "_____ Sandbox 2" regions that are on 537423 by joining the Second Life Beta group, and both events work as expected like they do in other 537423 regions like Venrigalli, Sirrakuk and Nadelhorn. Still no change in Toroge, Fearly and Korzun.

I noticed it looked like you were testing object_rez without testing on_rez inside the rezzed object at the same time. So I tested object_rez with a non-scripted object and did get the object_rez event in those 3 regions. So apparently if the rezzed object has an on_rez event then the object that rezzed it doesn't get the object_rez event in those 3 regions.

I confirmed that in Toroge, Fearly and Korzun, which are on 537423, the object_rez event doesn't happen. The on_rez event does still work as expected. But the object_rez event definitely DOES NOT work at all. I confirmed with the same test that on_rez and object_rez still work as expected in 536748. But I tested in Venrigalli, Sirrakuk and Nadelhorn, which are also on 537423, and both events work. So the bug doesn't seem to depend on 537423. But it's definitely a problem in Toroge, Fearly and Korzun which all happen to be on 537423. I would test in Magnum Sandbox A, LeTigre Sandbox A and BlueSteel Sandbox A but you have to be premium to enter those now. Magnum Sandbox 1, BlueSteel Sandbox 1, LeTigre Sandbox 1, etc. also block access. So maybe someone else can test in those.

The issue with saving scripts is gone after the second restarts, and still the same server version.

I think there's definitely something wrong, even though it's the same server version. I crash when saving a script in any region that was already restarted, and don't crash when saving the same script in any region that hasn't been restarted yet. They're all Second Life Server 2019-12-04T20:29:26.533447 before and after restart.

I crash after saving a script in any region that was restarted today, and don't crash in any region that hasn't restarted yet. They are all Second Life Server 2019-12-04T20:29:26.533447

Main channel was still on 2019-09-06T22:03:53.530715 until this morning when it got 2019-10-03T01:12:11.531528. Maybe your home wasn't restarted yet?

Is there a way to tell which day the restart will be on a certain region, without the server name being different now? It seems like estate regions are always main channel unless the owner opts in to a release candidate channel, so we can be fairly sure that estate regions will be on Tuesdays, but there doesn't seem to be a way to be completely sure without asking the owner. How do we tell at all on mainland, when last week's release candidate is this week's main server? Let's say we're working on something complicated tomorrow (Wednesday) morning in a region that's running version 2019-10-03T01:12:11.531528. How do we tell if we're going to be interrupted by a restart at some point that morning with only 5 minutes notice, if it's on the release candidate channel, or if it's on main channel and just got that version yesterday? It seems like we can only tell for sure on mainland regions where we already have a restart tracker that keeps track of the last server version.

We got two restarts in Cheertopia so far. After the first time it had the same version, Second Life Server 19.08.23.530380, and after the second time it has the new version, Second Life Server 2019-08-29T20:20:39.530516.

It's really a hard problem. They want as much typical use on the RC builds as possible so that they can get the best impression of how they would work when deployed everywhere, because last week's RC builds are this week's main server build. So it would probably help more to point out that the RC builds were already tested on the beta grid, and have literally become release candidates and are no longer beta builds. Because the problem is no one wants to have their production stuff running on a beta build. The best solution would be to have limited amounts of free land on the beta grid so that a good population would always be "living" there and testing stuff there. The whole point of the RC builds was that there wasn't a big enough testing population on the beta grid to catch all the problems before they were everywhere on the main grid.

It sounds like the same reason that Cool VL Viewer isn't on the list anymore. It is one of the best viewers, and the developer consistently integrates recent changes from the Linden Lab viewers within a week or two. Some third-party viewers like Firestorm take 3 months or longer to integrate the same changes. But they require so much personal information to be on the list now. People outside the USA especially tend to not want to give up unnecessary personal information for no reason.

My idea for the L$ option is based on the fact that currently anyone can: Upload an image for L$10 Upload a sound for L$10 Upload an animation for L$10 Upload a mesh starting at L$11 with increasing cost based on complexity Create a group for L$100 If the operational cost for experience keys is really high enough to justify a premium gate, a key could cost the L$ equivalent of a single month of premium since you keep the key when not premium. That would currently be L$2500 and will be increasing to L$3000. However, you can only own one per account and it's not transferable. They would need to make improvements in the management of the keys before it's viable for serious long-term projects, regardless of whether there's a premium gate. That is the bigger issue.

The larger issue is that they can't be effectively managed for anything non-trivial, because you can only make one with any account which is tied to that account. So if you're not premium then you can buy a month of premium for an account to make a key on it, and then you have the key and don't need to be premium anymore. But you can only retain the key with that account, and need to link it to a group to use it with your main account. So it's really not a good system for anyone, and isn't helping them sell premium accounts at all. If they made the keys a one-time purchase with L$ that can be transferred like groups, with the storage on it being unlockable with L$ as outlined in the JIRA idea, they would actually get the income and sustainability they're trying to achieve with the premium gate. Currently you can make one for free per account if you're premium, without the option to buy more. They could charge more (or at all under the current system) to create them for someone who's not premium, but oddly they are choosing to not make them purchasable at all. No one is asking for it to be free. It's bizarre to set up something incredibly useful that can't be paid for or managed effectively. There are many issues with SL that aren't really worth complaining about or criticizing, but the experience permission system itself is so revolutionary for SL. People put a lot of work into it, and making it more accessible at a reasonable cost would do a lot to keep SL thriving and competitive.