Paying nothing for something

I'm still building tutorial items for newbies and I have a new puzzle. I want to demonstrate how to buy something from a vendor with Quick Pay, but I need to set the price to zero (because many newbies have L$0). However, writing llSetPayPrice(0, [0]) grays out the Pay button. Is there a way around that?

I know I can use BUY instead, set the price to L$0, and sell the vendor's contents that way. I'd rather not do that, though, because (a) I'm trying to demo Quick Pay and (b) the vendor box has many freebies in it and I only one to sell ONE (determined randomly) when the box is clicked. If I use Buy, it not only defeats the purpose of the tutorial, but I can't figure a way to sell only one item from the vendor when a newbie selects "Buy" from the pie. So, am I doomed?

In short, you're doomed. As you've already learned you can't set the price to 0. Only other option is to require them to pay some token amount (1 works quite well) and then immediately refund it. This of course requires them to actually have 1 L$ or they cannot proceed.

Exactly the problem. Newbies don't necessarily have money, and I if I give them L$1 when they click the box, there's no guarantee that they'll spend it to buy an item. A smart newbie could drain my account in seconds.

Actually, it's not true that it grays out the Pay button -- at least I just managed to set the price to zero safely --but apparently the money event isn't triggered unless you pay something > L$0. So, I'm still stuck.

Start out with a balance in the prim, say:

integer balance = 0;

Increment the balance when the prim is paid:

money(key id, integer amount)
{
balance += amount;
llInstantMessage(id, "Kaching!"; // or whatever
}

touch_start(integer n)
{
if(balance > 0) {
key id = llDetectedName(0);
llGiveMoney(id, 1);
llInstantMessage(id, "Now you can pay me back.";
balance--;
}
}

If you want to avoid someone draining you:

list clients = [];

touch_start(integer n)
{
key id = llDetectedKey(0);
if(llListFindList(clients, [id]) >= 0) {
llInstantMessage("Sorry, one try per visitor";
return;
}
if(llGetListLength(clients) >= 64) // or whatever
clients = llList2List(clients, 1, -1);
clients += [id];
...
}

Thanks, Argent. I've spent the past couple of hours trying to reverse engineer a money tree, figuring that it was a decent model to work from. Your suggestion parallels what I had decided to try next. I'll give it a shot.

It's just an idea, off the top of my head, DO test it thoroughly, I can't guarantee someone sufficiently clever can't figure out a way to drain you anyway.

#include disclaimer

Maybe pay them first and then have them pay it back immediately? Haven't tried it but it seems like it would work.

You could also remove people from the "clients" list when they paid, making it a "deadbeats" list instead.

that would save memory, too.

Thanks, everyone -- especially Argent. I built on your suggestions and created a script that has a minimal downside risk for me. It's scripted so that anyone can choose PAY from the pie menu, QuickPay L$1, and get an item. The vendor then immediately refunds the L$1, so the item is a freebie. A newbie (less than 60 days old) can touch the vendor before paying for anything and get a one-time loan of L$1. The vendor refuses to give a loan after a purchase. The way I have it figured out, any newbie gets at least one shot at it, even if s/he has L$0.

There's a risk that the newbie will walk off with my L$1 instead of buying something with it, but it's only L$1 and I have limited my potential loss, as Argent suggested, by giving the vendor a minimal balance to play with. Once its internal balance drops to zero, it won't make any more loans until I add to it. I made the clients list fairly large and avoided memory overflow by storing only the final 8 digits of an avatar's UUID instead of the whole thing.

I've spent the last few hours field testing the thing with a newbie alt. I think I've plugged all the holes, but I'll watch it carefully and see what happens.

Excellent. I would be a little concerned about storing so little of the UUID, but if you're going to do that you might as well save even more memory by converting it to integer, since 8 hex digits == 32 bits.

Is a Key actually stored as text? That's foul. (Sorry to hijack the thread.)

Yes, and yes.

Now to descend on Rolig's place with my army of 100,000 noobie bots!

Ack!!

Actually, that's what I did do, following a suggestion that I believe Heweee made a few months ago in this forum. It reduces the memory demand and lets me save a longer client list before I need to start renewing it.

oh good, because if you didn't, it's only take about 500 newbie bots =X

of course if you uncap it, it'd act as an auto limiter and crash the script limiting your losses......... ::Whistles innocently::