… and in this case I don’t mean the mediocre-quality 2007 freebies on sale for 99L.
The cruft I’m referring to here is (are) the unnecessary scripts that many of your vendor devices are delivering to customers’ inventories, with names like “Floating Text” or “rotation script” or “vendor script – delete me”.
(Or most adorably of all, “New Script”.)
Vendors all too often deliver this stuff along with the stuff that the customer actually wanted (and sometimes annoying non-script cruft like pose stands, multiple landmarks, and so on), and they (you) ought to stop. Not only because it’s annoying to customers, but because it makes you look sort of clueless and unprofessional, and because annoyed customers are that much less likely to be repeat customers.
Why does this cruft come up in the first place? A little background: there are two different basic ways a vendor can work:
- Vendors that you buy things from with the “Buy” option on the menu, where you get a little popup that says “Buy a copy of Whatever and its contents [list of contents] from Whoever Resident for 235L?” or “Buy contents [list of contents] from…”; we’ll call these “Buy vendors”, and
- Vendors that you buy things from with the “Pay” option on the menu, and you get a little popup asking how much you want to pay, usually with just a single button with the price on it, but no list of exactly what you’re getting; we’ll call these “Pay vendors”.
A vendor can be set up so you don’t need to select either Buy or Pay, but you just need to touch it, and it acts as though you’d selected Buy (or Pay). You can still tell a Buy vendor from a Pay vendor, though, by the kind of popup you get after you touch it: either the list of contents that you are buying, or just an amount to pay.
(Not being much of a Viewer 2 or Viewer 3 user, I haven’t verified the exact contents of these popups on those viewers, but I think they are similar; feel free to leave comments if things are significantly different there.)
But anyway!
The interesting difference between the vendors for our purposes is this:
- a Buy vendor always delivers everything in the prim to the buyer, but it doesn’t need to contain any scripts at all, whereas
- a Pay vendor does have to contain scripts, but it has total control over what it delivers to the customer (so in particular it doesn’t have to deliver any unwanted scripts to anyone).
So the two primary sources of cruft are:
- Buy vendors that contain scripts that they don’t need mixed in with the goods, and
- Pay vendors whose scripts are poorly written, and deliver stuff (often including themselves!) that shouldn’t be delivered.
So how do we fix these things?
Remove the scripts! (Buy vendors)
So Buy vendors don’t need to contain any scripts at all in order to sell things (they just need to have the appropriate “For Sale” boxes filled in in the Edit window). Then why do we so often end up with useless scripts in our inventories when buying from Buy vendors? Because sellers put scripts into the Buy vendors in order to get various effects (floating text, spinning, etc), and then they leave the scripts there, even though they don’t actually need to.
If a box that is a Buy vendor has a Floating Text script in it whose only function is to make the box say “Awesome Blue Hat 240L” in floating text above it, the merchant should remove that script; the floating text will stay (it’s like, after you paint a wall, you don’t have to keep the paintbrush around for the wall to stay painted).
If a box has a rotation script in it whose only function is to make the box rotate around in an eye-catching fashion, the merchant should remove that script; the rotation will continue. (This is true for the common ways that people make sale boxes rotate; there are some kinds of rotation that will actually stop if you remove the script, but your sale box is unlikely to be using any of those.)
If a box has that ubiquitous “anim SMOOTH” script in it that makes the textures on the box rotate around, the merchant should remove that script; the cheesy attractive texture animation will continue.
If a box has a “New Script” in it whose only function is to make the box shoot pretty colored sparks out the top, the merchant should remove that script; the particle display will continue. (Again this is true for the common kinds of particle-displays. More elaborate kinds may stop if the script is removed, but in that case you should consider switching to a Pay vendor instead, or moving the particle script to a different prim, or otherwise avoiding delivering it to your customers.)
The result of removing these scripts is that when your customer buys one of your products from your Buy vendor, they get only the product, and none of those baffling and annoying extra scripts. They get a more satisfying shopping experience, and you get a higher customer retention rate. Goodness all around!
Don’t deliver the scripts! (Pay vendors)
Okay, so for Buy vendors the important thing is to just take out all of those visual effects scripts that don’t need to be in there anymore. What about Pay vendors?
In a Pay vendor, there’s always at least one script involved, with the job of noticing when someone has paid money to the vendor, and figuring out what to do about that. (For Buy vendors, SL itself takes care of seeing the buy action and delivering the goods.)
The script in the Pay vendor can do basically anything it likes; it can deliver copies of the items that are in the prim’s contents, it can deliver just the single boxed item that was selected at the time, it can contact some central server that will handle the actual delivery to the buyer. (That last kind is what you are using when you use a Pay vendor to buy something, and the actual item is sent to you by “Fred’s Central Vendor Server” or whatever.)
So if the script in a Pay vendor can control exactly what is delivered, why do these vendors also end up delivering unwanted cruft? Because so many Pay vendor scripts are incredibly simple and basically just deliver everything found in a particular prim. So this can include both all of the kinds of unnecessary scripts that Buy vendors tend to deliver (Floating Text and family), and also the vendor script itself!
This is easy to fix. Typically your vendor shouldn’t be delivering any scripts at all, so you or your friend who scripts can just look in the vendor script, find the place where it’s making a list of prim contents to deliver, and be sure not to add any scripts to that list.
So for instance if the script has a place that says:
integer n = llGetInventoryNumber(INVENTORY_ALL);
for(i=0; i<n; i++) {
items += [ llGetInventoryName(INVENTORY_ALL, i) ];
}
that is building up the list of things to deliver, you can change it to:
string item_name;
integer n = llGetInventoryNumber(INVENTORY_ALL);
for(i=0; i<n; i++) {
item_name = llGetInventoryName(INVENTORY_ALL, i);
if (llGetInventoryType(item_name)!=INVENTORY_SCRIPT)
items += [ item_name ];
}
which leaves any scripts (including itself!) out of that list.
(If you do need to deliver scripts, you can use llGetInventoryName() to find out the name of the vendor script, and at least not deliver that. More sophisticated vendors have a configuration notecard or something like that, so you can explicitly tell them what to deliver; those don’t generally have the problem of delivering extra script cruft in the first place.)
Waring: llAllowInventoryDrop (PSA for all)
As an Extra Bonus for those who have read (or even just skimmed) this far, here’s a Public Service Announcement and a warning.
There are a bunch of legacy “copied from person to person for years” scripts out there that contain the line:
llAllowInventoryDrop(TRUE);
I’ve seen this line in at least some Floating Text scripts; it may well occur in some other kinds of scripts as well.
While I’m sure that whoever put it into the original script had some good reason to do it given what that particular script was intended for, it’s definitely not something that you want in a random vendor.
If you have a script in a vendor that contains this llAllowInventoryDrop TRUE line, you may be opening your customers (and therefore yourself) up to being pranked and griefed in ways that might range from amusing to very harmful, depending on the prankster and the point of view.
(I’m not going to go into detail here on the exact vulnerability to avoid encouraging pranksters and griefers; a few minutes of web searching will find all the necessary information quickly enough.)
And if you do have one or more of these it’s not enough to remove the script or to remove the offending line from the script. If you find one or more vendors of yours have this line in a script, and you don’t know exactly what it’s doing there, you should change the TRUE to FALSE and re-save the script. So instead of the line above, it should say:
llAllowInventoryDrop(FALSE);
You should also check the contents of any vendors that you find the dangerous line in, to make sure that they don’t contain anything that you didn’t put there.
And about those posing stands…
Okay, that’s all for the “avoiding script cruft” issue. But while we’re on the general subject, I doubt I’m the only one that’s annoyed when Every Single Item I buy at a store comes in a box that also includes a posing stand with the store’s logo, and two or three landmarks for the store and its various branches (and the owner’s boyfriend’s Rock club, and…). I mean sure, have a little vendor that gives away free logo posing stands to people who want them, and by all means have a landmark-giver in the doorway, but if I buy five items from your store, I don’t want five copies of your posing stand, ‘kay?
So could y’all please leave those out, too? :)
Filed under: business, Rants, scripting, Second Life | Tagged: cruft, peeves, rants, scripting, sellers, vendors | 1 Comment »
There’s certainly lots of turmoil within Google right now, between the clever and non-evil people who made it successful, and the “Google Plus At Any Cost, we will own the world!” people; and there’s no telling how it’ll come out.
Well, the news has somehow 
This morning in the tub when I was trying to think of some more headlines that would make Second Life sound bad without being too obvious about it, I decided it was again time to 
Dale Innis's Weblog 