details on resolved fastpay loophole

The original thread in which the llSetPayPrice()-related bug was discussed has been closed. I'm not interested in starting drama here, but now that the bug has been resolved, I want to share the details that I figured out.

It seems that before one of the recent updates (1.10 maybe?), if a script used llSetPayPrice() to force a user to be able to pay only a certain amount, it was possible for the user to work around this and pay any amount they chose. They simply would minimize the payment dialog, and when it was restored, it would have all of the default payment buttons visible, and the dialog for entry of an arbitrary amount.

This, combined with a vendor script that relied completely on llSetPayPrice() and did not verify the amount of money it had received, would result in the possibility for users to get nearly free items out of some vendors. This bug only caused a problem if scripts did not check to make sure they received the proper amount of money for an item. The vast majority of scripts did not have this problem, and were unaffected.

There was no problem with the money event that I could see; the payment-amount argument to the "money" event was always accurate.

Now, there is no minimize button on the payment dialog, so the issue, presumably, is fixed.

Interesting. I suppose the lesson is "always count the money first".

Now, if only there was some way of checking whether something had been successfully received into someone's inventory....

hmmm... I wonder if this could become reality. you know how when you give something to someone, you get the "x has accepted your inventory offer"?
I am sure there is a way to almost replicate this with a vendor, seems like there would be at least....

Thanks for sharing this info.