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.