Important SL JIRA issues for April

I decided to skip this report for the month of March because I started this regular article at the middle of February. I have every intention of keeping this going on a regular basis — if only to just keep Linden Lab on their toes.

Important Server Fixes

  • [SVC-114] Meta-Issue: Inventory Loss: issues, fixes, development. Inventory loss has been a long standing problem in Second Life. This JIRA in particular has been open since 2007, but inventory loss has been in existence since longer than I’ve been in SL. It’s less of a problem for me because I try to keep my inventory around 15k items, but I know lots of people with 45k+ who regularly lose things.
  • [Many, many JIRAs] The Second Life Marketplace is a disaster of a rollout. With the introduction of the new Direct Delivery features, many people are upset not only at the rocky transition, but that the Marketplace is very slow — or fails to work at all. Then there’s the problem with the whole rollout schedule, in that many people feel it’s too fast and forced to make changes right away. Right now I think the marketplace database is being hammered so hard because so many vendors are having to update their listings. Still other people report that sales have effectively stopped, while others report that they’re not reviving the money from LL for their sales. A lot of people are having trouble transitioning as well, because of unicode characters in their products.
  • [SVC-7125] Bring Back Last Name Options! A staggering amount of votes have been put on this JIRA.  I remember when last names were removed, and at the time I though that it wasn’t a great idea — but it didn’t affect me so I didn’t care. Display names weren’t adopted as well as LL thought they’d be, because people still rely on actual account names. I can imaging having the last name “Resident”, is a pretty big bummer.  It has been proven in the past that LL can change an account name — perhaps LL should monetize this feature, and give anyone with the last name “Resident” a free use.

Important Client Fixes

  • [VWR-14674] Object Return Function of Region/Estate Menu does not work. A long time ago, these estate tools used to work.  The way they worked is that when you selected a name you could return ALL of the objects across an estate. This function was broken at one point, worked for what seemed a week, then broken again. Linden Lab should fix this post haste because of all the time they’ll save on support if estate managers can take care of their own estate without calling concierge for help. Griefing will be a thing of the past.
  • [VWR-28606] Viewer UI rendering slows to a crawl after extended viewer use, or teleporting. This JIRA is my own filing, and I bring attention to it because I know a lot of people suffer from viewer lag.  I’ve got a pretty beefy machine, and I’ve found out how to reproduce lag that ONLY comes from the UI interface. Ever since Viewer 2/3 came out the FPS in SL has been terrible in comparison to V1.  I think a lot of things can be done to the viewer UI code to improve it, so it may warrant the same treatement as the SHINING fixes for rendering.
  • [VWR-2950] Group Notices and Group IMs Constantly Malfunctioning. This is kind of a repeat of last Februarys. I like to imagine this issue is server side, but client side may also be part of the problem, hence sticking it in viewer issues. Group chat and notices are key to keeping SL great.  The poor performances of these services directly impact user experience.

Important Feature Developments

  • Pathfinding is still being beta’d and worked on.  In The Wastelands we’ve got one region Kronbelt, that is on the pathfinding beta.  A lot of bugs have been filed, and it seems like a good amount of feature development requests are in there too. Given LLs track history of releasing things, I’m pretty skeptical if any of the feature requests get worked on after the initial release. On top of that there’s some pretty serious bugs, such as dynamic objects (things that change shape, or size) can bring a whole regions’ FPS down to two.
  • There’s very little word on the Advanced Experience Tools, things like llTeleportAgent() or forcing attachments on people.  Wish there were an update on that front.

My Wish List

  • I wish that LL would just start over on the rendering engine of SL. It really is pretty terrible and only uses a fraction of my GPU, most everything that’s done for SL is on the CPU nowadays. I understand it’s hard to build a platform that is supposed to support as much hardware as possible, and to a degree you can’t control the viewer lag generated by people, because some people make 2048 resolution mesh eyes. I’m glad for the improvements that have been made, but the majority of everything done is on the CPU anymore.  Even with my Core2Duo overclocked to 3.6ghz, SL rendering seems lacking, and lagging.
  • I was recently forced to try a 3rd party viewer because a work deadline was coming up and the regular SL viewer was on the fritz. I really liked the UI of Nirans viewer, it was just more intuitive. What I really liked is the automatic graphics setting. Having said that I think upon setup LL should test for whatever openGL features are supported by the graphic card a user has, then automate what options are enabled by default.  Currently a list of features is used.  Develop an algorithm guys.

