Sayrah Parx

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.