Skill Gaming Policy Thread

[Coby Foden]

---

Tex Monday wrote:

---

MsJS Bagley wrote:

it means you have to have "payment on file" 

---

 Thank you...but LL answered my question two posts down from when I asked it

---

This thread clearly is getting too long. Soon nobody remembers what has been said and what not.

Thus it will start all over again.

 

:smileyvery-happy: :smileywink:

[Snickers Snook]

Wow am I having deja vu all over again with this. Zindra, adult content, lather, rinse, repeat. Linden Lab constantly amazes me at every turn. Just ignore the people who really pay the bills (regular users) and make things impossible for the little guys.

Why not just say "No more gaming. No more fun. We're closing the SL grid down and selling what's left to Sony or nVidia or somebody. Oh and by the way, your real names are going to be sold to the highest bidder."

To quote Forrest Gump - "Stupid is as stupid does."

So long and thanks for all the fish.

[DerekShane]

As Operators, we're getting a lot of information that's helpful. One thing we've gotten clarified and the FAQ has been newly updated is about Freeplay games. On most games, even Freeplay requires a L$1 payment that comes right back to the player, so is that still within the scope of the policy? Answer is No. We asked hoping other places in SL would be able to benefit as well (we've done that with several things that are now in the FAQ). 

Are “freeplay” games in Second Life subject to the Skill Gaming Policy?

Freeplay games, in which the sole payment required or permitted is a nominal Linden Dollar payment for the sole purpose of triggering gameplay and is immediately and automatically refunded without conditions of any kind, are not within the scope of the Skill Gaming Policy.

http://wiki.secondlife.com/wiki/Linden_Lab_Official:Second_Life_Skill_Gaming_FAQ#Are_.E2.80.9Cfreeplay.E2.80.9D_games_in_Second_Life_subject_to_the_Skill_Gaming_Policy.3F

Considering that most plays are L$25 or L$50, we're talking about US $0.10 or US $0.20 so a lot has gotten blown out of proportion. We find most people just want to have some fun and relax and play some games and hope this process will continue to go smoothly and Residents who enjoy playing will be able to continue to have fun.

[Phil Deakins]

That's interesting, Derek. I have a question about it. If the games are free to play, why do they require a payment to get the game going?

Another question: Is the amount to pay in settable by the operator? And can the operator of these games set whether or not the enty fee is immediately and automatically refunded?

My thinking is that, if a freeplay game requires money to play, and if the operator can set the game so that it doesn't immediately and automatically refund the entry fee, then, if the game pays out according to the result, it must be subject to the new policy, even though an operator may operate the game in the way you described.

I'm not familiar with these 'freeplay games'. That's why I'm asking.

[DerekShane]

Hi Phil, Maybe a Creator can jump in with the why, but most games have always required the L$1 payment. It's immediately refunded and that can't be changed, it's the setting for Freeplay. Maybe there was some technical requirement way back when.  Aargle made Zyngo's Freeplay mode where you just click it but  players get confused because everyone is used to the L$1 payin.

If our friends at Linden are still reading, on Transaction History, we wish there was a box to uncheck for "Show L$1 Transactions" the way it currently has it for "Show L$0 Transactions" because they take up tons of space and slow the engine down.

Of course you're right, if the Skill Game definition is met, it's part of the Policy. Our point was Freeplay games really are Freeplay, just with a technical requirement. Linden kindly clarified with exactly the definition of how most Freeplay games operate in Second Life.

[Phil Deakins]

With payouts, it's necessary for an object to get permission from the owner to take L$ from his/her account. I wondered if, having given that permission, an object can't be sat on (I have table games in mind) without paying it - or something like that.

[Tex Monday]

---

Coby Foden wrote:

This thread clearly is getting too long. Soon nobody remembers what has been said and what not.

Thus it will start all over again.

 

 

---

 That...and we haven't seen hide nor hare of a Linden in at least 50 pages. We should all just give up on this and wait to see what happens with the new policy. The Lindens were great for a while, answering questions and all that...but when they realized that there were SO MANY questions, they ducked into the nearest broom closet and disappeared.

