WolfBaginski Bearsfoot

Unfortunately the Linden-made viewer for Linux appears to still be an unsupported beta. And it doesn't succeed on loading on my system. Why, I don't know, and other viewers have no problems, both 32-bit and 64-bit code. I am a bit wary of recommending an unsupported beta

Unrigged mesh can also be made with any mesh editor program that exports a Collada file. You don't have to use Blender. I've done a few things with Wings3D. It's a lot less intimidating than Blender, but there are things it can't do. And there are specific add-ons for Blender to make rigged meshes for SL easier. It's a good idea to go for Blender from the start, but if you already use something else you don't have to change. Blender will import many file formats so it's worth having for that.

Historically, that actual announcement that planned rolling restarts had begun was always several hours after the actual start. It looked as though there was nobody able to trigger that announcement on the team which was actually doing the work. This revamp of the GSP amounts to lipstick on a pig. All that's been changed is the web page. The core problem of information flow is the same

The new style Status web page was pretty useless, nothing about this work until 06:55 PST, no pre-announcement, no calendar, and apparently finished half an hour later. I suppose there could be another reason for it, but there were sims showing as down on the minimap just now. It's an old complaint, I know, and I hope you can do better for Project Sansar. I find it hard to justify such hopes.

We do have the MC roll-out running, and that could be messing things up, but there was one sim that wasn't loading properly and then leading to a viewer-quit event. If that was roll-out related, and it could have been, I do wonder if a flag was being set before it should have been

The total allowed for a Sim has increased, but I get a strong impression that many sims have less land occupied, So the increased LI allowance may not be loading many servers above the old maximum. One of the things I saw was a low-occupancy sim with patchy appearance of land and linden-road textures, In some places the texture was loaded, in some it wasn't. So the texture clearly had been delivered, or was in my cache, but the data that put the texture in a particular place hasn't been. And there was no obvious pattern to the non-appearance. It wasn't obviously connected to distance or terrain altitude.

All good advice there. There was a JIRA entry on this problem but it has been closed as a duplicate. It's a duplicate of a JIRA entry we seem not to be allowed to see.

Since most textures are delivered through a cloud-like system, it's likely to be affecting some people and not others. I'm in the UK, and texture delivery has been good. Meshes, not good. On the other hand, sim crossing, which involve a lot of stuff on the Linden Lab network, rather than the wider internet, have been good. Nobody needs your postal address. it might depend on youe ISP's location, but country or US State would be useful info. I don't recommend being more location-specific than that.

It was badly announced, but "rolling restarts" could cover just restarting the RC sims, which may have been a good idea, and that appears to be what happened. Trouble is, that is different to what they usually mean by the term, and they don't seem to notice when their customers ask even simple questions. But since I don't speak American English, why should I care?

I saw the announcement on Twitter I know there's been some talk of revising the status page and getting this whole business more integrated It's about time.

I have to agree that things have been a lot better. I used to be able to fly non-stop long-distance flights. Not any more. Same plane, same scripting, far worse performance. No obvious relation to draw distance, or amount of scenery within draw distance Very high memory consumption assoiated with number of avatars in the region, reaching 6GB with a 64-bit version of Firestorm set to 32m draw distance, and the RAM doesn't get released. I can see why a viewer tracks position data for AVs in the same region, even when they're not visible. And somewhere close to 100MB per avatar seems excessive. Being told "It's you connection" is rather wearing.

What I am seeing is very prolonged sim-crossing processes, entering Sim A and not completed before hitting the Sim B boundary and a crash. It's affecting regions in all the channels Some of them are very empty Mainland, such as Fuschia. I am not optimistic about rolling out the new code on the Main Channel I do wonder if the higher prim counts are a factor. It's not obviously so.

Something to remember is that for small objects, the viewer may struggle to be close enough to see the highest level of detail. The boundaries are based on the object size, and for something like a shoe, it may be best to give High and Medium the same level of detail, because you'd rarely get your camera close enough to switch into High mode.

I am slowly losing confidence in the ability of Linden Lab to produce working software. Their Linux viewer is unreliable and still in unsupported Beta, all their viewers have, for years, have suffered from a horrible choice of UI colours, and the only way around these problems is to rely on one of the third-party-viewers.

I usually explain it by saying that Second Life is the stadium rather than the game played in it. When you think about the different sports that can be played in the same stadium, and the different other events that can be held, you can see how that fits. But "game" is a word with so many meanings that calling Second Life a game isn't so very wrong. And there are still places such as Universities maintaining locations here. So "game" isn't entirely right either. It's still a useful label for most of. We come here for fun.

Thanks for posting such a complete answer. I have some doubts about the current 64-bit Firestorm under Linux, it can use pretty mind-boggling amounts of memory, and using virtual memory can be a performance killer. But it does work. I am left with the feeling that without the efforts of TPV developers, Linden Lab would have crashed and burned years ago.

