Sayrah Parx

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.

I think it would really help for most of the "prim properties" to be editable in the object editor. Hover text and sit targets are the major ones that people leave scripts in after being set. Texture animation in the object editor would also be very helpful. Particles might be a little too complicated for an editor UI, but there could be a button to clear them at least.

I agree about all the scripts doing nothing. I believe there would be an overwhelming performance gain if they made it possible to edit the hover text properties in the object editor. People can only set the text, color and alpha with a script. They don't know it's a property of the object and doesn't depend on the script at all for existence. There are people who have been scripting in SL for 10 years who don't know that it doesn't depend on a script, other than it being updated by a script. It's possible that the majority of scripts currently loaded across all of SL were only there for the initial llSetText in state_entry, and never got run again once. All those useless scripts being loaded and using script time really add up.

LeTigre regions were restarted a second time after being updated to 18.11.01.521328 earlier, and went to 18.11.01.521329 like it says for Magnum.

I just had a third restart as well. The first was before 4 AM, the second was before 5:40 AM, and the third was before 6:45 AM SLT.

Do they know that regions get maintenance restarts twice sometimes? The second one can be anywhere from 1 to 3 hours after the first one. It's very strange, I think it only started happening at the beginning of the year. Would it help to post region names here?

Some main channel regions got restarted a second time. The ones I know for sure are Twice Right and Gama, about 60 minutes and 90 minutes after their first restarts respectively.

They managed to make it even harder to use and read. But there are new smilies

They have the same processor and video card. The first one has better hard drives, and two more USB ports. The second one doesn't have a DVD/CD drive, and has half as much RAM, and has a smaller screen. So it would be worth spending more for the first one.

https://jira.secondlife.com/browse/BUG-41196

You brought up a lot of really important issues. The two problems I've thought about a lot are the KVP store not being a separate premium feature, and not being able to transfer a key to another account. Not many people are able to create experiences in the first place, because they need a premium account to get a key. The best thing about groups in SL is that one person can own the land, and everyone else can contribute in other ways. So the worst part of experiences is that the premium requirement is due to the storage requirements of the KVP store, which most people don't even need or use. I know it works a lot better for me to use external webhosting with a mysql database, for a few major reasons. The first is that I can send and receive the data using less script memory (the script memory limit being another issue), than I would by having convoluted methods of dealing with the KVP store. The second is that I actually have interfaces to the data, and it's actually possible to manage it effectively. It's scary to imagine having to manage data on the KVP store for anything non-trivial. So the KVP store isn't useful for any large-scale application, but it's the deciding factor in limiting experience keys to premium accounts. You can sort of collaborate with people within a single group, which is an annoying way to share it but that's not a major issue. The major issue is that the entire experience depends on the account that created it, due to it not being transferable. So it's very time-consuming to create experiences for other people, if you want to sell them without the scripts being full-perm. You need to have them create their own experience, and add you to a group with a role that lets you contribute, and recompile your scripts. So it's not possible to simply sell an experience-based product on the marketplace. You have to include a note about contacting the creator in order to have them set it up...and hope that they understand your language. Then you have to rez your own copy that you'll transfer later, after setting it up with their own key, after they add you to their group. Because you can only compile a script with an experience in a rezzed object. So if we could create a separate key for every product, it would be possible to sell an experience-based product with much less hassle. So these two issues alone cause an experience to require a very dedicated collaboration, where it doesn't matter who owns the key, or require one person to simultaneously be owner, operator, designer and programmer. It's not something you can easily buy or hire an unknown third party to work on.