arabellajones

Linden Lab don't support Linux, so the usual "submit a JIRA" response you get from Firestorm Help doesn't work.. Wolf, I don't think the Lindens like you using language like that, but I have seen enough Cupid Stunt engineering from them that they ought to get used to the abuse. gstreamer 0.10 is not longer maintained. Why are they (or Vivox) throwing around an SLVoice that still needs it. almost five years after that was announced? It's like expecting us to use Windows 8, dammit!

Meanwhile, I found instructions for loading gstreamer 0.10 that worked on Mint 18.3, running kernel 4.13.0-45 gstreamer 1.0 has only been out for over four years. $ sudo apt-get update $ sudo apt-get install libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev libavcodec-dev libavformat-dev libavutil-dev libswscale-dev freeglut3-dev libasound2-dev libxmu-dev libxxf86vm-dev g++ libgl1-mesa-dev libglu1-mesa-dev libraw1394-dev libudev-dev libdrm-dev gstreamer0.10-ffmpeg It looks as though SLVoice can't be updated by TPV developers, it's provided by LL and uses a Vivox source. I've seen several people, across the net, saying things like install gstreamer v0.10 but this is what I did, on this system, and it works. It's a pity SL15B is almost over.

The pixbuf quote shows a developer compiling and releasing a version of the Viewer that looked for code in his own local directory, on his own machine. The names are a bit different, but you can make the same stupid mistake with Windows. And I wonder how it ever got past testing.

Further to my original problems with the dependency on voice... If you're using Linux, you can forget about voice. I Tried installing a different viewer, and got this error on install. (do-not-directly-run-kokua-bin:58120): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/home/nicky/3p-gdk-pixbuf/stage/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command gdk-pixbuf-query-loaders > /home/nicky/3p-gdk-pixbuf/stage/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache to make things work again for the time being. For those not familiar with Linux, "/home/nicky" is a home folder, and whoever "nicky" is they have distributed a program that expects to find that particular folder. I think you Windows users have something similar with "c:/users/" instead of "/home/" (I did have an earlier version working, decided that until they could provide alternatives to the rather manky default SL colour scheme, it wasn't worth bothering with. Then I went off and compiled a driver, put it in a .deb, and tested it. Everything worked. I know a vierwer isn't that simple, but at least I tested it on a different machine!) If it's a choice between Windows or Voice, I do have an alternative. https://youtu.be/GagAO2dyNPU

Yep, that's the SL15B I'm talking about. There are LL-arranged shopping sims? I'll spend my money on another bottle of rum.

I have had a bad day at SL15B. Some things mostly my problem, but there are things the people running SL15B could have done better. 1: I am struggling to get any sound out of voice, even though media streams and other sounds work: my problem, but they don't bother to tell you which events depend on voice. (I tried three very different viewers, all of them failed to detect the sound hardware on my computer for Voice.) 2: Very limited info on live performers, who at least do sometimes use media streams. I do see "More details" links on the calendar pages, but they open generic Google pages on setting up the calendar. I am worried about linking my SL account with my Google account, again the SL15B people seem unable or unwilling to explain what they're doing. 3: Poor signage, generally. Yes, there are things such as the SLURL pages and the parcel names, but trying the Pod Tours was bewildering. The common theme in all this is bad communication, and there have been hints of this all though the run-up. That's not all been the SL15B people, but Firestorm was giving me announcements about performer auditions long after the auditions were over. The final straw for me, and very personal, was a music performer opening with a song that was promising me my own personal Jesus. It was a bit of filler while the staging changed, but when he started the set proper with a UFO conspiracy song I decided to get my own personal rum bottle instead.

I am wondering who said "Further, Arabella, this is not your first rodeo, you know what LL are like over matters like this..." Pot and kettle, baby

It's all very well talking about being prepared, but it's the 29th May, support is still down for Memorial Day, there is nothing announced on the maintenance schedule, and sims are being restarted. Did somebody leave a cron job running?

