Rolling Restart : server version 1.25.3 / 1.25.4

Gah ... I had done as requested on the SL Grid Status post and asked to add my region to the pilot roll (BNJ RP Island) through e-mail to Prospero ...

... region didn't get changed over. Was I too late in the request? The list suddenly too long?

Oops.

My mistake.

I added "BNJ RP" to the list, not "BNJ RP Island"

I will convert BNJ RP Island over.

Thanks a lot Prospero - much appreciated.

You know, every time you say we need something done, you NEVER take into consideration that a lot of us don't have the freaking money to go out and get a new graphics card just to keep up with these lil things you want to put into this world! Why not start thinking with your head...the one on top of your shoulders? Every time someone wants to enjoy this world you created for us, our computer kicks out from under us cause of all these insignificant things you put it. QUIT MESSING WITH THE GRAPHICS...plz.

Pathetic
Totaly Pathetic

Um, Windchaser, the rolling restart has nothing to do with any graphics update.

Second Life is messed up bad. Are you going to roll back now?

Higher increase in sim ping and getting packet loss of 10%, has the high load returned with 1.25 server code?

New server version is in my homesim breaks quite a lot of my avatars that need a AO to work. Seawolf dragon, the Werehouse quads, some Grendel avis...

JIRA, Fox?

If you have a high ping sim and high packet loss, that's almost certainly a problem in the network somewhere, and doesn't have to do with the new server version.

Re: the regular problems, they're the same as we had yesterday, the day before... database load. Yes, there's some changes in 1.25 to reduce that, but we have more that need to come still.

I script for the WereHouse avatars, and just tested the quads and dire avatars on 1.25.3. Both work perfectly fine and only need 2 or 3 animations to be played at once. IMO 11 animations is enough, and avatars based on deformed animations should not be used.

Problem with deformed anims is the only fixes are a specific undeformer or relogging, thus I believe deformed anims should be considered a bug and fixed. Any product that relies on them could potentially be broken. Yes avatars that use deformers may come with specific manual undeformers in case the avatar doesn't shut them off properly, but the user would still be deformed for a while. Plus, I've seen a deformed animation avatar on a friend, when he switched to another avatar the deformed anims were still playing on my end, but he thought they were stopped properly and didn't see anything unusual.

I'm not saying that the anim count shouldn't be increased, just that deformed based avatars are basically relying on a bug in the animation system.

It seems that avatars that rely on more than eleven simultaneous animation are not working on 1.25.

If content creators don't bother to test on the beta grid, they can expect nasty surprises like this. I say the fix for this (if it's going to be fixed) should go into the normal pipeline like everything else. A heckuva lot more content will be fixed by 1.25 than is broken in this issue.

I agree, the physics issues and other bugs being fixed in 1.25 affect more people that the 11 anim limit will, and have been in the waiting list for over half a year.

We certainly wouldn't unroll 1.25 because of this. There was some vigorous internal debate as to whether or not the 10 limit should be raised. However, in the end, it will be raised to about 30, and the raised limit will go out next Mon/Tue.

We also have some new crash bugs. They're not HUGE crash bugs, but they do raise the simulator crash rate somewhat. We will either roll those out next Tue/Wed, or in a 1.25.4 roll the week after, depending on how fast we can get them fixed. (There are also some database load mitigation changes that will be going into 1.25.4, so we'll do 1.25.4 in any event.)

This does mean that the pilot regions will need to be rerolled on Tue or Wed next week.

Thank you for the wonderful news, Prospero! Glad to hear it.


One of two conditions must be met for an avatar to undeform properly:

1) Anyone nearby needs to be looking at the avatar when they undeform.
2) The avatar must leave the loading range of nearby people (512m maximum in the default client) and return. This "deruths" the avatar, forcing their mesh to be reloaded.

There are other issues with deformation, but guaranteed undeforming is not one of them. If you have any questions about deformations, feel free to IM/PM me. I'd be happy to help you understand them!

Yup, which is another reason why avatars should not rely on deformations unless LL makes them work properly like other animations. But anyway that is for another time and another thread, as this is offtopic for this thread.

The problems are that:

