arabellajones

I would have preferred something more like "We are about to shutdown access to the Grid for several hours as part of the planned network maintenance." Yeah, that's British English. I suppose that if there had been a nuclear war, the BBC would have reported "One of our cities is missing." That, I think, is actually useful. The messages on https://status.secondlifegrid.net are rather vague

Incidentally, I know this web page depends on Linden Lab for the data, but it looks to be a bit more drastic than just stopping logins. Why not call it a full shutdown? https://e*****up.com/slstats/

I know this is the low concurrency period, but it's usually still about 2/3 of the peak around now. Europe has been waking up for a couple of hours. Reading this thread, I get the impression that the website and Grid logins were cut off some time before the Status page was updated, which is clumsy. At least now I have an idea how long I have to wait.

Even with the CDN and our own cache, we depend on getting the ID code for the content (usually a URL) before we can see it. And that has to come from Linden Lab, through their network. And it wouldn't surprise me if one of my bad login events was due to the old problem with attachments vanishing on a sim crossing. It isn't unusual to detach the vehicle HUD and see other attachments vanish. Is that down to the network they're working on, or a UDP packet getting dropped on the wider internet? I don't know, but that's the sort of mechanism that can mess things up. In the days before CDN, when UDP was used a lot more, getting a corrupted texture in cache was a problem. We have a much more reliable system now. I've said it before. Linden Lab documentation, and its cousin the Status Page, often feels like the bigger problem. When the message is "Logins have been temporarily disabled" it's not a warning. It's the middle of the night in California, numbers are low, it's the rational timing, but I'm not in California and it reads more like an "Oops" than a planned activity. But how much warning should they give? Would folk rush to log in? I'm told that we could have expected a four-minute warning of the end of the world.

My initial reaction to this is short and vulgar and expresses astonishment at why this isn't documented. How can anyone at Linden Lab be sure of what the code is supposed to do?

The basic tech was used, years ago, to generate messages for when people clicked on tails, ears, and such for furry characters. There are still several scripts for this on the Marketplace, but they are all very old, pre-Mesh. It's known as a "clicky". I know some rigged mesh add-ons can show a menu when they're clicked on. My own experience creating mesh is that mouse-clicks only get detected when a rigged mesh isn't attached to an avatar, which contrdicts what I see. So somebody knows how to make a rigged mesh react to a mouse-click. But nobody can point to any documentation, no example code, no guidance on mesh creation, it's just something they heard, but can't explain. I can make efficient, low-complexity, mesh clothing. I can examine a rigged mesh, and find some sort of mesh component that contains the menu script, but it all ends up unexplained and undocumented. Can anyone rely on an undocumented feature working after the next server or viewer roll-out? The Lindens do try not to break existing content, but how would they know about this? If people know about this, why can't they point to documentation? The Lindens have a problem with multiple names for the same thing. I might just have not used the right jargon as a search term. But why does nobody else seem to know the word? I feel as if I am wasting my time. I may check this thread again, but I wonder if it is worth bothering.

If it does work, there is definitely something more to it. I can link a prim to the mesh tail while it's not attached, but as soon as I wear the item, the non-rigged prim vanishes and doesn't return. It doesn't matter which of the two parts is the root. And it puzzles me that this use fails, but I can wear items that can be clicked on, and respond with a menu, which calls into question your basic idea. You can click on rigged mesh. If it comes to that, how is the viewer able to detect the initial right-click? I am not having coffee at this time of day, I need to get some sleep this weekend. But it looks like the available script tools pre-date rigged mesh, which makes it feel as though something big changed.

What you're saying does make sense. So where is it documented?