It's not that difficult to be GDPR-compliant, if you're not passing personal data to other persons, and if you're not collecting data that isn't needed to run the game. One example I came across: a mail-order company was saying they couldn't send you info about the delivery unless you explicitly consented. Lawyers are rumoured to be giggling helplessly at that one. It's what they call "transactional data". It's like claiming people need explicit consent before they mail you a letter. The new Linden Lab Privacy Policy, and it was very last-minute, is a horrible piece of writing, but the core is simple enough. There are several linked companies that handle our data, they have to follow laws to safeguard against money laundering, keep records, and give access to law enforcement at need. But, key point, it's all for a purpose, and they're not passing it outside the group. I learned the basic principle of writing such stuff at school. In journalism they call it the "lede", the short summary of the key details of the story, though there are a few differences. You might call it an "abstract" or a "summary", and you don't bury it in legal verbiage. You make sure you start with the ladies of the harem of the court of King Caractacus, not with the fascinating witches who put the stitches in the britches of....

Here in the EU, there is a big change coming tomorrow in the law on data protection. You may well have had a flood of emails about changes in privacy policy or asking you for explicit permission to send you marketing emails. And there is every sign that some of these outfits do not understand either current law or the new GDPR. There are some games in SL which use an external server to store information about players. I have some reason to think that they may have to comply with the GDPR, since some of the players will be resident in the EU. The notorious Bloodlines game is the one I have heard of most often, with players "biting" other players, to building up a pyramid-like network of power, which needs to be recorded. Can they comply with the GDPR?

I know Inara Pey's Modemworld blog has reports on progress on these schemes. It's still a long way off. The Bakes-on-Mesh idea lets you put several textures on the same mesh, and that could make mesh figures a great deal simpler to render in the viewer, which would increase the frame rate.. It's the same core process as for the classic avatar and system clothing, but there is a critical detail that everyone seems to be missing. Is the UV mapping compatible. That defines where a point on the 2D texture appears on the 3D model. If the UV maps are different, the results will look broken. So the textures, including the alpha map, will have to be for the specific model. I am not sure I understand what Bitsy said. Having an alpha-map for a mesh body will open up the possibilities, let you do similar things to what you can do with the classic system body. But it won't let you use a classic-body alpha map on the mesh body.

I struggle to cope with long videos, especially those with minimal scripts. Few can match the qualities of a professional TV documentary as a way af, essentially, telling the story. I'll wait for something written, preferably from an official source. I was looking around earlier, and outside blogs were talking about some sort of follow-up being produced and yeah, I know, time zones. Monday morning hasn't started yet in Battery St. But I did a bit of looking around, and you're making the ancient Spartans look garrulous. Hmmm, am I being too laconic there?

Switching to use mesh-object size for rigged mesh is going to be really stupid. The outfit I have been working on has several components, things such as separate pants and boots, and there's about a 4:1 range on mesh-object sizes. The current system miscalculates, doubling the distances by how it measures the bounding box, but having a standard distance applied to the whole avatar makes sense. Bounding-box size seems to vary, in ways I don't see any reason for, same avatar, same worn items, loaded at different log-ins, but that 2:1 miscalculation would change the base from around 4m to around 2m, which is about the avatar visual size. That wouldn't wreck the visuals. Another 2:1 factor would give usable results, though I'd have to re-import to get adequate visual quality at Nearby Chat range. In all this, the AVC number needs to be calculated on the distances used. To be honest, it astonishes me that this wasn't picked up in testing and development. One explanation, consistent with what I see of SL and elsewhere, is poor documentation, and I shall extent that to include the initial specification

