Request Function llGiveMoneyWithPerm

Dear Linden,
I'm a LSL Scripter.

Unfortunately, function llGiveMoney have a problem.
Many bad users use it for take all L$ from an agent, with a bastard script with for loop llGiveMoney(llGetCreator(),1) method.

We need one more function:
llGiveMoneyWithPerm(key dest, integer amount)

This function DO NOT need a PERMESSION_DEBIT permissions.
Every time it is called, it show a dialog GRANT/DENY with a message "The script take "+(string)amount+"L$ from you, it is ok?".
If users click "GRANT" is called event runtime_permissions with a new permission PERMISSION_DEBIT_ONCE!

Thanks to this function the user know how many L$ script take from him!

Example (EVERY time (not once) you touch object, script shows you a popup):

default {
touch_start(integer num) {
llGiveMoneyWithPerm(llGetCreator(),1); // Show popup with amount = 1 and dest = llKey2Name(dest)
}

runtime_permissions(integer perm) {
if(perm & PERMISSION_DEBIT_ONCE) {
llSay(0,"Thanks you!";
}
else {
llSay(0,"You don't pay!";
}
}


DEAR READER, IF YOU ARE AGREE WITH THIS NEW FUNCTION, PLEASE VOTE THIS POST WITH A REPLY!

Its very important for SL's residents make something to protect their moneys!!!
Giulia Gianus

I am a LSL scripter too and I totally agree with you.
We need the function you said.

Kathrine Slade

While I support your cause to have this function implemented, truthfully I can't really ever see myself using this function. Most of the scripts that I write that use PERMISSION_DEBIT would need to function even when the owner is not online. Camping Chairs, Tip Jars, Employee Wages, Vendors that return inexact change, etc.

I plenty agree and support MarcoDuff request.
We need increased security functions to still tour inworld with money in pocket
too many con men around...

thank you

For that kinds of method the function llGiveMoney is ok!

The funcition llGiveMoneyWithPerms DO NOT override llGiveMoney. It is another function.

For gambling machine (es.: slots) or camping chair existstent function llGiveMoney is indispensable!

For other kinds of objects we need a one time permissions.
Example: an object that with 1L$ changes a text over avatars' head. In this case, if you use a llGiveMoney, you need a PERMISSION_DEBIT. If a bastard scripter inserts a for loop for llGiveMoney with ONE grant he takes all your account's money!
With my PERMISSION_DEBIT_ONCE every time you call function llGiveMoneyWithPerms you must grant a popup that says who and how much you pay.

llGiveMoney must continue to exists (for camping chair or other), llGiveMoneyWithPerms is ANOTHER functions that adds security and clarity.

(Ummm... Interesting that this issue should prompt so many first-time forum posters, don'tcha think?)

If one wanted this to be considered, it should be requested on the jira, not the forums. But it's doomed anyway, because introducing this function couldn't replace the existing use of PERMISSION_DEBIT for the reason Milambus cited, so it's rather like trying to stop handgun violence by demanding the invention of pointy sticks.

One thing that might help would be to give residents the ability to somehow revoke all granted permissions. Of course, anyone who'd set out vendors wouldn't want to use such a feature, but for others it might be useful.

But... something else is very confused here. The majority of residents have no reason to ever grant PERMISSION_DEBIT; the specific functionality described by the OP seems identical to the operation of llSetPayPrice() and the money() event.

No. llSetPayPrice() and the money() pays only the Owner of an object. llGiveMoney(llGetCreator(),amount) is not possible with only llSetPayPrice() and the money().

I don't want to REPLACE PERMISSION_DEBIT (it is indispensable for many kinds of object - camping or gamblign object for example).
I want to ADD new permission (PERMISSION_DEBIT_ONCE) for adding new features in security and clarity!

Example:
Can you make an object that an agent can wear and with a chat command (example: -setText Hi World!) puts a text over your head with a costs of 1L$ to the Creator's object?

My response: no, you can't... with PAY the moneys goes to owner, with llGiveMoney (and grant PREMISSION_DEBIT) moneys can go to creator, but bastard script can steal all you money!

Okay, I get it: the problem is gambling devices. (Or maybe extortion to turn "bling" off for a fee. )

In that case, I'm glad the request was posted here instead of the jira, where the following would be impossible:

Qie votes "no."

No, the problem isn't in gamblin device!
For gambling device, PERMISSION_DEBIT for the owner of device and PAY for users that use the device!
In gamblig devices, like Milambus Oh says, the new function llGiveMoneyWithPerm don't works (owner MUST be always online and MUST grant every transaction)!

I remember:
with llGiveMoney the popup DON'T shows how many moneys you pay!
with llGiveMoneyWithPerm the popup shows how many moneys you pay!

This function only improves security and clarity!

This doesn't sound too horrible to me.

Imagine, for example, a gun-based RP area with weapons that charge you for more ammo. Want to keep playing? Pay L$2 or something for some more ammo.

With the current system, I'd be very wary of granting a weapon/hud/whatever debit permissions. With the proposed system, I'd be much happier with pop-up saying that some object is requesting a one-time debit of some specific amount of L$.

/me will take the annoyance of more pop-ups if it means more security.

Just to clarify: new gambling devices are HUDs, to get around the Linden restrictions on promotion of online gambling, by which they're trying to show compliance with US law.

But I think I see a related need that might be addressed by a more general solution. It would be very nice to be able to pre-load some L$s into an object to be sure it can pay (only) up to that amount--even if the owner has a L$0 balance (the simplest example is the dreaded camping chair, but this problem comes up repeatedly, caused in part by the lack of an error code from llGiveMoney). So if one could Pay an Object instead of its Owner, and that object could then transfer up to that amount to another agent under script control... would that handle both needs? Or does this introduce some other security problem?