Let's end this already.....PLEASE

[Phil Deakins]

My thinking is that LL stopped posting when all the questions had been asked. If they'd continued, they would only have been asnswering the same questions, and the answers were already here. Since then, the thread has just been a general discussion of it.

[Innula Zenovka]

---

Phil Deakins wrote:

With payouts, it's necessary for an object to get permission from the owner to take L$ from his/her account. I wondered if, having given that permission, an object can't be sat on (I have table games in mind) without paying it - or something like that.

---

That can't be it.

A script can only take money from the account of its owner, for which it needs the owner's permission.   The only circumstances in which a script in a game needs debit permissions is when it will have to pay out to the players.   The owner is the only person who can give the script debit permissions, of course; the script can't ask the players for permission to debit their accounts.

I can't see any reason for charging players a L$1 fee and then immediately paying it back.   I can't see what it achieves that simply having them touch the object wouldn't, except that they might touch the object by mistake or out of curiosity, while they would need to intend to pay it, but I don't really see why that would matter in this context.

Maybe it was some sort of half-cocked anti-bot measure, like shouting !QUIT at them.   No one said popular scripting ideas had necessarily to be good ones.   

 

 

[Phil Deakins]

You appear to have misread what I wrote, Innula

 

[Innula Zenovka]

---

Phil Deakins wrote:

You appear to have misread what I wrote, Innula

 

---

Did I?    While it's not possible to script something so you can't sit on it, it's certainly possible to script it so it will immediately unsit you unless you've previously paid into it, just as it's possible to script it so it will unsit you unless you've previously touched it, or said /99 hello to it, or any number of things that will give it your uuid beforehand, so it knows whether to kick you off or not.

However, that's got nothing to do with the script having PERMISSION_DEBIT.   The only circumstances in which a script needs to have PERMISSION_DEBIT are when it needs to pay money to people.  

[Phil Deakins]

You wrote that only the owner can grant debit permissions to an object, and in such a way that I'd said something different, when I'd actuallu said that it's the owner who gives that perrmission. That's what you appeared to misread or misuncerstand in my post. Or one of us is misreading the other's post

What I was getting at is whether or not, once the object has that permission, it expects a user to pay it. I don't remember ever writing a system where money is involved, so the fact that freeplay games require an amount to be paid made me wonder if there was something I don't know in that area.

 

[Innula Zenovka]

---

Phil Deakins wrote:

You wrote that only the owner can grant debit permissions to an object, and in such a way that I'd said something different, when I'd actuallu said that it's the owner who gives that perrmission. That's what you appeared to misread or misuncerstand in my post. Or one of us is misreading the other's post

What I was getting at is whether or not, once the object has that permission, it expects a user to pay it. I don't remember ever writing a system where money is involved, so the fact that freeplay games require an amount to be paid made me wonder if there was something I don't know in that area.

 

---

No, an object with PERMISSION_DEBIT doesn't expect a user to pay it. 

 

integer maxPayout = 10; //how much in total I'm prepared to give away;integer counter;integer havePerms;default{	state_entry()	{		llRequestPermissions(llGetOwner(),PERMISSION_DEBIT);	}	run_time_permissions(integer permissions)	{		if(permissions & PERMISSION_DEBIT){			havePerms = TRUE; //record the fact I have debit perms, so I don't keep having to check		}	}	touch_start(integer total_number)	{		if (havePerms){//if I've got debit permissions			if (counter<maxPayout){ //and if I've not yet given away all my L$10				llTransferLindenDollars(llDetectedKey(0),1);//give the toucher L$1				++counter; //advance the counter			}			else{				llRegionSayTo(llDetectedKey(0),0,"Sorry, but I've given away all my money for the time being");			}		}	}}

 That script doesn't expect the user to pay anything.