1: Basic outline. I have been trying to write a script which sends a message when somebody clicks on the object, started with a sample script in a prim. It worked. default { touch_start(integer num_detected) { key avatarKey = llDetectedKey(0); string avatarName = llDetectedName(0); llRegionSayTo(avatarKey, 0, "Hello " + avatarName ); } } Nothing remarkable there. Click on the prim, you get the message. Attach it, still does the same. There's the hand pointer used on mouse over, all as expected. This sort of scripting is pretty common for attachments such as avatar tails, or hats. It's often called a "clicky". There's a few tools on the marketplace. Trouble is, the tail I use is a rigged mesh, running an animation. The control, using different animations, is by a chat command. So far, so good. Rez the tail on the ground, add that script, and it all works, just like a prim. And then... Wear the tail, and the script doesn't work. You can get at the "touch" entry in the right-click menu, and that generates the message, but the position in the menu seems to change with whether you or somebody else is wearing the object. Maybe it can be said to work but this is, we may say, sub-optimal. 2: Documentation OK, I looked. Started with http://wiki.secondlife.com/wiki/Touch and the related pages. Nothing there. Tried to find whether attaching the rigged mesh was relevant., because the script worked when it wasn't attached. I started using other words than "sub-optimal". That web page is three years old, but rigged mesh was around when it was last edited. I speculated whether some Lindens are good for anything more than paying for coffee at the coffee shop across the road. 3: My system Yes, I usually use Firestorm. I use Linux and the only version available from Linden Lab is from November 2017. I did try the Linux version of Cool VL Viewer with no apparent difference. That's hardly a surprise, but anyone who asks me if I have tested this on the "Official" viewer, I wouldn't trust to drink hot coffee without a dreadful accident. As for the JIRA, I think the last time I mentioned Linux there, they called for an exorcist. 4: Conclusions The documentation may be incomplete, or it might be badly organised. It easily could be both. But if anybody does know of how a touch event on an attached rigged mesh works, can they let us all know? I can see a couple of possibilities, such as the script having to be in the root of the whole Avatar, but that would add complications. I gather that putting up a menu is possible, but I don't use any rigged attachments that do 5: Note on Animesh I have made this tail work as Animesh, but as an attachment there are several niggling problems. It can behave oddly after a sim crossing, for instance, apparently because of displacement of the distinct skeleton.. I haven't tested the touch event on any animesh, attached or otherwise.

I was a bit grumpy when the latest fix, rolled out grid-wide on Wednesday, seemed to make things worse. Things are looking better now, and my guess is that a restarted region needs time to settle down, that there's a lot of data still flying around the network. There's other things to it but it suggests to me that the dream of using the Cloud for Second Life is going to stay a dream. The possibility that a few older creators had fixes for some of the problems, and took them with them when they left the Grid, sounds all too likely. I don't do scripting, but I have seen some pretty secretive behaviour from some creators. It doesn't help when Linden Lab uses so many different names for the same thing. Something to think about: when I was making a very fast run between Jeogeot and Sansara, with an old sculpt-era plane at about 60 m/sec, there were occasional messages on sim crossings, warnings that the HUD was using a lot of texture memory. I'm not sure if an alternative HUD is worthwhile for that plane, so much is controlled from the HUD, but I have seen the same warning on quite ordinary HUD/Vehicle combinations. Mesh, done right on LODs, can be a much lower load, Display and Download, than Sculpts, and I have seen good updates of some things, but scripts and HUDs seem to be the hidden load on vehicles.

Since I am a Linux user, there is no supported viewer I can use to confirm bugs before reporting them to the Lindens, but it's interesting that Cool VL Viewer works better than Firestorm. I usually use Firestorm. They're always asking me if I can replicate the bug using the Linden Lab viewer. I don't know what the rollout today did. Sim crossing was OK at the weekend, started getting bad yesterday, and is horrible right now. Most of what I have seen suggests that the teleport and sim-crossing problems are happening on the network connecting Linden Lab servers. It could be my connection that's part of it, but today is the last day I shall be using it. Just when the change takes effect tomorrow, I don't know, but it will be interesting to see what does change, and what doesn't. I don't expect the internet ping time to change. It was a little bit slower when I used dial-up to Demon, The USA has always been over 150ms away. I tried an early VR demo, and that trans-Atlantic wet-string is a problem The lag from scenery loading should drop, but I doubt it will help on the Jeogeot-Sansar channel: all you can see on that is water. Oh, and Debian Jessie? The support on that ends next summer. I get the feeling that it's getting a little too old to be switching to it.