Tip of the Hat

It’d be unfair to critique LL without giving credit when they deserve it, so this new section is for when LL makes changes that are favorable to the operation of Second Life.

  • I previously blogged about llGiveInventory throttles, and while I still disagree with the enforcement of throttles, the throttles have been loosened with a recent server rollout. This may or may not be enough for large businesses.
  • A long standing feature request has been fulfilled. With the addition of llGetAgentList(), you can now get all the keys of all the avatars in a region. This isn’t live yet, but will come to a rollout soon!
  • [SVC-680] is one of those older JIRAs that is finally getting some attention in a future rollout. It increases the http response size from 2k to 16k in mono scripts. I will happily use up every KB in my newer Wastelands game.  No more chain-stitching HTTP responses together!
  • It looks as if llCastRay() may have it’s throttles removed.  HOORAY!

(Editors Note: This article is all just personal opinion of the importance of what JIRAs need to be fixed most. I may not know of other JIRAs that have a bigger impact. If you have suggestions for next month, please leave a comment about them with a link.)

Critique: llGiveInventory Throttles

Recently there was a stealth modification to how the llGiveInventory function works in the LSL Language.  A stricter throttle was put in place to limit the amount of inventory an avatar can offer another avatar through automation. The old way it worked is that if the destination is an avatar, the script sleeps for 2.0 seconds.  In theory that would limit an object to 1800 offers per hour.  Most content creators (myself included) aren’t to thrilled with many of the imposed delays that some functions have. LSL scripts have no capability to multi-task, and a rest period on processing can be hard to deal with. What many scripters/coders do as a work-around is thread out their scripts to avoid these delays, especially for larger projects. These threaded scripts then handle certain events, and communicate with other scripts inside an object via link_message.  llGiveInventory is no exception. With script threading you can give out tens of thousands of updates per hour, keeping your customer base happy!  The new change limits inventory offers to 2500 per 30 minutes, per avatar, per region. Go over that limit, and you will have silent failures.

As a SL user who’s worked on some of the bigger projects in SL, I can say that the current implementation of the throttle is yet another hurdle a coder such as myself must overcome. But the turn around to deal with this stealth limit is a nightmare for any big project already active on the grid.  It’s only going to piss off the customers of the customers who bring in the big bucks for the Lab. Content creators will become further disenchanted with yet another hurdle to overcome in selling products to other users of Second Life — because you know, it’s not hard enough as it is.

Why Linden Lab chose to do this:

llGiveInventory is just another message to send on the backbone of the SL-Grid. Send a million messages an hour, and you’ll slow things down for everyone. To combat griefing, LL chose to silently patch the servers so it wouldn’t be a widely known exploit.

How this affects SL negatively:

Large communities, product lines, games, and just about everything commerce related in SL rely on these previously mentioned work-arounds to distribute content, keep content up to date, and more.  Even the Second Life Marketplace uses it’s Magic Box to distribute purchases from the online website from inworld object to customers. While working on one of my previous contracts, I know for a fact that we had single-handedly brought the SL-Marketplace down when we did a product update. This equates to probably tens of thousands of transactions in less than an hour. It’s not unfeasible to to have products that big in Second Life.  Because SL makes money when it’s content creators make money, you shouldn’t make it more difficult for people to make their products available.

What I think should have been done instead:

Rather than put stricter limit on the function, Linden Lab should ban the avatars involved in attacking the grid in this fasion, and globally delete the offending objects. I know LL has a governance team, and I know they operate in secret. But I can’t for the life of me see them following through on REAL damaging behavior of some residents. This method of griefing is an example, and copybotting is another.

What those affected by the limit can do now:

  1. Log into the SL JIRA link below, click watch and vote on it, then voice your opinion.
  2. The odds are that LL won’t back down from removing this limit. A simple, but pain in the ass solution would be to branch out into micro parcels across the mainland, and use a round-robin method of delivery and updates.

Linden Lab has always hammered home the mantra that they shouldn’t do anything to break existing content, but in their eyes this limit is okay because they’re protecting the grid.  Further discussion about the technical aspects and current woes content creators are facing can be found at this JIRA: SVC-7631.