Oz Linden

A couple of quick items… Linden Lab employees have a holiday from December 24 through January 3 this year (what can I say - it's a great company to work for), and some have added a bit on one end or the other of that with vacation days. Some of us will be monitoring this thread during that time, but we probably won't do any deep analysis of issues raised until after the holiday. We're not going to rush this feature out - there will be plenty of time for discussion and consideration of each issue. At the risk of repeating myself - please try to make thorough examples that illustrate whatever problems you see. By that, I mean: provide model and animation files that we can examine and experiment with. A screenshot or a video is fine along with those, but by themselves they are really not very useful. Along with those files, provide careful descriptions of what you think should have happened and how that differs from what you see actually happening. Try not to assume that we know anything; avoid references to "the SOMETHING bug": we may not have the same idea you do of what SOMETHING you mean). Make sure that you do all testing on the Project viewer (you'll get updates automatically when we get back to making new versions) and one of the Aditi Mesh Sandbox regions. I've seen a number of posts here that include some variation on "we have always had to do XYZ this way because of the SOMETHING bug, and so we can't do SO-AND-SO" (for example, joint offsets not loading correctly). If there are existing issues that are directly related to Bento (like joint offsets not loading correctly), we'd like to get them fixed so that we can get some of these obstacles out of the way. So, if you've got one, please describe it (see previous paragraph - concrete examples we can experiment with) by filing a BUG in Jira (put [bento] in the Summary). References to long-standing issues are ok; we're not only trying to do new things, we're trying fix at least some old ones too.

ObviousAltIsObvious wrote: if you miss the feature and don't want to wait, you can change the --channel name (for example in a shortcut) to bypass updates for now. Actually, if you just download and install the Quick Graphics Release Candidate from the Alternate Viewers page you'll get the feature back. Users on a release candidate are not updated automatically to new default viewers. It was explicitly downloading the new default viewer that caused the OP to lose the feature. There will be an update to the Quick Graphics candidate soon after the New Year to pick up the 4.0 features (we are not making any non-emergency changes during the holiday period so that Lindens can relax and enjoy the holidays). If you're running the current version, that update will be automatic (and mandatory).

