arabellajones

This isn't about the deploy plans, but it's the sort of inept notification which makes me wonder if you people can even read a clock.

Using an SSD does make a big difference to caching, but I have had a number of occasions when the viewer has switched back to the default location, for no obvious reason. So that's the first thing I check when textures are slow to load. I know, it shouldn't happen, but it does. And you can say that about too many things involved with Second Life.

So just when is 12PM? We've just had the British government making a hash of which day a particular Midnight is and I just wish the whole damn lot of you could stop using that time. Try using a 24-hour clock instead of AM and PM. And avoid timing anything at the 00:00 and 24:00 times.

This week looks to be cloud-related stuff, sorting out the servers, doing restarts. I'm hiding... We're not there yet, but there is going to be a time when "Cloud uplift" doesn't stand up as an excuse.

A couple of points come to mind which need clarification. 1: the use of the label "SLS channel" Is this replacing Main channel? The Status messges look to use standard wording and this would need revising if the label changes. 2: in the last report by Inara Pey it looks as though next week is going to be different (see Simulator User Group Meeting November 24th the Week #49 section). I'm not sure if this change is short-term or long-term. The Main Channel rollouts are a big lump, but the pattern was predictable for event planning. Try not to surprise us too much, OK.

"Samandjanet Evening" But that one is rather far north. I would have expected it to be in a more south-specific location.

There may well be a region called "Steeleye" which has a bridge in it.

I've said this before. It takes a while after restarts finish for the Grid to settle down. I'm nut sure when things finished today, it was a long time after April Linden's announcement that the end of the maintenance popped up on Status. Also, there were a couple of severe drops in reported concurrency in the last 24 hours, one at about 18:30 UTC. I was logged in then, and didn't see anything obvious where I was. I've come to expect high loads at weekends. Concurrency is already over 40,000, but right now would be a fair time to test. It's mid-range for concurrency. The Lindens have done a big job, but I got the feeling that the grid status page could have used some better messages. A couple of times I wondered just what was happening. I found out, the hard way, that Uplifting a region does involve a restart, but some of the messages were oddly worded. I suspect that when they used "the SLS Channels" they should have typed "all SL's Channels". That's me guessing, it was a new way of labelling things, and I feel I shouldn't have to guess. Anyway, things have worked out pretty well. I expect there are things still to do, some likely tweaks to the sim servers and other services, and there's the real world out there to worry about too. I'm in real-world lockdown where I am. I am planning for a lonely Christmas. I've had enough funerals this year. Wherever you are, be careful.

This is the sort of detail which I would regard as inadequately documented.

That's picked up by the same changed event that I pointed to. I can't figure out how you could usefully test for both happening at the same time, how they persist. Can two different triggers be tested for as a single event, or do you have to detect trigger_A, set a flag_A, and if trigger_B happens then check flag_A. Two different runs through the changed event. Does the order of the triggers matter? If you have a driver and passengers, and a passenger un-sits you will get a CHANGED_LINK, and nothing has gone wrong. I know vehicles focus on the driver, they often need to be the owner or have specific permission, and there can be pilot/co-pilot control transfers. So watching for a CHANGED_REGION, checking the currently-designated driver is in place, and handling that problem, may be a better answer than dealing with all the possing CHANGED_LINK options.

OK, I was asking about this "family of problems" a while back. Things improved. Several people were saying "you have to change the scripts", and a lot of vehicles use script packages without permissions to change the scripts. And some of the people saying that saying nothing at all about how the details could be changed. This time around, somebody said enough to point me in the right direction, still maybe not enough. You use a changed event with the CHANGE_REGION flag OK, I'm not a smart programmer like some of you folk, but the number of vehicle-program samples I found which bothered with a changed event can be counted on the fingers of one foot. The Linden Vehicle Tutorial doesn't even contain the words "region" or "crossing". Gentlemen, you disappoint me. Are URLs so hard to include? Anyway, it looks as if the root-prim script that has the changed event needs to have stored the UUID of the vehicle and the driver, and llGetObjectDetails gets the OBJECT_ROOT of the driver. If the driver is sitting properly on the vehicle, the UUID returned is that of the vehicle, root prim of the linkset.

The Wednesday activity has started. I am very confused as to what is happening on Thursday, with the various new labels appearing. Different timezones for me, but should I bother with anything planned before Friday?

Not too short, though. It depends what sort of load you want for testing. They're almost sandboxes in function. I don't know how long you'll need them for, but having an identifiable debug sandbox for MC and each of the RCs might be a good idea, even if they end up on the Cloud. Not worth fussing about now, but I can see there being some post-Uplift tweaking of old customs.

Tiny update: I just did a reboot on my internet modem/router after 28 days uptime. I have good hardware running OpenWRT 19.07.4 and it doesn't show any problems. Some of these boxes have had problems with SL in the past and, a bit like the servers, a reboot can sort things out. The downside for things such as ADSL and VDSL is that dropping the connection too often can be interpreted as a line-fault, and the connection speed is dropped to improve reliability. My last reboot was a momentary power cut.

There's at lest two different measure, with similar names. The viewer ping which can be obtained by the viewer and is shown in the Statistics Window includes any current delay from the servers. The internet ping is almost entirely the internet There are various services which try and test connections to AWS data centres round the world. This is one test of AWS servers and the numbers at the time I used that link looked scary bad, over three times typical internet ping numbers I don't know what to expect from the Amazon servers, I am used to the internet ping times. https://www.speedtest.net is a reliable service, and they have a server in Phoenix which is a useful check on the general internet. England to Phoenix is around 150ms, and I don't think that is far wrong for anywhere west of Chicago. On what I have seen today, the internet is running OK, but the Amazon servers are looking dodgy. But I know that some of these web-page stats services can be misleading. It's possible that I may have tried to use them at just the time (early Monday morning) when maintenance is being done. It's worth remembering that a lot of the internet ping has nothing to do with distance. My results give 20ms for about 150 miles, 150ms for 5300 miles. It's the IP switching at the nodes which dominates the timing. The number of nodes may be the same in a connection from Europe. A web page may give slightly different answers to the classic commandline utilities such as ping or traceroute I have a feeling that Google Search is misbehaving. One check can never be certain.

I know Linux makes the whole business tricky, because of what Vivox chooses to do. I have seen, a couple of times this weekend, error messages about SLVoice.exe unexpectedly closing. I am not sure if that message is sent from Vivox, Linden Lab, or generated locally by an obscure error-handler that uses an unchanged Windows filename. Point is, SLVoice seems to be having a bad weekend for some reason. But I think I shall stick with a viewer that can use a colour scheme which gives me decent contrast on text.

I just checked. the Firestorm v6.4.5 Public Beta loads OK for me. That has the original, now-superseded, EEP code. If there is a later Beta it hasn't been mentioned anywhere public, but the current EEP standard is so different that I can't recommend doing any building with this beta. It's useful to get an idea of what the tools are, but the look is misleading. (I use Linux, so STFU about trying the SL viewer.) I saw a passing mention of the problems with group chat getting in the way of in-game Firestorm Support, and the work on the next Firestorm release. I think Inara Pey mentioned it in her last report on the TPVD meetings. If in-world Firestorm Support is having problems, it might be a good idea to tell people if there are alternatives.

Timezones and everything, it's mid-morning in Battery Street, the weekend rise has started (I see 45k concurrency on one tracker),. Mazidox, write down that checklist, OK Mirror, signal, manouvre...

This pic is for Thursday, but it shows the general pattern. The shaded block is the 12 hours which starts at 3am Pacific Time, the times shown are for Europe, 9 hours ahead. The Lindens will have other data on what is going on, this uses the concurrencu figure that most viewers when they start up. Does the concurrency matter? It's always a bit higher over the weekend, and there are some things I am reluctant to do near the peaks. There are various groups which arrange vehicle-driving events, and region crossing when concurrency is high is usually bad. I reckon that peak and the following ledge is driven by residents in the Americas, but there is all the rest of the world.

I am wondering if some of the early reports, after any roll-out, are essentially misleading. The roll-out process has always put a fair load on the network. Some of that will be changing but regions were moving to the Cloud all day. According to status messages, from 03:00 to 15:00 Pacific time. Which is less than 12 hours ago, as I type. There's the normal daily load pattern as well. The end of that time block is when load problems are more likely any day, both the data-centre-specific network and the USA in general. That problem on Tuesday looked very different to any of my experience with lag. But how can you tell? We do have some tools. There are enough data centres in Phoenix that you can get some useful general indicators with tools such as speedtest.net but I am not sure what will be able to replace that (I did find that Project Sansar had significant AWS use from the start). There are ways, but what is normal? It needs time to learn what is usual.

Don't know anything useful, but the issue has gone to the engineers. So it must have needed more than a restart.

I couldn't get into Beaufort, Kendra, or Cattewater. Time of testing is 11:30 to 11:45

I suppose that Linden Lab are doing things today, more uplift going on... I don't think there's malice in the lack of communication. The big question is, can we trust them? I suppose the basic analogy is with driving. What do you call a driver who never bothers using their indicators?

I had a fun time getting voice working again with my Linux system after a breakdown. Not quite a new install, but close. Along the way, I noticed that the page the OP gave a link to is only the first step, the basic settings that should work. There is a link to the trouble-shooting page, but as a design choice I would have given it a bit more prominence, not a couple of highlighted words in a block of text, The troubleshooting page is Firestorm Voice troubleshooting It has specific instructions for Windows, Mac, and Linux. In Linux there are some fairly specific driver needs. Not for the first time, I wonder how ancient some of the kludges in viewers are getting.

The infinite loop is the obvious answer, and very problematic for LSL (I have been working through this.) Essentially, you can never get out of the loop. The trick is to put the repeated action into a timer event and then use llSetTimerEvent to start and stop. It depends on just what you want to do, but KFM can be an alternative, and doesn't need the timer event. If you want to change rotation rates it may have other problems. Don't forget that rotations in LSL use a 4-value vector, not the simple 3-value notation we see used in the editor. There are reasons for this, and functions to convert between the two. If you pre-calculate the numbers use the full precision. I tried using 4 significant digits for an object moving in a circle, and it slowly spiralled out from the centre. There's a piece of code in llRot2Euler that shows the various conversions. The chain of calculations would be worth putting in as comments. Comments don't slow the script. (There are fancier ways of doing this but comments are reliable.)