1.- Not everyone can afford spending hours long on the beta grid to test every and each of their products in the hope that all the new bugs will get triggered: some bugs may take hours or even weeks to show up, such as the Mono crashes on v1.24 servers: v1.25 supposedly fixes this issue (https://jira.secondlife.com/browse/SVC-290, but only time will tell, in the long run: not seeing it happen for a contents creator on the beta grid is not a proof it will not happen once on the main grid (simply because there will be millions more "testers" on the main grid, spending hundreds of millions more hours running scripts).

2.- Most often, your inventory on the beta grid is weeks or even months old and you therefore can't test your recent products or newer versions of older products.

3.- Unless you are lucky enough to have your own home sim reproduced on the beta grid (and it is not months old over there), you cannot count on having all your products rezed on your parcel in the beta grid and let them run there for a few days or weeks to achieve long term testing. At best, you will find a sandbox on the beta grid, but sand boxes are wiped off regularly, and you will not get the parcel permissions you have on your own parcels (may be critical for scripted objects needing group deeded parcel to run, or having to belong to the parcel owner).

4.- There is no guarantee whatsoever that the version on the beta grid will be rolled out on the main grid, and there is no log of what bugs have been already fixed or are going to be fixed before the actual roll out happens (i.e. we'd need to know what Lindens are working on before bothering with bugs that are already fixed internally to LL).

5.-Running tests on the beta grid is unpractical, because you cannot communicate with other contents creators (via your friends list) or your customers (via support groups) over there. When on the main grid, it's easy to ask for someone else if they can notice the same problem, on the beta grid, you can't.

6.- In the 11 (actually 9 user anims only, instead of 21 in v1.24 !) animations limit example, this change was *not even documented* in the v1.25 servers changelog/release notes (http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.25): how can you expect contents creators to *guess* that such a change occurred (and therefore to worry about testing the products that could be affected by it) ?



I don't agree at all, and serious software creators won't agree with you either: this bug is called a regression. Even worst, it is a voluntary regression (something someone at LL voluntarily changed without telling to the users and contents creators, and without even worrying about the possible consequences): all regressions in beta software shall be fixed without any delay before the release is done, and especially when such regressions break existing contents !

LL allowed an heterogeneous main grid (i.e. allowed several versions of the server to run on the grid): if they want *serious* testing of beta servers, they should run them in sand boxes on the main grid: at least, contents creators could test their latest creations/versions and/or hang out and wait for bugs to happen over there, without having to isolate themselves in a beta grid where they can't even communicate with others.

Henri, if it's voluntary, then it's not a regression, it's working as designed.

Otherwise, it's a new issue, and should go to the end of the line behind other issue. If it is deemed to be a bug, the bugfix goes in the pipeline.

Developers who relied on this were warned many months ago not to do so. Now it's bit them. If somebody "doesn't have time" for beta grid testing, their content needs to not rely on corner cases like this.

And I'll hold my own view as to who a "serious content creator" is and what their thoughts on this might be, thank you very much. That argument is an example of the "No True Scotsman" or self-sealing fallacy. http://en.wikipedia.org/wiki/No_true_Scotsman
In *my* opinion, a serious content creator tests edgy content on the beta grid, because it's edgy.

Anyway, Prospero says they're not unrolling 1.25 because of this, so I'm satisfied.

By Lindens?

Using more than 10 animas is not an edge case. Maybe using close to yesterdays 21 anima limit might have been.

Btw I'm on the beta grid almost daily wearing a AO stuffed with animations and only saw it hiccup once. At the time I couldn't repro it so I moved on. Nor could I find any mention of change to anima sorting.

Prospero, someone mentioned moving beta code to the sandboxs to get more traffic using the code. Seems to me, this would be a great way to preceed or replace the pilot roll. You'll still need the beta grid for secure testing of new code, but I think using "latest" code in the sandboxs would expose unexpected changes like this very quickly.

I think that's a great idea. In fact, isn't Skidz Isle on the pilot roll already?

I am not sure about skidz, great if it is though. I'm more sugesting linden sandboxs on test code. This way anyone at anytime can test their stuff without having to isolate on the beta grid. =)

While I'm at it....I would love to have a viewer sim icon that comes up when I am in a pilot rolled region. I know I can look in ... About secondlife. It would just be nice if it was obvious what code the region is running.

The way to figure out what version a region is running is, when you are in that region, look at Help:About Second Life.

Right now, if it's in a pilot region, that version will be 1.25.3. If it's an a non-pilot region, that version is 1.24.10.

Re: beta testing and all of that, hooray for you if you can enumerate a huge number of reasons why it's hard for you to test anything. However, the reality of the situation is that Second Life is an amazingly flexible and powerful platform for interactive immersive massively multiuser content creation, unprecedentedly so. The next reality of the situation is that there are something like a few hundred thousand active residents, a non-trivial fraction of which actively create and use content, and only about 300 Lindens-- and very, very, very far from all of those Lindens are people who are dedicated to testing code. Put those realities together, and there's no way that we can conceivably test everything that all of the creative residents have put together.

So, in the case of the animation limits : this was a SEC issue whereby griefers could crash sims by using lots and lots of animations. So, we put in a limit-- a limit that some developers *still* think is plenty high enough, and are grouchy about raising. We tested lots of AO type things with it, and didn't see problems. As with anything, it's not entirely surprising that there's more diversity of content out there than we can know about, never mind completely test.

So. Put all these things together, and the reality of the situation is that if you're really worried about some things, it is not a terrible idea to jump into aditi during the weeks we're beta-testing a new major release, and spot-test your stuff. How much time do you spend creating and writing that stuff? Isn't some small fraction of that time you spent developing it in the first place worth testing it as the rules of the world change? After all, when new video cards, new hard drive controllers, etc., come out, people who develop operating systems (be they Microsoft, or Linux programmers) often have to check their stuff out, and maybe even modify it, to make sure it works with the new stuff. Granted, the parallel isn't perfect, since with Second Life you don't always have the option of "just stay with the old version." But the world of comptuers is constantly evolving, and rapidly so right now, no matter where you are in it. Linden Lab is doing everything we can to avoid regressions. That's WHY we have public betas open to all of you, and is WHY we do pilot rolls nowadays. I would suggest that the time it would take to jump on to aditi and test things is time better spent than the time it takes to enumerate reasons why you don't want to do that.

Regarding inventories being out of date: right now, it's at most a couple of months. If you have a particular problem, jump into the beta testing form, or drop by the beta testing office hours, and ask us to refresh it. Unless and until we get overwhelmed with such requests, it's something we can do. (Note to all: please don't take this as an invitation! Only ask us to this if you *really really need* it. If you start asking us to do this, it takes time away from the other stuff we need to do.)

No, we can't get every island over on the Beta grid. We can get some (and do have some). But there are lots of sandboxes over there. Rez your stuff and try it there. Or, if you have a lot of users, ask them if some of them will try it; it may be that you've got some customers who don't mind jumping to the beta grid and trying stuff out. Also, all of you, try out other folks' stuff. You are certainly allowed to try out the things you like to use, not just the things you created, on the beta grid!

Re: putting main-grid sandboxes on beta versions: we've thought about that. Occasionally in the past we've done that. We're hesitant to do that on a regular basis, just in case there's something in the not-through-QA new version that might cause problems beyond just the region itself. We will probably not be doing this as a part of our regular procedure in the near future.