And they call the distances two different things in Firestorm... "LOD Swap" "LOD change boundaries". Why do you smart people try to confuse everyone? Anyway, Penny Patton wrote " the reason it looks the same at a distance is that rigged items are always displayed at their highest LOD level", which is not what you're describing. You are saying that the distances are set high (which I knew about), but the system works. As I recall from the JIRA I read, some Linden programmer used a different function. The one based on mesh-size gave a radius-like measure, the one used to get the bounding-box size used something diameter-like, doubling the number used to calculate distance. Anyway, if I can rely on the numbers Firestorm reports for LOD Swaps, those apparently crazy triangle counts I use for Low and Lowest make sense, and the AVC I get, compared to the avatars around me, is still a valid comparison. It just breaks the relationship between AVC and Display Weight. My avatar will be at 100,000 when most people will be pushing the 1,000,000 mark. The slider to adjust your AVC limit is going to need fixing. It's already awkward UI design, and distinguishing avatars over about 250,000 is already difficult. (Firestorm, or the bounding box it's measuring, isn't giving the constant result I'd expect. Same avatar, same attached items, same camera position, the "Object Radius" varies between 3.8 and 4.2 How can I not have doubts about the programmer?)

I can get the same sort of change in other modelling software, though they don't give exactly the same result. It's a smoothing process done in rendering so that a less complicated mesh can look good. Getting from the mesh, un-smoothed, to what people see in SL, is what you have to learn, things like how you get sharp edges. One element is the crease-angle setting on import. Using it will decide whether a mesh cube is shown as a rather amorphous blob or not. Facet size can be a factor in how it looks too.

So where is this documented? Has somebody submitted a JIRA on this? Or do we have to picket Battery Street? I know that from, say, a hundred metres away the avatar is a tiny number of screen pixels. If it comes to that, Firestorm has added a tool that reports the triangle counts and LOD transition distances. It includes the feature that affects rigged mesh, using the avatar bounding box as the base for the LOD distances, rather than the mesh size. Are those clever programmers wrong too? I see a lot of rumour, and a lot of crap mesh, and I hear a lot about the Lindens talking about new features. I work on what I can see. You can duplicate what I do. Where's your evidence?

There's a couple of things I do. 1: Use the wireframe view. It's a judgement call on the mesh density, but I get good results without the mesh looking solid. 2: Work out how big the polygons look at a distance. I suppose some people are using huge monitor screen with huge pixel counts, but what will you see if a polygon is smaller that a screen pixel? Since Firestorm introduced the LOD display in the object editor, showing LOD distance and triangle counts, I've been keeping complexity/display-weight well down on the clothing I have been making. As for whether those tiny triangle counts at Low and Lowest LOD, dragging down the complexity, I am not sure it is cheating. You really can't see the detail. These are the number for something I made this week, a pair of long boots. LOD Level Triangle Count Transition Distance High 2408 Medium 149 14.4m Low 18 57.8m Lowest 9 119.5m Lowest LOD may be too low, and I wouldn't argue against a higher LOD for Medium. Firestorm defaults to a higher LOD setting than that, doubling the ranges. Anyway, my monitor is 96 screen pixels per inch, which represents about 8mm at 20m. And you need the polygons to be several pixels across to really see their shape. The Medium number looks a bit small, but when I pull my camera back to 20m, you really can't see very much. (why 20m? That's when the name-tag over your head vanishes.) Classic avatar, complex mesh, or my work, they all look the same at the longer distances. Anyway, that is the evidence that led me to my choice. Where you decide on is up to you, but those ultra-low LOD numbers aren't a cheat. (A normal height avatar is about 30 pixels high at the transition to Lowest LOD)

If I can't trust the numbers for the LOD distance that I get, how can I judge whether the detail of the lower LOD models is too low? That's part of what I do. I am told that the Low-Lowest switching distance on the rigged mesh I made is 107.1m (I love the excessive precision...) which means it subtends about 3 milliradians. Figuring what that is in screen pixels depends on the physical screen and the actual angle of view (a lot of people confuse zoom and dollying, and right from the start camera distance changes have been wrongly called zooming in the documentation). I've never found any plausible numbers for the default angle, but, from the Mini-map in Firestorm, and the view indicator shown, it's not far from 2 radians. With my screen, and erring on the side of detail, I decided 3 milliradians was 6 screen pixels. Yeah, excessive precision. The difference between 6 screen pixels and and 5, at that distance, is about 18m Anyway, when I dug through the JIRA I found a bug report suggesting that some Linden had used the wrong calculation, and doubled the switching distances for rigged mesh. And I read the conclusion as that nothing had been done to fix it. But if that is the way it works, where is it documented? Where's the link from the LOD explanations to that particular JIRA entry? I can see the point of all rigged mesh on an avatar using the avatar bounding box as the base for the LOD switching, but when you dig into it, it's the radius of the bounding box. OK, but then what about people who want to do the giant robot thing? Use the largest bounding box of the set. It still makes sense, but it's all rather pointless if you don't bother to tell people. Apart from the giant robots, just using the avatar height would work pretty well., but how quickly can you get that number?

I have been making some rigged meshes and getting low ARC, with decent LOD distances. And using low triangle counts for Low and Lowest because I can work out the triangle size is smaller than a screen pixel at that distance. Now some of you guys are saying low triangle counts are wrong. I have the feeling that a huge part of the problem is crap documentation, internal to Linden Lab and published. Can I trust anything on this? Can I trust you, J. Random Linden, or my viewer? At least I can say that I have tried to keep triangle counts small.

I think, after reading the whole thread, that what you missed here is that pink textures are an expected sign of problems with the texture download process. You say it later, and you obviously know about it, but you just couldn't be bothered to mention it. That JIRA might be an example of when you can expect to see it, but there is nothing at all about the causes that is limited to old drivers or a particular brand of graphics card. The first three lines of your reply are just pointless, unthinking, blather, as if you'd just searched the JIRA for "mostly pink screen". Why are you surprised at the responses?

There was certainly something affecting image downloads during the DDOS, and I ended up with two copies of some uploads. I don't know what is handled as UDP and what as HTTP, but I do know that control messages are mostly UDP. It's not yet over, I think, some inventory changes didn't get through yesterday. The textures were there, but a couple of object edits hadn't stuck. I do have a spare viewer, using a different cache and settings folder, to help check on such things.

The DDOS attack at the beginning of the week was having effects all over the internet, although it might have been hard to distinguish between problem covering the whole internet, and something to do with the ISP and your connection. Something needs to be done about how the Dashboard page handles this sort of news. The timing of the blog announcement can be questioned but, when it was made, it didn't get tagged on the Dashboard. The Status page sometimes seems a bit silly, such as when Support lines being closed on a public holiday is described as "maintenance" (I suggest "scheduled event" for things such as that), but at least we knew something was wrong at SL. Remember, what happened, the DDOS, wasn't the fault of Linden Lab. So why did they seem to hide it? The use Twitter to propogate status messages, but all we got was that they knew logins were failing. Yes, they were busy, but it looked as though they didn't care.

Thanks for the info about viewers. Meltdown/Spectre slowdowns can depend a lot on the particular program and what it does. I'd be more worried about my web browser than my viewer, and maybe you should check how your viewer is set to handle web links. I know my web browser gets security updates. I am not so confident about SL viewers. I know the "bitcoin miner" label is a bit misleading, but the whole cryptocurrency thing is making good graphics hardware expensive.

I have a vague recollection that Viewers used to be single-core, like a lot of other software. Multi-core processors would use one core for the OS, one for the Viewer, and while the OS wasn't monolithic, and the viewer could do some things through SLPlugin.exe, SL still gained most from raw clock speed I know we finally have 64-bit code now, but does it use multiple cores and threads (and what does the Meltdown/Spectre stuff mean for SL). I really can't recommend running SL in less than 4GB of RAM, and Firestorm definitely runs better in 8GB, I find I need more that 4GB of RAM for Firestorm and my OS, and swapping to disk can be a killer. Either the SL Viewer is terribly old-fashioned, or the documentation on these things is badly out of date. Do I go for clock speed or more cores? And what sort of affordable graphics card is there out there? This machine works, but it's getting old.

I am glad my Linux box doesn't use UEFI... nVidia 384.111 is part of the Meltdown/Spectre patches. I think it's the same version number for Windows, but it might not be. There have been a lot of patches. There's another one out for the kernel: 4.0.13.0-32