Recommended: llSetPayPrice to set one price

I notice not many vendors are using the llSetPayPrice function (introduced in 1.7) to set a single price for an item. A single price means users don't have to type in the price (bad interface design) and the script doesn't have to handle errors. To have customers see a Pay dialog with just an amount button and a cancel button, use the function like this:

llSetPayPrice(PAY_HIDE, [150, PAY_HIDE, PAY_HIDE, PAY_HIDE]);

Here's me modelling it



And here's the code I use for a single item vendor. The price comes from the vendor object description, and the product name is the first object in the vendor's inventory, so there's no need to change the script for each vendor.

//    single item vendor script by Sky Honey 2006/2/10
integer _price; // price is anywhere in the vendor object description
string _product; // product is the first object in inventory

default {
    on_rez(integer parm) {
        llResetScript();
    }
    state_entry() {
        _product = llGetInventoryName(INVENTORY_OBJECT, 0);
        string desc = llGetObjectDesc();
        _price = (integer)llGetSubString(desc, llSubStringIndex(desc, "$") + 1, -1);
        if (_price == 0) {
            llSay(0, "ERROR: The description of " + llGetObjectName() + " should contain the price, starting with a $ sign");
        }
        llSetPayPrice(PAY_HIDE, [_price, PAY_HIDE, PAY_HIDE, PAY_HIDE]);
    }
    touch_start(integer total_number) {
        llSay(0, "Right click and choose 'Pay...' to buy a " + _product + " for $" + (string)_price);
    }
    money(key customer, integer amount) {
        llSay(0, "Thank you for buying a " + _product + ", " + llKey2Name(customer));
        llGiveInventory(customer, _product);
    }
}

Note how simple the money event is after llSetPayPrice has done its work. No need to use llGiveMoney and no need to ask for the DEBIT permission.

I don't think this is a case of not knowing how to use the function, it's just a case of vendor users being slow to move; it's a lot of hassle to replace an entire vendor network and set it up again, and as long as they achieve the basic goal of selling items for money that's all the users need, which is why there's less innovation in the vending market than in many others.

That is a good suggestion, Sky, but as Yumi pointed out -- A lot of people are using free/premade vendor systems, so all of the older-style vendors cycling out might take a while.

Also, just to be clear, llSetPayPrice is not %100 guaranteed to prevent mispayments.

Even with a fixed price, it still *IS* possible to pay the wrong amount for the wrong item. Because the Pay dialog remains on the screen and still lets the user interact with the SL world, it's possible that the user (or another one nearby for that matter) can click or invoke the "display next item" function of your vendor. So now, when they hit that "Pay X $L" button, the amount goes towards a different item.

Yes, llSetPayPrice does help minimize the "ooops" factor, but it doesn't entirely eliminate it either. Don't trust what comes in through your money event, even with llSetPayPrice and a fixed price.

It's the same scenerio as llDialog. We (as the script writers) do not know or have no way of finding out if the user has left the dialog open on their screen, or immediately hit ignore to dismiss it. (Or in the case of the Pay idea, simply closed it.) All we can go on is the amount coming in through the money event.

Oooh, thanks for pointing that out Fenrir. My vendor script is currently just for a single item so it's safe from this problem. But the next one I write will be for a set of items and this bug might easily have slipped by me. Not any more

I use this, but I still take debit permissions, and I still keep "if the amount isn't correct the refund the money" kind of checks in my code. It's not that much of a hassle for the owner to grant debit permissions, it's 2 extra lines of code and one extra comparison at run-time... all of that is worth it for the rare case when the system messes up.

Having said that, I agree with your basic idea. All vendor-ish projects I've done since this was added, I've used this function. It makes the end user experience a lot simpler.