Oz Linden

The simulator/LSL change is scheduled to roll tomorrow (6/21) to the Magnum RC channel for another try; simulator version 2017-06-19T17:18:00.327192. Thank you all for your patience. This release fixes two things that were responsible for the rollback: Our previous change had broken adding custom headers; those should work again We modified the server to properly escape space characters in the url value. Technically, the script should already have done that, but we didn't enforce it before so there are a lot of scripts out there that send them and we could make the change in a backwards-compatible way, so we did.

We rolled this back for a little rework... stay tuned.

It would be more useful to show us your script.

Ok.... I've updated the wiki page for llHTTPRequest to show the parameter that will be available with the new server roll. If you previously invoked the method like this to hack a User Agent header into the URL parameter: HTTPRequest=llHTTPRequest(URL + "/7.html HTTP/1.0\nUser-Agent: LSL Script (Mozilla Compatible)\n\n",[],""); then it won't work on the new version because the spaces and newline are not allowed in the URL (that's actually why it broke in the current Magnum server already). You'll need to change your script to do something like: HTTPRequest=llHTTPRequest(URL + "/7.html",[HTTP_USER_AGENT, "Stream-Script/1.0 (Mozilla Compatible)"],""); The User Agent value you provide will be added to the one provided by the server, so both your script and the server version will be identified. As has been noted above, this change is scheduled to roll to the Magnum RC regions tomorrow.

See https://wiki.secondlife.com/wiki/LlHTTPRequest

I should have been more clear... we are aware that it's not just one script, and the fix we're working on will be usable by any script. I expect to have specifics in the next couple of days. In the mean time, the scripts still work if the region is on the main channel, or on the Bluesteel or Le Tigre release channels. Support can move your region if needed.

We have diagnosed the problem with this script, and are reaching out to the author to define a change to the script and the server to restore the functionality.

We're wary of the term "NPC" (whether expanded or not) because it seems to be understood very differently by different people. What we're working on isn't an automated avatar, which would imply a great many other things that have nothing to do with animation at all. We are excited about seeing what our talented creators will do with what we are doing though.

Debugging issues with the CDN isn't very easy, but it's impossible if we don't get very careful and thorough reporting. For example, including where you are, how you are connected to the network (who is your ISP), exactly what sort of problem you had loading (images, inventory, mesh objects, whatever), what region you were on, what time it was (including the timezone or explicitly in SLT). We have occasionally been able to diagnose and correct problems when we had enough information to go on....

Whenever you're asking about a Viewer problem, it's helpful if you include at least the viewer version information from About Second Life (even better is all of what's in that box... we even have a handy button for copying it). As a part of the 64 bit viewer project, we're revamping how upgrades are downloaded and installed in an attempt to make them more robust and quicker (and incidentally to make sure that Windows users get the 64 or 32 bit version that will work best on their system). That component isn't in the Project Viewer yet, but we are integrating it now so it will be in an update soon.

We're aware of the problem and are looking into it.

Have you tried the VLC viewer for your file? It uses much newer media handling. You can download it from http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers There will be an update to that viewer posted this evening, but the current version should work.

Of course we read the forum ... we're just quiet and retiring by nature

Solving that problem would require major rewrites to lots of viewer code; it is not on our roadmap at present.

Just FYI ... there's nothing magical about 80,000; that's the default for Medium graphics setting (and most Macs). The default you get will vary depending on the viewers assessment of your GPU - high end ones will default higher, and some may default lower. It's a great goal, though. I have my own viewer set to around 100K most of the time, which really improves performance by cutting off the very expensive ones.

This is fixed in the current default viewer, and that fix will be in the next Bento Project Viewer update

Also see http://wiki.secondlife.com/wiki/Avatar_Rendering_Complexity

Also see http://wiki.secondlife.com/wiki/Avatar_Rendering_Complexity

Christin73 wrote: After an update to the viewer lastnight i noticed everything I put on ups my "visual complexity". First off what is visual complexity? Is there any way to turn that off from popping up everytimg you put clothing on or tp someplace? If you look at that message, you'll notice that the words "visual complexity" are a link... if you click on it, it will take you to a page that explains what it it is and why you should care about it. There is a debug setting that controls how long that message is displayed; at the next update, you'll be able to set that to zero to supress them entirely (but you shouldn't).

Webroot has, alas, been implicated in a bunch of problems. If at all possible, find another security package.

Can we please try to keep this thread focused on the Bento features and bugs without getting into a discussion of the relative merits of different modeling and animating tools?

Gael Streeter wrote: This is a very very old known bug : When importing a BVH animation into SL, the SL viewer performs an "optimization" of the animation (to reduce its load). But this "optimization" algorythm has bugs and induces very big problems of "phantom moves" (I call it like that) when the animation has very small moves between keyframes : the fine moves are replaced by big and long incoherent moves. We are trying to find and if possible fix any bugs related to the Bento features. If you can find a good quality report (meaning one with usable instructions to reproduce it), please add a pointer here; if not, please try to create one. Extra points for including an animation file that demonstrates the problem. It may also be that we should implement checks in the viewer to alert the author that an animation does not use an appropriate frame rate, but let's see some actual examples before we draw any conclusions.

Yes, communication is important. Please don't take our recent quiet as an attempt to avoid communication... it wasn't: we were just on holiday. We're looking at having a series of open meetings for and with content creators, and will be posting both those and other things here in the coming days and weeks. Almost nothing is set in stone yet (the bones that existed before Bento being the most conspicuous exception). Second Life Examples Please!

Kitsune Shan wrote: ... Ok now think on that issue translated to the new bones. Take into account that bones have increased to, how much? 3 or 4 times the old ones? Add to that some bones chains for the supossed facial animations. Just the face bones should be increased by 3. Now, with all that try to make an animation. You will then hit a big wall when your animations looks nothing like the ones tried to make, when your face starts to get some muscle spasms here and there and when the file size limits your animations to very short clips. Adding bones chains wouldnt just decrease performance, it would decrease animations quality. Unless these animations file size gets increased by the same amount of bones number ... Leaving the bones translations subject, I would like to recall on the bone per vertex limit issue. We already strugle at time to rig using fitted mesh bones in combination with default ones. Certain parts are surrounded by more than 5 bones while the limit is 4. This gives you distortions on skinned meshes and often puts you on the choice of having to disccard some necessary bones simply because you cant add more than 4. If the limit is really tight already, try to imagine if you add the new bento bones. Think when you will try to make a smooth facial skinning but you cant use more than 4 bones per group so you have to discard essential facial bones for an optimal animation. We need a limit of a minimum of 6 bones per vertex. I am not programmer so I am not sure wether tis can get scaled to 6 or if have to be directly raised to 8 like most games engines. But the fact is that we really need to be able to rig to more bones per vertex if we want to use the new bones, fitted and old ones properly. Without commenting on the merits of either of those issues above (because I don't have an opinion yet), I'd just like to point out that they would be perfect for filing a Jira issue including rigs and animations that clearly demonstrate the problems... doing so would be far far more effective than the post above alone.

Working for me... When reporting a potential system problem, it helps a lot to be specific about exactly what is happening.