"Debit" message popping up when obj rezzes

Thanks, that's pretty easy then.

Only if the object came with copy perms - if it is no copy then you are hosed. A lot of high priced items (such as pool tables) come as no copy but with transfer instead.

Mine are copy. They are just vendors.

A lot of games use a Pay $1/Refund $1 method to start a free game. A lot of people that set up free games include a payout for the winner. When I've tried to set up some games with a $0 payout, they didn't reset correctly when trying to announce the winner because the code choked on being asked to pay $0.

Any of these can be a reason why the game would need debit permissions for freeplay. If you are configuring the pay-in/pay-out amounts in a notecard, the code has no idea in advance what those will be and will ask for the permissions when rezzed.

The only reason this is done this way is because you don't want to bug the owner for debit permissions upon first pay-out, it really has nothing to do with reading unknown amounts from a notecard as I am sure you meant to say.

For the benefit of everyone reading:

You can simply decide to not ask for debit permissions and change state to a state that has no pay handler defined for no a pay system, that will give you no way to pay in and no need for pay out. There is no technical reason not to do it this way except that the owner will get bugged for debit perms when the first pay-out is given when configuration in such a fashion. It is better to bug them at rezz time as Argos said.

You do know llSetPayPrice is not a secure way to prevent wrong pay amounts? all it does is send a mesage to the viewer what fields to show in the quickpay box but viewers can ignore it and still make it posible to pay other amounts, I had plenty of attempts of someone paying vendors 1L$ when llSetPayPrice was used to only show the buttons with the right amount.

If it's xfer/no-copy, you can transfer it to a friend or alt and have them start it up, and then pass it back to you.

Trusting the seller is far more important than trusting the creator.

For example, there are plenty of products out there showing my name as the creator, which I did not create.

Even if the same person is listed as creator of the object and all its contents, and everything is no-mod, you can't be certain that the stated creator actually wrote the code in the scripts.

Switcharoos often happen unwittingly, too. I got a note from B&B to please stop distributing a freebie script with Craig Altman listed as the creator. My bad!

Make sure you trust whoever you got it from.

It could be scripted to take permissions after reading the configuration and before the first payout is given. But many devices aren't made this way -- often because the free option was an afterthought.

I have a tipjar that gets debit permission right away. If someone used it as a venue tipjar rather than a dancer tipjar, the debit permission wouldn't be needed, but that wasn't the intended purpose.

Another reason for doing it first is so the owner, when setting up a bunch, can get one started and move on to the next, while the last one reads its configuration.

But the main reason is simplicity.

Right, Abigail, and this is clearly documented for llSetPayPrice() ... or at least, it was back when I learned to use it.

(Sorry, I lost track of this thread for a while.)

Yeah, a script cannot trust that the money() event will get any of the amounts specified in llSetPayPrice(). However, assuming the script specifies just appropriate buttons and a FALSE "price" argument to llSetPayPrice() it is impossible to *innocently* pay the wrong amount. The point is that it would be just frightfully sporting of a script to give back improper amounts to users who are trying to trick it using hacked viewers; personally, I'm just not nice enough to request debit permissions in order to conveniently make change for scammers.

Good point!