See if this works for you, too? =)

## Answered - Thanks!! ##

Heyy.. I modified a One Person Vendor script, to make it a Multiple Person Vendor Script. Left the original credits of course =p I don't really care if its the "best" script, so long as it'll work with several people buying the contents. I also added in the PAY_HIDE, etc, so that the likelyness of people paying the wrong price is reduced.

Script makes it so the item doesn't even need to be placed for Sale. Could you try it out, too, and see if it'll work? Works for me, but thought to let you Techies give it a crack too!

//Title: Multiple Person Vendor (Originally One Person Vendor)
//Date: 01-28-2004 04:38 PM
//Version: 1.0.0
//Scripter: Ama Omega
//Modified: Malina Chuwen 9-27-08
//
integer price = 10; // adjust accordingly
string item = "Object";

default
{
state_entry()
{
llRequestPermissions( llGetOwner(), PERMISSION_DEBIT );
llSetPayPrice(PAY_HIDE, [10, PAY_HIDE, PAY_HIDE, PAY_HIDE]);
}
run_time_permissions(integer perms)
{
if (perms & PERMISSION_DEBIT)
state run;
}
}

state run
{
money(key id, integer amount)
{
if (amount != price)
{
llWhisper(0,"Sorry! The price is $" + (string)price);
llGiveMoney(id,amount);
}
else
{
llGiveInventory(id,item);
}
}
}

what makes it a multiple person vendor?

Or rather, what made it a one-person vendor? With such a simple set-up there's not much reason to make it one-person only.

So it works or no?..

What MADE it a One Person Vendor is easy enough to figure out. It had the scripts in there to limit it, and place in the 'who'. Therefore making it Multiple is easy to figure out too - I took it out.

I've not tested it but it certainly looks as it will work. One thing that puzzles me, though.. what's the point of setting up a procedure to refund someone's money should they pay the incorrect amount when

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

ensures they can only pay what you ask for?

I tested it as is and it worked just fine.

But then I reduced it to the minimum of what you need:

integer price = 10; // adjust accordingly
string item = "Object";

default
{
    state_entry()
    {
        llSetPayPrice(PAY_HIDE, [price, PAY_HIDE, PAY_HIDE, PAY_HIDE]);
    }
    
    money(key id, integer amount)
    {
        llGiveInventory(id,item);
    }
}

As was previously mentioned, there is no need for debit permissions when using only FastPay.

Because on a previous Scripting thread of mine, I got yapped at for NOT having it. Stating that it is possible to pay the incorrect amount. Etc etc.

Debit permissions don't bug me But thanks Cheree! Am glad it works, lol.

Debit permissions bug me unless I can see the source code. There are very few people I trust enough for that. I know too much about scripting to blindly trust scripters.

heyas;

because it IS still possible for someone to (inadvertantly or not) pay the wrong amount, even using pay hide.

if they manage to pay something else then the popup you get with llSetPayPrice(PAY_HIDE, [price]) then they`re trying to cheat the system as how hard is it to click a button instead of finding ways to pay the object any other way then obvious?

same boat as Cheere, debit permission items vanish into the trash bin, main reason i think onrez isn`t popular (i`ll be damned to grant debit for a store)
hippo however, i trust Andy
with the money tree i scratched my head for a moment if to go trough with it or not

i`d strip out the debit permission tbh

Since you CAN see the code for this script.. What's the issue?

Anyway, question answered!

The llSetPayPrice() boxes don't always load right away, so it's possible for someone to choose pay and get the default pay-dialogue. I've not had it happen in a long time, but it's bad-practise to just assume that llSetPayPrice() covers all your bases, especially when in essence it is a /suggestion/ to the viewer and nothing more.

true, but if they managed to pay in any otherway, they can IM instead of having a dozen debit boxes around

got a genetic hatred against debit permissions and rather control payouts by hand

The problem isn't really debit permissions as such, but the fact we can't control them in any way as users. I've a JIRA on this issue:
https://jira.secondlife.com/browse/VWR-3387

If you don't like 'em.. They don't use 'em!

Easy, no? Just because you see something posted, doesn't mean you gotta use it. So, really, why fuss over something you aint gonna use anyway? Just move on!