So the Status page is showing Rolling Restarts on the Magnum RC, while yesterday you were saying there would be and there wouldn't be. The only way we can be not allowed to change our minds is apparently if we voted in a Referendum. These things do happen. But I hope you can at least give us a straight story of what happened, when it's all over.

It looks like the same code as hit the RC channels last week, and I heard, somewhere, that this switched off the legacy UDP support for asset fetching, which means the Linux Spur, and the very old version of the viewer for old Windows, will no longer work. That change was mentioned for an older version on RC Magnum, over a month ago, and all the RCs are on the same, later, code version now, but the change didn't get mentioned. That's a bit slipshod. I think there was a mention on Inara Pey's blog, and I sometimes think, the way the Lindens seem to depend on her passing on this sort of information, that she ought to be paid by them.

"depreciation" is the fall in value of an asset, often an accounting fiction to spread the cost over several years in a way that is agreed by the tax collectors. "deprecated" and "deprecation" are probably what you are trying for, but it isn't the correct word for when you actually stop using a method. It's the word for the method being still there, but you're telling people to stop using it. You describe flash video as "deprecated".

As I said, Flash videos work under Opera, Firefox, and Chrome on this machine. But not with any viewer using Dullahan.

I've had some odd experiences with streaming media, and I am wondering just where this Dullahan thing comes from. It seems to be a web engine, handling all the various connections that the viewer uses, but while every web browser I have installed can still handle Flash videos, Dullahan can't. The usual solution recommended is to install pepperflash, which is the library used by Google Chrome, so I installed it. (That was a bit of a carry-on, many sites describe it as "deprecated") Things work on Opera, Firefox, and Chromium, but Flash doesn't work with the Dullahan system I found that test game on the home page used by the viewer's internal web browser. It works with the external browsers, not through Dullahan. There seem to be two possible libraries to use. Adobe Flash, which is on the way out, only getting security updates now, and pepperflash which is provided by Google, but only supports one of the two possible APIs. I have tried both libraries. They have worked with the three browser I have. Neither have worked. with Dullahan. OK, so Flash End-of-Life will come at the end of 2020, and that may be reason enough for the Dullahan developers, whoever they are, not to bother with this problem. But there are video sites which still use Flash. And if Dullahan can't detect a library that other web software can use, who should I be prodding? If it's not handling a library properly, what else might break? What's breaking the connection; Dullahan or the library? I have a horrible suspicion that Dullahan is something provided for TPVs by Linden Lab, but where do they get it from?

The problem with Standard Sizes is that they were an attempt to get around the problems that were solved with fitted mesh. They're from an era when people didn't know how to make mesh clothing that changed shape when the underlying body did. They're not a bad answer, just obsolete, but they also tend to over-emphasise the slightly caricatured body shapes common in Second Life. I use Avastar, and with that you don't need to use standard sizes. But you do need to use the correct devkit, matching the clothes to the mesh avatar. That can lead to problems. There are some mesh avatars which have no easily accessible devkit: either it doesn't exist, or the body creator is very careful who is allowed to use it. I've never tried Marvellous Designer, but the videos I have seen leave me feeling that it generates meshes with far more triangles than are needed. That pushes up the Complexity, partly from the number of vertices needed in the mesh, which needs more effort to render in the viewer, and a bigger file to deliver over the internet. I make my meshes by hand, and rig them with Avastar. I have the devkit for my mesh body, and I think I get good results. I think it helps that I have some idea of the structure of sewing patterns, which influences my UV-mapping. That sweater is UV-mapped so that I could use a tiled texture for the normal map. The panels are lined up so the structure of the knitting comes out looking OK, not like the UV map of the classic avatar.

