Miller Thor

Dec 11, 2019 Rolling Restarts for RC Channels Completed - The scheduled maintenance has been completed. Dec 11, 10:05 PST In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Dec 11, 07:01 PST Scheduled - We will be performing rolling restarts for regions on RC Channels on Wednesday, December 11th. Please refrain from rezzing no copy objects and remember to save all builds. Please check this blog for updates Dec 11, 06:47 PST Rolling Restarts for RC Channels Completed - The rolling restarts have been delayed until 7 AM PST. Dec 11, 06:46 PST In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary. Dec 11, 03:00 PST Scheduled - We will be performing rolling restarts for regions on RC Channels on Wednesday, December 11th. Please refrain from rezzing no copy objects and remember to save all builds. Please check this blog for updates Dec 10, 06:33 PST And what happened, ladies and gentlemen? .................. nothing. At least not on Magnum. Neither yesterday nor today. Linden should finally learn to honestly admit mistakes, or if they are unable to do something that has been announced. Nobody pulls their heads off if they are honest with the users, but this is how you, as a paying customer, only feel fooled.

Does Linden want to lure us with that Grid Status reports? At 3 o'clock they write the Rolling Restart is in work, at 6:46 there are delays, at 7 o'clock again the restart is in progress so that we get to read at 10:05 o'clock that the restart is finished. Stupid only that nothing happened at all and as usual the live chat is of course not available. Probably to avoid "annoying" questions. And for that we pay? So lets see what happens tomorrow.

That Rolling Restart isnt that i normaly know from a Rolling Restart and as usual the Livechat is not available. It took 1 1/2 Hours until our Region came back and that with a very low Scriptperformance so we had to Restart again to bring back a Scriptperformance witch we can see as "normal" .

@Bugsly Linden 2019-11-19T22:26:38.532992 A build of 2019-11-15T21:13:13.532828 using new build technology. …………………….. What exactly is meant by that? In that case, a more detailed description would be interesting, at least for experts.

Sorry i had pasted the wrong Name. Now its correct.

@Mika Palmyra Contact the Support via Live Chat and ask them to take a look on it.. Here noone can help you. Only the Support can restore your Items if needet.

@Maddy Gynoid The Link works now. I´ve still tested it Right now. For you also here. 2019-10-26T00:06:48.532192 Wednesday, October 30, 2019 Release Notes Includes a previously released hotfix to fix teleports being 5%-7% less reliable Made the simulator take a little bit longer to report as “Up” to our internal tools to more accurately reflect when residents can actually access a region Resolved Issues SL-12107 Simulator Doesn't Call For Help When It Can't Start SL-12075 Allow Dev Machines to Change Grids Without Restarting SL-12035 Investigate and fix simulator startup setting 'up' and 'down' status SL-11762 What Happened To Startup Mode?

Interesting. In long-term observations, we noted a positive stabilization and, consequently, an increase in script performance, which had more than a positive effect on the regional performance. From us, the last week rolled version could remain. And my wife and I know our regions only too well and know the performance to judge it. With the todays DOWNGRADE we lost more than 50% of the Scriptperformance we had before with 531693. Is that the will of Linden to keep us on low Level?

Why do we get rolled back to 531528 on Magnum-RC? 531693 works much better especially with the Internal Script Improvements.

In theory, the servers would not have to have any names at all. Even knowing the version number is n.e. not really important. It is sufficient to have the region name, or for advanced users, the estate ID and the date and time of the incident, in order to be able to access all relevant data in the database. Since not all problems are due to the region software, but often only affect one region, it is better to continue after this new procedure. Thus, it can first be checked whether it is a "local" error and this can be fixed immediately from the 1st level, or whether this is a bigger problem that must be assigned to the 2nd level. In this case, the opening of a ticket is necessary anyway. The main problem, however, is the user himself who either does not, very late or only gives very vague information about the region. It is important to sensitize the user so that, if he notices a problem, he immediately reports the problem, either in the form of a ticket, a jira or in live chat, notes down the name of the region and makes the time and a concise indication of the problem. Information like "in a sandbox where I was 3 weeks ago goes nothing" is absolutely incomprehensible and in reality unusable for support. That would be the same as saying, "In China, a bag of rice has fallen over." From adults one should actually be able to assume that they are able to describe a problem at least in such a way that it is also understandable for the other person, in the case of 1st Level Support. Well, you can't expect every user to be an IT professional, but most of them are in SL long enough to at least provide more precise information than "there's nothing" or "there's a problem you're to blame". When I look at some regions and then look at the statistics bar to see, for example, why there are such massive delays there, I usually realize why it is. However, the problem is not always with the region itself, but with the user who is located in the region. Scriptlag is not only generated by objects, but is also primarily burdened by the visitor of the region with 6 , 7 , 8 or even 20MB script load per person. Therefore, it is necessary to act as I described it above.

@Aishagain Every week the same spectacle with you. The only troll is yourself. You've now been told by several people what it's all about. Obviously, this doesn't go into your skull as the situation is. In the future, please let your frustration sit down, that not everything is as you imagine in your seemingly sick brain, go somewhere else and get on your nerves from me with your neighbors or anyone else. Get away with the existing facts or let it stay at all, but don't get on our nerves all the time. It's not your head, it's about logical and systemic facts.

It MUST not!! 2019-10-03T01:12:11.531528 is the long and wide declared version number with the time stamp of the compilation and the date below is a date automatically generated by the system that shows the date of the posting and can not be changed. Everyone knows when the respective rolling restarts will take place and, in addition, it will be announced again in the grid status. In this post here the start date of the respective week is assumed to be relevant and not the date of the respective rollout.

I know that our 2 Regions are both on RC-Magnum so it was smple to find out witch Version we got. 😉 Even if the server information is no longer officially displayed, nothing has changed in the server version on which the region is located. It is simply no longer displayed, but generally only displayed as an SL server. @Whirly Fizzle I'll even give you it right. It used to be easier for the simple user, but once you realize that only the last sequence of numbers, which is already familiar, is relevant then you also drive well with the new system. As I said. The timestamps have only relevance for the defs. For laymen, the last sequence of numbers counts entirely. For more informations About the ISO-Timestamps read https://releasenotes.secondlife.com/version_numbering.html .

Last Week: Second Life Server: (No roll) Second Life RCs: https://releasenotes.secondlife.com/simulator/2019-10-03T01%3A12%3A11.531528.html https://releasenotes.secondlife.com/simulator/2019-10-03T01%3A23%3A43.531529.html 531528 was on RC-Magnum last Week and this Week it got released on Mainchanel. This Week https://releasenotes.secondlife.com/simulator/2019-10-11T18%3A12%3A36.531693.html comes on all Second Life RC-Regions so it can be released on Mainchanel next Week if there are no Bugs. The Timestamps shows that Time when the Version was done local and went into the first Testing on SL-Betagrid before it comes on the RC-Chanel. For normal User the Timestamps are not important cause they are only important for the Defs working on it. Important to knwo for normal User is only the last number. In that case 531693 for the RCs this Week.

And now we turn on our brains and think logically ............. One version number indicating Second Life RCs can only mean that this time all RCs get the same version. If there were different versions for one or more RC versions, Caleb would have written it for sure.