Zi Ree

This is a good step, but how do we make sure a bot is actually properly flagged as scripted agent? It's the same problem with traffic farming bots that don't have themselves set to scripted agent, so their time spent would count towards traffic.

2

Done! Thank you! https://jira.secondlife.com/browse/BUG-232779

Any chance to get: list llLinksetDataFindData( string regex, integer first, integer count ); to search for data?

@Rider Linden Is there a chance to get Search and Regex also for Experience KVP storage? It would make things SO much better! See also: https://community.secondlife.com/forums/topic/492023-linkset-data-is-coming/page/4/#comment-2520025

llLinksetDataReset() helps here.

With these things it's always good to come up with a good prefix for your keys that make them unique. So don't just use "position" as key but "myscript_position", where "myscript" can be anything that acts like a namespace for this specific script.

I just looked at my recorded region statistics and ever since December 1st my region consistently reports scripts run at >95% - everything runs a lot snappier and I am not sure what changed. But whatever it was ... DO NOT CHANGE IT BACK! 😀

I agree with pretty much every single point in Chaser's post. Well summarized.

To be fair, VSCode is open source and cross platform.

Probably the same reason why there is no built-in animation editor or no built-in mesh modeling tool and no built-in image editor and no built-in audio editor: There are excellent external tools already available. Just edit your script(s) in an external development environment. The script editor even has the "Edit" button that watches external files for changes, so a saved file automatically gets compiled in SL. I would even go as far as to saying: The scripting tool inside the viewer is the ONLY creative tool inside the viewer. Everything else needs to be done externally. So the scripters already have a huge advantage over everyone else.

Thanks Chaser, that was a pretty good summary. The FS AO had its fair share of bugs pre 6.3.2 which mostly were fixed in 6.3.9. A few more remain and will be fixed going forward. But it surely does not use "some kind of ancient hack", it simply uses the same commands as the system animations do, just replacing the system animation UUID with the one in your AO. So it pretty much is just as fast as the system animations are. The only delay you see is the time it takes from pressing a movement key to the server sending the animation command to your viewer.

Why do you need a 32 bit viewer for Linux? Maybe we can figure out a better solution.

There was a change in the AO to fix double starting of animations, which resulted in jerky movement whenever an animation state change happened. The AO now does the same as a scripted AO, it sends a request to the region to animate your avatar, and the region will signal this back to the viewer. That means, you have a delay according to your ping time towards the region. This also fixes the case when you would see a different animation than other people looking at you would. Having said that, the AO itself is still viewer side and will remain viewer side.

I wonder why it is marked as "Deprecated" when the function hasn't even been released yet. They could just take it out completely without even mentioning it at all.

Glad to hear you're reconsidering! But why do we need this function at all? Apart from reacting to changed mail addresses, I can't see any real use for it. Can you share a use case I am missing?

What if someone gets hold of a full perm object I made and uses that to spam my email?

Thank you Inara for the link, and thank you Linden Lab for the explanation! It makes a huge difference to hear about the reasons behind maintenance, especially such a very extended one. It makes us appreciate the work that your hardware team is doing to keep the grid up and running! Good job!

The DDoS attack is a well known case, targeting UltraDNS, the service provider Linden Lab uses for DNS resolutions: http://threatpost.com/ultradns-dealing-with-ddos-attack/105806 Nothing secret about it, just no information that was important for the blog post.

This is a very welcome statement and an interesting read about the architecture behind the system! We didn't have so much openness from the Lab in quite a while. Please keep it up, people want to know what's wrong when stuff breaks

Sending mails to everyone and putting up a blog post with lots of text was hardly worth the effort to send people L$10 as a Valentine's gift. It seems like a cheap trick to get people to log in at least this once to receive their oh-so-well-announced gift, to make their login statistics look better for whatever reason. But instead of actually offering something nice, a pretty card, a heart-shaped box with a bear in it, whatever, you get a L$10 consolation price and nothing else, not even a message that you were gifted. Poor, poor form. Cheap marketing, not a good way to make your residents feel loved and appreciated, Linden Lab.

This more sounds like an issue with your network connection. Your laptop is probably quite fine.

What's your problem with client-side AOs? The one in Phoenix can now override about all default animations seamlessly, and you could still sell animations plus accompanying notecard to customize the built-in AO. And while a good scripter can make an AO with relatively low sim impact, a client side AO is still better, becuase it uses exactly NO sim resources at all. And the less resources used, the better. Did you take a poll over all of the people in SL to justify your 20% comment, by the way? I surely wasn't asked.

The graphics card in that laptop (if I looked up the correct one) should offer a good SL experience, actually. What kind of problem do you see with your SL exactly?

If you want to improve your viewer performance, the first thing you need to find out is what makes it seem to be slow. If it's your viewer's drawing speed (Viewer FPS), reduce your graphics settings, switch off advanced options like anisotropic filtering or anti alias. Switch off atmospheric shaders, reduce terrain detail to lowest setting, and so on. If you are on a low performance system, like intel graphics chipset, you can't do much but reduce all options to the bare minimum and live with whatever you get. If you're feeling your viewer is reacting slowly, like pressing a key and it takes a long time before your avatar moves, make sure your bandwidth setting is close to what your internet download speed is, better a little higher. If that doesn't help, check your packet loss. If it's high, you have a bad connection to the SL servers at some point. It might be in your home (bad cables, wireless connection, bad ISP connection) or on the way from your ISP to Linden Lab. In the latter case, there is not much you can do.