any tips on scripting for product update delivery?

I was wondering if anyone had any general tips on writing product delivery scripts.

I've released my first product, which contains a few prims and 4 scripts, and already, it's time to send out an update to deal with... "issues" (stomp those bugs! Because updates will occasionally include completely new scripts, I can't simply use llRemoteLoadScriptPin.

So, I think the only option is to use: llGiveInventory

But then, I need a list of all the keys of the users. But, although there's an llKey2Name, there's no llName2Key function, right? Neither the SL transaction history, or SL Boutique, or SL Exchange appears to make available the keys to the users.

What's the best way to keep a list of the keys of all the users?

My guess, and PLEASE correct me if I'm wrong:
- this time, I'll have to manually search each user, and drop the new product on their profile
- the new product will somehow communicate the owner's key to me (what's the best way? email?) I've never been a fan of RL products that "phone home", and this bugs me a little.
- in the future, I'll have a list of keys, and would write a script looping through them all and do an llGiveInventory (what's the best way? reading lines off a notecard?)

Or perhaps, have a notecard with all the avatar names, and then an object in a store the users would need to go to. When they touched the updater object, the avatar's name could be checked off the notecard list, and if present, the updated object could be given to them. Perhaps their avatar KEY could also be recorded at this point, with their permission. This avoids the "product phone home" distastefulness too.

Any thoughts? Thanks in advance.

To help with the first part of your question, there are a few name2key services, most of which can be used from both in-world (using llHttpRequest) or on the web. W-Hat have one, as does Moopf Murray.

In your case, because you have a whole list, I would download Moopfs list and knock up a bit of code to match names in there. Any it can't find could be thrown out for you to check manually later. It won't have every single av in there, but it should help cut down your searching a lot.

This means you don't need your products to phone home in future, you can just look them up from your transaction lists.

Oh that does help a lot! I wonder how they compile their lists?

Although I'll probably make use of it (probably download and then use a Perl script to pull out the names / id's i need), I still would like to come up with an independent (i.e., not relying on a 3rd-party database) general solution.

But those are great resources, thanks!

Each client keeps a list in its cache of all the avs it's seen and their keys, in C:\Documents And Settings\(your name)\Application Data\Second Life\cache\name.cache (on Windows)

I know that the W-hat one accepts people posting their cache files, to help fill in the gaps in its database. I'm not sure where Moopfs data comes from.

As for maintaining your own solution, if you're using a scripted vendor to sell your items you could extract the key in there and then do a llKey2Name, and do something appropriate with the results to keep your list up to date.

If you sell transferable items, just going by your transaction list isn't going to work for some people of course.

For my auto-update system, the items simply check in at regular intervals with an e-mail to the server. I don't attempt to store the names and keys of every buyer - that would require offsite storage, because SL scripts can't scale to any real amount of data storage. On the other hand, the system does send regular logs, and the check-in message is fairly heavily encrypted, so I can check if someone who's never bought a product has recieved an update for it.

The items usually have to be no transfer because there is almost no way of making sure the buyer gets rid of the old version when the new one is released.

Why can't you use llRemoteLoadScriptPin? The pin is a property of the prim, not the script, so you can replace (or even delete) the script that set it, and the pin will still work.

Hey Ged, also consider using a networked vendor like Apez or SLexchange.

I've personally been using Apez for several weeks after hearing it recommended from a friend.

In addition to all kinds of crazy features, it offers a complete list of people who have bought from you, and the website has a key2name service which works 100% of the time, since all the people who bought from you did so using the Apez service.

I've been having to do some product updates as well, though my preferred method is to just give whole new units to people with the updates. All of my stuff is no-trans anyway, so it works best for me.

There is a free vendor package to get you started, and if you like it I recommend paying the L$3000 or so for the full version.

Check out http://www.apez.biz

One other thing that's worth considering is simply creating an 'upgrade vendor' that users can drop their old versions into. When they do, it destroys it and gives them a new one. Then just post a general notice that an update is available for your product, and where the update is. Simple but effective.

I've been considering creating an update manager. Initial thoughts were to use notecards to store the names and keys of your customers, but then I like doing stuff via server.

I was gonna design it for myself, but I think it might be useful for others to when I get around to it.

Basically, you would drop in your product and a notecard about your update. Then edit a pre-existing notecard with the list of names & keys, or it will be tied in to the server db, then click Go.

Would then transfer it to all of your customers.

Wow, lots of great suggestions. I'll definitely be thinking about these options!



That would work, except that I've added a completely new additional script. The original script was running into stack-heap collisions, so I needed to split out some functions to a new script.

But you can still add that completely new script via llRemoteLoadScriptPin, can't you?

The problem with llRemoteLoadScriptPin is that the object doing the updating has to be owned by the same person as the object recieving the update. Thus, since you're distributing an object to all of them anyway you might just as well send them another copy of the original - unless it's no copy/transfer ok, but in that case, there's a huge issue with securing updates no matter how you do it.

Hey for less hassle of keeping track of the keys of the customer, why can't the script check the internet for a new version with llHTTPRequest. I've been looking all over for one but no luck. I think its very possible to do it, but I've never used llHTTPRequest.

Well, it could request and find out there was a new version, but then the new version would still have to be delivered (which can't be by HTTP).

Hmm. are you sure that there isn't a way to receive the newest version. I once bought the DCS 1.7(Combat System for Toxia) and it gave me a newer one when I was wearing it.

I think you misunderstand the original problem of my post

Yes, llGiveInventory could be used to transfer an object to you (with your permission), knowing your key. Just having an Avatar name is not enough for llGiveInventory.

I was just asking people of various suggestions of obtaining and keeping track of all the keys of purchasers.