It's the other way round, really.   Many scripts that expect the user to pay them allow for the possibility that they will have to debit money from the owner's account , for example to pay a commission to a business partner, or to issue a refund if the customer pays the wrong amount (a very dangerous and unnecessary practice, but that's not the point).   

If a script expects to be paid something, it needs to include a money event, which fires when someone pays the object money.   It only needs debit permissions if it expects to give money away to someone. 

[Yingzi Xue]

Without debit permission, a script can't pay out from the owner's account.  Debit permissions is typically requested at the start of a script, to which the owner must Allow or Deny via a dialog window.  If the dialog is ignored, the script is denied access to the owner's account.  How the owner responds determines whether the script can pay out or not.  If you want a script to be able to pay out or refund, debit permission has to be granted, so the script can access the owner's account, otherwise it's not possible.  Paying in has nothing to do with debit permission, unless you consider the relationship between the two; that refunding a pay in is dependent on debit permission so that the refund can be paid out. 

 

Typical uses of debit permission:

 

• Refund if some requirement isn't met, since there's no way to restrict payment to a script before-hand.
• Commission pay or split profit pay, since only the owner is paid, others need to be paid after the fact from the owner's account.
• Discount percentage pay back after payment and certain requirements are met (group tag, for instance).
• In the case of games, pay out of winnings.

 

Here's a similar example, for a discount percentage if group tag is active:

 

float   discount = 25.0;integer debit_granted; default{    state_entry()    {        llRequestPermissions(llGetOwner(),PERMISSION_DEBIT);    }      run_time_permissions(integer which_permissions_granted)    {        if (which_permissions_granted & PERMISSION_DEBIT) debit_granted = TRUE;    }     money(key avatar_key_that_paid, integer paid_amount)    {        if (debit_granted)        {            if (llSameGroup(avatar_key_that_paid))            {                integer refund = llCeil((discount/100)*paid_amount);                 if (refund > 0)                {                    llGiveMoney(avatar_key_that_paid,refund);                    llRegionSayTo(avatar_key_that_paid,0,"You've received a discount and have been refunded "+(string)refund+" L$ ("+(string)((integer)discount)+"%) for being in our group.");                        }            }             llRegionSayTo(avatar_key_that_paid,0,"Your item(s) are being delivered.");                    }         // Add give inventory code here    }}

 

In response to Derek - There is no reason for a game to require a 1 L$ pay in to play, unless you wanted to track players, but that can be done just as easily without requiring a pay in.  If a player can't take the time to read chat, IM or dialog menus pertaining to the status of the game, then they shouldn't be playing it in the first place.  Session tracking and timeout is simple to achieve in a script, to keep other players from being able to touch and affect a current game and to kick dormant players who may have stepped away.  I see the 1 L$ pay to play as lazy scripting; unnecessary and pointless.  As you said, it would clog your transaction history beyond belief.

[Phil Deakins]

"No, an object with PERMISSION_DEBIT doesn't expect a user to pay it. "

That what I wondered. So that's not the reason for the nominal pay-in. I wonder what the reason is.

 

Yes, I know that, if an object is to take money, it still needs permission to pay out from the owner's account. That's because it will need to give money to the user if s/he either pays too much or too little.

[Yingzi Xue]

---

Phil Deakins wrote:

Yes, I know that, if an object is to take money, it still needs permission to pay out from the owner's account. That's because it will need to give money to the user if s/he either pays too much or too little.

---

Normally, you try to set exact amount(s) for the pay window (llSetPayPrice) when possible, which keeps this from happening.

[Innula Zenovka]

---

Yingzi Xue wrote:

---

Phil Deakins wrote:

Yes, I know that, if an object is to take money, it still needs permission to pay out from the owner's account. That's because it will need to give money to the user if s/he either pays too much or too little.

---

Normally, you try to set exact amount(s) for the pay window (llSetPayPrice) when possible, which keeps this from happening.

---

I agree.  I will not, in fact, on principle script vendors that offer automatic refunds, because I regard it as too risky.

Instead, as you suggest, I set the exact amount in the pay window and, if the customer somehow manages to pay the wrong amount, the script tells them to contact the vendor's owner for a refund.     That's because if someone actually does manage to pay the wrong amount using a pay window with one option button and no entry box, they're almost certainly using an exploit that used to enable them to obtain refunds to which they're not entitled (I don't know if the exploit still works, but it doesn't seen worth taking chances).   

I've only once known someone to manage to pay vendors I've made the wrong price, when someone paid several different vendors L$1 each, when the selling price of each item was several hundred L$.

For some reason this person didn't ask for their money back.

[DerekShane]

Hi Yingzi, Exactly, debit permissions are granted by the object owner just when a game is rezzed; in the case of most games, that's for Freeplay or regular payin mode so perhaps the L$1 represents Freeplay when the game is expecting some sort of payment. I can't think of any game except Zyngo without that L$1 requirement. For 99% of games that currently exist, if they were covered by the Policy just because of the L$1 payin issue, Linden's now clarified that doesn't invalidate their Freeplay status. 

And yes about the clog, but that's how it's been forever. However, the new Transaction History window is more prone to crash with 20,000+ transactions per day than the old version and that's why the "Show L$1 Transactions" box to uncheck would be really helpful.

Point was the reply from Linden is good news for a lot of players because more places will be able to have Freeplay games since they aren't covered by the Policy. There's been lots of progress, we're all working directly with Linden in our cases and not posting here much. Have a great weekend!

[Yingzi Xue]

---

Innula Zenovka wrote:

---

Yingzi Xue wrote:

---

Phil Deakins wrote:

Yes, I know that, if an object is to take money, it still needs permission to pay out from the owner's account. That's because it will need to give money to the user if s/he either pays too much or too little.

---

Normally, you try to set exact amount(s) for the pay window (llSetPayPrice) when possible, which keeps this from happening.

---

I agree.  I will not, in fact, on principle script vendors that offer automatic refunds, because I regard it as too risky.

Instead, as you suggest, I set the exact amount in the pay window and, if the customer somehow manages to pay the wrong amount, the script tells them to contact the vendor's owner for a refund.     That's because if someone actually does manage to pay the wrong amount using a pay window with one option button and no entry box, they're almost certainly using an exploit that used to enable them to obtain refunds to which they're not entitled (I don't know if the exploit still works, but it doesn't seen worth taking chances).   

I've only once known someone to manage to pay vendors I've made the wrong price, when someone paid several different vendors L$1 each, when the selling price of each item was several hundred L$.

For some reason this person didn't ask for their money back.

---

It would be interesting to know what allowed them to pay a wrong amount.  If you can't keep fraudulent payments from happening, at least you can prevent a person's account from being drained with debit permission by not allowing it at all.

Also, keep in mind (Phil) that your script is only going to pay out when it's designed to do so, which means if your script is set for split profits, for instance, the script most likely won't be exploited as they're paying in more than they're getting back.

It's all in the script design and not all scripts are created equal.  You'd like to think that scripters consider these things, but I don't think that's the case most of the time.  With scripting comes great responsibility. :matte-motes-big-grin-wink:

[Yingzi Xue]

---

DerekShane wrote:

Hi Yingzi, Exactly, debit permissions are granted by the object owner just when a game is rezzed; in the case of most games, that's for Freeplay or regular payin mode so perhaps the L$1 represents Freeplay when the game is expecting some sort of payment. I can't think of any game except Zyngo without that L$1 requirement. For 99% of games that currently exist, if they were covered by the Policy just because of the L$1 payin issue, Linden's now clarified that doesn't invalidate their Freeplay status. 

And yes about the clog, but that's how it's been forever. However, the new Transaction History window is more prone to crash with 20,000+ transactions per day than the old version and that's why the "Show L$1 Transactions" box to uncheck would be really helpful.

Point was the reply from Linden is good news for a lot of players because more places will be able to have Freeplay games since they aren't covered by the Policy. There's been lots of progress, we're all working directly with Linden in our cases and not posting here much. Have a great weekend!

---

If it became such an issue for me, as a game operator, I would get with the creators and ask them to make a non-pay version so your transaction history isn't overloaded with data you don't care to see.  The fact that they didn't consider it is just mind boggling to me.

I think it's great that this clarification was made.  I'm sure it puts a lot of minds at ease.  You have a great weekend as well.

[Innula Zenovka]

---

Yingzi Xue wrote:

It would be interesting to know what allowed them to pay a wrong amount.  If you can't keep fraudulent payments from happening, at least you can prevent a person's account from being drained with debit permission by not allowing it at all.

---

I'm told it's easy enough to circumvent the options in the pay window simply by using a slightly modified viewer.

The other thing people have to remember -- obviously you know this, but some readers may not  -- is always to check 

if (payment == payPrice) 

before giving out the goods!

 

[Yingzi Xue]

---

Innula Zenovka wrote:

---

Yingzi Xue wrote:

It would be interesting to know what allowed them to pay a wrong amount.  If you can't keep fraudulent payments from happening, at least you can prevent a person's account from being drained with debit permission by not allowing it at all.

---

I'm told it's easy enough to circumvent the options in the pay window simply by using a slightly modified viewer.

The other thing people have to remember -- obviously you know this, but some readers may not  -- is always to check 

if (payment == payPrice) 

before giving out the goods!

 

---

Most definitely.  I always check for price vs paid amount.  One can almost obsess about safeguards for scripts.  I know I do.  Most times I go overboard, but a few extra bytes are worth the peace of mind.

[Sorina Garrigus]

Are “freeplay” games in Second Life subject to the Skill Gaming Policy?

Freeplay games, in which the sole payment required or permitted is a nominal Linden Dollar payment for the sole purpose of triggering gameplay and is immediately and automatically refunded without conditions of any kind, are not within the scope of the Skill Gaming Policy.

 

Thank you LL for finally clairifying this very clearly. It was clear to me all the long when the big picture is looked at. The fall out would have been horrendous otherwise killing content going back a full decade

And thanks to the trolls and pointless arguers for all the post saying this was not the case and claiming, or in my book lying (responses completely from ones buttocks is still a lie in my book), Hopefully those individuals can now try to have productive posts. Please try not to flood the forum with arguments purely for self entertainment. This is a complex issue and people need to see the big picture and the "sit back and eating popcorn" mentality in the forums is not helping anyone. If people are that bored go explore SL. Its a heck of a lot more fun and interesting than any forum.

[Sorina Garrigus]

---

Yingzi Xue wrote:

---

---

---

It would be interesting to know what allowed them to pay a wrong amount.  If you can't keep fraudulent payments from happening, at least you can prevent a person's account from being drained with debit permission by not allowing it at all.

Also, keep in mind (Phil) that your script is only going to pay out when it's designed to do so, which means if your script is set for split profits, for instance, the script most likely won't be exploited as they're paying in more than they're getting back.

It's all in the script design and not all scripts are created equal.  You'd like to think that scripters consider these things, but I don't think that's the case most of the time.  With scripting comes great responsibility. :matte-motes-big-grin-wink:

---

Being able to attempt to pay a false amount is a VERY VERY old exploit. It is usually done with "hacked" viewers or customer viewers none of which are legal to use in SL. I believe (I never seen such a viewer in action) the pay window with the fill in your own amount block pops up and they put in a different amount. There was also reports of a viewer that was able to pay L$0 somehow. Scripters need to ALWAYS check pay in amounts for anything that accepts money

 

 

[Phil Deakins]

---

Yingzi Xue wrote:

Also, keep in mind (Phil) that your script is only going to pay out when it's designed to do so, which means if your script is set for split profits, for instance, the script most likely won't be exploited as they're paying in more than they're getting back.

---

My script is going to do not such thing. As I said earlier, I don't remember ever writing any scripts that deal in money

I merely wondered if a script that gets the owner's permission to take money from his/her account expects a user to pay in. The answer was posted and it was no, so I really don't know why all the discussion about debit permissions has continued.