Jump to content

arabellajones

Resident
  • Content Count

    115
  • Joined

  • Last visited

Community Reputation

23 Excellent

About arabellajones

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. "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".
  4. As I said, Flash videos work under Opera, Firefox, and Chrome on this machine. But not with any viewer using Dullahan.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.)
  12. What part of "unreliable, undocumented, unmaintained hack" are you guys struggling to understand?
  13. 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.
  14. So the official viewer has a quick preferences window? I somehow doubt that's in the ancient Linux version they fob us off with.
  15. So the Firestorm developers decided to make it easily accessible for the users without any documentation.... I am not surprised. The latest version of Firestorm, the animesh beta, is misbehaving on Linux. Other viewers on the same version of Linux are not, and (I had to ask somebody to check it) the Win 10 version of animesh Firestorm is OK.. And JIRA as a bug-reporting tool is about as user-friendly as a rabid honey badger with a hangover.
×
×
  • Create New...