Medhue Simoni wrote: The development side is the 1 I really do not get. What was the point of making this a CLOSED beta? Why did you make people sign NDAs for this? Why would you threaten people with legal action for talking, over adding bones to an avatar? First and most important, we did involve quite a few resident creators in this project from very early on - we could not have done what we have without them, and we very much appreciate their generous help. What has happened to date was not a closed beta, it was the initial implementation - what we just started yesterday was the beginning of the beta, and it's wide open to everyone. As Vir has said, we may well make significant changes based on this beta (which is why none of this is on the main grid yet, so that we can make changes that are incompatible with what we have now). As someone here has already suggested, when we begin a project that we consider to have significant risk we prefer not to discuss it externally because we don't want to cause confusion or set inappropriate expectations. We've been working on this for several months - consider what it might have done to avatar and animation sales during that time if there were rampant rumors about how we might break everything, or even just that big improvements were coming. Since we could not be sure either what the final scope of what we could do would be or how long it would take, we didn't want to cause that kind of disruption. It wasn't possible for us to keep the secret (which, suprisingly, we apparently did pretty well) without some limits on how many people we brought in. I'm sure that there are many more creators out there who could have contributed, and we look forward to getting their input now. One small request ... please actually get the Project Viewer and test how things work, and try the tools that are available to work with them (if there are other tools we can help to support these changes, we're ready to help). In the course of this project we've tried to address a number of problems with how rigging and animation work, so you may find that old problems have been improved. We very much want your input on what we've done so far so that we can bring this to all of Second Life.

Now. https://community.secondlife.com/t5/English-Knowledge-Base/Enhanced-Skeleton-Project-Bento/ta-p/2975160 https://wiki.secondlife.com/wiki/Project_Bento_Testing

Ok. We get that you would like demo items excluded from search. We can't do that immediately, but we get it. You can all stop repeating that now, and really we don't need 30 point bold type for anything.

Sorry about that ... most of our Release Candidate viewers prove to be ready to go when we put them out in a test group, but once in a while one needs a serious problem solved. You were unfortunate enough to be caught in one of those. If it's any comfort, your experience prevented others from having the same problem. We've fixed that bug, and are putting the update through QA now - it should appear in a few days for another test (your odds of being picked for that test are not very good). The good news is that while the problem you experienced was serious enough that we withdrew that viewer until we could fix it, our overall results with it were excellent - it had the best crash rate we've seen in years, so with this fix made we're very optimistic about it.

ChinRey wrote: Do you feel the visual complexity algorithm is exact enough to target the high lag avatars precisely enough? And if so, can you explain a little bit why? I don't think I'd use the term "exact" for anything of this kind, because different features have slightly different real costs depending on the capabilities of your system. Short of having a very deep understanding of the specific capabilities and performance characteristics of every graphics system out there (many many thousands), an "exact" formula isn't possible. So the question is "is it good enough to be useful?", and we think the answer to that is "yes". Certainly many of the Lindens who've been using this viewer for months (including myself) have decided that the feature is very very valuable. Personally, I usually run with my limit set to about 100,000 - good enough to display most avatars in the settings where I spend time, and keeps my lag under control even in substantial crowds.

Loraan Fierrens wrote: Out of curiosity, is there any work being done to provide some sort of proxy layer for viewer doing MOAP? Not at this time.

Looking in the data logged to the simulator by your viewers in recent sessions, it shows high packet loss rates and ping times that are usually over a half second, and in at least one session over 3 seconds. For those sessions at least, you have a quite serious network problem.

There's a new update out for this viewer. We believe it corrects some of the problems people have seen, including setting better defaults. There are still a few minor bugs to be fixed before this becomes a Release Candidate (most notably that after you change your outfit, you keep getting the same message as before about how many people may not be seeing you). Feedback on the new defaults and messages would be most helpful.

Nalates Urriah wrote: I see Jelly Babies even with the slider maxed out. Most of that is due to one bug in the comparisons that we've got a fix for ... next update.

seanabrady wrote: The assumption then is that VMM RC will be promoted to the defacto release prior to the 23rd? Probably not because we've just done a promotion and we don't feel we need to push a new update on everyone immediately just to get it to Merchants, but it's available now and we don't know of any problems with it. It is first in line for the next promotion though assuming that nothing really bad happens.

You might try the "Big Bird" release candidate viewer - it has many fixes for attachment problems. See http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers

Theresa Tennyson wrote: If you prefer using the Linden Lab viewer you can use the "Obsolete Platforms Viewer" on this page. Make sure you go to "Preferences" and turn off automatic updates. No need to turn off updates; there won't be any. That viewer is in its own update channel and we won't be building or releasing any more in that channel. Most systems that can run XP can at least be upgraded to Windows 7, which would get you back onto supported viewers.

Sorry - Second Life simulators rely on a very large set of backend services to work. Even we can't create a standalone simulator.

Samual Wetherby wrote: Which is what several of us in this area need. Some sort of multi user data information that points to an ISP issue. But everything I see points only to a CDN issue. From where you're sitting, it's impossible to tell the difference. What tells us that it's the ISP is that there are many customers successfully using that same CDN node from other ISPs in your region without the same problems. As for finding information to give to your ISP, here's how to find it in your SecondLife.log file. There are two similar log entries that will show up that show an http request failure: 2015-03-13T02:01:48Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://asset-cdn.agni.lindenlab.com/?texture_id=65e28e31-9700-7784-4181-796869041279 Status: Easy_28 Reason: 'Timeout was reached' 2015-03-13T02:19:50Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for:http://bake-texture.agni.lindenlab.com/texture/4c4ab9a6-0d19-4428-957e-bd283729474c/head/874a0639-79e0-c470-149b-fbd1b20c3d4d Status: Easy_28 Reason: 'Timeout was reached' The entry with 'asset-cdn' is either a texture or a mesh, and the one with 'bake-texture' is an avatar baked texture (either may be followed by .agni.lindenlab.com or .gbl.agni.lindenlab.com). The names are different mostly for historical reasons - they go to the same place. If you (or your ISP) looks up the translation of the domain names in bold in those messages, you'll see which CDN node they point to. That mapping may change depending on configuration changes. A traceroute to those names will show a network path to the node (depending on how your ISP is configured, there may be more than one... sometimes diagnosing these things from the edge is just hard).

Samual Wetherby wrote: Just so odd to go up to mid Feb without a problem. Everything popped info place. No rez issues then like clockwork failures. Up until we began using the CDN, all your texture and mesh fetches went to our datacenter in Phoenix. Now, those fetches go to the CDN node, while the rest of your communication still goes to the simulator in the datacenter. Those used to be the same path, and evidently that path was pretty good for you. However, it's a different path to the CDN node now (we verified this during the testing), and that path exhibits high packet loss during the times that you're having problems. That won't show up in the packet loss stats reported by your viewer, because that stat is only for UDP traffic - which all goes to the simulator and is apparently fine.

The times you cite are in fact not even close to Second Life peak times - those are (roughly) Noon to 5PM SLT. They are, however, exactly the peak times (evening tv streaming, online gaming, and web surfing) for a primarily residential cable ISP on the US east coast. That the network path(s) between such an ISP and a major CDN node would be more stressed during those times isn't at all surprising. We've done quite a lot over the last year to make the network behavior of the viewer less stressful to and more efficient in its use of the network, and that work is continuing (look forward to other asset types like sounds and animations being delivered faster in the coming months). As I mentioned in the Jira issue, we also plan further improvements to the CDN configurations (I don't have a time frame for those changes yet, and probably wouldn't post them here now if I did because they might change). We can hope that those changes will help with the particular problems working through your ISP - we're confident that they will be better in other ways, but since we don't know enough about the network topology, configuration, or load at your ISP we'll have to wait and see.

There are any number of things that can cause rez failure, but you have not given any actual information that might be useful helping to find what's afflicting you. Incidentally "the latest update" isn't descriptive enough for us to identify even what viewer you're using. As I'm writing this, we have 4 different candidate viewers in use in addition to the most recently released default viewer (3.7.25.299021). You can find all the information about which viewer you have in 'Help->About Second Life'.

Whirly Fizzle wrote: Their content can still be used though, there's nothing stopping them from wearing it and seeing themselves correctly. When this new automute feature is out, all that will change is for those users who decide to enable the feature (maybe it will be enabled by default for very high draw weight avatars?) will see the high draw weight avatars as an imposter - unsure yet if LL are going to keep the multicolour jellybaby imposters for this feature (current behaviour) or change it to the normal "2D cutout" imposters. The current thinking is that we will use the mono-colored avatars for those who are over your limit (I've toned down the brightness of the colors a lot), and continue to use the "2D cutout" (really, we just leave out some of the fancier shader passes and update less frequently) style for more distant avatars. We've also changed the coloring of the avatar draw information display so that it's relative to your own limit, not some arbitrary values we've picked; those under your limit will be green or green-yellow, shading toward red for those far over your limit. The hope is that will help you decide how to adjust your own limit. Each avatar will also report to the simulator whether or not each of the other avatars it sees is over its own limit (without reporting what that limit is). My current thinking is that the simulator will use that information to report to each avatar an approximate percentage of those who are limiting rendering, so that you'll be able to tell whether or not others can see you in all your blinged-out glory.

