Friday, February 9, 2007

Automated product updates: one solution

So I mentioned the other day that I was trying to come up with a decent method to deliver product updates. This pipeline is horribly kludgy and not automated, but it's what I've come up with so far.

Issues and solutions
  1. Need to maintain a complete list of purchasers, regardless of whether they've purchased from Sirena Fashions, SL Exchange, or SL Boutique. It would have been easier if I had just scripted a vendor that kept track of all purchasers and their avatar keys, but then it would not have been available on the regular web.

  2. Downloaded the available avatar name / key database from

  3. Wrote a Perl script that took each purchaser's avatar name and searched the 600,000+ entries in the moopf database, and returned the listed key. Amazingly, only one avatar UUID key was missing (it was someone who was created just a few days ago).

  4. Manually found the missing avatar UUID by following the instructions at
    You can also look up keys yourself using the SL client. First, enable the debug menu (ctrl+alt+d), and use it to turn on the Debug Console (ctrl-shift-4, or Client -> Consoles -> Debug Console). Search for the person using Find, and then hit Instant Message. A message will come up in the debug console following the form:

    INFO: LLTalkView::createFloater: target (user key) in (session key)

  5. Copied all the avatar names + keys into a notecard. Here's where my paranoia shows. The databases of names / keys are NOT Linden Lab official. There is no assurance that the key that they list for a name is actually linked to that name. So, I copied all the name + supposed key pairs into a notecard in SL, and...

  6. Wrote a script that read line by line from the notecard, and checked that the name pulled up with a llRequestAgentData on the key actually matched the name I had. They all matched, lol, which shows that my paranoia is groundless and a waste of time. :)

  7. If the key and name match, the script will send the inventory item to the user. Just in case there are people who do NOT want to receive updates, I also coded it so that in the avatar / key list, lines could be flagged as people who didn't want updates.
Phew! So much of this hassle could have been avoided if LL just included a "name to key" function...

Or, since there are minimal sales at SLEx and SLB, a simple solution will be to replace the product in Sirena's with a scripted vendor that records the avatar UUID's, so I plan go write a one-prim vendor soon.

For everyone who asks, "Why the heck are you reinventing the wheel? Other people have written vendors and product updaters," well, this is how I've taught myself how to script. :) Before today, I'd never written a Notecard reader or Agent Info query before. Having done it now, I now understand how it works, and for me, that's fun! (Yeah, weird sense of fun, I know...)