Sayrah Parx

Main channel regions stayed on 2023-07-31.581251. Ferrari RC regions moved to 2023-09-01.6051776725. BlueSteel RC regions stayed on 2023-08-24.581535, and the rest of the RC regions moved to 2023-08-24.581535.

The BlueSteel RC regions are forging ahead with 2023-08-24.581535. All other regions are staying on 2023-07-31.581251 after being restarted.

It's great to see RC channel names again! I know one RC region still on 2023-07-31.581251 after the restart, so that must be LeTigre or Magnum.

Main channel regions are staying on 2023-07-31.581251. RC channel regions will most likely be moved to 2023-08-02.581292.

Server 2023-07-31.581251 is a small maintenance release in addition to the changes from 2023-07-14.581036, that is now on all regions after starting on the RC regions last week. It fixes logging into the beta grid, and allows a viewer to get updated limits for the number of avatars that can be in the estate manager and ban lists without requiring a viewer change.

Main channel is still on 2023-04-21.579747 after restarting on Tuesday the 16th. The RC channels might be getting 2023-05-05.579955 on Wednesday the 17th.

I agree, it seems like they don't realize how hard it is to even see the release notes otherwise, and to know when and where the changes are rolling out. It's strange because they've actually done a lot of great work to be proud of, like linkset data. There are also times where it would help to test something on Aditi before it gets rolled out on the RC channels on Agni. So it would help to go even further with the forum posts and tell us what's currently being tested on Aditi every week. There are lots of people who would be glad to help in some way but can't make it to the meetings.

The one RC region I monitor stayed on 2023-04-21.579747 after being restarted, even though 2023-05-05.579955 exists. So there may be an RC channel that got 2023-05-05.579955 after being restarted.

Main channel was on 2023-04-03.579248 and as of May 9th is now on 2023-04-21.579747

That makes sense now that you say it like that, but it's been a while since there were two completely different versions out at the same time in different RC regions, so it wasn't immediately clear that one had all the changes from the other. I believe they've had separate versions out in the past to test specific things, where neither version was an upgrade of the other, and then had to combine the changes from both.

I was surprised that today the RC regions on 2023-03-24.579022 got moved to 2023-04-03.579248. I thought they would need to be moved to a new version that combines all the changes from 2023-03-24.579022 and 2023-04-03.579248, instead of losing the changes from 2023-03-24.579022. I'm not aware of any issues personally with this loss of changes from 2023-03-24.579022 in regions that already had it, but thought it was worth mentioning considering that main channel regions stayed on 2023-03-24.579022 this week.

The RC regions are indeed now on 2022-12-06.577088 after the restarts.

The main channel regions restarting today are still on 2022-11-11.576542 after the restart.

One that was down for 2 hours and 50 minutes is still on Second Life Server 2022-11-11.576542

The RC regions are now being rolled to 2022-11-11.576542

I found out that linkset data works in the RC regions again at least.

The ones I've seen restart today are still on 2022-10-07.575585

If there is actually a way to determine arm length based on the relative 0 to 100 shape values, that's great. But if that were possible to calculate, we would already have things that let someone set them up with their shape values manually. Suddenly being able to get someone's shape values with a script doesn't magically make it possible to calculate anything useful from those values. I think it would be great to be proven wrong that it's not possible to calculate measurements from the relative values with enough practical accuracy. But I haven't seen anything in SL that can calculate measurements from them in almost 14 years. I'm pretty sure that not being able to get the shapes values with a script was not the problem.

Yes, I am still shocked that this made it out of testing because there is absolutely nothing else that the relative shape values could be used for. Unless of course someone has a formula to convert the relative values to meters. It would not help at all with adjusting avatar animations otherwise. I don't speak for anyone, but I don't think this is what anyone ever asked for. I read Lucia's request as being a way to get actual measurements in meters, which would be really useful. But no method to calculate those based on the relative shape values has been provided, and may not even be possible to calculate to enough accuracy in practice with the relative values alone. I think it's early enough that they could just pull the function out completely, and any scripts that get broken for failing to compile it deserve to be broken. Because the only use it has currently is to spy on the relative 0 to 100 values for someone's shape, which cannot practically be used for any other purpose.

I still don't know what the point is of llGetVisualParams. We've been able to check if someone's shape is male or female for years, with llGetObjectDetails. Everything else is just the shape values from 0 to 100, and not actual measurements. As far as I know, there is no way for that to be useful in any way other than being able to copy a shape. But at least someone realized it was a bad idea to be able to get all of someone's shape and physics values. People selling no-mod shapes must have been really upset, especially ones that have demos. I'm still shocked that no one responsible for llGetVisualParams really thought it through, when being able to copy a shape seems to be the absolute only use for it. If it's actually possible to put the shape values into some kind of formula to determine height, that would be great to know. But that would be the only real use for llGetVisualParams if that's possible, and no formula has been published anywhere. Without such a formula, the values are only relative to other values. It would be great to know if anyone else has actually discovered a real reason for it being implemented.

There's one for llRequestAgentData but it was a feature request in https://jira.secondlife.com/browse/BUG-225392 which is restricted and the release notes don't say what it is.

Does anyone know what the constant is for account level for llRequestAgentData (the analogue to the OBJECT_ACCOUNT_LEVEL constant for llGetObjectDetails)? It may be in https://jira.secondlife.com/browse/BUG-225392 but I can't access it.

https://releasenotes.secondlife.com/simulator/2022-02-02.568051.html seems to be the last public release notes. As of right now, my group's main channel region has been up for 14 days and is still on 2022-01-06.567269. It looks like main channel regions never got 2022-02-02.568051. Were the RC regions on 2022-02-02.568051 before 2022-02-10.568388, or were they rolled back to 2022-01-06.567269 before they got 2022-02-10.568388?

https://releasenotes.secondlife.com/simulator/2022-02-10.568388.html still says "access denied".

Was anyone ever able to look into how easy it would be to change the restart process to give more than 5 minutes notice? Changing it to 10 minutes would really go a long way to avoid work disruption when people need to take a bathroom break, feed a pet, etc. During group activities it would give a more reasonable amount of time to find another place for the group to go. Having 10 minutes notice would create a much more stable environment in general compared to only having 5 minutes notice, with no real impact on the rollout time frame. With an additional 5 minutes for the warning, nearly all regions would still complete the rollout within the current stated time window.