I have a suspicion it may be server-side, as it seems to be happening with all the viewers I have tried. Not often, but after a TP something attached to the avatar can vanish. It shows as worn, but it's not there. Right-click doesn't work, and about all that works is to detach and reattach. I couldn't try it with the LL viewer, as it crashes on my Linux system. To be honest, the LL viewer doesn't seem worth the hassle under Linux. It's incomplete (missing Havok code), unsupported, and has a UI that seems to have been designed by a color blind teletype operator. The way that TPVs just work under Linux pushes me in the direction of wondering if the Lindens know what they're doing. This seems to be another one of those glitches that we just have to live with. Somebody will say, "It's your connection!" Trouble is, from everything I hear these glitches may arise from the balance between HTTP and UDP. I know these things seem to happen when the CDN is delivering huge amounts of error-corrected HTTP data, and UDP packets from the sim server just get dropped. There are other places on the net that use HTTP/UDP combinations, but they're almost the opposite, things like HTTP for control signals and UDP for streaming video where the dropped packets don't break anything.

And here we are in September 2016, with pre-4.0.5 versions of the Linden viewer blocked, and forced updates, to a version that doesn't even get as far as the opening screen.

Yeah, third-party viewers... They don't get the new features straight away, not for any operating system. It's almost as if they want to test the code, and I am rather glad of that.

Thanks for the link. The info on that page is pretty old. There's a 2015 last modified date. but the last Ubuntu version is refers to is from 2013, and the context implies it is a new version that a fix might not work for And user groups accessed within Second Life are a bit useless when the SL viewer doesn't load. Anyway, why don't Linden Lab even bother to put a link to that page in the footnote where they tell us they don't support Linux? The various TPVs just work. They don't have to mess around with loading a set of 32-bit libraries (which I have anyway). And either the syntax for the cp command has changed rather dramatically, or some of the contributors know less about what they're doing than I do, Is Bento going to be worth trying to use any Linden Lab viewer?

According to the system requirements page, Linden Lab don't support the Linux version of their viewer. It's all left to community support, They don't provide any links. So where do I find that community support? I have checked, and my 64-bit Linux should be able to run a 32-bit program (although there are way too many Linux users speculating as to why people are still writing 32-bit code). There are several TPVs that are compiled for 64-bit Linux, though they sometimes fail in interesting ways that suggest a poor understanding of 64-bit memory management. But it's the Linden Viewer that has the new features that I want to try out. Anyway, where do I find this "community support"? Does it even exist?

Taken from the file "Fluffy%20Big%20Clouds.xml" supplied as part of "Second_Life_4_0_6_315555_i686", the Linux version. <key>cloud_scroll_rate</key> <array> <real>11.809999465942383</real> <real>12.799999237060547</real> </array> "not changed" seems synonymous with zero QA or maintenance.

I have asked people in-world, and they report seeing similar speed of cloud movement. They were using different operating systems to my computer, and of course had different hardware. I have examined the .xml files that contain the presets, and it looks as though the number shown in the UI as set for cloud movement is not the number that is stored in the file. The data-type is specified as "real", and the format used is consistent with the format specified for that data-type, but I not found any of the files giving a negative value for the scrolling. It seems that the original Windlight spec expects a value between 0 and 20, with the numbers shifted to give a range from +10 to -10, and a file-value of 10 representing a zero. Local RL weather has surface wind speeds of about 18mph, and the cloud movement is visible. The apparent movement of the clouds in SL Windlight is rather faster than that of an airliner on approach to the local airfield, suggesting a windspeed of over 150 knots. It seems incredible to me that nobody has noticed.

I have been trying various Windlight presets. I see very fast cloud movements. This is controlled by two Cloud Scroll settings, which are in the Windlight .xml that defines the preset. The highest value I have seen in any of these files is 20 (they define a vector for the cloud motion in the X,Y plane). In the editor window they are set with sliders. So far, so good. The trouble is that these setting provide a very high speed motion on my computer, which isn't particularly powerful. But, with a vector manitude of about 2, I am seeing distant clouds cross my field of view in about two seconds. I have not found any dependency on the Draw distance setting. Even if the clouds are no more than a 32m draw distance away, the apparent wind speed is Force 10 on the Beaufort Scale, which on land is described as "Trees uprooted, considerable structural damage occurs". If the clouds are further away, the wind speed is higher. I checked this with a couple of different viewers, though I couldn't even get the SL Linux viewer to run. It doesn't look as though they modify the Linden code on this. Firestorm has a magnitude scale of 0-300 on the sliders. On a hunch, I checked with Cool VL Viewer, which has the UI, at leat, based on the v1 code. The magnitude range is 0-10. The graphics engine follows the current Linden codebase, and the Windlight preset files are the same, giving the same rapid movement of clouds. So what's changed? Advanced Lighting has no effect on the movement. The clouds do depend on Atmospheric Shaders: turn thenm off and the clouds vanish. It looks like a mix of erratic UI design (the slider operation, and different viewers allowing such widely different ranges) and a change in the graphics engine that didn't get noticed.

So why this announcement? Announcement of Main Channel Roll It was made about five hours later, Did somebody forget to turn off a bot?