It does depend on what somebody is doing, and what timezone they're in. For an example of activities that can be messed up by the rollouts, and they usually avoid rollout times, have a look at the yacht racing on the Blake Sea. Sim-crossing is an essential part of that, and if a sim goes down for a restart at the wrong time it spoils everything. Sim crossing also depends on the Linden Lab network, which is under extra load during rollouts. A little bit more progress reporting from Linden Lab might help. We just get a starting message and a completion message, no indication of whether the process is running fast or slow. I don't know if the RC rollouts are run one RC at a time, but if they are it could be useful to know when each is completed. Some of the don't-do-this messages are very generic. Don't rez objects, don't spend L$, things like that. They're playing safe, but there's a lot more in all this than just the restarts. And then we get something like Wednesday was, and Linden Lab's mushroom farming efforts go into overdrive.

It's certainly worth comparing the frame rates you get with ALM on and off, but it depends a lot on the graphics card. It did hit things badly when it was new. With a good card, one from the last couple of generations, I think you might be surprised.

Short answer: I am not a programmer. And when this debug function got put into the Firestorm Quick Preferences, nobody bothered to explain what this "alpha" value was for. Alpha channels can be used for other purposes than transparency, but nobody seems to know what it does here. It doesn't look all that difficult to make a duplicate of the function (is that what you call them) that is switched on by Quick Preferences and only returns the RGB data. But what do I know? I'm only a user.

It's how it goes from "Each component is clamped to the range [0,1]" to the displayed range that looks careless, and that doesn't get mentioned in any way I can understand. I'm guessing "llformat" is involved, and the "%d". And that's the detail that is totally missing from the Firestorm documentation. You can argue that GL_UNSIGNED_BYTE implies a 0-255 range, but nobody bothers to tell us. Likewise over what "alpha" means in this context. It's used in the ALM/materials settings for a different purpose than transparency, and that is defined. Transparency makes no sense for screen pixels, we're guessing that it's meaningless. My brain hasn't quite exploded yet over that OpenGL wiki page. It's very inclusive, but details are there. I wouldn't call it user-level documentation, but it is documentation.

Sure, it's there for testing, but nobody can point to any documentation. What the numbers even mean isn't clear, the first three are likely RGB, but the fourth? I see lot of different guesses. The alpha? That doesn't make sense, because how an a screen pixel be transparent? Yes, of course it's affected by lighting, but even on flat planes with unvarying textures there can be huge variations between adjacent pixels, with no visual difference. I think that can be fairly called unreliable. And if it was written as temporary code over a decade ago... I suppose there might be comments in the code. It would be silly if there were not. Has anyone looked? I suppose I could download the source, but that's an alien language to me, which happens to be written in a character set I recognise. I have tried to find if there is some obscure standard for representing colour with four numbers, which includes RGB. Yes, you do have CMYK in printing, it's a subtractive colour system, and the "K" is black ink. It's used because it is far closer to black than a mix of cyan, magenta, and yellow inks can be. If some of you guys working on the actual viewer software are using it, and know what the numbers mean, OK. If you don't know what the numbers mean, what do you get out of it? And if you can't be arsed to document it, why the hell did you put it in that easily-accessible Quick Preferences window for Firestorm? (Yeah, I am picky about documentation. And I do know programmers who can do it.)

What part of "unreliable, undocumented, unmaintained hack" are you guys struggling to understand?

What I am getting from all this is that "Color under Cursor" is an unreliable, undocumented, unmaintained, hack. If I want to find out what colour is used in something, such as for matching a skin tone, I'd do better to take an in-world picture, save it to my hard drive, and check that image.

So the official viewer has a quick preferences window? I somehow doubt that's in the ancient Linux version they fob us off with.