That was an awful lot to digest all at once. We have an active open source program; you're welcome to conduct some experiments to demonstrate problems and help develop solutions. I look forward to your contributions, but please give them to us in smaller bites so that we can keep up.

Alas, no, there isn't. There's a lot of information on wiki.secondlife.com (some of it, like most wikis, not as up to date as we would like).

I didn't discuss linux crashes in that post because the 'version' reported for Linux isn't very useful. We do collect crash statistics on the linux viewer, but the number of users running our builds on linux is so small that the sample sizes are too small to make meaningful comparisons.

If you're having this problem, we could use a copy of your log file. Whirly Fizzle added a very helpful comment about how to collect the information we need and post it to the Jira in https://jira.secondlife.com/browse/BUG-7776

Another small note about what this does and does not affect... The CDN (and HTTP in those viewers that have them) improvements for texture and mesh data are improvements to how long it takes to download the the data. Once they've been downloaded, your viewer caches them locally so the next time you need that data it doesn't need to download them at all. What that means is that these improvements mostly affect how quickly you see new things: places and objects you've never seen before. You probably won't see a big difference in familiar places because your viewer should be using cached data for those. So... now's the time to try checking out places you've never seen before! The use of pipelined HTTP for the initial load of your inventory when you log in matters every time, since while we cache some inventory data locally we always make sure it's correct by loading it all at the beginning of your session.